The J Curve Nobody Warned You About
Your team is generating code faster than ever. They're also rejecting half the pull requests. That's not an AI problem. That's a methodology problem — and there's a name for what you're experiencing.
5/25/20263 min read
When AI development goes wrong, it doesn't go wrong slowly. It goes wrong at sprint velocity.
There's a moment in almost every AI adoption story where a manager makes the same mistake.
They see what the tools can do. They see the speed. They tell their team to start using AI for development. They wait for the productivity numbers to follow.
They're still waiting.
What they got instead is the J-curve — the productivity dip that occurs before the improvement, when a new capability is introduced without the system to support it. It's well-documented in technology adoption. It's almost never discussed in the context of AI development. And right now, it's happening inside engineering teams everywhere.
There's a moment in almost every AI adoption story where a manager makes the same mistake.
They see what the tools can do. They see the speed. They tell their team to start using AI for development. They wait for the productivity numbers to follow.
They're still waiting.
What they got instead is the J-curve — the productivity dip that occurs before the improvement, when a new capability is introduced without the system to support it. It's well-documented in technology adoption. It's almost never discussed in the context of AI development. And right now, it's happening inside engineering teams everywhere.
AI is not magic fairy dust.
Here's what the instability looks like.
Your team is busy. That part is real. AI is generating code around the clock. Pull requests are coming in faster than before.
Your engineers are also spending their days in review — reading AI-generated code, tracing its assumptions, checking it against architectural decisions it never knew existed, and rejecting roughly half of what comes through.
That's not acceleration. That's a review tax on top of your existing workload.
Meanwhile, AI has another problem with Agile. The methodology that most teams use works precisely because it breaks work into small, manageable pieces — contained enough that a team can understand what they're building, review it carefully, and ship it with confidence. Sprints exist to maintain that cadence.
AI doesn't respect sprints. It can burn through a sprint's worth of code in hours. When the generation speed outpaces the capacity for review and integration, the sprint breaks down. You're not delivering faster. You're accumulating faster — a backlog of AI-generated code that nobody has fully validated and everyone is responsible for.
That's Bode's Ideal in practice. You increased bandwidth. You did not increase control. The system is unstable.
The artifacts your AI doesn't have.
Here's what most teams skip and then spend weeks paying for.
AI needs to read your Ubiquitous Language — the authoritative glossary of domain terms, architectural concepts, and naming conventions that define how your system thinks about itself. Without it, AI generates code in its own language, not yours.
AI needs a PRD — a structured, precise product requirements document that defines what the feature is, what it isn't, who it's for, and what success looks like. Vague requirements become vague code. At 10x speed.
AI needs your coding standards and style guides — not as suggestions, but as constraints. Architecture rules. What patterns do you use and why? What you never do and why. Without these, AI picks patterns from the internet, not from your codebase.
These aren't bureaucratic overhead. They're the control loops that make AI development stable. They're the feedback mechanisms that tell AI what "right" looks like before it starts generating.
This is why I built Camino.
The teams winning with AI aren't the ones with the fastest generation. They're the ones who built the system around it — who understood that the J curve is real, that the dip is not a tool problem, and that the way out is methodology, not a different model.
Camino is a spec-driven development system built for exactly this: gated phases, structured requirements in EARS notation, mandatory context artifacts, and dual acceptance gates that neither the engineer nor the AI can wave through.
The J curve ends when your control loops match your speed.
Anyone can generate. The question is whether what you're generating is actually ready to ship.