AI Velocity Is Bidirectional
Everyone talks about shipping 10x faster with AI. Nobody talks about accumulating debt 10x faster. 7 months of production data from a real EdTech platform.
TL;DR
| What | Details |
|---|---|
| Context | 7 months building an EdTech platform at Méthode Aristote. Solo then team of 5. 1,100 commits, 49 releases. |
| The claim everyone makes | AI makes you ship faster. True. |
| The part nobody mentions | AI makes you accumulate debt faster too. Also true. |
| 3 negative accelerators | SSE migration aftermath, bug velocity matching feature velocity, context switching amplified by parallel projects. |
| Guardrails built | ”Never merge without approval” rule, Critical Thinking guardrail, UVAL protocol. |
| The framework | Good velocity = features shipped with understanding. Bad velocity = features shipped with hidden cost. |
The dominant narrative around AI-assisted development is productivity. You ship faster, you do more with less, you go from idea to production in days instead of weeks. That’s real. I’ve lived it.
In September 2025, one developer on the team pushed 171 commits. August was 57. Same person, same codebase, and the only change was adopting Claude Code in mid-August and spending evenings tuning the config instead of just running with the default suggestions.
Nobody was saying it out loud yet, but everything had accelerated. The good and the bad together.
The dominant myth
The framing most AI productivity content uses is additive. You get feature velocity, you get code quality, you get faster iteration. The implicit model is: AI takes what you do and makes it strictly better.
That model is wrong, or at least incomplete.
A more accurate model: AI is a multiplier, not just an adder. It multiplies output, in every direction. If your process is solid, you ship more solid code faster. If your process has gaps, those gaps compound at the same rate as your features.
This isn’t an argument against AI-assisted development. It’s an argument for going in with open eyes.
The 3 negative accelerators I observed in production
1. Migration aftermath: -97% traffic, +3 weeks of debugging
In February 2026, we migrated from polling to Server-Sent Events for the workplan real-time feature. The numbers look clean in retrospect: 17,000 requests per day dropped to 500 (-97%). Neon connection pooling went from 905 active connections to under 200.
What the metrics don’t show: the weeks between deciding to migrate and having stable SSE in production. SSE graceful close behavior (self-close at 100 seconds, reconnect at 100ms). Debugging orphan stream cleanup (we cleaned up 20,000 orphan streams in December alone from the earlier chat SSE implementation). Redis Pub/Sub patterns that don’t fail silently under load.
The feature shipped fast, but the aftermath took three times as long to stabilize. The velocity win was real, and so was the debugging bill that came with it.
AI made the migration faster. It also made it easier to skip the parts that were supposed to slow you down: thinking through edge cases, testing reconnection behavior, understanding what happens when the client drops mid-stream.
2. Bug velocity matching feature velocity
November 2025 was the most intense month: 289 commits, 9 releases. The codebase grew fast. Features landed fast. Bugs landed at the same pace.
AI-generated code is often correct for the happy path and wrong for the edges. Not wrong in ways that fail tests, but wrong in ways that fail users in specific circumstances: a button that doesn’t appear at the right moment, a click that redirects to the wrong URL, a permissions check that passes when it shouldn’t.
These aren’t AI failures per se. They’re the predictable result of shipping fast without proportional investment in edge case coverage. The difference with AI: you can now ship 5 features in the time it took to ship 1, which means you can also ship 5 partially-tested features in that time.
We course-corrected in January 2026: 283 unit tests across three focused phases, SonarCloud integration, code duplication cut from 55% to 8%. Not because the velocity was a mistake, but because moving that fast requires guardrails to catch what speed leaves behind.
3. Context switching amplified by parallel scope
Running 5 open source projects in parallel while building a full-time product is possible with AI. The throughput is real. The cognitive overhead is also real, and it compounds differently than managing a team does.
Each project has its own context: different stack, different conventions, different open issues, different users. AI helps you re-enter a context quickly. It doesn’t help you decide which context deserves your attention right now, or notice that three of your projects have diverged from their original scope, or catch that you’ve been making architecture decisions in one project that conflict with decisions you made in another last week.
Context switching amplified by AI is a different kind of problem than the context switching you experience managing people. It’s faster, lower-friction, and therefore easier to do more of than is sustainable.
The guardrails we built
These weren’t planned upfront. They emerged from pain.
“Never merge without user approval” (December 11, 2025)
A Claude Code rule added to CLAUDE.md after the AI merged a PR without my explicit confirmation. One line. What it took to write it: in YOLO mode (approving everything quickly), the AI does exactly what you said you wanted, including the thing you said you wanted in a moment of distraction. The rule slows down one specific step on purpose. For the mechanics of how hooks enforce rules like this deterministically, Claude Code Under the Hood covers the hook event catalog and what “CAN BLOCK” actually means at the execution layer.
Critical Thinking rule
The AI’s default is to accept the problem statement and solve it. The critical thinking guardrail forces a step before accepting: challenge the assumption. Is this the right problem to solve? Is there a simpler approach? What are the second-order consequences?
Added after a pattern of shipping technically correct solutions to the wrong problem. The implementation was fine. The requirement hadn’t been challenged before implementing it.
The UVAL protocol
Documented separately. The four steps: Understand before asking, Verify by explaining back, Apply by modifying rather than copying, Learn by capturing the insight. Written specifically to fight the tendency to ship code you can’t explain three weeks later.
How to distinguish good from bad velocity
The question isn’t “are you shipping fast?” It’s “are you shipping with understanding?”
Good velocity: features land, you can explain why they’re structured the way they are, edge cases were considered before shipping, the test coverage reflects the actual behavior, the next developer (or you, in three months) can reason about the code without reconstructing decisions from scratch.
Bad velocity: features land, the metrics look clean, you move on. Three weeks later someone asks why the token refresh is triggered on every request instead of on expiry, and you open the file and can’t explain it.
The commits won’t tell you which kind of velocity you’re running. You find out in code review, when someone asks why the code is structured the way it is and you have to pause before answering, or in a debugging session three months later when nobody can reconstruct the reasoning behind an auth flow that worked fine until it didn’t.
The velocity number on its own doesn’t tell you whether the team is learning or just moving fast and accumulating debt they’ll pay back in six months.
What the data shows
Over 7 months:
- 1,100 commits, 49 releases: real throughput
- 20 → 150 active students (×7.5): product growth
- 283 tests added in January: catching up on coverage
- Code duplication: 55% → 8%: paying down debt
- 70+ SonarCloud issues resolved: addressing what speed left behind
- SSE: -97% traffic: the win after the aftermath
The wins and the costs are in the same dataset. A narrative that shows only one side misses the actual dynamic: AI-assisted development produces more, faster, in both directions.
The teams that handle it well build guardrails early, usually after the first incident that makes the gap visible. I haven’t found a way to make that happen before the incident.
The guardrails mentioned here, including the UVAL protocol, are documented in the Claude Code Ultimate Guide. If you’ve built similar velocity checks in your own workflow, I’d like to hear about it.