5 Rules for Prompting AI Coding Agents

Prompting AI coding agents is mostly about error rate over time. A model that fails 5% of the time per 10-minute window fails about half the time across a two-hour run, so raising the floor is worth more than a higher peak.

Prompting AI Coding Agents: Frontier Models Win on the Floor

Prompting AI coding agents effectively starts with judging models by their worst behavior, not their best. Frontier models from labs like Anthropic and OpenAI earn their price mainly by making fewer dumb mistakes per unit of time, which is what lets one prompt carry a task end to end.

In a September 2026 video, developer Theo Browne argued against the claim, attributed on screen to Sentry founder David Cramer, that most engineers should switch back to cheaper or older reasoning models because task quality does not change. His rebuttal: if you genuinely notice no difference when you drop a model tier, your prompts are probably too narrow to expose the difference.

The useful framing is the gap between a model's ceiling and its floor. A model with spectacular peak capabilities but a low, unpredictable floor will read the same file repeatedly, misunderstand a word like "revert," or fail to center an icon in a div. Those low points are what end long runs, and Theo's argument is that engineers systematically over-weight the highlight reel and under-weight the lows.

Wide Prompts Beat Hard Prompts

The width of a prompt, meaning how much ground it covers from a vague starting point to a finished, verified result, matters more than the difficulty of any single step. A wide prompt hands the agent the whole distance; a narrow prompt hands it one file and one change.

Theo distinguishes two prompt styles with the same difficulty but very different width. A narrow prompt looks like: here is the Jira ticket, the files are listed, make the change and tell me when you are done. A wide prompt looks like: here is a screenshot of a user-reported bug, fix it, test it, record a video proving the fix, open the pull request, and address review comments until they are resolved. Both are simple work. Only one of them requires the model to stay coherent for an extended stretch.

His claim, from first-hand experience, is that narrow prompts clear the quality bar of almost any modern model, which is exactly why downgrading tiers feels harmless to people who prompt narrowly. Widen the prompt, and the weaker model's low points start landing inside the task, and the difference between tiers becomes obvious.

The Compounding Math of Agent Failure Rates

Agent reliability compounds badly over time, which is the arithmetic core of the whole argument. If a model has a 5% chance of doing something wrong in any 10-minute window, the probability of a clean run shrinks geometrically as the run gets longer: roughly 86% over 30 minutes, 73% over an hour, about 54% over two hours, and under 30% over four hours.

Small floor improvements pay off disproportionately. Cut the same failure rate from 5% to 3% per 10-minute window, and a four-hour run goes from roughly 29% success to roughly 48% success. A two-point change in the per-window floor becomes a twenty-point difference at the timescale where autonomous work actually happens.

Run length | Success at 5% per 10 min | Success at 3% per 10 min | --- | --- | --- | 30 minutes | 86% | 91% | 1 hour | 73% | 83% | 2 hours | 54% | 69% | 4 hours | 29% | 48%

This is also why Theo reports, from his own prompt logs since April 2026, a median prompt length rising from 53 seconds to 2 minutes 20 seconds and a 95th-percentile length rising from under 7 minutes to over 16 minutes 20 seconds. These are his personal measurements, not an industry benchmark, but they illustrate the direction: usable run length per model generation is growing fast, and the longest runs grew the most. A reviewer in his chat guessed the floor had improved 10 to 15%; his point is that even a small per-window improvement compounds exponentially into run duration.

Fix Your Codebase, Not Just Your Prompts

When agents fail repeatedly in your repository, the fix usually belongs in the codebase. If a capable new developer could not contribute by the end of their first day, that is a codebase problem, and the same blockers stall agents.

Practical adjustments that reduce agent failure rates:

• Remove the ambiguities that trip up any newcomer: unclear naming, implicit setup steps, missing scripts.
• Learn from bad runs instead of discarding them. One developer cited in the video runs overnight autonomous sessions specifically to surface failure points, then restructures the codebase so one- to two-hour threads stop hitting them.
• When you do watch an agent work and it goes wrong, ask it what signals and files led it there. Models rarely know why they acted, but they usually report the tools they called and the files they read.
• Let the agent verify its own work. Running the code, or attaching screenshots and videos of the change working, catches failures that reading diffs cannot.

The sponsor example makes the same point from the review side: Greptile, an AI code review tool, launched a sandbox-driven reviewer that spins up environments and sub-agents to test hypotheses about a change, returning images and videos as evidence rather than a bare approval. The underlying insight matches Theo's: code breaks in ways that are not visible from reading it.

What Frontier Models Cost Versus What Engineer Time Costs

Token spend looks large next to zero and small next to salary. A $200 monthly subscription to a coding-model service, Theo argues, buys enough headroom that a strong engineer can delegate whole tasks rather than babysit short ones.

His example is arithmetic, not vendor data: if an engineer worth three times their salary in output can spend the equivalent of two times that salary in tokens to get there, the trade is obvious compared with hiring two additional engineers who may slow them down. The failure mode he warns about is downgrading models to save money and then paying the difference in human time at both ends: more setup before the run, more cleanup after it.

He applies the same logic to tooling. Long autonomous runs were unreliable in earlier agent generations regardless of how detailed the specification was, and products built around that assumption struggled; Cursor, the AI-first code editor, he argues became stable again partly because newer models can sustain four- to eight-hour runs without falling apart. This is his first-hand assessment, not a published product benchmark.

Who Keeps Downgrading Models, and Why

The engineers most likely to conclude that cheaper models perform identically are, in Theo's view, two groups: people whose tasks are genuinely narrow, and experienced leaders who stopped coding day to day.

The second group is the interesting one. Strong leaders already moved the valuable work to before the code starts (specs, architecture) and after it ends (review, vetting). They are testing models against the middle, the part they personally stopped doing months ago, and the models cleared that bar a while back. The moment they widen the prompt in either direction, pushing setup or verification onto the agent, the tier differences reappear.

The counterexample he cites is a developer who spent three to four days reviewing her own agent traces and refining her skills and prompts, after which a single prompt reliably produced a merged pull request. That investment, not a model downgrade, is what her time bought.

One caution: Theo's video is opinion and personal experience, delivered as commentary on other engineers' posts, including David Cramer of Sentry and David Khourshid, creator of the XState state machine library. The run-length figures are his own logs, and the reliability math is arithmetic on assumed failure rates, not a measured study. Treat it as a practitioner argument worth testing on your own workloads.

FAQ

• Why do frontier models feel no better than cheaper ones for my tasks? Because narrow, short prompts clear the quality bar of nearly every current model, so tier differences stay invisible. The differences show up when one prompt has to carry a task from a vague bug report to a tested, verified pull request without your input.

• What is a "wide" prompt for a coding agent? A wide prompt covers more of the distance from problem to finished result: describe the problem, let the agent find the files, fix, test, record proof, and handle review comments. Width is about span and autonomy, not difficulty.

• How does failure rate change with agent run length? It compounds. A 5% failure rate per 10-minute window means roughly 86% success over 30 minutes but only about 29% over four hours, because you multiply the per-window success probability across every window.

• Should I write more detailed specs or fix my codebase? Both help, but codebase fixes help more over time. Agents hit the same ambiguities a new developer would, and removing them raises the floor for every future run, while specs only guard a single run.

• Is it cheaper to use a smaller model for coding agents? Only if your prompts stay narrow. Theo's argument is that cheaper models shift cost into human time spent steering before the run and correcting after it, which can exceed the token savings for wide, long-running tasks.

Turn Your Own Agent Runthroughs Into Writing

The argument in this article came from a video: one engineer's opinions, arithmetic, and prompt logs, useful precisely because they were captured in full. If you have the same kind of knowledge sitting in your own YouTube videos, such as runthroughs of your AI coding agents, postmortems of failed runs, or the reasoning behind your prompting style, that material does not need to stay locked in a timeline.

Skalablog turns a YouTube video into a reviewable written article: you paste the video URL, the video is transcribed, and you get a structured draft you can edit and publish. If you record what your agents do and why, that habit is already most of the work.

And if you want a codebase that agents and new developers alike can navigate, a structured reference such as CrazyStack Typescript is one way to build that discipline from the start. Gustavo Dev Doido could paste any of his own stream recordings into Skalablog and have this kind of draft waiting for review the same way.

Source video