# Speed is not control

> AI makes software production dramatically faster, but velocity does not establish whether a change is understood, justified or safe. As generation gets cheaper, confidence becomes scarce.

Paper: 01.1
Published: 2026-08-13
Canonical: https://harten.io/papers/01-1-speed-is-not-control/
Original publication: https://www.linkedin.com/posts/harten-technologies_modernisationcontrol-softwareengineering-activity-7493607022110740480-IqSS

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/01-1-speed-is-not-control.jpg?v=237f9971bf0f). Illustrative cover artwork, not an application screenshot or a record of measured results.

AI has made software production dramatically faster.

Code can be generated, explained, refactored and tested in minutes. Tasks that once took days can increasingly be completed in hours.

But speed is not control.

Velocity tells us how quickly change is being produced. It does not tell us whether the organisation understands that change, whether it addresses the right problem, or whether it can be introduced safely.

That distinction becomes critical in modernisation.

Legacy systems contain more than old technology. They contain accumulated business decisions, undocumented behaviour, operational workarounds, hidden dependencies and controls learned through years of experience. Much of this knowledge is not visible in the code alone.

A technically convincing change can therefore still be wrong.

It may misunderstand a business rule that only becomes visible at month end, overlook a downstream dependency outside the application boundary, or change an operational characteristic on which the organisation relies.

AI can produce that change quickly. Its speed does not make the underlying assumptions true.

## The constraint is moving

For much of software engineering, producing the change was the expensive part.

That constraint is moving.

As AI reduces the cost of generation, the scarce capability becomes confidence.

Confidence that the current system has been understood; facts separated from assumptions; important unknowns kept visible; and the proposed change verified against its intended outcome.

This is why measuring AI transformation primarily through generated code, completed tasks or developer velocity is insufficient.

Those measures describe production. They do not establish control.

## Confidence must be earned

Confidence is not the absence of uncertainty.

It comes from making uncertainty explicit and governing what happens next.

That requires engineering rigour. Evidence needs to be distinguished from interpretation. Assumptions need to remain visible. Important unknowns need to survive the pressure to move quickly. And proposed changes need to remain connected to the problem they are intended to solve.

This does not mean slowing everything down.

Routine, reversible and well-understood work should move quickly. But acceleration should be earned by evidence, not granted merely because a tool can generate a plausible answer.

The organisations that benefit most from AI will not simply produce the most change.

They will be those that can establish why a change should be made, what evidence supports that conclusion, and whether the result remains faithful to the intended outcome.

The important question is no longer only:

**How quickly can AI make this change?**

It is:

**What gives us confidence that this change should be made?**

Generation is getting cheaper. Confidence is not.