AI velocity is bidirectional

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 focuses on productivity. You ship faster, do more with less, and go from idea to production in days instead of weeks. 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, including the good and the bad.

---

The dominant myth

Most AI productivity content treats the gain as additive: feature velocity, code quality, faster iteration. The implicit model assumes that AI makes existing work strictly better.

That model is wrong, or at least incomplete.

AI acts as a multiplier. It increases output in every direction: solid processes yield more solid code faster, while gaps compound alongside 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.

The metrics omit the weeks between deciding to migrate and having stable SSE in production: SSE graceful-close behavior (self-close at 100 seconds, reconnect at 100ms), orphan stream cleanup (we cleaned up 20,000 orphan streams in December alone from the earlier chat SSE implementation), and 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 and made it easier to skip the parts that were supposed to slow you down: thinking through edge cases, testing reconnection behavior, and 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 at the edges. It can pass tests while failing users in specific circumstances: a button that doesn’t appear at the right moment, a click that redirects to the wrong URL, or a permissions check that passes when it shouldn’t.

These are predictable results of shipping fast without proportional investment in edge-case coverage. With AI, you can ship 5 features in the time it took to ship 1, including 5 partially tested features.

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

AI makes it possible to run 5 open source projects in parallel while building a full-time product. The throughput and cognitive overhead are real, but the latter compounds differently from managing a team.

Each project has its own context: stack, conventions, open issues, and users. AI helps you re-enter that context quickly. Choosing where to spend attention remains yours, as does noticing when three projects have diverged from their original scope or when architecture decisions conflict across projects.

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

Pain, rather than a plan, produced these guardrails.

“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. The incident happened in YOLO mode (approving everything quickly), where 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. The instruction records the intended boundary; enforcement requires a configured control on the action. Claude Code under the hood explains event-specific hooks and client permission checks.

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

The full UVAL protocol expands four steps: Understand before asking, Verify by explaining back, Apply by modifying rather than copying, Learn by capturing the insight. The protocol was 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 means features land with explanations for their structure, edge cases considered before shipping, test coverage that reflects their behavior, and code the next developer (or you, in three months) can reason about without reconstructing decisions from scratch.

Bad velocity leaves behind clean metrics and unanswered reasoning. Three weeks later, someone asks why the token refresh is triggered on every request instead of on expiry, and you open the file without an explanation.

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 alone cannot distinguish a team that is learning from one accumulating debt it will pay back in six months.

---

Seven months of velocity and debt

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.

---

---

What seven months of data required

AI velocity is real in both directions, and teams usually learn that after shipping something they cannot explain three months later. The useful discipline is recognizing whether a commit moves the product forward or moves the debt counter. Guardrails cost time to design, enforce, and maintain, but they stop the multiplier from working against you. I started with one rule and applied it consistently.

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.

---

YSNK

(You should now know)

• AI multiplies your process: solid practices ship faster, and gaps compound at the same rate as features
• The debugging bill for a fast migration lands after the migration. Budget for the aftermath as well as the ship date
• Bug velocity tracks feature velocity by default, unless you add proportional test coverage as you scale output
• “Never merge without user approval” exists because YOLO mode does exactly what you asked, including the thing you said in a moment of distraction
• A pause before you can explain why code is structured that way signals bad velocity more clearly than the commit log