Why do AI coding agents write too much code, and how do you fix it?

We wrote 70,000 lines of code for an agent system that already existed and already worked as an open-source tool. That explained why so many random things just crapped out.

"These agents just don't like to cut code. It's almost like they treat code like it's their baby."

What happened when I told it to start over?

I told the coding agent we were starting over from zero: delete everything and rebuild only what's needed. Two days later, it had gone from 53,740 lines to 53,629. That's well under 1%. Asking once isn't enough. You have to insist, and keep insisting.

Why does this keep happening?

After repeated audits of my AI build system over a year, the diagnosis is always the same:

• Too much code. Agents build more than the job needs. At one point my newsletter builder had about 135 pieces of code for a single component.
• Too many restrictions. Every problem gets a new rule or guard, so more and more things "need" to happen that don't.
• Conflicting language. Rules in different files say different things, and the agent follows whichever it reads.
• Symptom fixes. One agent found about 14 earlier "fixes" to my survey software, each tuning a single query, when the real cause was an undersized database server. A $5 a month upgrade solved it.

As a non-technical founder, I talk plainly and rely on the system. That only works if the system is simple.

What does bloated AI code look like in practice?

Two traps that came up in a single build session on a survey product:

1. Hard-coded where it should flex. It had built one fixed survey. That's not going to work, because different types of people need different types of surveys. That's the whole point. The AI agreed, and warned it meant a massive rebuild. It acted like it would be really hard and take a long time. It was done the same day, and it did it all by itself.
2. The same thing built twice. The mobile view and the desktop view were completely different code. Every change would have to be made in two systems, and sooner or later one wouldn't get changed. When I asked about it, the AI itself said it wouldn't recommend that and should put it all together.

Neither problem showed up until I asked the AI to explain how things were built and what the risks were. Ask that question early.

How do I stop it before it starts?

My rule is existing capability before new capability. Before custom code, go down this list:

1. Use the current system correctly.
2. Fix the root cause.
3. Change a configuration or setting.
4. Use something upstream or open source that already does it.
5. Simplify or delete.
6. Only then, write custom code.

Custom code is normal inside real products, like lightbreak, greetform and larkfeed. The higher bar is for internal plumbing: orchestration, memory and agent infrastructure. That's exactly where my 70,000 lines went. And never solve a narrow problem in a way that damages the larger system.

What do I say to the agent?

Before adding anything, tell me:
- Does something we already have, or an existing tool, solve this?
- What can we delete instead of add?
- Are any of our rules now conflicting?
I want fewer, clearer rules and less code. Deletions are wins.

For a bigger cleanup, I frame it as a hire. After about 15 months of building lightbreak with multiple systems, multiple developers and lots of false starts, I asked my agent for one full code review. The framing:

"What if you acted like we hired an OpenAI or Anthropic engineer and said, 'Hey, we want you to work for lightbreak, but you know there's a 12-month-old system ... Can you fix the code to be as good as humanly possible and get rid of anything that doesn't make sense and upgrade and whatnot?'"

I asked it to flag duplicates, old code we weren't using and anything worth upgrading, especially from 6 to 12 months back, when AI was weaker. I'm non-technical, so I lean on the agent to recommend the approach. I want it to be the first and, hopefully, last big cleanup for a while.

When should I rebuild instead of patch?

When the cruft outweighs the product. My newsletter builder started about 16 months earlier in the early Replit days and collected so much dead code that, when I asked a current model whether to upgrade or restart, the answer was start over. That's literally why we built lightbreak v2: version one had an insane amount of code because we didn't know what we were doing, and AI wasn't as good then.

The goal is an app that works well for the long term, with the least amount of code necessary, instead of a patch for the bug of the moment. Until the way it's coded changes, you keep dealing with crazy problems. With current models, a rebuild can be cheaper than patching forever.

Keep your agent instruction files lean for the same reason. Rules bloat just like code.