AI tools don’t 10x developers — they 10x the rate at which developers create tech debt

Michael Parker’s Stack Overflow Blog essay reframes the 10x-developer debate in a way that lines up uncomfortably well with what most teams actually experience. His thesis: AI productivity gains are unevenly distributed, but more importantly, AI is being deployed against the wrong tasks. It’s automating the creative parts of software work (which developers like doing) while leaving the tedious parts (which developers hate) untouched. The result: developers become reviewers and janitors for AI-generated code that nobody designed.

Parker’s specific framing — and the line worth remembering — is this: I used to be a craftsman whittling away at a piece of wood to make a perfect chair, and now I feel like I am a factory manager of Ikea.

The structural misalignment Parker identifies

AI is currently strongest at: pattern-matching existing code, generating boilerplate, completing repetitive structures. It’s weakest at: judging which abstractions are worth keeping long-term, understanding the system context that drives architectural choices, knowing when to refactor vs. leave alone.

The industry deployed AI as a creative-work accelerator. But the creative parts of software (architecture decisions, naming, abstraction choices) are where developer judgment compounds over time. The tedious parts (dependency updates, framework migrations, refactoring legacy patterns to current ones) are where the actual hours are spent and where AI would compound far better.

Parker’s specific examples of what AI should be doing instead: dependency updates, Python migrations, refactoring. Boring, necessary, deterministic work where AI’s pattern-matching strength matches the task. Instead, AI is generating new code while humans clean it up.

Why this matters for indie founders

If you’re a solo founder or small team using AI to build product, you’re probably exhibiting the failure pattern Parker describes — without realizing it, because you don’t have a senior engineer telling you. Specifically: every PR your AI generates is a new piece of code that someone (you) will need to maintain or rewrite in 18 months. The productivity feels real today; the tech-debt accumulation is invisible until it’s too large to refactor.

The move Parker advocates — using AI on boring maintenance work instead of creative new code — is harder for indie operators because you don’t have a backlog of boring work yet. You’re new; nothing’s legacy. But the principle still applies: if you can identify any work that’s mostly pattern-matching against existing code (extracting helpers, updating call sites, applying a new convention), prefer using AI there over using it for novel code. The boring work compounds positive; the creative work compounds negative if you don’t have the judgment to review it.

The deeper warning

Parker isn’t anti-AI. His proposed solutions include more sophisticated planning agents that educate rather than simply execute and better team-level collaboration tools. These don’t exist yet at the indie scale. So the practical advice for now is: when AI generates code, treat the output as a liability until you’ve understood it, not an asset because it appeared. The factory-manager-of-Ikea framing is the right mental model — you’re orchestrating output, not craftsmanship, and orchestrating output that you don’t review is how the chair ends up wobbling.