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
i have a simple rule too. if i need to explain the code for ten minutes before someone understands it's probably more complex than it needs to be.
Great rule. I’d add one more strict filter to the 'simplest wins' approach: zero unnecessary dependencies. Often, an agent will give you a working version that quietly introduces a new package or deviates from the framework's native tools just to get the job done quickly. I always pick the version that strictly adheres to our core stack and doesn't bloat the architecture. Speed of fixing > speed of writing, 100%.
Funny how we've gone from struggling to write code to struggling to choose between multiple working solutions. That's a much better problem to have, but it's still a problem.
SlimSnap
@amard_sonal A better problem is still a problem sums up the whole AI era
My deciding factor is usually the test coverage. a simple implementation without confidence checks can still hurt you later. The winner is the one I can safely change not just the one that works today.
SlimSnap
@ashir_murtaza1 Test coverage is a different kind of filter, it measures whether you can change the thing, not just whether it runs. Do you let the agent write those tests too, or is that the part you keep for yourself?
I like this rule because simple code usually survives longer. How do you measure simplicity when two versions solve the same problem differently?
SlimSnap
@advin_jadis No metric, a quick gut check of a UX person with a technical background and 20 years in. Fewer files touched, fewer dependencies, and I can explain the change in one sentence. Same rule I use for interfaces: if it needs explaining, it lost
me choosing the simplest version has saved many future fixes. have you tried tracking bug counts after release to see whether simpler implementations actually reduce maintenance over time?
SlimSnap
@alheri_murya No real tracking, my scale is too small for bug stats to mean much. My signal is cruder, which versions I end up reopening. The simple ones mostly stay closed
Great question, this is exactly the kind of problem more teams are running into as agents get better at generating options. My honest answer: pick the version that's easiest to debug 6 months from now, not the one that's cleverest today.
Most of the "wow, this is beautiful" versions I've picked from AI-generated batches turned into maintenance nightmares. The ones that felt boring but had clear structure and readable logic aged way better. Ship-ability isn't just about now, it's about the version you'd still be willing to inherit later.
SlimSnap
@nolan_vu The agent optimizes for right now. Everyone in this thread is optimizing for whoever opens the file in six months. That second person is the one the agent doesn't have, which is why "inherit later" is the filter and the agent can't apply it for you.
@bickov Great point Alexander, honestly this reframes the whole conversation. Most reviewers are unknowingly acting on behalf of a future teammate the agent doesn't even model. That's why "inherit later" holds up as a filter even when the surface-level output looks impressive.
The agent is optimizing for local elegance while we're the ones responsible for long-term coherence. That mismatch is where a lot of AI-generated code quietly fails, not because it's wrong, but because it wasn't written with the future maintainer in mind. Really appreciate you sharpening this idea further.
This really resonates. AI has changed the bottleneck from writing code to making good engineering decisions. I'd rather maintain something boring and predictable than something brilliant but fragile.
simplicity is underated, especially with AI generated code. i have seen agents produce beautiful solution that become nightmare once requirements change. fewer abstractions usally means fewer surprises.
I usually keep the version that's easiest to improve later. Future me always appreciates simpler code.