The speed limit humans impose on code production isn’t a limitation to overcome. It’s the mechanism that keeps codebases maintainable.
Author: James Phoenix | Date: March 2026
Source: Mario Zechner, “Thoughts on slowing the fuck down” (2025)
Summary
Human developers are slow. They can’t produce 20,000 lines of code in a few hours. This has always been framed as a limitation. Agents remove it. But the bottleneck was doing something important: it rate-limited error compounding, created pain signals that triggered cleanup, and forced understanding through friction. Removing the bottleneck without replacing these mechanisms produces codebases that degrade faster than anyone can fix them.
The Conventional Wisdom Is Wrong
The entire narrative around coding agents frames human speed as the problem. “10x developer productivity.” “Ship in hours, not weeks.” The implicit assumption: the bottleneck was always the human typing speed, and now we’ve removed it.
But bottlenecks aren’t always bad. In manufacturing, a bottleneck that slows production also slows defect propagation. In software, the human bottleneck served three functions that nobody noticed until they were gone:
- Error rate limiting. A human makes errors, but can only make so many per day.
- Pain-triggered cleanup. When booboos accumulate, the human feels pain and fixes things.
- Forced understanding. Writing code (or watching it built step by step) creates comprehension through friction.
Remove all three at once, and you get compounding degradation with no corrective mechanism.
Why Agent Errors Compound Differently
Humans and agents both make errors. The difference isn’t the error rate. It’s the compounding dynamics.
Human error compounding is self-limiting:
- A human learns not to repeat the same mistake (either through pain or someone screaming at them)
- A human produces code slowly enough that booboos accumulate at a manageable rate
- When the pain gets bad enough, the human stops and cleans up
- Or the human gets fired and someone else cleans up
Agent error compounding is unbounded:
- An agent has no learning ability across runs. It will make the same mistake indefinitely
- An agent produces code fast enough that booboos accumulate at an unsustainable rate
- There is no pain signal. The human has removed themselves from the loop
- You only discover the mess when you try to add a feature and nothing works
The individual errors are identical. A useless method here, duplicated code there, a type that doesn’t make sense. Harmless on their own. But the rate of accumulation is the variable that matters, and agents shift it by orders of magnitude.
The Pain Signal Theory
Mario Zechner’s key insight: pain is a feature, not a bug.
When a human developer works in a degrading codebase, they feel friction. Things take longer. Patterns stop making sense. This pain creates a natural corrective loop. The developer either:
- Stops and refactors before continuing
- Raises it with the team
- Or at minimum, slows down and pays more attention
This is analogous to how your nervous system works. Pain isn’t the injury. Pain is the signal that prevents further injury. Remove the pain signal (like leprosy does to peripheral nerves), and small injuries compound into catastrophic damage because nothing triggers a corrective response.
Agents remove the developer from the loop. No human in the loop means no pain signal. No pain signal means no corrective response. No corrective response means the booboos compound until the codebase is unrecoverable.
You only feel the pain when it’s too late: when you turn around and want to add a feature, but the architecture (which is largely booboos at this point) won’t allow it.
Merchants of Complexity
There’s a second compounding problem beyond errors: complexity.
Agents are “merchants of learned complexity.” Their training data is full of enterprise-grade architectural decisions, cargo-cult best practices, and abstractions for abstractions’ sake. When you delegate architecture to agents, they produce exactly what they’ve seen most: overengineered, over-abstracted code.
Worse, agents never see each other’s runs. They never see the full codebase. Their decisions are always local. This produces the same pathology you find in large enterprise codebases: massive duplication, inconsistent patterns, abstractions nobody needs. The difference is that enterprise codebases take years to reach that state. With agents, you can get there in weeks.
And once complexity passes a threshold, even agents can’t help you refactor out of it. Agentic search has low recall in large codebases. The bigger the mess, the less likely the agent is to find all the code it needs to change. Which causes more duplication. Which makes the mess bigger. A positive feedback loop toward collapse.
The Practical Response
The answer isn’t to stop using agents. It’s to reintroduce the mechanisms that the bottleneck provided.
Set throughput limits
Cap how much code you let agents generate per day, matched to your ability to actually review it. If you can review 500 lines per day carefully, don’t let agents generate 5,000.
Stay in the code for architecture
Anything that defines the gestalt of your system (architecture, API contracts, data models), write by hand. The friction of writing it yourself is what lets your experience and taste shape the system. Use agents for the boring implementation work inside the boundaries you’ve drawn.
Keep the pain signal active
Review every diff. Not skim. Review. If you’re not feeling occasional friction (“this is getting messy, I should clean up”), you’re not reviewing carefully enough or you’re generating too much.
Scope agent tasks for closed loops
Good agent tasks can be scoped so the agent doesn’t need full system understanding. They have evaluation criteria the agent can check itself against (tests pass, types check, linter clean). The output isn’t mission-critical. If a task doesn’t fit these criteria, it’s a human task.
Accept slower output
Building fewer features, but the right ones, is the goal. The discipline to say “no, we don’t need this” is itself a feature. Speed of code generation is not the metric that matters. Maintainability over time is.
Connection to Quality Gates
This note complements Compounding Effects of Quality Gates. Quality gates (types, tests, linters, CLAUDE.md) are the automated replacement for some of what the human bottleneck provided. They catch errors mechanically, creating a corrective signal loop.
But quality gates alone aren’t sufficient. They catch categories of errors they’re designed for. The human bottleneck caught everything else: the gut feeling that the architecture is drifting, the pattern that’s inconsistent but passes all checks, the feature that nobody asked for.
The complete picture: quality gates handle the automatable constraints. Human throughput limits handle everything else. Both are required.
Key Takeaways
- The human bottleneck was a quality mechanism, not just a limitation. It rate-limited error compounding and created corrective pain signals.
- Agent errors compound differently because agents don’t learn, produce code faster, and don’t feel pain from degrading codebases.
- Pain is a feature. Removing developers from the loop removes the signal that triggers cleanup.
- Reintroduce the mechanisms explicitly: throughput limits, architectural ownership, active review, scoped tasks.
- Quality gates are necessary but not sufficient. Human judgment catches what automated checks cannot.
Related
- Compounding Effects of Quality Gates – The automated side of error compounding prevention
- Online Learning via Constraints – The worker-observe-constrain loop that requires human observation
- Skill Atrophy – Which human skills to protect from agent-driven atrophy
- Growth vs Polish Phases – When to let agents generate vs. when to slow down and polish
- Highest Leverage: Plans & Validation – Where human judgment has maximum impact
- Goodharting Prevention – When agents optimize for the wrong metric
References
- Mario Zechner, “Thoughts on slowing the fuck down” – Original article articulating the human bottleneck as quality mechanism
