Coding Has Stopped. Understanding Hasn't.

Something quiet has happened to the craft of software.

Not to software itself, and not to engineering. To coding in the old sense: a person at a keyboard typing every line by hand. For more and more teams, that way of working has quietly stopped being the main event.

And yet the same survey found more developers distrust the accuracy of AI output than trust it. That tension is the heart of this shift.

The typing changed. The responsibility didn’t.

When a machine writes code, it’s tempting to think the machine is responsible for it. It isn’t. The customer doesn’t mind who typed the line. Neither does the regulator, or the person called at 3am when something breaks.

You are still responsible for every line. You are just no longer the only one writing it.

That changes how we spend our time. In the old world, most of an engineer’s hours went into writing. Increasingly, they go into understanding.

What “understanding” means

Understanding is more than skimming a pull request and clicking approve. In many ways it is harder than writing. It means being able to answer four questions about any part of a system:

FlowWhere does data come in, where does it go, and what touches it on the way?

IntentWhy does this exist, and is it solving the right problem?

FailureWhat happens with bad input, a slow dependency or a retry?

Trade-offWhy this design and not a simpler one? What will hurt in a year?

AI is a fast, tireless collaborator. It can write code that works. It doesn’t always know what is right for this business, this customer or this set of risks. Knowing the difference is becoming the core of the job.

An example. Ask an AI assistant to add a retry when a payment request times out, and it will do it in seconds. The code will look clean and the tests will pass. But a person who understands the flow will ask the next question: if the first request did reach the bank, does the retry charge the customer twice? That one question, about idempotency, is where the real engineering lives.

From writing to reading

For decades, software teams were organised around writing. Requirements went in, developers wrote, testers checked, and a release went out.

That sequence is starting to change. A new loop is emerging: intent, assembly, verification. A person states clearly what should exist. AI helps assemble it. People verify, carefully, that what was built is correct, safe and fit for purpose.

How it used to work

Requirements

People writemost of the hours

Tools test

How it increasingly works

People state intent

AI assembles

People verifymost of the hours

One way to describe this is an assembly inversion. People used to assemble the code and tools checked it. Now tools help assemble it and people judge it.

Many strong engineers are already working this way. They spend more of their day reading, questioning and steering, and they often understand more of the system than before.

Every organisation will meet this shift

This isn’t only a startup trend. Most businesses that build software are likely to feel it over the next few years, at their own pace.

We have seen patterns like this before. The spreadsheet didn’t remove accountants; it changed what their day looked like. Each big change in tools brings uncertainty first, then adaptation, and the people who learn early help shape what comes next.

Roles are likely to change shape rather than simply disappear. Fewer hours will go into typing code. More will go into designing intent, reviewing systems, owning quality and carrying accountability. The job title may stay the same while the work behind it evolves.

Some ideas for Monday

For engineers:

1. Measure yourself less by lines written and more by how clearly you can explain the system.
2. Read AI-written code as if you’ll be the one called when it fails.
3. Practise the four questions above until they become habit.

For people leading technology teams:

1. Reward understanding as well as output. A small change someone fully understands is often worth more than a large one nobody does.
2. Make reviews real. Give people time to understand, because that is increasingly where the work lives.
3. Hire for judgement and curiosity.

The new craft

The people who thrive in this era probably won’t be the fastest typists. They’ll be the clearest thinkers: the ones who can look at a system they didn’t write and say, with confidence, “I understand this, and I’ll stand behind it.”

Coding, as we knew it, has stopped. Understanding is just getting started.