AI Writes Fast. It Doesn't Know What's Good.
AI writes code fast, and it has no idea whether the code is any good. This week I shipped a few features with AI, and the first result wasn’t always good enough. So I stopped relying on a single attempt. I ran several agents in parallel on the same feature, picked the version closest to right, and tweaked it myself. The agents produced options quickly. Deciding which option was usable took taste, and that part was mine.
The first attempt is one draw
Every response from a model is one pick from a wide range of plausible answers. Run the same prompt twice and you get two implementations: different names, different structure, sometimes a different approach to the whole problem. The first one you see has no special claim to being the best.
When that first attempt misses, the habit is to fix it in place. Point at what’s wrong, ask for a correction, point at the next thing. That works when the miss is small. When the draft went in the wrong direction, every correction gets stacked on top of the wrong idea, and the conversation fills up with the history of what didn’t work. That history crowds the context window and pushes the session toward the dumb zone.
Throwing away a bad draft and drawing a few fresh ones is often cheaper than repairing it.
Several agents, one feature
When I wrote about turning a terminal into an AI dev team, each agent had its own task. This flips that around: several agents get the same task.
The setup is simple. Each agent gets the same spec and its own copy of the code, a separate git worktree or branch, so the attempts can’t step on each other. They don’t see each other’s work, which is the point. You want independent attempts at the same problem.
The spec still matters. Five agents working from a vague prompt give you five versions of vague. Each attempt benefits from the same research up front you’d do for a single agent, and running in parallel multiplies whatever context you start with, good or bad.
Keep the count small. Generating another version costs tokens. Comparing it costs your attention, and attention is the expensive part.
Read them side by side
Once the attempts are done, put them next to each other. Where every version agrees, the problem probably had one obvious answer. Where they diverge, there’s a decision to make. One version adds a new table and another reuses an existing column. One wraps the logic in a service object and another keeps it in the model. You may not have known those were choices until you saw both.
All of them might pass the tests. An agent can generate twenty implementations that pass, and most of them will be fine. Green tests tell you a version is a candidate. They don’t tell you which candidate to keep.
Picking takes taste
“Closest to right” covers a lot. The version that follows the patterns already in the codebase. The one with the smallest diff that solves the problem. The one whose names match how the team talks about the domain. The one that didn’t pull in a dependency nobody needed.
An agent can’t make that call for you, because it doesn’t know what good looks like in your codebase, for your users. That’s taste, and it’s one of the things I listed when I wrote that code was never the goal: choosing the right abstraction and the right tradeoff is judgment, and generating more code doesn’t supply it. The version you pick is the one you’ll maintain, and bad code rots the same way whether a person or a model wrote it.
Finish it by hand
After picking the closest version, I tweaked it myself. When the gap between a draft and what you want is small, editing the code is faster than describing the edit to an agent and waiting for it.
Pay attention to what those tweaks are. If you make the same correction on feature after feature, renaming the same kind of thing or moving logic to the same layer, that correction belongs in a SKILL.md file. Then the next round of attempts starts closer, and the picking gets easier.
Agents make options cheap. Picking the right one still takes someone who knows what good looks like.