Alfonso Graziano wrote the cleanest short definition I have seen: building production software by directing AI agents through spec, context, and verification. His three prescribed pillars are spec, context, and harness. I think verification is a fourth pillar rather than a step inside review, and it is the one that decides whether the other three hold.
Date: August 2026 | Riffs on: Alfonso Graziano, “What is AI-Native Engineering”
The definition
AI-native engineering is building production software by directing agents through a written spec, engineered context, an execution harness, and automated verification. The agent does the typing. The human stays accountable for what the system does in production.
The word doing the work in that sentence is native, and it is worth separating from assisted. AI-assisted means the model helps you write code you were going to write anyway: better autocomplete, a faster first draft, a rubber duck that answers back. Your workflow is unchanged, just quicker. AI-native means you restructured the work so an agent can carry it. The spec exists in a file because the agent cannot read your intent. The repo carries its own context because the agent starts every session with amnesia. The checks run without you because the agent needs to find out it was wrong before you do.
The tell is what happens when you remove the agent: an AI-assisted workflow gets slower, an AI-native one stops. That is not a failure state, it is the point. You built a system whose throughput is no longer bounded by how fast you type, and the cost of that is that the scaffolding has to be real.
The antipattern it is defined against
Alfonso names vibe coding as the thing this is not, and he is right to. Describe intent roughly, accept whatever comes back, ship it because it runs. For a prototype or a throwaway internal tool that is a legitimate mode and I use it happily. In production it fails for a specific reason: the output looks like code written by someone who understood the problem, and nobody did.
The subtler failure is the slide into it. You adopt agents to keep up, you start reviewing output instead of writing code, then you let an agent review the agent, and one stacked approval later you have stopped reading anything at all. I call that cognitive surrender, and it is worth naming because nobody decides to do it. It is what AI-native engineering degrades into when you keep the speed and drop the scaffolding. The two camps are separated by whether the channel is constrained before generation starts, not by tooling.
Pillar one: the spec
Write down what “done” means before you prompt, in enough detail that a stranger could judge the result. Behaviour, boundaries, acceptance criteria, the cases you explicitly do not care about.
This is the cheapest leverage in the whole practice because it moves review from “read 2,000 lines and pray” to “check the diff against the contract.” My version is verified spec-driven development: the spec is not a prose wish, it is a document with checkable claims. In practice that means a design doc that carries the full spec, indexed PRDs the agent can retrieve from, and enumerating options before committing to one so the agent is choosing inside a space you bounded rather than inventing one.
Pillar two: the context
Context engineering is getting the right information in front of the model at the right moment, and it is the discipline I have written the most about because it is where most of the day-to-day failure lives.
The entry points: writing a good CLAUDE.md so the repo teaches every session what it took you months to learn, dotfiles as a shared agent brain so conventions follow you across machines and projects, and contextual retrieval for the moment the codebase outgrows the window. The counterweight matters too: more context is not better context, and the MCP abstraction tax is what you pay when you bolt on tooling that fills the window with things the model did not need.
Pillar three: the harness
The harness is the environment the agent works inside: the commands it can run, the sandbox it runs them in, the loop that restarts it, the tools that let it see what it did.
Start at building the harness, then the sandbox is a harness for why isolation is a capability rather than a restriction, and 12-factor agents for the shape of an agent you can operate. The economic argument is the harness is cheaper now: infrastructure that was not worth building for a human team is trivially worth building for a fleet of agents, because the agent uses it a hundred times a day and never gets bored of it.
Pillar four: verification, and why it is load-bearing
Here is where I add to Alfonso’s version rather than just agreeing with it. He gets to “review output rigorously” and stops. That instruction cannot survive contact with agent throughput, because it asks a tired human to be the last line of defence against a generator that never tires.
Generation fell to roughly zero and verification stayed exactly as expensive as it always was, because it is still bottlenecked on a person reading a diff. Every pillar above increases the rate at which code arrives. Only this one changes what it costs to trust it. Skip it and AI-native engineering is just vibe coding with better paperwork.
What it looks like as engineering rather than exhortation: the verification ladder for how far to escalate proof as stakes rise, quality gates as information filters so each automated check collapses a huge space of defects into one signal that costs nothing to read, the trust-but-verify protocol so the agent produces the evidence and I review the evidence, and evals rather than vibes for anything whose correctness is a judgement call. Human attention does not disappear, it gets aimed: read less code, not no code, spending the budget where being wrong is expensive.
The role shift is real, but “orchestrator” is not a job title
The bottleneck did move from implementation to direction, and I would not fight that framing. I would resist the version where the engineer becomes a manager of agents who no longer needs to understand systems. The coder is obsolete, the programmer is not: writing the code was the commodity, deciding what should exist and what proves it works was always the job, and seniority was partly a proxy for typing speed until agents removed the proxy.
What changes is what you are responsible for. Stewardship over authorship: when you cannot read every line, reliability has to be a property of the system rather than of your attention. That is the practical content of “humans on the loop, agents in the loop” from the AI-native principles.
Where to start
In order, because each step makes the next one cheaper:
- Write the repo’s context file. One
CLAUDE.mdorAGENTS.mdthat says how this codebase works and what it will not tolerate. Highest return per hour of anything here. - Write a spec before the next non-trivial prompt. One page. Behaviour, boundaries, acceptance criteria.
- Give the agent one command that tells it it is wrong. Types, tests, a lint rule, anything it can run itself without asking you.
- Grow the harness from the failures you actually hit. Do not design it up front, build it from what breaks.
- Move each recurring review comment into a gate. That is the compounding loop: every defect you catch by eye once becomes a check that catches it forever.
I run this across roughly 350,000 lines of production code as a team of one. Solo does not make the practice optional, it makes the pricing visible. There is no colleague downstream to absorb an unverified diff, so every gate I did not build lands on me at 2am.
One sentence
AI-native engineering is directing agents through spec, context, harness, and verification, and the fourth one is not optional, because it is the only pillar that changes what the other three cost you.
Related
- AI-Native Principles – Tokens are cheaper than people, humans on the loop, software is clay
- Verified Spec-Driven Development – The spec pillar, made checkable
- Building the Harness – The harness pillar, in practice
- The Verification Ladder – How far to escalate proof as stakes rise
- The Two Camps of Agentic Coding – Constrain the channel, or send more tired humans through it
- Code Stewardship Over Authorship – Reliability as a system property
- The Evolution of AI Coding up to 2026 – How the practice got here
- Read Less Code, Not No Code – Aiming human attention instead of abandoning it
Sources
Part of the field guide
This is one of my field notes in AI Native Software Engineering, a plain-English guide to building software with AI agents. The terms behind it are defined in the AI Coding Dictionary.
