Claude Code Developer: AI Has a Capability

There is a version of the current AI moment where the tools are already good enough and the bottleneck is us. That is the argument Thariq Shihipar, who works on the Claude Code team at Anthropic, made at a San Francisco gathering organized by Greg Kamradt and Deedy Das of Menlo Ventures in late June 2026. It is not a comfortable argument for an industry that prefers to frame every limitation as a model problem waiting for the next training run to fix.

Shihipar's framing is worth sitting with. He calls it "capability overhang" — the gap between what AI models can actually do and what users are getting them to do. His claim is that this gap is large and that the responsibility for closing it sits squarely with the humans on the other side of the prompt.

"We sometimes oversimplify agentic engineering where we're like it's just prompts, it's just loops or whatever," he said. "And I think it's more like no, we need to know what we're doing. We need to learn more and then be better at prompting and make sure we're creating valuable work."

That is a more demanding position than the industry typically advertises. Most AI marketing promises effortlessness — describe what you want, receive what you imagined. Shihipar is saying the opposite: the model has depth, and accessing that depth requires skill you have to develop. The intent gap that derails enterprise AI deployments shows up at the individual level too, just with a different name.

The Pokemon Illustration

To make this concrete, Shihipar walked through a specific example: asking an AI model to list all Pokemon whose names end in a particular sound. Straightforward enough question. The answer, according to Shihipar, is two — and he named them from the talk. An AI assistant asked directly, he argued, will likely get it wrong, not because the model lacks the underlying knowledge, but because it is trying to retrieve from memory rather than compute.

The fix, he said, is to give the model a code execution tool and ask it to write a script. Claude Code, he noted, will write code to pull the complete Pokemon list, run a filter, and return a verified answer. One line of code, correct result. The model was never the problem; the interface was.

"If you're an average user, you just don't have the ability or the skill of understanding Claude well enough to be like, how do I prompt it better? How do I give it the tools needed?"

This is where the argument gets interesting and also where it invites pushback. Shihipar is essentially saying that effective AI use is a craft skill — closer to writing or public speaking than to operating a microwave. That is probably true. It is also a claim that cuts against a decade of UX philosophy built around reducing friction for ordinary users. The question of what developers are actually worth in this environment is partly a question about who develops this craft and who does not.

Models Don't Get Smarter in a Straight Line

One of the more intellectually honest things Shihipar said concerns how model improvement actually works. The standard mental model — bigger context window, smarter outputs — turns out to be wrong in practice. He used the evolution of AI coding tools as an example: people assumed models would get better at coding by ingesting larger and larger codebases in a single context window. Instead, the gains came through tool calling, bash access, and structured agent loops. Nobody predicted that specifically. It emerged.

"Models don't get smarter in a straight line. They get smarter in unexpected ways."

This matters for how practitioners think about building on top of these systems. If improvement is spiky and emergent rather than linear and predictable, then the mental models you built last year may actively mislead you this year. The format that unlocks a model's capabilities today — he cites the shift from markdown to rich HTML reports as one example from his own work — is not something you can derive from first principles. You discover it by doing.

This also complicates the narrative that AI coding tools produce minimal quality gains. The honest answer may be that quality gains are highly variable depending on how sophisticated the practitioner is. A slot machine and a piano both have keys. What you get out depends considerably on what you know.

The Unknown Unknowns Problem

The most practically useful section of Shihipar's talk concerned what he calls grounding down unknown unknowns. He illustrated it through his experience using Claude Code to edit video — a task most people would not think to assign an AI coding tool.

The workflow he described: raw video clips from a shoot, a transcript of what he intended to say, and Claude Code given the task of transcribing each clip, identifying the best cuts, assembling them, and generating React-based UI overlays to compile into the final product. He does not use a human video editor for this. The first pass was adequate. The second was better. The difference came from color grading — a domain he knew nothing about.

His process for closing that gap is worth noting. He asked Claude to explain color grading, received an explanation that did not actually help him understand it, and kept pushing — requesting visualizations, asking follow-up questions, demanding examples. Eventually the model framed color grading as analogous to a shader: you take in a pixel value, you output a different one. That mental model clicked because he already understood shaders. From there he could express what he wanted, and the model could execute.

The temptation, he acknowledged, is to treat the initial AI-generated explanation as sufficient — to skim it, feel informed, and move on. He called this "education porn." You feel like you learned something. You did not learn enough to act differently.

The honest version of agentic engineering, by this account, requires you to actually understand what you are building well enough to know when something is wrong. Not to implement it yourself, but to recognize the gap between the output and what good output would look like. That is a non-trivial skill, and it is one that scales with domain knowledge you already have — which raises obvious questions about who benefits most from these tools. The value question does not disappear just because production costs fall; it relocates to whoever can recognize quality.

The Structural Work That Doesn't Go Away

During the Q&A, an audience member pressed Shihipar on something worth examining directly: agentic engineering workflows start to look a lot like traditional waterfall software development. Interview the user, write specifications, implement, test, iterate. Is the methodology actually new, or is it old wine in a new interface?

Shihipar's answer was honest rather than defensive. He recommended building cheap HTML prototypes before full implementation, resetting when learnings from a prototype change the requirements, and treating the spec-to-prototype loop as the real work. His observation that he often does not know what he wants until he is 80 percent through an implementation — and that this is what actually slows things down — will be familiar to anyone who has shipped software.

The agent does not solve the problem of unclear requirements. It executes on whatever requirements you give it, faster than before. The structural setup that separates working implementations from accelerated dead ends remains the engineer's problem.

What Shihipar is describing, stripped of the technical vocabulary, is a new apprenticeship model. You learn the craft by doing, you discover the model's capabilities by probing, you close your ignorance gaps methodically rather than hoping the tool will compensate for them. The models are powerful. The question is whether the humans using them are willing to put in the work to find out how powerful.

That question does not have a comfortable answer for an industry still rationalizing its valuations.

Bob Reynolds is Senior Technology Correspondent at Buzzrag.