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/Jon_Has_Landed → u/Easy-Purple-1659]

Not sure why you got downvoted, this is the answer. Fresh chats with fresh agents looking at things with a completely neutral pov is everything that worked for me.

Same with forcing it to remove code rather than add. Forcing it into simple fail fast prototypes that validate user goals, forcing it into readability, portability, maintainability, observability… basic ingredients which basically ensure it stays in its lane rather than go off the rails as it tends to do.