The Brownfield Problem: Why AI Makes Your Technical Debt More Dangerous, Not Less

By Andrew Siemer · March 18, 2026

← All insights

The brownfield problem — AI and technical debt

AI coding tools deliver real gains. The catch nobody puts on the slide: those gains are distributed wildly unevenly. Companies with clean codebases see something close to transformation. Companies babysitting aging, under-documented systems get more output without much improvement in outcomes — and sometimes new risk.

Mind the gap

The headlines say 100x. Google's CEO reported something closer to 10%. Research from December 2025 found brownfield environments averaged 26.9% productivity gains — meaningful, but a fraction of the greenfield fantasy. And here's the kicker: AI-generated code often needs more review effort than human-written code, not less.

Meanwhile the debt keeps billing you. Developers spend around 17.3 hours a week on maintenance versus 13.5 on new features. For a 20-person team at $100/hour, that's about $1.73 million a year going to keeping the lights on instead of building anything new.

Foundation is the whole game

The difference between elite teams and struggling ones is mostly codebase health, not raw talent. The line I keep coming back to: a healthy codebase multiplies good engineering; a fragile codebase taxes it. AI doesn't repeal that. It enforces it harder. Poor architecture doesn't get better because you can now generate code against it faster.

The real risk is subtle. AI produces plausible code inside systems it doesn't actually understand. In an environment where institutional knowledge is already thin, that means new technical debt accrues faster — and yesterday's cleanup sprint quietly becomes tomorrow's full redesign.

What to do, by stage

  • Mid-market: Aim AI at your 2–3 highest-friction modules. Resist the broad rollout.
  • Growth-stage: Document aggressively before you scale AI across the codebase.
  • Enterprise: Use AI for explanation and knowledge transfer before you let it generate.

Four questions to ask yourself first

  1. Do you actually know your DORA baseline metrics?
  2. Where is your code genuinely well understood — and where is it folklore?
  3. How long does it take to onboard a new developer?
  4. Who owns technical debt? (If the answer is "no one," that's the finding.)

The advantage in this moment doesn't go to whoever moves fastest first. It goes to whoever understands their foundation before they accelerate. Treat this as a chance to fix the foundation — not just to go faster on top of a cracked one — and the advantage compounds for years.

enjoyed the read?

LIKE WHAT YOU just read?

Let's talk about what we could build together.