Kudos to Boris Cherny and Claude Code
The terminal-first approach that changed coding
Claude Code didn’t just change how developers write code—it exposed how the entire industry was thinking about the bigger picture of AI coding tools wrong. The failure mode wasn’t weak models. It was constrained interfaces. While Silicon Valley poured billions into making IDEs “smarter,” Boris Cherny was building something that looked like a step backward: a terminal agent that used basic file operations instead of using semantic search and being an IDE plugin. It turned out the “primitive” approach was exactly what AI needed to scale.
Most people don’t know much about how Claude Code was built. Cherny—a former Meta principal engineer and author of “Programming TypeScript”—started it as an internal side project at Anthropic in late 2024. What began as filesystem experiments evolved into a terminal agent that could read files, run tests, commit code, and even open pull requests autonomously.
The Contrarian Bet
When Cherny started experimenting with filesystem access in September 2024, he was betting against what seemed like inevitable technological evolution. The path forward appeared obvious to everyone: IDEs were getting smarter. Cursor was the poster child—take VS Code, add AI capabilities, raise venture money, repeat. GitHub Copilot had proven the model worked at massive scale. The entire industry was following the same logical progression: IDE → Smart IDE → Even Smarter IDE.
This wasn’t just consensus—it was common sense. Developers already lived in their editors. They had muscle memory, customized workflows, and thousands of extensions. Why would you ask them to learn something new when you could just make their existing tools more intelligent? Every serious AI coding company was building enhanced IDEs with better autocomplete, smarter chat interfaces, and more sophisticated code understanding.
Cherny made two contrarian bets to solve this. First, instead of building within IDEs where the AI was limited to whatever files you had open, he put it in the terminal with access to the entire filesystem. This simultaneously eliminated the problem of writing a different plugin for every IDE. The distinction matters more than it sounds: an IDE plugin is a guest in someone else’s house, having to ask permission to see files, struggling to interact with the compiler, sandboxed from the broader environment. The terminal isn’t an interface layered on top of the codebase — it’s the environment itself.
Second, instead of the RAG systems that everyone assumed were necessary for AI to navigate large codebases, he used simple file operations—letting Claude read files directly, follow imports organically, and grep for patterns the way experienced developers actually explore unfamiliar code. The difference is fundamental: semantic search asks “find me code that feels like a login controller”; grep asks “find me the exact line where this constant is defined.” For most working codebases, the latter wins. Code is a graph of explicit dependencies, not a cloud of vibe-based embeddings.
Both choices looked primitive compared to the sophisticated approaches others were building. Why give up the rich IDE context to work in a “dumb” terminal? Why use basic file operations when semantic search seemed so much more advanced? The whole approach looked like a step backwards to anyone focused on making existing tools smarter. But that framing assumed the IDE was the right foundation to begin with. What if the IDE itself was the bottleneck?
No VC firm would have given you a nickel to make such a product. The pitch deck would have been laughed out of Sand Hill Road: “We’re going to ignore IDEs, skip the sophisticated AI techniques everyone else is using, and build a command line that looks like something from 1980.”
It was not buzzword compliant and had all the hallmarks of something that seemed amateurish compared to the well-funded competition.
IDE plugins, for all their richness, introduce real friction for autonomous agents: context windows limited to open tabs, integration tax across every different editor, and retrieval systems that add latency. A terminal agent sidesteps all of that — full repo access, composability with Unix tools, and a lightweight loop of think, act, observe, fix.
Why It Worked
Richard Gabriel called this “Worse is Better” in a famous 1991 essay — the argument that simple, imperfect solutions often win because they’re easier to adopt and iterate on than theoretically superior alternatives. Claude Code is a textbook case. Cherny built the first working prototype during his first month at Anthropic — not as a formal project, but as a quick hack to learn the company’s internal APIs. This was not a two-year research initiative. It was one engineer, moving fast, finding something that worked. Within two months of that first prototype, a dogfooding-ready version shipped internally. According to accounts from Cherny’s own interviews, adoption was explosive — a large fraction of Anthropic’s engineering team was using it within days. That virtuous cycle—real users, fast feedback, quick improvements—is hard to replicate in a more complex system where every change requires rethinking the retrieval architecture or the IDE integration layer.
I’ve witnessed this phenomenon firsthand: a single developer lapping an entire team of PhDs from a well-funded competitor. It happens more than people admit. The solo developer makes better engineering tradeoffs, because engineering is an artistic skill and ultimately a balance of schedule, quality, and cost. The PhD acquisition process teaches one to optimize for theoretical elegance and publication worthiness. The solo developer optimizes for shipping something that works.
Cherny’s approach gave him the freedom to move fast, learn from actual usage, and improve continuously. The sophistication came later, once the foundation was proven. That’s almost always the right order.
The Hammer and Nail Problem
Once a sophisticated technique is known, it’s easy to imagine it as part of every solution. This is an old problem in computer science.
To a hammer, everything looks like a nail.
In the early days of compiler design, LR parse generators became the mandatory approach for building language front-ends. If your language wasn’t LR-compatible, it was considered poorly designed and had to be contorted to fit the tool. This orthodoxy arguably stifled programming language innovation for years, forcing elegant language designs into awkward grammatical constraints just to satisfy the parser generator du jour. Nobody worries about LR compliance anymore.
There was an even more extreme period when program provability became a requirement for programming language design. The joke making the rounds was: “Let me design a language where you can’t do anything, and I’ll prove that you didn’t do anything.” Theoretical elegance trumped practical utility, and the languages that emerged were often unusable for real work.
The RAG obsession in AI tools follows the same script: a sophisticated technique becomes orthodoxy, practical alternatives are dismissed as primitive, and everyone builds around the approved approach regardless of whether it actually solves the problem at hand.
The Future of Code Understanding
The final chapter of this story hasn’t been written. RAG and other sophisticated techniques may yet play a significant role—and may already be quietly incorporated into newer versions of Claude Code. As context windows continue to expand, the calculus may shift again — if a model can see an entire repository at once, the terminal agent approach may become even more dominant, or evolve into something we haven’t imagined yet. But that doesn’t diminish what Cherny accomplished: he found a powerful solution to a problem the industry at large had missed entirely.
In a market obsessed with scale and fundraising, Claude Code is a reminder that the binding constraint on AI tools isn’t model capability — it’s the interface that wraps it. Give the model the right environment, with real access to real things, and get out of the way.