Faster Generation, Not Faster Delivery: Where the Time Went

Time moved into requirements, verification, security, and release. The AI-Native SDLC playbook admits it: the human is now the bottleneck at every stage except writing code.

An agent writes a function in a minute. It used to take an hour. The math is simple: an hour became a minute, delivery accelerated sixty-fold. Except delivery didn't accelerate. The release goes out on the same schedule as before the agent, or slower. The time didn't disappear. It moved.

I'm a product manager at Explyt, where we build an AI agent for JetBrains IDEs. Our team and our users keep seeing the same picture: the agent generates code faster than the team can review it. This article breaks down where the time saved on generation went, and why delivery can only be accelerated where the human still works.

TL;DR

• Code generation is one stage of many. Requirements alignment, verification, security, and release take more time than writing code. At these stages the agent doesn't make the decision for the human.
• AWS AI-DLC frames the rule: "AI creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation." The agent executes; the human decides.
• The CTO caps release velocity at the speed of team comprehension. If the team doesn't understand the code, the release doesn't ship, regardless of who wrote it.
• Rising MTTR with a stable defect count is an early signal of model loss. It shows up before review metrics shift.
• Tools multiply what the team already does. Without engineering discipline, faster generation accelerates unsafe delivery.

Where the time went

The principle is well known: when you remove one bottleneck, the constraint moves to the next stage. Before the agent, the bottleneck was writing code. The agent removed it in minutes. The next constraint falls on the stages where the agent can't make the decision for the human.

Here's what happens to a change the agent generates in twenty minutes:

Requirements alignment. The agent received a one-line task and produced working code. But what was actually needed? The reviewer reconstructs intent from the diff, because the spec was too loose to check the result against. The time the developer used to spend writing code, the reviewer now spends reconstructing intent.

Verification. The agent wrote tests, and they're green. But are they testing the right thing? A test written by the same agent that wrote the code can be wrong alongside it. Independent verification requires a separate review, a separate run, a reproduction of the scenario. All of it takes time that generation didn't cut.

Security. Vulnerability scanners and access policies didn't get faster because code was generated faster. Faster generation increases the volume of changes that need scanning. The load on security grows.

Release. A two-week sprint now contains forty changes instead of eight. Each one needs review, merge, staging deployment, and sign-off. The release pipeline didn't accelerate. It just has more changes flowing through it, and the queue grew.

AWS describes this structure in the AI-Driven Development Life Cycle (AI-DLC): "AI creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation" [1]. AI proposes and executes. The human decides. The time that used to go to implementation now goes to decision-making, and that is time the agent doesn't cut.

At Explyt we see where this time settles. Plan mode forces the agent to study the project and the task, ask clarifying questions, and produce a plan with related files. The human reviews the plan before any code is generated. Edit Scope restricts which files the agent can modify for that task. These steps don't speed up generation. They move part of requirements alignment into the moment before generation, when correcting intent is cheaper than after.

Comprehension caps release

The conflict between author and CTO gets described on Reddit in one line: the author wants to ship at the speed of generation, the CTO ships at the speed of comprehension [2]. The CTO is right, and here's why.

Code the team doesn't understand can't be independently verified. Can't be debugged. Can't be answered for in front of the business. When the agent generates code faster than the team can understand it, the queue of unverified code grows. A CTO who ships at the speed of generation ships unverified code. A CTO who ships at the speed of comprehension ships code backed by a model.

This isn't conservatism. The constraint is dictated by the nature of accountability: if the team can't explain a change, it can't be responsible for it. Faster generation doesn't lift this constraint. It makes it more visible.

Rising MTTR as an early signal

If bugs aren't increasing but fixing them takes longer, the team is losing its model of the code. Mean time to recovery (MTTR) rises while the defect count stays stable. This is an early signal, visible before review or coverage metrics shift.

The mechanics are simple. A developer who understands the code localizes a bug from symptoms: knows which module is responsible, which inversion of control might be silent, which consumer might have dropped off. A developer who doesn't understand the code brings the agent in to find the cause, and the agent starts by summarizing the architecture instead of localizing. Each such step adds time without moving closer to a fix.

MTTR rises for the same reason the CTO caps release at the speed of comprehension. Without a model of the code, fixing takes longer than generating. The gap in understanding becomes a gap in recovery speed.

Enterprise: accountability for every line

Enterprise voices on Reddit distill the priority to one thing: for large organizations, what matters is not speed of writing but the ability to answer for all the logic [3]. Business context and accountability for every shipped line outweigh generation speed.

Enterprise doesn't ask how many minutes the agent spent writing the code. Enterprise asks: who can explain why this line is here, what business process it serves, and what breaks if it's removed. If the answer sounds like "the agent wrote that," the next question is "who is responsible for it." If there's no answer, the code doesn't ship.

The constraint doesn't depend on generation quality. The agent can write flawless code, but if no human on the team can explain it, enterprise won't release it. Faster generation doesn't help answer "who is responsible for this." It sharpens the question, because it generates faster than the team can take ownership.

Tools multiply what the team already does

Trisha Gee's thesis "Shiny New Tools Won't Fix Your Problem" articulates the principle that ties it all together: speeding up code output without engineering discipline speeds up unsafe delivery [4]. Tools multiply what the team already does.

A team with strong practices, such as regression tests, change-level reviews, and attention to critical paths, gets acceleration from the agent on generation and verification. A team without those practices gets faster generation of unverified code. The tool doesn't create discipline. It scales it.

This explains why some teams report faster delivery while others report growing debt. The difference isn't the agent; it's the practices the agent scales. A team whose reviews were a formality gets a formal review of a large diff. Only now the diff is ten times larger. A team whose tests were mocks gets more mocks. A team with strict acceptance criteria gets verifiable changes faster.

Where the IDE helps

If the bottleneck moved to alignment, verification, security, and release, then a tool that accelerates delivery helps the human at these stages. Faster generation has nothing to do with it.

At Explyt we built the agent around the JetBrains IDE as a source of precise facts about the project. This gives the human evidence to make decisions at the stages where they're now the bottleneck:

Intent and boundaries. Plan mode forces the agent to study the project and the task and produce a plan specifying which files it intends to modify. Edit Scope restricts changes to an explicitly named list of files and directories. The human approves intent and boundaries before generation. Reconstructing them from the diff afterwards is no longer needed.

Verification. Auto Review works as a separate read-only agent that receives the original task and the final diff and runs IDE inspections. It doesn't write code. It reports what it found and ties findings to lines. The human reviews specific findings. Reading the entire diff becomes unnecessary.

Runtime evidence. In Debug mode the agent sets a breakpoint, stops, shows variable values and call stack, makes a minimal fix, and reruns the original scenario and related tests. The human sees the program's behavior. Compilation serves as a necessary but insufficient condition for this.

What changed. The Agent Changes panel shows the full diff with IDE context: which usages are affected, which run configurations were executed, which inspections fired. The human sees what the agent did, with project context. Free-text chat doesn't work for this.

These capabilities don't accelerate generation. They cut the time the human spends on alignment, verification, and confirmation, right where the time moved. One Auto Review run doesn't prove the code is correct. It gives the human specific findings to make a decision on. One Debug session confirms one scenario. But the human makes the decision on facts from the IDE. The agent's paraphrase doesn't work for this.

What to check on the next change

• The agent's plan describes a concrete solution. If after reading it you don't understand what will change, ask for clarification before generation.
• The test the agent wrote for its own code fails without the fix. If the test passed immediately, it documents the implementation but doesn't test the invariant.
• The change is limited to the files you named. A new dependency in the diff is a sign the agent didn't find a solution with the project's existing means.
• You can explain the change in your own words before merging. If you can't, the code isn't understood, and the merge is deferred.

Conclusion

Faster code generation doesn't accelerate delivery. Time moved from writing code to the stages where the agent can't make the decision for the human: alignment, verification, security, release. Closing this gap with faster generation isn't possible. What works is giving the human facts from the IDE to make decisions faster.

The next question: what does the lifecycle look like when built around this gap? In ADLC: The Lifecycle Taking Shape the Explyt team breaks down how two tracks (humans manage, agents execute) change the shape of the process, and which artifacts become durable when code is generated in minutes.

Get started with Explyt

Sources

1. AWS DevOps blog, Raja SP, "AI-Driven Development Life Cycle: Reimagining Software Engineering", 31 July 2025. https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
2. Reddit: discussions about CTOs, release velocity, and code comprehension (community opinions, not proof of scale).
3. Reddit: enterprise discussions about business context and code accountability (community opinions).
4. Trisha Gee, "Shiny New Tools Won't Fix Your Problem", Devoxx UK 2026. https://trishagee.com/presentations/shiny-new-tools-wont-fix-your-problem/