Agents hand you five working versions. How do you pick the one that ships?
by•
Any coding agent gives you a working version of a feature in minutes. Ask again and you get another one, also working, slightly different. Working stopped being the filter.
My rule is simple: I ship the version with the fewest moving parts, because I'm the one debugging it at 2am. Speed of writing means nothing against speed of fixing.
What's your filter? Curious if anyone has a better rule than simplest one wins
332 views
Replies
Would stronger tests make a more complex version worth shipping instead?
Simplest-one-wins is close to my rule, but I sharpened it after enough 2am debugging of agent output: I ship the version whose failure I can predict. Fewest moving parts usually correlates, but not always. Sometimes the shortest version leans on clever implicit behavior, and that is exactly the one that bites. So my filter is: read each version and ask, when this breaks, will the error land near the cause? The version where failures surface loudly and locally wins, even if it is a few lines longer. Agents made writing code free, so the whole game moved to what happens six weeks later.
SlimSnap
@virko_kask Predictable failure is a better word for what I meant by simple. The extra lines are cheap insurance against the six-weeks-later bill
Cheap insurance against the six-weeks-later bill is the phrase I was missing. Stealing it, with credit. Looking forward to the results post.
and what would your approach be if you are non-tech?
other agents in the loop?
SlimSnap
@jitain If you can't read the code, judge behavior. Spend ten minutes trying to break each version and pick the one whose failures are loud and easy to describe. A reviewer agent helps a little, but it checks the code. What bites you later is behavior, and you still own that part.
Completely agree with the 'fewest moving parts' rule. 2 AM debugging sessions are brutal.
My secondary filter is 'Standardization over Cleverness.' Agents love to introduce overly complex frameworks, weird library dependencies, or 'clever' custom logic to solve simple problems. I always pick the version that sticks strictly to the standard, native features of the stack I'm using. If an agent introduces three new dependencies just to build a simple utility feature, it's an immediate reject. Fewer dependencies = faster fixing
simplest-one-wins is right and mine is close to it. i add one more filter: pick the version i can hand to one other person and have them say "yeah this did the thing" without me narrating what they're looking at.
when the agent hands me five, four of them require me standing next to the reader explaining what the buttons do. the fifth one lands solo. that one ships. the others are demos disguised as features.
One thing I have noticed, agents optimize for completing the task, humans optimize for owning the consequences. The winning version is usually the one that respects the second part.
I think "the one that works" stopped being the filter a while ago.
Multiple implementations can produce the same output, but differ significantly in latency, cost, observability, security, maintainability and failure modes. Correctness is necessary, but the process matters just as much as the result, especially in production.
Simplicity is one of the constraints, not the objective. The best solution is the simplest one that still meets the system's requirements.
Same filter for me. Working is not enough anymore, I’d pick the version that is easiest to understand, easiest to change, and least likely to create hidden cleanup later. AI makes building fast, but maintenance still comes back to you.
the fewer-files, one-sentence-explanation test is a good gut check, but it breaks a bit when two versions are simple in different directions. one has fewer files but a gnarlier one-liner buried in it, the other spreads the same logic across more files where each piece is dumb on its own. file count picks the first one, but my instinct says the second ages better because nobody has to hold the gnarly part in their head six months from now. curious how you'd call that one, since it's not really the same axis as "fewer moving parts."
SlimSnap
@galdayan File count was always a proxy. The real measure is how much one person has to hold in their head at once. That gnarly one-liner is a moving part in disguise, so I'd ship the spread version too
@bickov that tracks. one thing i keep wondering though - "how much one person has to hold in their head" assumed the person doing the holding is human. now that agents are increasingly the ones re-reading and modifying the code too, does the calculus shift at all? an agent with full context doesn't get tired at 2am the way you do, so it might not "mind" the gnarly one-liner the same way. or does it still lose either way because a gnarly one-liner is exactly the kind of thing an agent will confidently misread and "fix" into something broken?
SlimSnap
@galdayan The second one. A tired human at 2am at least knows he is confused. The agent edits the gnarly line with full confidence, no hesitation, no error message, and you find out weeks later. Clever code didn't get cheaper with agents, its failures got quieter.
@bickov "failures got quieter" is the whole thing in three words. that's the actual cost nobody prices in when they measure agent speed against human speed, a human's confusion is visible in real time, an agent's isn't, so the bug just moves further downstream instead of getting cheaper. good place to land this one.