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
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
Same, I’d rather ship the version i can understand in 10 minutes than the one that looks clever for 2 days and becomes pain later. AI makes options cheap. maintenance is still expensive.
My filter is close to yours but one step earlier. I pick the version I can explain to a client without opening the file.
Agency work makes that concrete. Three months after shipping, someone asks why a screen behaves a certain way, and I am reading my own codebase like a stranger. The clever version and the boring version both worked on the day. Only one of them is still explainable in month four, and it is never the clever one.
What surprised me is that the agent will happily give you the boring version if you ask for it. Most people never ask. They take the first working answer because working feels like the finish line, when it is really just the entry fee.
So, fewest moving parts, and when two are tied, the one whose failure mode I can predict.
The filter answers here are good, but I want to question the setup itself. Choosing the best of five blind variants is already the expensive path, because by the time you are comparing finished versions you are judging on what you can see, which is surface readability, and the thing that actually bites you later, hidden assumptions and coupling, is the part that does not show up in a quick read. You end up grading the cover.
So the move that saved me the most is pushing the decision upstream. Instead of generate five then pick, I spend the effort on the constraints before generation, the stack we already use, no new dependencies, must be testable, one responsibility, and let the agent produce one version against that bar. Selection after the fact is reviewing, specification before is designing, and the second is where you actually control quality. When I do still want variants I make it deliberate, two that differ on one axis I have genuinely not decided yet, not five that differ on everything and force me to referee. Fewer constrained options beats a wider buffet you have to police at 2am.
Really appreciate this one @bickov — the "I'm the one debugging it at 2am" framing is the whole game.
Building on Ashir's coverage point and Nolan's "inherit later": from running coding agents heavily on integration code, I've found "working" is usually measured against a test suite the same agent often wrote — so "it passes" can be quietly circular. And the five versions are almost always identical on the happy path; they only diverge in the error-handling branch — the 500, the partial response, the retry — which is exactly the part the agent has the least signal on.
So the diff I actually read between the five isn't the feature code, it's just the failure behavior — which one fails loudly, in the right place, when an upstream lies to it. My filter ends up being "fewest silent failure modes" more than fewest moving parts. When the simplest version and the one that degrades honestly aren't the same file, I've learned to take the honest one. Curious whether you weight that in, or if at your scale the simplest usually is the honest one? 🙏
SlimSnap
@akbar_b Mostly the same file for me, but that's a scale artifact. I wrote all of it and I'm the only one who'll ever debug it, so simple and honest collapse into each other.
When they do split I take the honest one too, for a worse reason than yours. No monitoring, no team, no alerting. A silent failure doesn't surface on a dashboard, it surfaces as a user emailing me three weeks later. If they bother.
An agent grading its own test suite explains a lot of green builds I never trusted. And the failure I can't write a test for at all is the visual one. Nothing throws, nothing logs, the button just sits on top of the label.
@bickov "a user emailing me three weeks later" is the honest version of monitoring — the cost of the silent failure didn't vanish, it just got deferred and quietly repriced onto whichever user bothers to write in. The visual bug is the sharpest case of why the agent can't help: it only exists once something computes layout, which is exactly the step skipped when the model grades itself on text and DOM. Both elements are present and "visible" by every check it can read — the overlap is purely geometric. So the only gate I've found that catches it is actually rendering the page and diffing it (pixels, or a bounding-box overlap check); everything cheaper is the agent inspecting a channel the bug never touches. 🙏
Simplest wins is my rule too, but the better lever sits upstream. You get five equally valid versions because the task was underspecified, so the agent had room to wander. When I pin the output contract first, the exact shape it has to return and the cases it has to pass, the count of "working but different" versions collapses, because there is less undefined space left to be creative in. Then the filter is not taste, it is which version I can put under a test fastest. And on your tests question in the thread: I do let the agent draft the tests, but only after I have written the contract by hand, because the contract is the part that encodes what I actually want.