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.
September 2025: 171 commits. August 2025: 57 commits. Same developer, same codebase, same hours. The difference was adopting Claude Code in mid-August and spending evenings tuning the config instead of just using the suggestions.
What nobody was saying out loud: everything accelerated. The good and the bad.
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. The aftermath didn’t. The velocity win was real. So was the debugging cost that followed.
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.
The pattern: AI-generated code is often correct for the happy path and wrong for the edges. Not wrong in ways that fail tests, 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.
The corrective: 283 unit tests added in three focused phases (January 2026). SonarCloud integration. Code duplication from 55% to 8%. Not because the velocity was wrong, but because the velocity required 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 actually 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 explicit confirmation. The rule is one line. The lesson behind it: in YOLO mode (approving everything quickly), the AI will do 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.
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. Short version: Understand before asking, Verify by explaining back, Apply by modifying rather than copying, Learn by capturing the insight. Exists 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 don’t tell you which kind of velocity you’re running. The code review conversations do. The debugging sessions do. The questions you can’t answer about your own codebase do.
Measuring velocity without measuring understanding is measuring the wrong thing.
What the data actually 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. The narrative that only shows the wins is incomplete. So is the narrative that only shows the costs.
The accurate picture: AI-assisted development produces more, faster, in both directions. The teams that handle it well build guardrails fast enough to catch what velocity leaves behind. The ones who only measure speed are measuring the wrong thing.
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.