Measure Twice. AI Can Cut Fast Enough.

When you start using AI seriously in software development, the first stage is almost inevitable:

“Wow. That was fast.”

A large section of unfamiliar code can be analysed in minutes. Routine changes, tests, refactoring, dependency tracing, documentation — everything starts moving at a pace that feels slightly unnatural.

It is very easy to draw the obvious conclusion:

we will now do the same work, only several times faster.

Then comes the second stage.

You discover that AI really can move fast.

Including in the wrong direction.

And the old engineering rule “measure twice, cut once” starts to sound a little different:

Measure twice. AI can cut fast enough.

Because the real constraint is gradually becoming not the speed of implementation, but the quality of the direction we choose.

A wrong solution does not become right by arriving faster

A person heading in the wrong direction usually gives you at least some time to stop them. AI can cover the same distance much faster — neatly, with sensible structure, comments and sometimes even tests.

You can make a local change to data-exchange logic and break a rare error-handling scenario. You can improve the structure of a module and quietly alter a contract that another part of the system depends on. You can look at an odd architectural decision, quite reasonably decide that it is time to clean it up, and only later discover that this particular oddity has been preserving compatibility with legacy equipment, an external system or historical data for years.

AI has no reason to know why ugly-looking code exists in exactly that form. If the reason has never been recorded, all it sees is a suspicious fragment that appears to be asking for improvement.

Which leads to the more interesting question:

how do you give a very fast implementer enough freedom to be useful without letting it build the wrong system at very high speed?

The first instinct is to write better instructions

When AI does something wrong, the natural response is to explain more precisely how it should behave.

One rule appears. Then another. Then a clarification. Then an exception.

Before long, the instruction set starts to resemble the legislation of a small but remarkably industrious country.

Do not change anything unnecessary. Do not touch the accepted version. Do not declare success without verification. Stop if the initial state is unclear. Record changes. Make rollback possible.

All perfectly sensible rules.

Then you run into an inconvenient fact:

a critical rule that exists only in the task description is still only text.

You can write “do not break the working system” twenty times. It is much safer to arrange the workflow so that changes happen in an isolated environment and cannot quietly alter the accepted version.

You can write “make sure you verify the result”. Better to make verification a mandatory stage.

You can tell an agent not to claim success without evidence. Better still, build the process so that “done” cannot be reached without concrete build, test and review results.

At that point, the rules stop being prose and start becoming part of the engineering system.

AI exposes everything the team used to “just know”

A conventional engineering team carries a surprising amount of knowledge that has never been written down.

One developer knows that a certain module is best left alone. Another remembers that a particular approach has already been tried. The architect knows why an odd constraint exists. Someone remembers a hardware quirk. Someone else remembers the rare integration scenario.

Formally, that information may not exist.

In practice, it is part of the architecture.

As long as the team is stable, everything works.

Then someone leaves, and you discover that half the documentation has resigned with them.

“The documentation exists. In someone’s head.”

This storage system has several advantages. It is fast, flexible and requires no additional server.

There is only one small problem:

it usually exists in a single copy — inside one person.

That approach starts to fall apart almost immediately when AI enters the workflow.

You cannot tell an agent, “Have a look — it is more or less obvious how we normally do this.”

You have to make the context explicit: what the current state of the project is, what problem is being solved, what may change, what must not change, which decisions have already been made, which constraints are mandatory, what the result should look like and how to prove that it has actually been achieved.

That is how I gradually arrived at what, for myself, I call documentation-driven development.

Not in the sense of writing a 200-page specification and opening the development environment six months later.

Quite the opposite.

The documentation becomes a living part of the project and moves with the code.

Code stops being the only source of truth

The project starts to have explicit architectural decisions, constraints, acceptance criteria, a recorded repository baseline, a history of significant decisions, build and deployment procedures, verification results, and a clear distinction between what is known and what is still a hypothesis.

Documentation used to be easy to treat as an appendix to the product.

I increasingly see it as part of the engineering result itself.

Because a software system is not just source code.

It is also the ability to understand why the system is built the way it is, how to build it, how to verify it, how to change it safely and what must not be destroyed by accident.

We always knew documentation mattered. We just rarely wanted to pay for it.

The problem was never understanding.

The problem was economics.

An engineer can spend an hour implementing a feature, and the result is obvious: the feature exists.

Or the same hour can be spent recording an architectural decision, updating a diagram, describing a constraint, documenting a dependency and explaining why the obvious solution must not be used.

The second hour may make the project considerably safer.

It is simply much harder to point at the result.

Especially when the client asks the entirely reasonable question:

“So when are you actually going to start programming?”

Sometimes the change itself takes forty minutes, while several hours go into understanding the existing behaviour, checking dependencies, finding every consumer of an interface, preparing a test and recording the decision.

From the outside, the system has barely changed.

The chances of an unexpected production adventure, however, have gone down considerably.

Documentation therefore tends to follow a familiar lifecycle:

We will write it up later.

Then:

We will tidy it before release.

Then:

Right now we just need to ship.

And a few years later:

Does anyone remember why this works like this?

AI changes the economics of documentation

This, to me, is one of the most interesting changes.

AI sharply reduces the cost of recording engineering knowledge that has already been created.

It can help analyse source-code changes, relate them to architectural decisions, update technical descriptions, compile change histories, gather dependency information, describe test results, turn rough notes into a coherent structure, find mismatches between documentation and the actual system, and prepare context for the next person — or the next agent.

Meaning is still our job.

A model should not get to make architectural decisions simply because it can describe them fluently.

But the mechanical work of turning acquired knowledge into a durable project asset has become much cheaper.

For the first time, it becomes realistic to maintain documentation continuously rather than through an annual heroic clean-up — almost at the same pace as the project itself changes.

And, rather unexpectedly, the client benefits too

For a client, well-documented engineering means much more than a docs folder.

Six months later, you can still understand why a decision was made. A new engineer can join without beginning with an archaeological dig through the source code. Changing development suppliers becomes less painful. A build can be reproduced. You can check whether the current state still matches the decisions that were accepted.

And you can tell the difference between:

“we verified it”

and:

“it should work in theory”.

Most importantly, knowledge about the system starts to belong to the project rather than to individual people.

“Someone will explain it” is not a knowledge-transfer strategy

One of the most common ways of transferring context works roughly like this:

A new developer will join, and someone from the old team will explain everything.

For a couple of weeks, that person barely gets any of their own work done. The newcomer still does not remember everything. A month later, everyone discovers that the most important detail was never mentioned because, to the experienced engineer, it was “obvious”.

If that engineer has already left, the architecture gradually starts to acquire the qualities of detective fiction.

Documentation does not replace conversations between people.

It simply makes knowledge transfer slightly less dependent on preserving a folk epic through oral tradition.

For AI, documentation becomes an interface

Today one agent performs the task. Tomorrow another one does. The model itself may change the day after that.

If important decisions exist only inside the conversation history with one particular AI, the architecture is fragile.

If the project has an explicit state, rules, decisions, constraints, criteria and evidence, the next implementer does not begin by reconstructing the previous conversation.

It begins from the canonical state of the project.

In that sense, documentation becomes an interface between the human, the project and the automated implementer.

It makes engineering context portable.

The funny part is that the process AI needed turned out to be better for people too

We started formalising the development process because an automated implementer needs precise context.

The result is that the developer understands the task more clearly, the reviewer knows what to review, the manager can see the real state of the work, a new engineer can join more easily, and the client has a clearer view of what has actually been done.

Which gives us a rather satisfying paradox:

AI has finally pushed us to do what we had considered good practice for human teams for years, but kept postponing because it was expensive.

Documentation alone is not enough

If an implementer can change a large system very quickly, it also needs technical guardrails.

That means a precise baseline, an isolated change environment, separation between implementation and review, mandatory verification, evidence of the result and the ability to roll back.

There is another rule I particularly like:

The sentence “I checked everything; it works” is not, by itself, a verification result.

A useful rule well beyond AI.

A good system needs to be able to say “I don’t know”

Automated development should not have only one state:

“Done.”

It also needs:

“I cannot verify this.”

“The initial state is unclear.”

“There is not enough information.”

“Continuing would be unsafe, so I stopped.”

At first glance, that sounds like a weakness.

In practice, it is the opposite.

A system that always reports success is extremely convenient.

Right up to the first serious incident.

Sometimes an honest “I don’t know” is worth considerably more than a confident three-page report.

So what actually changed?

AI genuinely accelerates engineering work. We can investigate code faster, build prototypes faster, test hypotheses faster, write tests faster, refactor faster and maintain documentation with far less effort.

A small team can now handle a volume of work that previously required noticeably more people.

But faster has stopped being a value on its own for me.

You can write the wrong feature faster.

Choose the wrong architecture faster.

Automate a bad process faster.

Replicate a bad decision faster.

So the main question is no longer:

“How quickly can AI do this?”

Nor even:

“Can we trust it?”

The question is:

How do we design the process so that trust is not the only control mechanism?

Let AI do what it is genuinely good at: investigate, propose, implement, compare, automate routine work and help preserve knowledge.

But significant results must remain verifiable.

If a rule is critical, it should exist not only in the prompt but in the structure of the process.

If the result matters, there should be evidence.

If the change is dangerous, there should be a boundary.

If the information is insufficient, stopping is better than confident invention.

Perhaps the biggest change is not code generation at all

AI has forced me to answer old engineering questions much more precisely:

What counts as a result?

How do we prove that we obtained it?

Where does knowledge about the system live?

Can development continue without the author of the previous decision?

Can we change implementers without losing context?

Can we reproduce the result a year from now?

And that led me to a conclusion I did not expect at the beginning.

Perhaps one of the most important effects of AI is not that code can now be written faster.

AI makes it economically possible to develop software in a way where knowledge about the system is recorded almost as quickly as the system itself changes.

That changes more than the tool.

It changes the engineering process.

So I now mentally phrase the old rule a little differently:

Measure twice. AI can cut fast enough.

The cutting really has become faster.

Which means measuring well has only become more important.