An AI-generated CAD pull request should be merged only when the team can explain its assumptions, test its failure modes, and name the person who will own it after the author leaves. Shipping it without that evidence preserves Friday’s momentum by transferring an unknown liability into Monday’s product.
On 4 June 1996, Ariane 5 Flight 501 lifted off from Kourou, French Guiana. About 37 seconds into the flight, its guidance system failed. The rocket veered from its intended path and destroyed itself.
The failure began inside software carried over from Ariane 4. A conversion from a 64-bit floating-point value to a 16-bit signed integer caused an exception because the value exceeded the permitted range. The backup system failed in the same way because it ran the same software.
The inquiry board chaired by Jacques-Louis Lions documented the failure in the official Ariane 5 Flight 501 Failure report. One of its most useful findings concerned code that had remained in the system even though Ariane 5 did not need the function during flight.
That is the part worth remembering when a large pull request appears late on Friday.
The code can work while the assumption is wrong
Imagine the review window. The CAD feature produces convincing geometry. The tests pass. The engineer who built it is leaving in a few hours, and delaying the merge means losing the person best able to answer questions.
The founder faces two visible costs. Merge now, or let the branch sit while product momentum slows.
The third cost is harder to see: the feature may contain an assumption nobody has named. Perhaps the generated geometry respects the requested dimensions but ignores a manufacturing constraint. Perhaps the model works for the sample parts and fails when a customer uploads an older design. Perhaps the test suite confirms output shape without checking whether the result can be edited, exported, or manufactured.
This is why finished CAD can conceal more risk than an obvious error. I explored the same problem from the manufacturing side in what happens when finished CAD hides the wrong manufacturing assumption. A polished model encourages everyone to move on. The missing assumption travels with it.
Ariane 5’s software did what its inherited logic told it to do. The problem was that the surrounding flight conditions had changed.
An AI-generated feature creates the same review challenge. The code can be internally coherent while carrying reasoning that belongs to a different context.
Review the transfer, not only the pull request
The Friday decision should turn on what crosses the ownership boundary when the engineer leaves.
I would ask the engineer to walk through one successful case and one deliberately hostile case. Which inputs make the feature refuse to proceed? Which manufacturing or geometric constraints remain outside the model? What part of the generated code did the engineer rewrite after inspection? Where would the next engineer start if a customer reported a plausible but incorrect result?
These questions test whether knowledge has moved from one person’s head into the product record.
The answers do not need to become a large internal manual. A short decision note can capture the input limits, rejected alternatives, known failure modes, test fixtures, and rollback path. The departing engineer should also identify any generated section they cannot confidently explain.
If that cannot happen before departure, I would preserve the branch and delay the merge. The work remains recoverable. Once merged into an active release path, other decisions begin depending on it.
That distinction matters for a smaller team. When one senior engineer leaves, the remaining team inherits code, customer promises, and a sequence of decisions they did not witness. Kojo’s product-plan redesign after a senior engineer resigned shows why the roadmap must reflect the team that remains, rather than the capacity that existed when the work began.
A merge needs an owner and an escape route
AI changes how quickly a feature can become mergeable. It does not shorten the time required to understand who carries the consequences.
Before approving the pull request, I would require three things: a named owner for Monday, tests tied to the feature’s stated assumptions, and a way to disable or reverse it without untangling the rest of the release.
The named owner matters because “the team” cannot answer a customer report. The assumption tests matter because ordinary unit tests may prove that the code runs while missing whether the CAD result is appropriate. The escape route matters because a problem discovered in production arrives under different pressure from one found during review.
There is also a useful separation between merging and releasing. The team can retain the work without exposing customers to it. A feature flag, isolated integration branch, or disabled production path can preserve progress while the remaining engineer reconstructs the reasoning. The right mechanism depends on the codebase. The principle stays the same: preservation does not require immediate exposure.
Friday’s real deadline
The engineer’s departure creates a deadline for knowledge transfer. It does not create a deadline for customer release.
That reframing removes some of the pressure. The founder can use the remaining hours to capture the decision trail, run boundary cases, and assign ownership. If those steps reveal that the feature is understood and reversible, merging may be reasonable. If they reveal that the engineer alone knows why the geometry is safe, the branch should wait.
The Ariane 5 inquiry did not treat reused software as safe because it had flown before. It examined whether the assumptions behind that software still held in a new vehicle.
At 5:47 on Friday, that is the founder’s job too. Before the engineer closes the laptop, write down the assumptions, choose Monday’s owner, and prove that the feature has a controlled way back out.
Comments
No comments yet.