Prompt engineering is overrated for Claude Code

99% of Claude Code gains come from task design and verification, not prompt tricks.

Boris Cherny is right: for Claude Code, prompt engineering is no longer the main lever, and teams that keep treating it like a magic craft are wasting time.

His argument is not abstract. He described giving Claude a hard programming job, then letting it run in a Mac virtual machine, compare screenshots pixel by pixel, and keep going until the result matched. The breakthrough was not a clever prompt. It was a workflow that gave the model a difficult task, the right tools, and a way to check its own work.

The first argument: capability has outrun prompt craft

The strongest evidence comes from Cherny’s OpenCV anecdote. An engineer gave Claude access to a computer vision library with thousands of algorithms, then asked it to draw images. The model produced something unexpected and useful. That is the real story here: modern models surface abilities that users do not unlock with verbosity or formatting. The old belief that success depends on finding the perfect wording is already behind the curve.

This is why the “prompt engineer” era was always temporary. Cherny said the role shifted from prompt engineer to context engineer, and now the better skill is task framing. That tracks with how strong systems actually work. When the model is capable, the highest-value move is to define the job, attach the right tools, and let it iterate. The person who wins is not the one who writes the prettiest prompt. It is the one who knows what outcome to demand.

The second argument: verification beats verbosity

Cherny’s most important point was not that prompts do not matter at all. It was that verification matters more. He said the single biggest mistake people make is failing to give Claude a way to verify its work along the way. That matters because AI systems are not just answer engines anymore. They are agents. Once an agent can act, the question is not “Did I describe the task elegantly?” The question is “Can the system prove it is on track?”

The Claude desktop rewrite example makes that concrete. Cherny did not micromanage each step of the migration from Electron to Swift. He told Claude to run the app, screenshot it, compare it visually, and continue until done. That is a software engineering pattern, not a prompting trick. Human engineers use tests, logs, and visual checks for the same reason: output quality improves when the system can inspect itself. In this world, verification is the control surface.

The counter-argument

The best case for prompt engineering is that it still creates leverage for novices and edge cases. A weak prompt can bury the model in ambiguity, under-specify the goal, or omit critical constraints. In regulated, high-stakes, or highly structured work, wording still matters because the cost of drift is real. A marketing team, for example, cannot simply say “make it better” and expect reliable output. The model needs audience, tone, source material, and boundaries.

There is also a practical reason the prompt-engineering mindset persists: it is visible. People can copy a prompt template, post it online, and feel immediate progress. Verification and task design are less glamorous, but they are harder to generalize. That makes the old advice sticky, especially for teams that have not built agentic workflows or test harnesses yet.

That counter-argument is valid only at the margins. For Claude Code, the dominant failure mode is not missing prompt flourishes. It is under-instrumented work. If the model cannot check its own output, no amount of phrasing rescues it. If it can check its output, plain language is enough. The limit is simple: prompt engineering still helps when the task is underspecified, but it is not the core competency for getting serious work done with Claude.

What to do with this

If you are an engineer, stop polishing prompts and start building feedback loops: tests, screenshots, evals, logs, and tool access. If you are a PM or founder, define tasks in terms of outcomes, not scripts, and give the model the context and verification path it needs. The winning habit is empirical use, not prompt theater.