Boris Cherny, creator of Claude Code, sits down with Alex from Claude Relations to trace how coding changed in a single year — from copy-pasting snippets out of a chat window to running an agent in the inner dev loop. The throughline is the tight instruct → edit → test → verify feedback cycle: the models and the harness coevolved because Anthropic engineers dogfood Claude Code every day, and the truest "eval" is just doing real work and checking the vibes. Boris closes with two hands-on best practices for using Claude Code well.
Alex opens by asking Boris to catch everyone up on how fast the coding domain has moved. Boris frames it starkly: a year ago, writing code meant an IDE with some autocomplete plus a separate chat app you'd shuttle code back and forth from — "that was the state of the art, that was AI in coding." Around a year ago, agents began to appear as something people earnestly use, not a gimmick or a prototype, but an actual part of the inner loop. The core shift is from directly manipulating text to having the model do the text manipulation for you, and Boris sees that trajectory continuing into the future.
People had tried to automate coding for years and it hadn't worked, Boris says, for two reasons: the models weren't good enough and the scaffolding on top of the model wasn't good enough. The earliest Claude Code shipped on Sonnet 3.5 (before the upgraded version) and was only good for maybe 10% of his code — yet the day after he handed it to the core team, engineers like Robert were already using it. Over the last year the model got dramatically better at agentic coding (3.7, then 4.0 and Opus 4.1) and the harness improved in step. He reaches for a memorable analogy: the model is a horse, and the harness — Claude Code — is the saddle that lets you steer. Concretely, the harness is the system prompt, context management, tools, MCP servers, settings, and permissions: everything that interfaces with the model behind the API and shapes how well it performs.
When Alex probes what "coevolve" means, Boris says it's pretty organic. Everyone at Anthropic — including the researchers who build the models — uses Claude Code to do their job every day, so they hit the model's natural limits firsthand. A low-level example: the "failed to replace string" errors that surface when the model is bad at certain edits are a model capability that can be learned from and improved. A higher-level one: letting the model "cook" autonomously. With 3.5 it might stay on track for a minute; newer models stretch that window longer and longer. Because humans can feel exactly where they have to course-correct and steer, that experience gets folded back into training so the model learns to do it itself — the instruct-edit-verify loop tightening on both sides.
Asked how he evaluates a new model or harness feature, Boris is refreshingly blunt: "I just do my work that day." His perfect day is coding all day, so he just codes with whatever new thing is being tested and sees what the vibe is. The team tried hard to build product evals — a benchmark to tell whether a system-prompt change made the model better — but honestly it's just so hard to build evals, and by far the biggest signal is the vibes: does it feel smarter? The reason matters: models are already scoring so well on evals like SWE-bench that the team hunts for harder, less-saturated ones like T-bench, but synthetic evals struggle to capture all the complexity of real software engineering. The most real-life-like eval — actually using it — gives the best result, and Claude Code's tight feedback loop delivers more immediate signal than any hardcoded eval suite.
Alex notes Claude Code has the best dogfooding cycle he's seen in any product and asks what made it work. Boris built it the way he builds anything: listen to users and make it as easy as possible to listen to them. Early on there was a single feedback channel in Slack, and he'd direct everyone there. Feedback often feels like it vanishes into a void, so the thing they did right was fix reports as fast as possible — sometimes three hours in the office burning down bugs — and then comment back to say it's fixed. That reciprocity kept people posting, and to this day the internal channel is a nonstop fire hose. His honest admission underpins it: nobody really knows what they're doing with AI yet, so the best indicator is what users want.
On the current state of the product, Boris stresses Claude Code was built to be the simplest, most hackable thing possible. The original extension point was CLAUDE.md — a context file you check into your repo, placeable in root or child directories. Over time they added a sophisticated settings and permission system; hooks (built by Dixon in response to "I want to hook into this" asks); MCP as a major extension point; and slash commands and subagents. User-defined slash commands are just reusable markdown workflows — Boris keeps one for making commits that pre-allows the git commit Bash command so the model can run it without prompting. Subagents, he explains, are "two sides of the same thing" as slash commands: a slash command with a forked context window. Looking ahead, the future is mostly about more extension points, making it easier for others to build on top, and a more useful SDK for any kind of agent — all riding on continued work to make the model more autonomous and better at following instructions.
Asked what work looks like in 6–12 months, Boris predicts a mix: still hands-on coding (using Claude to manipulate text rather than doing it directly), plus a growing bucket of less-direct work where Claude proactively makes and even reviews changes and your job is to decide if you want them. Further out (12–24 months) he expects Claude to move up the abstraction stack toward goals rather than specific tasks. His advice to people learning to code: you still have to learn the craft — languages, compilers, runtimes, how to build web apps, system design — but get more creative, because ideas that used to sit in your backlog forever can now be built in minutes. Stacks had gotten too complicated (React, Next.js, build systems, deploy systems); agents make it easy to get started again, the way BASIC on a TI-83 once did for him. And the code itself is no longer precious — Claude Code is rewritten all the time.
Boris closes with two tricks. First, if you're brand new to Claude Code, don't use it to write code yet — use it to ask questions about the codebase (how do I add a logger? why is this function designed this way?) and let it explore Git history and answer. Get comfortable with the research agent first, then start coding with it. Second, match the tool to the task by mentally bucketing work into easy, medium, and hard: easy tasks he one-shots by tagging @Claude on a GitHub issue to write the PR (freeing up his terminal); medium tasks start in plan mode (Shift+Tab) to align on a plan, then auto-accept to implement; and for hard tasks he stays in the driver's seat, using Claude for codebase research, prototyping options, or writing unit tests while he does most of the coding himself.
"But yeah, man, it's all vibes."
"The code itself is no longer precious."
"if you're brand new to Claude Code and you haven't used it before, don't use it to write code."
"no one really knows what they're doing with AI."
| Approx. Time | Topic |
|---|---|
| 0:00 | Cold open — programming answers into a TI-83 in math class |
| 0:24 | Intros — Alex (Claude Relations) and Boris (creator of Claude Code) |
| 0:57 | How coding changed in a year — agents enter the inner loop |
| 2:24 | Why it works now — better models and a better harness |
| 3:55 | What the harness actually is — system prompt, context, tools, MCP |
| 5:00 | Coevolution — daily internal use feeding back into the model |
| 6:18 | Evaluating models — "it's all vibes" and eval saturation |
| 8:56 | The dogfooding feedback loop in a single Slack channel |
| 10:47 | Hackability — CLAUDE.md, hooks, MCP, slash commands, subagents |
| 13:11 | The future — moving up the abstraction stack toward goals |
| 14:37 | Advice for engineers — learn the craft, get creative |
| 17:49 | Best practices — don't code first; easy / medium / hard tasks |
| 20:11 | Wrap-up |