The What, the How, and the Agentic That

Everyone is talking about AI writing code. That is impressive. It is also only one part of software engineering. Whenever software is built, three different questions have to be answered:

• What should exist?
• How should it be constructed?
• How do we make sure that it actually exists?

Or, more simply:

The WHAT. The HOW. And the THAT.

The WHAT

The WHAT begins with people.

What are they trying to do? What is getting in their way? Which problem is real — and which requested feature is merely somebody’s first spontaneous guess at a solution?

This is where human understanding and product thinking matter.

A user may ask for a dashboard when they actually need one clear decision. A company may want an app when a small internal tool would do. A team may want “something with AI” because AI is currently offered as the answer to almost every question.

Defining the WHAT means looking past the stated wish and deciding what should actually be built.

Agents can help explore options. The understanding of real-life situations, the ideas, and the guardrails — that part we still have to supply ourselves.

The HOW

Once the product is clear, it still needs a structure that can hold.

Where are the system boundaries? Which data belongs where? What happens when an API fails? How will the software be tested, deployed, monitored, updated, and later changed by people who were not there when it was created?

That is the HOW.

Architecture is not about drawing impressive boxes. It is about making decisions whose consequences often only show up months or years later.

Agents can propose architectures and implement them at astonishing speed. They can just as quickly produce a cleanly executed implementation of an idiotic decision.

The weighing of long-term consequences and the decisions themselves — that is still on us. Which is why the popular idea that product managers should vibe-code these days is too simple. Pair vibe-coding by a product manager and a senior developer gets closer.

The agentic THAT

Then there is the work of making the system actually exist.

Writing components. Connecting APIs. Creating migrations. Generating tests. Fixing errors. Refactoring code. Trying another approach when the first one fails.

This is the agentic THAT.

Coding agents are becoming extremely good at it. They can turn clear product and architecture decisions into working software faster than any human developer typing alone ever could.

That is not a small change. It is enormous. But it does not make human engineering judgment obsolete. It amplifies its effect: a carefully thought-through and well-phrased wish can now become a lot of working code before lunch.

The human frame

For me, this is the most useful way to think about agentic engineering:

Human understanding and product thinking
                  ↓
             THE WHAT

        Software architecture
                  ↓
              THE HOW

       Agent-directed execution
                  ↓
             THE THAT

The agentic layer is powerful when it works inside a human frame.

The better the WHAT and the HOW, the more useful the agents become. The weaker both are, the faster a project produces the wrong thing — just in a surprisingly convincing form.

This also changes what makes a good engineer.

Typing speed matters less. Knowing another framework by heart matters less. What matters is getting from a human problem to a sound product decision, from that decision to an architecture that can hold, and then steering the build through a tightly guided agentic process.

That is the kind of engineering I find interesting: not replacing human competence with agents, but using agents to put seven-league boots on human understanding, human creativity, and human experience.