AI / ENGINEERING SYSTEMS

AI makes implementation faster.
Where does the team get stuck?

Andrew Yuan · Adapted essay draft · 2026.10.05

I keep coming back to a question: as code is generated faster, can the engineering system around it absorb that speed?

AI's impact on implementation speed is easy to see. An idea becomes code sooner, and unfamiliar code gets explained more quickly. These abilities are useful, but the path from code to product delivery still requires human understanding and judgment.

So I want to look beyond implementation time. Where else does a change wait?

Start with a Hypothetical Scenario

Suppose implementation time drops to one-third starting tomorrow. Review time, integration conditions, test environments and release cadence all stay the same.

More changes may then wait for review, more fixes may need integration, and more assumptions may need checking during verification. Improvement in implementation can make constraints elsewhere more visible.

This is a scenario for thinking. Actual outcomes depend on the team's workflow. Different kinds of waiting call for different improvements.

Waiting Contains Information

If a change repeatedly waits for review, waiting alone does not explain why. Does the reviewer lack context? Is the change too large? Is the decision-maker clear? Or is the verification evidence still insufficient for a decision?

These can all look like unfinished work, but they point to different next steps. Adding context, reducing scope, clarifying responsibility and improving verification address different constraints.

Mapping a change's path—where it waits, what it waits for and whose judgment it needs—makes the question more specific. This is an observation approach extended from the original bottleneck argument, not a validated method for improving a team.

More Code. How Does Understanding Keep Up?

AI can produce a complete implementation quickly. As changes grow, engineers still need enough context to own the consequences: the problem being solved, the assumptions, the boundaries being changed and the evidence supporting the next step.

We can discuss sufficient understanding through concrete judgments. Can the author explain the risks when a reviewer asks? Can the team revisit the assumptions when verification fails? Does someone know where to investigate when something goes wrong?

Those answers need to develop alongside execution speed.

Three Questions Extended from the Original Posts

The following discussion questions are editorial extensions of the original posts' focus on context, verification and responsibility. They do not describe a fixed process I have used with a team.

1. What context reaches the next person?
   Do the problem, constraints, verified findings and remaining unknowns travel with the change?
2. What evidence is enough for work to proceed?
   What conditions distinguish implementation complete, verification complete and release readiness?
3. Who owns the outcome after release?
   Field behavior needs to inform the owner and the next decision for continued correction to be possible.

For a discussion, choose an actual change and compare the available review records, verification results and decision process. Knowing only that it stalled for a long time does not tell us whether to add people, context or verification conditions.

The Questions I Want to Keep Following

AI will keep changing implementation costs. Engineering management also needs to revisit how context moves, how verification is arranged and how responsibility follows the work.

The next time a team produces more code, I want to keep asking: where did those changes go? What are they still waiting for? What capability did the team retain from this delivery?