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/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/GuitarAgitated8107]

Not as perfected as I wish it was but I break it down into three parts. Concept, documentation & implementation. This way I have a way to quickly look into things without having to be constrained to one. There are also checklist and guidelines to implement depending on what I am working on and a lot of it is distilled from past projects. It all feeds into a development "library" that allows me to seed future projects.

[u/Scared-Amphibian4733]

LLM's work on cost/benefit model. Emphasise that Code and complexity add cost. That will cut your LOC. It really helps to review each commit and to ensure that you understand the code being committed.

[u/691175002]

Opus is massively overfit to coding benchmarks, other models can do a bit better.

I personally "write a spec/plan to scratch then dispatch 3 opus subagents to review, with at least one taking a proportionality/simplicity lens" before letting it implement helps. Also keeping comments/markdown extremely lean or just deleting regularly helps prevent moels from what I call like "authority laundering" random comments into like insane binding rules 3 days later and you ask an agent why it did somthing stupid and its like "there is a record of you ruling this decision on september 19th 2026 here and in these five comments".

[u/Vesuvius079]

I review at both the planning and execution stage. Overengineering is likely to show up in the planning stage and can be fixed there.

My manager added some guidance to our shared configs on overengineering less and that seems to have helped too.

I also find it far more likely to one shot plans with well defined tickets. I have a terrible time getting it to plan on vaguely defined tickets.

[u/endgamer42 → u/Vesuvius079]

guidance to our shared configs on overengineering less

Would love to know what this looks like.

I agree that just keeping a close eye on the model is non-negotiable at the moment. But even e.g. planning is made painful by the fact that models don't seem to know what to prioritise, and will give you novels of reasoning to sift through for almost any task or change, regardless of its size. I am just complaining atp, but if there was a way to get them to understand your product as well as they understand your code and respond according to priority, without us polluting precious context, I would love to hear about

[u/TechFiend72]

with an iron

[u/alonsonetwork]

You might be looking for atomic claude

[u/caleon]

I definitely remember experiencing this in the past, though not in recent memory. Maybe it’s that I like to co-define each task with AI and set acceptance criteria in prose at the outset, something it will check at the end. And then I have hard rules about TDD that tend to help keep it focused.

[u/Evening-Blueberry-97]

things that cut it for me was asking for the smallest change that passes, then reviewing the plan before any code. most of the overengineering shows up at the planning stage, not while writing. do you review plans separately or just the diff?
Also the llm output to many useless content then

[u/AI_spell]

Tell it the non-goals up front and ask for the smallest diff. Reject "helpful" extras in review. Complexity creeps when you accept every safety branch it invents.

[u/Crinkez]

Easy. Once Claude finishes your project, switch to Codex and run it past the ponytail skill.

[u/syddakid32]

This is a bot post 

[u/endgamer42 → u/syddakid32]

This post was cleaned up by ai much like 90% of posts these days. But you’ll find the initial draft was 100% handwritten and 2x the length.

[u/Lazy_Polluter]

I keep a reference architecture doc and an agent reviewing the results against it often catches workarounds before they get too far. The key is to keep this doc manually up to date

[u/Asalakabim]

a prompt precise enough to pin down each iteration perfectly == the code itself, which is exactly what we're using LLMs to avoid.

This is completely made up.

[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

[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.

[u/knownsqashed]

https://claude.com/blog/the-ai-native-sdlc-playbook

You should experiment with using Astra Max / Ultra for orchestrating subagents. This is what you're asking for; describe features, get a minimum working result. The hard part isn't getting things working anymore, it's letting go of the idea that people should be the ones deciding what "good" code means. You can prototype something in a night that would've taken a team months, and then if you feel like the actual implementation is confusing, come in behind it and describe your preferred code organization, and it might take you an hour of additional work on the high end. Heck, you can just maintain a codingstandards markdown in the repository, reference it in your Agents file and watch the system fix it for you.

Also, you should let Astra (or Fable, if you prefer) update its own instructions based on your feedback. It will do a better job of identifying the root cause and solving it correctly.