Agentic Engineering: not the model, the method

Every few weeks a new model, a new benchmark, a new headline. I write about these a lot, but the decisive thing is not which model is currently ahead. What matters is the method you use it with. Models come and go, the discipline around them stays. I call that discipline Agentic Engineering, and here is how I think about it, after three major technology shifts in my career.

What is Agentic Engineering?

Agentic Engineering is not a tool or a product, it is a way of working. AI writes code, plans steps, takes on whole tasks. The real engineering is to surround that capability with enough structure and verification that what comes out is reliable, something that still holds up in a year. It is not the AI that makes the difference, but how much craft you put around it.

Why not whether you use AI, but how?

Whether to use AI is settled, almost everyone does. The difference is in the how. An output without context and without review is a suggestion, nothing more. Structure is what makes it usable: good context, clear constraints, a review that holds the result against reality. And context almost always beats the clever prompt. Showing the model what it is working on yields better answers than polishing the perfect wording. I wrote about this in more depth in not whether you use AI, but how.

What is loop engineering?

The next step: stop prompting agents one by one, build loops that do it. A loop finds the work, hands it out, checks the result, records what is done, and pokes the next thing. The pieces are modest: automations as the heartbeat, separate workspaces for parallelism, captured project knowledge, connections to real tools, one agent that builds and a second that checks, and a memory outside the conversation. The model forgets between runs, the repo does not. That moves the leverage point away from the single prompt and toward designing the loop. What that looks like in practice is in loop engineering.

Why does responsibility stay with the human?

The better the loop runs, the more this matters. “Done” is a claim, not a proof, which is why I split the one who builds from the one who checks; the model grades its own work too kindly. Better models help, they raise the floor a review stands on; a newer model, for instance, overlooks code flaws less often. But they do not take the review off your hands.

There is also a quiet danger: the more code appears that nobody wrote themselves, the wider the gap between what sits in the repo and what you have actually grasped. A smooth loop widens it faster, unless you read what it built. Tools that openly show their uncertainty, such as confidence scores, are valuable for exactly this reason: they tell you where to look.

What does this mean for the foundation?

When a model becomes this central, the architecture question follows. A model is not a foundation. It can get more expensive, change, or vanish overnight. Reliability therefore lives not in the model but in the architecture: a clear abstraction over the model, a fallback to an available one, and a review that does not depend on which model happens to answer. Then a provider going down is a bad day, not a standstill. Why that is more than theory I showed with a concrete case.

What do you get out of it?

Two people use the same tools and get opposite results. One gets faster at work they understand. The other avoids understanding the work at all. The tool does not know the difference. The engineer does. Agentic Engineering means using the speed of AI while keeping control. For your project that means software that ships faster and still stays maintainable, verifiable, and independent of short-lived trends. I do not know tomorrow’s model. The method I use it with, I do.