Engineering Strategy in the AI Era: Why Every Assumption Needs an Expiry Condition

An engineering strategy approved today can be wrong within two quarters, because AI moves the constraints the plan assumed. Robert Kimani makes this case in a recent article, and this piece extends one claim from it: every major bet should record the condition that would end it.

Kimani argues that an engineering strategy can go stale without anyone making a mistake

Kimani describes a leader who approves hiring five engineers, building an internal AI platform, and reorganizing two teams. Six months later, output has risen but delivery has not sped up. Reviews take longer, CI queues are growing, and security verification work has increased. In his account the original plan was not necessarily flawed. The conditions it relied on moved. He cites figures to show the pattern is common, including a September 2026 CloudBees survey of 213 enterprise technology leaders in which 57% named reviewing, testing, and deploying as the bottleneck, against 35% for writing code.

His remedy has several parts. Leaders should match the strength of each commitment to the evidence behind it, review long bets more often than their full time horizon, and connect the people who see warning signals, such as platform, security, and staff engineers, to the people who can act on them. At the center is an assumption register. For each major bet it records the decision, the conditions that must hold, an observable signal, an owner, and a reassessment trigger.

A register entry only protects a bet if its signal is chosen before approval

A signal chosen after a bet is under way tends to be the one that looks best. A signal chosen at approval is a commitment the sponsors cannot adjust later. The practical rule I propose is to write each register entry as an ending condition. It names a measurable signal, a threshold, a time window, and the person who may call the reassessment. An illustrative entry, which I invented for this piece and which is not from Kimani’s article, would read: if median time from pull request opened to merged rises for two consecutive quarters while code volume also rises, the internal platform bet is reopened by the platform lead.

The signals in Kimani’s example, review duration, CI queue length, and security verification load, already suit this format because teams can measure them without new tooling. The value of the ending condition is social. Reopening a funded program is awkward when no one agreed in advance what evidence would justify it. With the condition on record, the reassessment is the execution of an earlier decision and no one has to accuse the sponsor of failure.

Gartner’s cancellation forecast shows that cost, value, and risk controls are all testable assumptions

In a press release dated 25 June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. This is a forecast and not a measured outcome, so I use it only as a list of the assumptions that tend to break. Each of the three maps to a register line: a cost per completed task that the budget assumed, a value metric the sponsor named at approval, and a control that must be in place before agents touch production systems.

Written as ending conditions, those lines turn a surprise cancellation into a planned decision. A program that is stopped because a threshold agreed a year earlier was crossed has a different internal story than one cut in a budget round. The first teaches the organization which assumptions held. The second teaches it to avoid proposing ambitious work.

Reversibility should set how often each assumption is reviewed

Kimani cites Jeff Bezos’s distinction between one-way and two-way doors. In Amazon’s 2015 shareholder letter, Bezos describes irreversible decisions that “must be made methodically, carefully, slowly,” and reversible ones that can be made quickly by high-judgment individuals or small groups. He warns that large organizations tend to apply the heavy process to the reversible kind, which produces slowness.

Applied to a register, this means entries should not all carry the same weight. A two-way door, such as a three-month trial of a coding assistant for one team, needs one signal and a light check. A one-way door, such as a multi-year platform commitment or a restructuring, needs several signals and an early review date. A uniform register would repeat the mistake Bezos describes by loading reversible experiments with heavy governance.

An ending condition can misfire, so it should trigger a review and nothing more

There are real limits. A metric can move for reasons unrelated to AI, such as a hiring wave or a change in release policy, so a tripped threshold is evidence that calls for a conversation and does not prove the bet failed. Some investments get worse before they get better, and a threshold set too tight would end sound platform work in its first quarter. A register can also decay into paperwork that no one reads. For these reasons the trigger should open a decision meeting with a named owner, as Kimani proposes, and should not cancel anything automatically. Where a bet has no measurable signal at all, that gap is itself a finding, because it means the sponsors cannot say what would change their mind.

Why This Matters for Engineering Leadership

Leaders approve strategies at a point in time, and AI changes the constraints between approvals. The question that keeps a strategy honest is what evidence would end this bet, and who is allowed to say so. From an AI governance view, a decision with no stated ending condition has no real accountability, because no one can show when it should have been revisited. Leaders who ask for the ending condition at approval give their teams permission to report bad news early and make reassessment part of the plan.

FAQ