The Speed vs. Correctness Dial You Can Turn Up and Down Coding with AI

While I still think LLMs are mediocre at code, the whole "using LLMs is vibe coding" thing has passed. With the right constraints and feedback loops, they produce work comparable to a decent developer well-versed in the system and the toolchain.

Because LLMs never tire, they don't need perfection the first time. They can iterate until the result is right. As long as "right" can be verifiable without human intervention, you can have them keep banging their head autonomously until everything works, although poorly defined goals can still lead to problems and agents doing some crazy things (see overcoming meat-metal divergence).

Giving them the ability to run and inspect the project, along with solid unit and end-to-end tests and code reviews, slows them down but produces much better results. Overall speed isn’t primarily controlled by how fast the model types code (hint: always super fast!) - it's really controlled by the verification loop and the decisions and tooling around it.

This means that you actually have control over how fast you want to go. You're trading speed for correctness, with diminishing returns as you add more verification. Reviews, testing, and gates are relatively cheap to implement and, crucially, automatable.

For example, I've found when writing design documents, a 3-step process works for me:

1. 1 -
   Have an agent write a design document in the main thread
2. 2 -
   Have a clean-context sub-agent review the design document (I call it the "devil is in the details review")
3. 3 -
   Have the main thread verify the claims of the clean-context sub-agent and fold them into the document

I used to just do step 1, but found that occasionally - maybe one in twenty - there was something written that was so fundamentally flawed in a design that the implementation agent couldn't correct it mid-flight, effectively nullifying the build and requiring a git reset. Since total clock time is important, it was worth the extra few minutes of step 2 (and the not insignificant token cost of a clean-context sub-agent) to avoid those catastrophic issues. I then also realized that sometimes the review agent screwed stuff up, and letting it fold its opinions into the design unchallenged also occasionally led to issues. Hence the addition of step 3.

I've extracted this process into composable skills: /design, /devil, and /devil-design.

Depending on the project and scope of what I'm working on, I can go fast (/design), slow (/devil-design), or in between. The latter runs maybe 2.5x slower than the former and more than doubles the token cost as well.

This same idea applies to testing philosophy. If I had to force it onto a generic linear scale, I'd write it roughly as: No Tests → Unit Tests → Integration Tests → Mutation Testing → Eval Suite → End-to-End Tests. The exact ordering isn't important. The point is that each additional layer costs time and tokens. Depending on the project, you can decide how constrained you want the agents to be. Each addition will noticeably slow down the development process and eat more tokens, but will likely lead to better outcomes.

Applying the idea to front-end implementation: Just Build it → Add a Design → Add a Design System → Force Storybook Components → Pixel match to reference design each phase.

And again, the same applies to the build process by defining what clean-context reviews you do of each PR and with what lenses (code review, architecture review, security review, functionality review). Each of these adds some value, but cost more. Running them in parallel helps minimize the time cost.

Turning the dial up too high, especially when trying to implement small pieces interactively with the agent, will lead to frustration and reduced overall performance. Building a one-off utility with mutation testing and an eval test suite is overkill.

Turning the dial down too low, especially when sending your agents off to run a build autonomously overnight, will lead to a big pile of spaghetti you need to unwind or throw away in the morning.

Where you set the dial mostly depends on the cost of being wrong. Early in a codebase - take your time (see Start Slow). Banging out a clear UI feature or a bug with an obvious testable regression? Blast away. It's not a one-size-fits-all per-codebase dial. Make sure your process keeps you in the driver's seat, turning it up and down as you go.

As experienced developers know - there's no assembly-line factory process for software development. People certainly try, and I'm sure we'll see more and more "software factories" in the AI age. However, there's still an art to applying the right process to the right piece of software, and understanding the speed vs. correctness trade-offs when coding with LLMs can help you dial things in just right.