When AI agents produce a week’s worth of code before Monday stand-up, the bottleneck moves from writing to deciding what deserves review. Apparent velocity becomes a queue of unverified assumptions, and the product lead must slow the merge rate before the team loses control of the release.
On August 1, 2012, Knight Capital Group began routing orders through newly deployed software. Within minutes, the system was sending erroneous orders into the US stock market. The company did not yet know how far the damage would travel or whether it could stop the activity in time.
By the end of roughly 45 minutes, Knight Capital had lost more than $460 million.
The US Securities and Exchange Commission later documented the failure in its order against the company. Knight had deployed new code to seven of eight servers. The eighth still contained dormant functionality that the deployment accidentally activated. The release process lacked the controls needed to confirm that every server held the intended version before trading began.
Knight’s engineers had shipped code. The organisation had failed to establish that the code was safe to trust.
The queue changes the meaning of velocity
An AI coding agent can finish several tickets overnight. By 9:12 on Monday morning, a product lead may find new endpoints, database migrations, interface changes and tests waiting in separate pull requests.
The dashboard looks encouraging. The team cleared work that would have occupied an engineer for days.
Then review begins.
One pull request assumes every account has a billing address. Another adds a dependency nobody selected. A third changes an API response that a mobile client still expects. The tests pass because the agent wrote them around the same assumptions it used to write the implementation.
None of these outcomes makes AI-generated code useless. They change the unit that matters.
Lines written no longer measure progress. Reviewed decisions do.
I would treat that Monday queue as a product incident, even if production remains untouched. Each pull request contains decisions about customer behaviour, data handling, failure states and future maintenance. The longer the queue grows, the harder it becomes for one reviewer to hold those decisions in context.
This resembles a problem I have seen while shipping products across small teams in Africa, Germany and the US. Scarce engineering time makes extra output attractive. Scarce review time makes unchecked output dangerous. Both constraints exist at once.
Limit generation to the team’s review capacity
The first response should be to stop assigning more work to the agents. A queue already beyond review capacity does not need additional code.
Set a work-in-progress limit for generated pull requests. If the team can examine three meaningful changes per day, the agents should not open twelve. Give them smaller tasks or use the remaining capacity for investigation, test cases and documentation that help reviewers make decisions.
Next, sort the queue by risk rather than arrival time.
Review authentication, payments, permissions, migrations and external API changes first. A copy adjustment can wait. A change that alters who can access customer records cannot.
Large pull requests should go back for separation. A reviewer needs to answer one clear question: what behaviour changed, and what evidence shows the new behaviour is correct? When a pull request mixes schema changes, interface work and refactoring, the agent has transferred its speed advantage into human confusion.
This is the same reason I would pause an impressive demo when its assumptions hide the difficult part. The missing page an AI demo avoided may contain the decision that determines whether a customer will pay.
Make every pull request explain its decision
I would require each generated pull request to include four things in plain language:
- The customer or operational problem it changes.
- The assumptions the agent made.
- The failure cases it tested.
- The parts that still require a human decision.
This forces the agent to expose its reasoning surface. It also gives the reviewer a way to reject a change without debating every line.
Passing tests remain useful, but reviewers should ask who chose the tests. An agent can produce implementation and validation from one mistaken interpretation. Independent acceptance criteria, written before generation, create a stronger check.
For higher-risk changes, assign a named human owner before the agent starts. Ownership cannot appear after the queue fills. The owner decides whether the change should exist, which evidence is sufficient and when it can merge.
That principle also appears in product incidents outside code. A fragile feature can pass its happy path while weakening trust in the whole product, as Abena’s team found in what a camera feature taught them about reliability.
The merge rate is the release rate
Knight Capital’s failure did not come from a shortage of software output. The missing protection was a release process capable of detecting that one server differed from the others before the system touched the market.
AI product teams face a smaller version of the same control problem. Generation can run continuously. Trust still has to be earned one decision at a time.
On Monday at 9:12, freeze new agent tasks. Count the open pull requests, mark the changes that can affect money, identity, permissions or stored data, and assign one human owner to each. Merge only what the team can explain.
The remaining queue is not delayed progress. It is unfinished verification.
Comments
No comments yet.