Ship without the engineer only when the recorded context can prove what changed, what must remain true, and how to reverse the release. A workbench full of notes and generated explanations is useful, but the customer deadline should depend on evidence you can check yourself.
In April 1970, the Apollo 13 crew faced rising carbon dioxide inside the lunar module. The command module had square lithium hydroxide canisters. The lunar module’s system used round ones. The crew had the filters they needed, but the parts did not fit.
NASA engineer Ed Smylie and a team in Houston had to design an adapter using materials already available inside the spacecraft. Mission Control then had to transmit the procedure to astronauts Jim Lovell, Jack Swigert and Fred Haise. Nobody could walk over to the spacecraft, inspect the assembly or correct a misunderstood step in person.
NASA’s Apollo Flight Journal documents the episode as the “square peg in a round hole.” The solution worked because the team converted specialist knowledge into a procedure that another person could execute and verify under pressure.
That is the standard I would use at 09:12 when the only engineer is offline.
Recorded context must support a decision
An AI workbench can preserve commit summaries, architecture notes, test results, customer requirements and earlier reasoning. That record reduces dependency on whoever happens to remember why the code looks the way it does.
Yet volume creates false confidence. Twenty pages of generated context may still leave the decision-maker unable to answer three basic questions:
- Which customer outcome does this release change?
- What evidence shows the critical path works?
- How do we return to the previous state if it fails?
If I cannot answer those questions without interpreting the absent engineer’s intentions, I do not have operational context. I have a transcript.
This distinction matters for a small team in Accra, Lagos, Berlin or New York because one engineer may hold several roles at once. They wrote the integration, configured the deployment and spoke to the customer who reported the original problem. Their absence exposes every undocumented assumption at the same time.
Trust the trail, then test the claim
I would begin with the smallest customer promise due that day. Suppose the release changes how an AI assistant classifies uploaded invoices. The workbench says the new prompt fixes a merchant’s example and the branch passed its tests.
That gives me a claim. I still need a trail.
I want to see the exact input that previously failed, the expected output, the result produced by the candidate release and the cases that must remain unchanged. I also want the deployment steps and rollback path written for someone who did not build the feature.
The recorded reasoning can tell me why the engineer chose one approach over another. The test evidence tells me whether the current build still earns that reasoning.
This is especially important with AI features because a convincing example can hide a weak boundary. A correct total on one document says little about a different layout, missing field or ambiguous currency. The same problem appeared when Youssef’s AI showed the wrong closing balance: the launch decision depended on making the consequential step visible, rather than trusting a plausible result.
A deadline does not define acceptable risk
Customer pressure changes the cost of waiting. It does not change what the product can safely prove.
I would separate the release into reversible and irreversible consequences. A change behind a limited flag, with observable output and a tested rollback, gives the team room to ship narrowly. A migration that rewrites customer records, changes billing or removes the previous path deserves a higher bar.
The decision can then be smaller than “ship or delay.”
I might release to the affected customer account, keep the previous version available and monitor the exact transaction that motivated the change. I might deliver a manual workaround while holding the automated path. I might also delay, tell the customer what remains unverified and name the next check.
Those options protect runway better than a broad release followed by a recovery nobody prepared for. Knight Capital’s 2012 software deployment offers the harsher version of that lesson: an old function remained active on one server, and the resulting trading incident cost the firm about $460 million. The US Securities and Exchange Commission’s administrative order documents both the deployment failures and the missing controls. I explored that case in the one server Knight Capital missed.
Build the handoff before the absence
Apollo 13’s adapter instructions mattered because the astronauts could perform them with known materials and confirm the result. The procedure carried enough context to support action at a distance.
A useful engineering record should do the same before anyone goes offline. For every customer-critical release, capture the promise, changed components, known failure cases, evidence from the candidate build, deployment sequence, observable success signal and rollback procedure.
Then ask someone other than the author to follow it.
If that person gets stuck, the record has already failed its test. Fix the handoff while the engineer is available. The next Tuesday at 09:12 should begin with a verified procedure, not a search through yesterday’s chat.
Comments
No comments yet.