Approve the AI agent’s code change only when the evidence available at 2:13 a.m. makes the failure contained, detectable and reversible. If the Berlin engineer’s knowledge is required to establish any of those conditions, protect the customer launch by shrinking the change or waiting.
On January 27, 1986, engineers at Morton Thiokol joined a conference call about launching the space shuttle Challenger from Kennedy Space Center the next morning. The forecast was unusually cold. Engineer Roger Boisjoly had already raised concerns about how the solid rocket booster O-rings performed at low temperatures.
Thiokol initially recommended against launching below 53°F, the lowest temperature represented in its available flight data. NASA managers challenged the recommendation. Thiokol management reconsidered and approved the launch.
The outcome was still uncertain when that approval moved forward. The evidence did not establish that the O-rings would seal safely in the forecast conditions.
Challenger launched on January 28 and broke apart 73 seconds later. The Rogers Commission documented the decision process and the technical failure in its report to the president.
A customer launch in Accra is nowhere near the stakes of a shuttle launch. The decision mechanism can still look uncomfortably familiar: time pressure, incomplete evidence, an absent specialist and a request to approve because delay carries a visible cost.
The approval request is hiding three decisions
The Slack message says the AI agent changed the code, tests passed and the launch is waiting. That sounds like one decision: approve or reject.
It contains three.
First, does the change do what the agent claims? A passing test suite answers only the cases encoded in that suite. It says little about an untested dependency, a stale fixture or a production condition the Berlin engineer knows from experience.
Second, what happens if the change is wrong? A formatting defect and an authorization defect should face different approval thresholds. So should a change behind a disabled feature flag and one that alters every customer request as soon as it reaches production.
Third, can the team detect and reverse the failure before the customer does? “We can roll back” is weak evidence until someone identifies the previous version, confirms the deployment path and names the signal that would trigger reversal.
The product manager should separate these decisions in Slack. The thread needs a short claim for each one, backed by something another person can inspect.
Approval depends on the blast radius
An AI agent can produce a plausible patch faster than a tired product manager can rebuild the service context around it. That speed creates pressure to treat generated code as a finished answer.
I would instead ask the agent to reduce the decision.
Can the change sit behind a feature flag? Can it apply only to the launch customer? Can the affected workflow fall back to the previous path? Can the team remove a disputed part while keeping the rest of the release?
A smaller release changes the approval from “Do I understand this service as well as the sleeping engineer?” to “Have we contained what I do not understand?”
That distinction matters on small teams. Limited runway often means one engineer carries years of context that never made it into tests or documentation. Pretending the context exists does not make the launch safer. Narrowing the exposure acknowledges the gap without surrendering the entire schedule.
This is the same reason an evidence trail matters before a consequential automated decision. Two convincing outputs can still conceal the missing proof, as I explored in the evidence trail Monday had to wait for.
A reversible change still needs an owner
Reversibility has operational requirements.
Before approving, the product manager should write down the release boundary, the expected production signal, the rollback trigger and the person who will watch it. If nobody in Accra can interpret the relevant logs, the change is not observable during the hours that matter. If rollback requires the Berlin engineer, it is not presently reversible.
The same test applies to data. A code rollback may restore the service while leaving corrupted records, duplicated messages or customer actions that cannot be undone. The decision must cover the state the code changes, not only the deployment artifact.
This is where launch pressure often distorts the discussion. The customer delay is immediate and visible. The uncertain failure is abstract. Naming the failure mode makes the comparison fair: a delayed feature versus incorrect billing, exposed data, lost records or a blocked workflow.
If the failure could cross a boundary the team cannot restore, wait. If the change can be isolated, monitored and removed by the people awake now, approval may be reasonable.
Leave Berlin a decision record
Roger Boisjoly’s concern existed before Challenger launched. The Rogers Commission could later reconstruct how the recommendation changed because records and testimony preserved the decision path. Documentation did not prevent the failure, but it made the organizational failure visible.
At 2:13 a.m., the product manager should leave more than a green checkmark.
The Slack thread should state what changed, which tests ran, what remains unknown, how exposure was limited and exactly when the team will reverse course. It should also name the question reserved for the Berlin engineer when they wake.
Then make the smallest defensible call. Approve the contained version, postpone the unsafe part and keep one person watching the signal that would prove the decision wrong.
Comments
No comments yet.