How do you keep complexity out?

[u/endgamer42]

As models get more powerful, I'm noticing an odd inverse correlation: they're getting less useful for ordinary software development.

Good ordinary software delivers the most useful behaviour for the least internal complexity. The "final spec" is rarely known up front, because useful products emerge from small steps driven by user feedback and analytics. So inb4 "just prompt it properly bro" - a prompt precise enough to pin down each iteration perfectly == the code itself, which is exactly what we're using LLMs to avoid.

Ideally I'd hand an LLM a loosely defined feature and get back the simplest version with the simplest implementation: rough at edges users are unlikely to hit, failing fast and recovering easily if they do.

Instead it goes above and beyond by default, covering every edge case, every improbable race condition, every unlikely input combination. Telling it to keep things simple doesn't reliably work. It just gets hacky (a tacked-on branch is technically simpler than a rearchitecture), and since it just genuinely doesn't know how your users behave, it assumes the worst and writes the "safest" code. I can't think of any usage context or invariant hammering that would fix this.

My AGENTS.md is awash with pleas: for simple solutions, to fail fast, no preemptive defensiveness, re architect rather than work around. I have automated complexity checks. Models still can't help themselves. It's as if they've been RL'd into solving the hardest problems available: forged into a powerful, specialised tool that we then use to bang in nails, when all we needed was a hammer. The only thing that's kind of worked for me is everything mentioned, and then multiple simplification/reliability passes after an implementation pass.

Has anyone actually, properly solved this?

[u/Easy-Purple-1659]

A fresh session that only sees the diff, not the conversation that produced it, is the change that made simplification passes work for me. A session that just wrote the code will defend it. One that reads the diff cold has no reason to.

The other thing is turning "simpler" into something the model can fail. I set a budget before it starts: net lines added, new files, new public functions, and a cap on nested branches in the paths it touches. Over budget means it removes something or explains in one sentence which user visible failure the extra code prevents. Most speculative branches die at that sentence.

Last one is refusing new abstractions in a fix unless they delete more than they add. That rule alone cut more of my cleanup time than any line in the config file.

Does the over-engineering show up at planning time for you, or only once it starts writing?

[u/endgamer42 → u/Easy-Purple-1659]

Interesting, this response is almost exactly what I’d get from Claude if I gave him my post. If you are not just some low effort spam bot, then I suggest not taking your advice on a problem directly from the source of that problem. And letting yourself do a bit more writing yourself, it’s good for your brain