When is optimising for delivery speed the wrong choice?

On four kinds of work: when the risk is building the wrong thing, when the decision is expensive to reverse, when the failure is hidden rather than visible, and when the real constraint is outside engineering. Each shares one property, which is that the cost of being wrong substantially exceeds the cost of being late.

What counts as a hard-to-reverse decision?

Data models that will require migrations for years, public interfaces that third parties integrate against, permission and tenancy models that everything else assumes, and choices that cross a compliance boundary. These are decisions rather than features, and speed gives nothing because the constraint is information rather than execution.

What is a silent failure and why does speed make it worse?

A defect nobody reports because nobody can see it: a rounding error in a payment total, a permission that works for one organisation and not for two, an export that omits rows. Visible failures get fixed within hours because someone complains. Silent ones persist until an audit or a customer discovers them, so releasing faster only means the hidden problem starts earlier.

How do I tell whether the slowest step is really engineering?

Ask what happens the day after the code is finished. If the answer involves waiting on a partner, a regulator, a data agreement, or a compliance review, then engineering speed produces completed work sitting in a queue. That is inventory, and it carries the cost of becoming out of date while it waits.

Does this mean careful work should be slow?

No, and the distinction matters. These four categories call for spending time on deciding rather than on building. The building should still be fast once the decision is made, and a team that is slow at execution is not being careful, it is just slow.

What is the cost of treating every project as high-stakes?

Roughly the same as treating none of them that way. Applying heavy discovery and reversibility analysis to work that is cheap to undo uses up the organisation's patience, and by the time genuinely irreversible work arrives, nobody takes the process seriously. Reserve it for the decisions that need it.

How does this apply to AI-assisted development specifically?

AI code generation shortened the build step and did not change the deciding step, which raises the share of total project time spent on judgment. It also means a wrong decision now produces a larger quantity of code committed to it, so the cost of deciding badly went up at the same time the cost of building went down.

What should a team do differently on irreversible work?

Write down what is being committed to and what would have to be true for it to be wrong, then spend the time to test the assumptions that are cheap to test. A day spent proving that a third-party interface behaves as documented is worth more than a week of implementation built on the assumption that it does.

Is this argument against moving fast in general?

No. Most work is reversible, low-stakes, and fails visibly, and on that work speed is straightforwardly good and hesitation is waste. The argument is only that the four exceptions exist, that they are identifiable in advance, and that applying the default to them is where expensive mistakes come from.

When speed is the wrong goal: Reveneau

Q: Why does releasing fast make a bad idea harder to stop?

Because a released feature gains users, support obligations, documentation, and internal supporters. Removing it becomes a negotiation rather than a decision, so the organisation keeps maintaining something it would not choose to build again. Discovering the idea was wrong before it is released costs a week and no internal arguments.

Our whole pitch is speed. So read what follows as an argument against our own commercial interest, which is roughly the only condition under which this kind of piece is worth reading.

Speed is the right default. Most work is reversible, most decisions are cheap to undo, and hesitation on that work is pure waste. But there are four kinds of work where optimising for delivery speed costs more than it saves, and the ability to recognise which kind you have is worth considerably more than another week off a timeline.

They share one property. In all four, the cost of being wrong is much larger than the cost of being late.

1. When you are not sure you should build it at all

This is the most common and the most expensive.

Going faster on work whose value is uncertain means arriving at a wrong answer sooner and with more code attached. The cost is not the wasted weeks, which are recoverable. The cost is that a released feature stops being an experiment.

Something that is released gains users who now depend on it, support load, documentation, a line in the sales deck, and at least one person internally who advocated for it and would prefer it not be deleted. Removing it becomes a negotiation rather than a decision. So the organisation keeps maintaining a thing it would not choose to build again, and pays for it every quarter in attention.

Discovering the idea is wrong before it is released costs a week and no internal arguments. That asymmetry is the entire argument for discovery, and it is why we would rather spend five days stopping an idea than five weeks building it well. The method is in how to run a product discovery sprint, and the more precise version of the argument is in knowing what to build.

The test: if the feature turned out to be unused in six months, how hard would it be to remove? If the honest answer is "nobody would ever find time for it", you are in this category.

2. When the decision is expensive to reverse

Some work is not really a feature. It is a decision that looks like a feature, and the code is just the part you can see.

The recurring examples:

A data model you will be migrating around for years.
A public interface that a third party will integrate against, at which point changing it is their project too.
A permission or tenancy model that everything built afterwards will assume.
Anything that crosses a regulatory boundary, where the cost of being wrong is not a refactor.

Speed gives nothing here, because the constraint is not execution. It is information. Building the schema quickly does not make it more likely to be the right schema, it only makes it arrive sooner and with less thought behind it.

What helps is writing down what you are committing to and what would have to be true for it to be wrong, then spending time on the assumptions that are cheap to test. A day proving that a third-party interface actually behaves the way its documentation claims is worth more than a week of implementation based on the assumption that it does. We covered the related judgment on codebases in when to rewrite vs refactor legacy code.

Worth being precise about the request: spend the time on deciding, then build fast. A team that is slow at execution is not being careful, it is just slow, and the two get confused constantly.

3. When the failure mode is silent

A visible failure is cheap. The page does not load, someone complains within minutes, an engineer fixes it, and total damage is an hour of embarrassment.

A silent failure is a different thing entirely. A payment total that rounds the wrong way on one currency. A permission check that works correctly for one organisation and stops working when a user belongs to two. An export that quietly omits rows matching a condition nobody thought about. A metric feeding a dashboard that executives make decisions from.

Nobody files a ticket, because nobody can see it. The defect persists until an audit, a reconciliation, or a customer with unusually good attention finds it, and by then it has been wrong for months and the remediation includes every decision made on the bad data.

Releasing faster on this class of work only means the hidden problem starts earlier.

This is also precisely where generated code is weakest. Veracode's Spring 2026 research across more than 150 models found generated code compiling and running correctly over 95 percent of the time while being secure in roughly 55 percent of generations. Code that runs correctly and is not safe is the definition of a silent failure, and it will not be visible in any demo.

The response is not to slow the work down. It is to make the hidden failure impossible by asserting the invariant explicitly, which is a day or two per flow rather than a change of pace. That method is in what to check in an eval suite.

4. When the constraint is somewhere else

The least discussed and the easiest to check.

Ask what happens the day after the code is finished. If the answer involves waiting for a partner to countersign, a regulator to respond, a data-sharing agreement to complete, or a compliance review that takes six weeks regardless, then engineering speed produces finished work sitting in a queue.

That is inventory. And software inventory is worse than physical inventory, because it goes out of date: dependencies move, the surrounding code changes, the assumptions age, and the person who wrote it forgets the context. Work that waits three months for an external approval arrives there needing a week of repair.

When the constraint is elsewhere, the most useful engineering decision is usually to build the smallest thing that lets the external process continue and leave the rest until the approval arrives.

What changed, and why this is more relevant now

AI code generation shortened the build step and did not change the deciding step. That shifts the ratio: when building took twelve weeks and deciding took one, sloppy decisions were partly hidden by the length of the build. When building takes two weeks, the decision is a much larger share of total project time and its quality decides the outcome.

There is a second effect. A wrong decision now produces more code committed to it, faster, which makes it harder to reverse. The cost of deciding badly went up at the same moment the cost of building went down.

Google's 2025 DORA report, across nearly 5,000 technology professionals, found AI adoption associated with higher delivery throughput and lower delivery stability at once. DORA's framing is that AI makes whatever the organisation already is stronger. A team with good judgment about what to build gets more of the right thing. A team without it gets more of everything, sooner.

How to use this without over-applying it

The failure mode of an article like this is a team that decides everything is high-stakes and adds a review process before work that is cheap to undo. That costs about as much as having no judgment at all, and it uses up the organisation's patience so that by the time genuinely irreversible work arrives, nobody takes the process seriously.

Three questions, asked in about two minutes at the start of a piece of work:

If this turns out to be wrong, what does undoing it cost? Cheap to undo means go fast.
If this is broken, how will we find out? If the answer is "a customer will tell us within the hour", go fast. If it is "an audit, eventually", slow down and write the check.
What happens the day after we finish? If something external must approve it first, build less.

Most work passes all three and should move quickly. The point of naming the exceptions is so the default can be applied confidently to everything else.

Thanks to the founders who objected when we recommended a discovery week instead of a build, and to the two who took the build anyway and told us honestly how it went. Both outcomes taught us more than the agreeable conversations did.

Fast is the right default. Knowing the four places it is not is what makes the default safe to follow.

Related guide: How to scope the first project.

Sources

Veracode, Spring 2026 GenAI Code Security update: across more than 150 models, generated code compiled and ran correctly in over 95 percent of cases while being secure in roughly 55 percent.
Google Cloud, Announcing the 2025 DORA report: nearly 5,000 respondents, positive relationship between AI adoption and delivery throughput alongside a negative relationship with delivery stability.

When speed is the wrong goal