The Decisions Nobody Can Check
'Is this risky?' is answered several times a week by the person who has been there longest. Nobody records the reasoning. Your most consequential decisions run through an oracle with no audit trail.
"Is this risky?"
Somebody asks it in every engineering organisation, several times a week. Usually of the person who has been there longest. That person thinks for a moment and says yes or no, and the organisation acts on the answer.
Nobody records the question. Nobody records the reasoning. Nobody can reconstruct, six months later, why the decision went the way it did. And it was probably right — those people are usually right, which is why they get asked.
But consider what that process actually is: your most consequential technical decisions are being made by an oracle with no audit trail, whose accuracy you cannot measure and whose availability you do not control.
The cost is invisible by construction
This never produces an incident report. When the answer is right, nothing happens and nobody notices a process worked. When it is wrong, the consequence surfaces weeks later attached to something else — a bug, a delay, an outage — and gets attributed there.
So the failure rate of your most important decision-making process is unknown, and unknowable, because the decisions are not written down in a form that could be checked against outcomes.
Deloitte attributes 64% of software defects to the requirements and design phases — the decision phases, not the coding phase. The IBM System Science Institute's figures put a defect found in maintenance at roughly 100× the cost of fixing it at design, and one found in testing at 15×. The Standish data has long put around 68% of projects in the challenged-or-cancelled column.
Those three numbers describe the same thing from different angles: the expensive failures happen at the moment of deciding, and they are cheap to prevent and expensive to discover.
Three properties a decision should have
The fix is not more process. Most of these decisions are correct and should stay fast. What they lack is not deliberation — it is durability.
It should be checkable. Not "billing is affected" but "this touches the renewal path and the access gate, here are the files". A claim with a source can be verified in seconds by someone else. A claim without one can only be trusted or re-derived, and re-derivation is the expensive thing everyone is trying to avoid.
It should survive the person. If the reasoning exists only in one head, the decision cannot be revisited when circumstances change. Teams end up living with constraints whose justification nobody remembers — the guard that everybody routes around because removing it feels dangerous and nobody knows why it is there.
It should be reviewable after the fact. Not to assign blame, but because a decision you can revisit is a decision you can learn from. Right now most organisations have no way to ask "were we systematically wrong about a class of thing", because the record does not exist.
Why this got more urgent
Two things changed at once.
More decisions per unit of time. Code generation is cheap now, so more changes are proposed, so "is this risky" is asked more often — while the number of people who can answer it stayed the same. The oracle is now a bottleneck as well as a single point of failure.
A new source of confident answers. An AI assistant will answer the risk question immediately and fluently. DORA finds 90% of technology professionals now use AI at work, and 96% do not fully trust that its code is functionally correct. Yet the same assistants are increasingly consulted on judgement questions, where there is no compiler to catch an error and no test suite to disagree.
An unverifiable answer from a person at least comes with a track record. An unverifiable answer from a tool comes with nothing — and arrives in the same confident register whether it is grounded or reconstructed.
What to do about it
Write the impact analysis before the branch, not in the pull request. At review time the change exists and the analysis is a rationalisation of it. Before the work, it is a scoping decision — cheap to change, which is the entire point.
Require citations in decisions, not just in code. "This affects the renewal path (billing/renew.ts:88) and the access check (auth/gate.ts:140)" is auditable. "This affects billing" is a feeling with a confident delivery.
Record the misses. When something surfaces that a decision did not anticipate, write down what it was and why it was missed. A dozen entries in and you have a map of where your system's real coupling is — which is the map nobody has, and the reason this keeps happening.
Ask for the uncertainty explicitly. Whether of a person or a tool: "what part of this are you least sure about?" People answer this well and volunteer it rarely. Tools answer it only if asked, and a tool that never expresses uncertainty is not more certain — it simply is not tracking it.
Stop treating the oracle as a resource. If one person answers most of the risk questions, that is not seniority working as intended. It is a concentration you have chosen not to look at.
The reframe
Software organisations have spent a decade instrumenting delivery — build times, deploy frequency, mean time to recovery. Almost none have instrumented deciding, even though the evidence says that is where most of the expensive failures originate.
The goal is not slower decisions or a committee. It is decisions that leave a trace: what was considered, what it was based on, and where somebody could check.
An answer nobody can check is a second opinion from a source with no accountability. You may act on it, and it may well be right. You simply have no way to know — and neither will the person who inherits the consequence.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
Why are technical decisions rarely recorded?
Because they are usually right and always fast. The senior person asked "is this risky" answers correctly most of the time, so nothing appears to go wrong and no process failure is visible. The cost only shows up later, attached to a bug or a delay, and gets attributed there instead.
Where do most expensive software failures originate?
In the decision phases, not in coding. Deloitte attributes 64% of defects to requirements and design, and the cost multiplier is steep — roughly 15× to fix at testing versus design, and around 100× in maintenance. Failures are cheap to prevent at the moment of deciding and expensive to discover afterwards.
What makes a technical decision durable?
Three properties. It can be checked, because claims cite sources someone else can open. It survives the person who made it, so the reasoning can be revisited when circumstances change. And it can be reviewed afterwards — not to assign blame, but so the organisation can notice if it is systematically wrong about a class of thing.
Does using AI for risk assessment make this better or worse?
Potentially worse, unless answers carry evidence. An unverifiable answer from a person at least comes with a track record. An unverifiable answer from a tool arrives in the same confident register whether it is grounded or reconstructed, and there is no compiler or test suite to disagree with a judgement call.
How do we start without adding process?
Move the impact analysis before the branch rather than into the pull request, require that decision claims cite a file, and keep a short log of what each decision failed to anticipate. After a dozen entries that log becomes a map of where your system's real coupling is.
Related articles
Everyone Is Speaking a Different Language About the Same Product
Support, product, engineering and finance describe one fact in four vocabularies with no shared object connecting them. Every handoff is a translation, and 64% of defects originate there.
When the Person Who Knew Leaves
Handover documents fail for a reason that is not laziness: the departing person does not know what they know. Expertise is retrieved by situation, not enumerated on request.
What to Measure When AI Writes the Code
Most engineering dashboards were designed for a world where producing code was expensive. Six numbers that still mean something, and three things to stop reporting.