What Happens When Everyone Approves the Code but Nobody Owns the Workflow?

A pull request can pass review and still create a customer incident when nobody owns the workflow it changes. AI-written code makes that gap easier to miss because it can look complete before the team has proved what happens at the edges.

On 1 August 2012, Knight Capital deployed new software for a retail-order routing system. One server did not receive the new code. When the market opened, the remaining old code was triggered and sent unintended orders into the US equities market. Knight lost roughly $440 million in about 45 minutes. The SEC’s later order describes the deployment failure and the controls that did not catch it.

The code was not waiting for a philosophical debate about quality. It was running. Orders were moving. The business consequence arrived before the team had time to reconstruct which server differed from the others.

Approval can become a substitute for ownership

A pull request gives a team a useful ritual: someone reads the diff, asks a question, checks tests, and presses approve. That ritual matters. It does not answer who is responsible for the customer outcome once the change reaches production.

AI makes this distinction sharper. A model can draft a migration, a fallback path, or an integration change quickly enough that the review feels unusually productive. The diff is tidy. Tests pass. The person who requested the change recognizes the feature they wanted.

Then a customer imports a file with an old field name. An automation retries an action the customer expected to happen once. A support teammate cannot explain why a record changed because the decision sits inside a prompt, a tool call, and a new bit of application code.

Everyone may have approved the code. Nobody may have approved that new operating reality.

For a small team, this is rarely carelessness. Friday is often the day an important customer is waiting, an engineer is about to go offline, or the team wants a demo ready before Monday. AI can compress the build. It cannot compress the need to decide what must remain true for the customer.

The workflow is the unit of review

The useful review question is not, “Does this code work?” It is, “What does the customer now experience from start to finish?”

That question turns a vague concern into a reviewable path. A customer uploads an invoice. The system extracts fields. A person checks a mismatch. The customer receives a result. If the extraction fails, the invoice stays visible, the original file remains available, and someone can correct it without guessing.

Now the team can ask concrete questions:

• What happens when the model returns a confident but wrong value?
• Can the customer repeat the action without creating duplicates?
• Which person sees the exception first?
• Can support explain and repair the result?
• What is the rollback if the change damages active work?

These are product questions, but they belong in engineering review because the code is where the answer becomes irreversible.

This is why I keep returning to the need for accountability before an AI demo. Buyers do not experience your architecture. They experience whether the result can be trusted, corrected, and explained when their own work is on the line.

Assign an owner before the merge

For changes that touch a live workflow, name one person who owns the outcome after release. That person does not need to write every line. They need the authority to delay the merge, narrow the release, require a manual check, or roll back.

The owner should be able to state three things in plain language before approval:

1. The customer path that changes.
2. The failure most likely to hurt that path.
3. The first signal that tells the team the release is causing harm.

This is a small discipline, especially for a team without a dedicated reliability function. It also prevents the common situation where product assumes engineering is watching the behavior, engineering assumes support will report it, and support discovers the issue from the customer.

AI-generated code deserves an additional check: ask the author to explain the logic without referring back to the model. If they cannot explain why a condition exists, what data the change depends on, or how it fails, the code has not yet become the team’s code.

Release scope is a product decision

Knight Capital’s incident was not caused by an abstract lack of care. A deployment difference became a market event because the system acted at full speed before the discrepancy was contained. The same mechanism appears in a smaller product when a new automation reaches every active customer before anyone has watched it handle one real case.

Start with a narrow group. Keep a visible manual path. Review the first exceptions. Decide in advance who can stop the release.

That may feel slower on a Friday. It is usually faster than explaining on Monday why a customer’s work changed in a way nobody can undo.