The Speed Trap

Speed is not what you think it is

Speed is not how fast you ship today. Speed is sustained velocity. It is the ability to keep shipping at a high rate without the drag on future work compounding. A team that ships ten times more features this quarter at the cost of making next quarter’s work five times harder is not moving fast. They took a loan. They just haven’t seen the bill yet.

Quality has the same problem. Most teams measure it in the small: does this PR look clean? Does this function do what it says? Those questions are worth asking, but they miss the dimension that matters for this argument.

Quality in the large is a different thing. It’s whether each addition to the codebase makes the next addition easier or harder. It’s whether the system is still navigable at 200,000 lines or two million. It’s whether a new engineer can understand what a component does without reading its entire history. That is the quality measure that determines whether you can sustain speed over time.

Teams regularly optimize for quality in the small while quietly degrading quality in the large. AI accelerates that pattern.

The curve has always existed

This tension is not new. Every engineering team lands somewhere on a speed/quality curve. Where they land is shaped by the stage of the company, the values of the team, what gets praised in code reviews, and what you hire for.

A seed-stage team finding product-market fit might consciously accept significant technical debt. When you don’t yet know what you’re building, over-engineering is a real risk. Moving fast and learning is the job. A Series B company with enterprise customers has different priorities. Reliability is a product requirement at that point, not just an engineering virtue.

That tradeoff is legitimate. It always has been. The argument in this post is not that quality should always come first. The argument is that the equation has changed.

What AI changes about the curve

Four things are different now.

Debt accumulates faster at the bottom. Before AI coding tools, a team with minimal quality controls accumulated debt at a pace the team could occasionally interrupt. Bad code got written, but humans have natural bottlenecks: reviews, meetings, the cognitive cost of context-switching. Those bottlenecks were also accidental governors on how fast the mess could grow. They set a rhythm. The quality in that cadence came not from the ceremonies, but from the pauses. A team that only sprints eventually loses form.

AI removes those governors. A team can now generate more code faster than any traditional quality process can absorb. The data from GitClear bears this out: code refactoring has dropped 60% since 2021, and code cloning has risen 48%. AI-assisted code produces four times more clones than traditional development. Teams with minimal quality controls today are accumulating debt at a rate that would have taken years pre-AI. Now it takes months.

The failure modes are different. AI-generated code has specific pathologies that traditional quality gates were not designed to catch. Code duplication at scale. Design flaws that look locally correct but break at the seams. Elevated security vulnerability rates. CodeRabbit’s 2025 analysis of 470 GitHub PRs found that AI-generated code has 1.7 times more major issues than hand-written code. The tooling most teams have in place was built for a different kind of error pattern.

The time compression is real. The debt wall used to arrive slowly. Teams had years to mature their processes before the consequences became acute. CodeRabbit’s analysis points toward 2026 and 2027 as the reckoning for teams that adopted AI coding tools aggressively in 2024 and 2025 without updating their quality infrastructure. Their framing is plain: 2025 was the year of speed. 2026 will be the year of quality.

The ceiling at the top is potentially higher. This is the optimistic part, and it is real. AI can enforce quality at a scale no human team could manage manually. Automated code review that understands context. Architectural consistency checks across large codebases. Testing patterns that would be too expensive to write by hand. The teams building these systems now may eventually have higher-quality codebases than anything achievable in the pre-AI era. The ceiling is moving up.

That gap has consequences. In early 2026, Amazon experienced multiple Sev-1 incidents, including a six-hour outage on their main ecommerce site that cost 6.3 million orders in a single day. Internal memos attributed the incidents to “Gen-AI assisted changes” with “high blast radius.” AWS Senior Vice President Dave Treadwell acknowledged that safeguards “are not yet fully established.” Amazon’s response: a 90-day safety reset on over 300 critical systems, and a new requirement that junior and mid-level engineers get senior sign-off on any AI-assisted production code changes. One of the largest technology companies in the world is mid-reckoning with the gap between AI adoption speed and quality system maturity.

Stage and values still drive the outcome

What has fundamentally changed is the cost of your position on the curve. If you’re operating without quality systems, understand that AI has made that position more expensive than it used to be. The debt compounds faster. The failure modes are harder to catch. The wall comes sooner. That doesn’t mean operating without those systems is wrong for your situation. It means you should be making the choice consciously, not by default.

The deeper thing is this: your team culture is what actually determines where on the curve you land. How you hire reflects what you care about. What gets celebrated in retros shapes what engineers optimize for. Whether code review is a rubber stamp or a genuine craft conversation shows up in the codebase eventually. AI doesn’t change any of that. It amplifies it. A team with high standards and strong review practices will use AI to move faster without compromising those standards. A team that was already cutting corners will cut them faster.

The pipeline problem

There is a dimension to this that goes beyond the code itself.

The junior and senior quality divide in AI-assisted development is documented and measurable. Senior developers adopt AI tools at more than twice the rate of junior developers, and they catch problems that juniors miss. The code that looks right but isn’t. The architectural decision that works locally but breaks at scale. They have pattern recognition that took years to build, and that pattern recognition is what allows them to use AI productively rather than just accepting its output.

There is another layer to this beyond the technical. Senior engineers have also accumulated product sense. They make architectural decisions with customer context in mind, not just code correctness. A junior engineer wants to make it work. A senior engineer wants to solve the customer’s problem. Those are different goals, and they produce different code. AI cannot close that gap. Product judgment comes from proximity to the problem, from shipping things that failed, from understanding why a technically correct solution missed the point entirely.

This shows up directly in how senior and junior engineers collaborate with AI. Most serious AI-assisted development now involves shaping a detailed plan before asking the model to execute. A senior engineer brings bruises to that conversation. They know which abstractions tend to leak, which integrations have hidden costs, where the last three production incidents came from. They can tell the model what not to do, what edge cases to be mindful of, where to slow down. That kind of guardrail-setting requires experience you cannot fake and cannot shortcut. A junior engineer working with the same model, on the same task, starts that conversation with far less to offer it.

Amazon’s policy response, requiring senior sign-off on all junior AI-assisted code, treats the symptom. The deeper question is what happens to the engineers who never develop that pattern recognition in the first place.

Anthropic’s own research on this is striking: AI users scored 17% lower on knowledge comprehension assessments than developers who wrote code by hand, roughly equivalent to two letter grades. The largest performance gap appeared in debugging questions, which is exactly the skill that separates effective engineers from excellent ones. The mechanism has a name in the research: the “Silent Silo.” Junior engineers stop asking questions because AI answers them. They get the output without the struggle that builds understanding. Debugging something for two hours before understanding why it failed builds judgment you cannot shortcut. The struggle that matters is not the unproductive kind: fighting build tools, chasing environment errors. It is the kind that builds pattern recognition. Making an architectural call and living with its consequences. Tracing a production failure back to an assumption you made six months ago. That is what AI bypasses, and there is no substitute for it.

The pipeline that produces senior engineers requires the struggle. AI can bypass the struggle, but it cannot bypass the growth. This does not mean AI is harmful for junior engineers. It means the way junior engineers use AI matters enormously, and the managers and senior engineers shaping that use are making long-term bets about the health of their teams and the durability of the profession.

The QA gap

There is one more layer that code-level quality systems do not cover: does it actually work for users?

Static analysis tells you whether the code is structurally sound. Code review tells you whether it follows your conventions. Unit tests tell you whether individual pieces behave as written. None of these tell you whether a user can complete a checkout flow, whether a form submits correctly under real conditions, or whether two features that passed review independently break each other in production.

AI-generated code has a specific failure mode here. It can look correct at every layer: clean code, passing tests, approved review. And still miss the user’s actual need. The model optimizes for coherent output, not for whether the thing it built solves the problem it was asked to solve. That gap only shows up when someone uses the software.

QA as a quality system, including functional testing, end-to-end coverage, and exploratory testing against real user flows, is not a relic of a slower era. It is the part of the stack that answers the question the other tools cannot. The metrics tell you the code is healthy. QA tells you the product works. Both have to be true, and in an AI-assisted environment where more code ships faster, the surface area QA has to cover grows with the velocity. Teams that invest in AI tooling without investing proportionally in quality assurance are solving half the problem.

But you cannot functionally test your way out of the problem either. Full end-to-end coverage of everything is expensive in time and compute, and at some point the test suite becomes its own drag on the SDLC. This tension is not new. Over a decade ago, Kent Beck, DHH, and Martin Fowler had a conversation about whether TDD was dead that still has relevant things to say. DHH argued that over-investing in testing creates its own form of design damage: indirection, complexity, test suites that slow you down more than bad code would have. Kent Beck offered a useful frame: optimize across frequency, fidelity, overhead, and lifespan. How fast does the feedback need to be? How accurate? What can you afford to run on every commit versus every deploy versus once a week?

In the AI era, that calculus inverts. GitHub’s own research acknowledges downward pressure on code quality when Copilot is in use, with developers introducing more mistakes and redundancies. Testing skills become more valuable as AI automates routine coding, not less. And tests serve a new function: not just verification, but specification. Writing tests before prompting the model gives the AI a concrete definition of correct behavior to work toward, rather than letting it optimize for plausible-looking output.

The answer is the same as it was a decade ago, just higher stakes: invest in testing where you get the most signal for the cost, and keep the feedback loop tight. A fast unit test suite that covers your critical paths, functional tests for the flows that matter most to users, and human eyes on anything the automated suite cannot reach. The goal is not coverage for its own sake. It is confidence in the things that cannot fail.

What moving up looks like

Moving up the maturity curve is a deliberate act. It does not happen by adopting more tools.

Measure first. Only about 20% of engineering teams currently use metrics to track AI’s impact on code quality. Before you can improve, you need to see what is actually happening. That means being specific about what you are measuring.

The metrics worth tracking are not new: cyclomatic complexity, code churn, duplication, test coverage, static analysis. What is new is that their meaning is shifting, and any thresholds you have internalized from pre-AI codebases should be held loosely. These were established for human-paced development. In a codebase where AI is generating significant volume, the baselines change. What still holds is the directional logic. Use them as trend lines, not targets. GitClear found that AI-written code is already revised within two weeks at a higher rate than human-written code, and duplication, the most unambiguous signal in AI-generated output, has risen 48% since 2021. The specific numbers matter less than whether your numbers are moving in the wrong direction.

For tooling, there are practical options at every scale: SonarQube, Code Climate, CodeScene, and GitClear. Any of these, running consistently, will tell you something true about the direction your codebase is moving. You cannot manage what you cannot see.

Codify what quality means for your stack. Most teams have an implicit answer to this. An AI-assisted environment requires an explicit one. The model needs to know what good looks like before it can help you get there, and that means writing it down in a form it can use. Some will push back here and say instruction files get ignored, that AGENTS.md files don’t actually shape what the model produces. That criticism is real, but it’s aimed at the wrong target. The problem is not that instruction files don’t work. The problem is that overloaded instruction files stop working. ETH Zurich researchers tested context files against Claude Sonnet 4.5 and GPT-5 and found that bloated instruction files reduced task success while increasing inference costs by over 20%. Anthropic’s own engineering guidance frames context as a finite resource with diminishing returns and warns explicitly against stuffing in edge cases. You are not fighting a model limitation. You are fighting a context problem. The fix is not to abandon instruction files. It is to keep them lean.

Keep your base instruction file concise. Put the specifics into targeted reviewer skills and agent commands. A Rails reviewer should know your team prefers thin controllers and fat models. A React reviewer should know you avoid prop drilling and favor composition. An architecture review should know whether you are working in a microservices system with explicit domain boundaries, an event-driven system with defined seam contracts, or a monolithic structure where the conventions are implicit. Whether your team follows a 37signals sensibility or domain-driven design. Those choices, distributed into focused contexts rather than dumped into a single file, stay active in the model’s behavior.

This connects directly to how the best AI-assisted teams work. The pattern is deliberate: shape a detailed plan, then execute in phases. Write the plan, reabsorb the plan, do the work. Each phase has its own focused context. Nothing competes for attention with everything else. Research on progressive prompting found 96.9% average task completion versus 80.5% for direct prompting, and practitioners report the plan-then-execute approach runs roughly 40% faster end-to-end because large chunks of output rarely need to be thrown away. The discipline is the quality system. Quality is the set of guardrails that keeps the codebase reliable and malleable, flexible enough to keep building.

Update your quality gates. Traditional static analysis and linting were designed for human-written code. AI-generated code has different failure modes, and the tooling needs to match the input. This is not an argument for buying more software. It is an argument for understanding what your current gates catch and what they miss.

Change how you review. When roughly 41% of a given PR is AI-generated, reviewing it the same way you review hand-written code misses the specific risks. Asking engineers to annotate their approach choices, adding secondary review for high-AI-percentage PRs, requiring that people explain what they shipped and why. These are different practices than what most teams have in place. Code review in an AI-assisted environment is not a faster version of traditional review. It is a different activity. The norms around it are still forming, and what works today may not be the right answer in six months. The teams getting this right are the ones treating it as something to experiment with and refine continuously, not a process to set and forget.

Invest in junior development intentionally. If your review process allows junior engineers to merge AI-generated code they do not fully understand, you are trading long-term team capability for short-term velocity. The most valuable thing a senior engineer can do right now is not ship more code. It is help the person beside them understand what they shipped. That investment compounds.

Understand the human context window problem. There is a dimension to AI-assisted development that does not show up in any metric: the cognitive cost to the humans shepherding all of it. Steve Yegge’s “The AI Vampire”, Addy Osmani’s comprehension debt framework, and BCG’s March 2026 “brain fry” study each approach the same problem from a different angle, and together they make a case that deserves its own full treatment. A longer post on this is coming. For now, the version that matters here:

The parallel to code quality is direct. The same way a codebase accumulates comprehension debt when code is generated faster than it is understood, a team accumulates cognitive debt when workstreams multiply faster than any human can genuinely track them. The output looks fine until it doesn’t. The person managing it feels fine until they don’t. AI was supposed to reduce developer burnout. For teams that treat every saved hour as an hour to fill with more AI output, it has made it worse. Sustainable pace is not a soft concern. It is a quality system. A team running on cognitive fumes does not produce work that holds up.

The equation is changing

The ceiling is real. Teams that build the right infrastructure are already seeing it: 81% of teams specifically using AI for code review report quality improvements. That trajectory points toward a version of software development where AI makes teams genuinely faster and genuinely better at the same time.

One more thing worth naming. As you build these systems, how you measure whether any of it is working matters as much as the systems themselves. Dr. Cat Hicks has written one of the sharper pieces on this. Her argument is that most organizations measure AI’s impact on development by collapsing complex, heterogeneous usage into single velocity metrics, which tells you almost nothing useful and creates perverse incentives. “Measurement is a practice, not a single thing.” Pair software metrics with qualitative signals. Track across quarters, not sprints. Understand why effects should occur, not just whether your throughput numbers moved.

The speed trap is partly a measurement trap: teams that only count how fast they ship will always optimize for shipping faster, regardless of what it costs them. The bill always comes due. Now it just comes faster.