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
334 views
Replies
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.
Dial
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
Dial
@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.
Dial
@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.
SlimSnap
@apiosk Tests for each, written by the same model that wrote the code. Five students grading their own exams.
@bickov Just kidding. Usually I plan with the smartest model out there, 5.6 Sol or Fable 5. Then I split the plan into multiple smaller tasks using a cheaper model, because it doesn't have to think or work very hard to do that. I build it with Opus 4.8 UltraCode, one TODO at a time, testing each item as I go. Once everything is done, I let the smarter model I used for planning do the final review. Works okay.
SlimSnap
@apiosk One TODO at a time with a test each is more discipline than most people have. Whole loop is still text though. Plan, code, review, all reading the diff, nothing ever looks at the screen.
What does "okay" mean here? Where does it let you down?
@bickov point is, i have a technical background which most ‘vibe-coders’ dont have
My filter is: which version will I still understand two weeks later?
If it is easy to read, easy to explain, and easy to change without touching half the codebase, that’s the one I’d ship. Working is table stakes now; maintainable is the real filter.
Simplest is solid, but I'd add one layer: fewest moving parts that still handles the edge cases you've actually hit. The version with less code sometimes just kicks the problem down the road. I've picked "simpler" before and regretted it when something broke in production that the other version was defensive about. So maybe it's simplest that you understand completely rather than simplest on paper.
SlimSnap
@mohammed_messeguem Simplest you understand completely is the right correction to simplest on paper. The scar earned it.
One layer even that misses though: understanding the code completely still doesn't tell you it renders right. Every filter in this thread reads the diff. None of them run the thing and look at the screen. The version you understand perfectly can still lay the button on top of the label.
i pick the one i can roll back in one command. working is easy, recovering is the actual test