Eight names for one shift, and which ones hold up
Agent-driven, agent-first, agent-native, spec-driven, intent-driven. What each one actually means — and who was selling something when they named it.
There are at least eight names in circulation for the same broad thing: AI agents doing meaningful work inside software development. Agentic software development. Agent-driven. Agent-first. Agent-native. Agent-assisted. Spec-driven. Intent-driven. AI-native. They overlap, they are used interchangeably in the same paragraph, and most published comparisons treat them as a settled hierarchy.
They are not a settled hierarchy. I checked where each definition actually comes from, and the pattern is worth knowing before you adopt any of the vocabulary in a strategy document: three of the eight have a definitional source with nothing to sell. Five were named by a party selling the thing the name describes.
That does not make the five wrong. Vendors are often first to name a real pattern, and two of these terms describe something genuinely distinct. But it changes how much weight a term can carry in a procurement conversation, an architecture decision record, or a board slide — and it explains why the definitions contradict each other depending on whose page you land on.
Where each term's definition actually comes from
Most taxonomies circulating right now cite Microsoft’s VS Code documentation as evidence that agent-first development is a distinct tier of autonomy. It is not what that page says. VS Code’s own wording is that the practice is “often called agentic programming or agent-first development” — the two are offered as synonyms for the same thing, not as separate rungs on a ladder. The eight-term hierarchy is a useful construct, but it is largely a synthesis rather than a set of industry definitions, and this page says so where that applies.
The three that have an anchor
These are the terms I would use in a document that has to survive contact with a procurement team.
Agentic Software Development
IndependentForrester · the umbrella category
Forrester’s definition, verbatim: agentic software development is “the use of AI agents (aka TuringBots) that can plan, generate, modify, test, and explain software artifacts across multiple stages of the software development lifecycle (SDLC) — working alongside human developers with a degree of autonomy.”[1]
Three things make this the strongest of the eight. It comes from an analyst firm rather than a toolmaker. It names the distinguishing property directly — Forrester’s phrase is “agency, more than assistance”, meaning the system can take on a task, decompose it, execute steps and iterate, often asynchronously, rather than merely responding.[1] And it puts the accountability where it belongs in the same sentence: the practice is “about delegating meaningful development work to AI agents while keeping humans accountable for intent, review, and outcomes.”[1]
That last clause is the whole design problem in one line, and it is the reason this term is worth defending against the eight lookalikes. Use this as your umbrella. Everything else is a sub-case or a marketing variant.
Spec-Driven Development
IndependentIBM · the specification becomes the contract
IBM’s definition: “a software methodology in which a detailed specification of implementation details is authored and agreed upon before development begins. In other words, it serves as a single source of truth for what to build and how to build it.”[3] Microsoft frames the same practice as spec-first AI-native engineering, opening on the observation that matters most: “AI has made software delivery faster, but speed alone does not guarantee better outcomes.”[4]
This is the term with the most consequential implication and the least novelty. Writing the spec first is not new. What is new is the economics: when code production becomes cheap, precisely defining what should be produced becomes the expensive part — and the part that determines whether the cheap production was worth anything.
It also has a failure mode worth naming. A specification detailed enough for an agent to implement without ambiguity is, in some domains, close to the length of the implementation. Teams adopting SDD should expect the spec to become a maintained artifact with an owner, not a document written once at kickoff.
Spec-Driven Agentic Development — SDAD
IndependentarXiv, submitted 5 May 2026 · the combination, formalised
The most recent of the three and the only one with a paper behind it. SDAD is formalised as “a synthesis of disciplined up-front formalisation and high-velocity implementation: intent capture, machine-readable specification, agentic synthesis, and independent multi-agent verification under human sign-off.”[2]
The phrase doing the work is “specification quality [as] the execution fuel for autonomous delivery”.[2] The paper’s argument is that frontier coding agents with very large context windows can now ingest substantial requirement documents and repository context in a single workflow — which shifts the constraint from how fast code can be written to how precisely the target can be described.
Two framings from the paper are worth borrowing whether or not you adopt the acronym. It introduces AI-code as a fourth production paradigm alongside the historical pendulum between Waterfall and Agile, and it compares Human-Agile circa 2020 against Agentic-SDAD circa 2026 as distinct operating models rather than as a tooling upgrade.[2]
The five that were named by someone selling something
Each of these describes something real. The question is only whether the definition can carry weight in a document that outlives the vendor relationship.
Agent-Driven Development
Self-namedThe clearest of the five · agents drive execution
The idea: structure development so that agents perform substantial development work, rather than sitting beside a developer suggesting the next function. Human defines the outcome, agents plan, implement, test and review, human approves.[7]
The operative word is driven. The difference is not the tool but the unit of delegation. “Help me write this endpoint” is assistance. “Implement authentication according to this spec, add tests, run them, fix the failures and prepare the PR” is delegation — and it is a different management problem, because you are now reviewing an outcome rather than watching a process.
Worth keeping despite the provenance. It names the thing that actually changes for an engineering manager: the review surface moves from diffs to outcomes, and nothing in the existing process was built for that.
Agent-First Development
VendorVS Code · agent as default interface
VS Code’s framing: instead of writing each line, you direct an AI coding agent to read your codebase, make edits, run commands, fix its own mistakes and accomplish work — and “these agents operate in a loop. You give direction, the agent acts, you course-correct, and repeat.”[5]
The inversion in the question is the useful part. Not “how can AI help a developer do this?” but “how would an agent do this?” That reframing has a concrete consequence: it makes your environment’s legibility a first-class engineering concern. Machine-readable documentation, clear repository structure, an AGENTS.md, accessible tests, CLI-reachable tools, MCP servers, reproducible environments, explicit acceptance criteria.
But as noted above, VS Code uses the phrase as an alias for agentic programming rather than as a distinct level of autonomy. Treat “agent-first” as a design posture, not as a rung.
Agent-Native Development
VendorFactory (July 2025) · Northflank · the environment itself is redesigned
The distinction from agent-first is subtle and, in my view, the most useful one on this page. Agent-first is an organizational preference about how humans interact with development. Agent-native is a claim about the infrastructure.
Built for a person waiting
- developer writes code, pushes
- opens PR
- waits for CI
- reads the errors
- fixes and repeats
Built for a loop that closes itself
- agent creates branch, launches environment
- executes tests, reads failures
- repairs the implementation
- runs browser verification
- produces PR plus evidence
- asks a human for approval
Note the date on Factory’s post: 1 July 2025.[8] This term predates the 2026 wave by a year, which is mild evidence that it is describing a real engineering constraint rather than riding one. Northflank uses it the same way, for autonomous coding agents handling multi-step feature development and the problem of deploying what those agents build.[11] Red Hat is building in the same direction, describing an agentic SDLC with a central management layer they call Org Pulse, giving live visibility into what the system is doing.[6]
Intent-Driven Development
Self-namedOne layer above spec-driven
The claim: neither code nor the specification is the durable source of truth — human intent is, and both spec and implementation are derived artifacts.[9] The chain runs why (business intent) → what (desired behavior) → constraints (security, architecture, UX) → specification → agent plan → implementation → verification.
The problem it exists to solve is genuine and getting worse: coding agents implement extremely quickly while still misunderstanding what the human actually wanted. Speed of implementation has made the cost of a misread intent higher, not lower, because more of the wrong thing gets built before anyone looks.
Whether it needs its own name is a fair question. In practice it is the first phase of spec-driven development, taken seriously.
Agent-Assisted Development
Self-namedThe low-autonomy end, and where most teams actually are
Human is the primary actor; the agent generates tests, explains code, refactors a method, suggests an implementation, finds a bug, writes documentation.[10] The human still controls the loop.
Worth naming precisely because this is where the overwhelming majority of teams currently sit, while the vocabulary in their strategy documents comes from four rungs higher. That gap between the language and the practice is the single most common failure I see in agent adoption plans — it produces roadmaps costed for agent-native infrastructure and staffed for agent-assisted reality.
The autonomy ladder
Once you strip the branding, the terms sort onto one axis: who holds the loop. Not what the tool can do — what the human has to be present for.
Five levels, defined by what the human still has to do
All eight, side by side
Term, emphasis, source, and how much the source can carry
| Term | What it emphasizes | Primary source | Anchor | Note |
|---|---|---|---|---|
| Agentic Software Development | Agents across the SDLC | Forrester | Independent | Analyst category definition |
| Spec-Driven Development | Specs drive agent execution | IBM · Microsoft | Independent | Vendor-neutral explainer + vendor blog |
| SDAD | Spec + agents + independent verification | arXiv 2608.20341 | Independent | Paper, submitted 5 May 2026 |
| Agent-First Development | Agent is the default interface | VS Code | Vendor | Used as a synonym, not a tier |
| Agent-Native Development | Environment redesigned for agents | Factory · Northflank | Vendor | Both sell agent-native tooling |
| AI-Native Development | AI is structural, not additive | Microsoft | Vendor | Broadest and least precise |
| Agent-Driven Development | Agents drive execution | agentdrivendevelopment.com | Self-named | Domain exists to promote the term |
| Intent-Driven Development | Human intent is the source of truth | intent-driven-development.com | Self-named | Domain exists to promote the term |
| Agent-Assisted Development | Agents help humans | blog.agentcohort.ai | Self-named | Vendor blog field guide |
What actually changes
Strip the vocabulary away and three things are genuinely different. Everything else is tooling.
One. The expensive artifact moved. When producing code was the constraint, the spec could be thin and the code carried the meaning. When production is cheap, the spec carries it — which is why both IBM and the SDAD paper independently land on specification quality as the limiting factor.[3][2] A team that adopts agents without moving effort upstream simply produces more of whatever it was already misunderstanding.
Two. The review surface changed shape. Reviewing a diff written by a colleague and reviewing an outcome produced by an agent are different activities. The diff review assumes a shared mental model you can interrogate. The outcome review does not — and most engineering organizations have no process for the second one, because it never existed before.
Three. The environment became a dependency. This is the agent-native point, and it is the one teams underestimate. Machine-readable docs, an AGENTS.md, CLI-reachable tools, reproducible environments and explicit acceptance criteria stop being hygiene and start being throughput. An agent in a poorly documented repository is not slower; it is confidently wrong, which is worse.
The SDAD pipeline, and the two steps that stay human
The bottleneck nobody put in the taxonomy
Every one of the eight terms describes how work gets produced. None of them describes what happens when it needs checking — and that is where the constraint has actually moved.
We scored twelve enterprise platforms on two axes in the Agent Supervision Register: what the agent can do without a person present, and what the person accountable for the work can see, approve or reverse afterwards. Median capability came out at 11 of 12. Median supervision, 6. Not one of the eleven scored platforms documented a way to reverse the work an agent had performed.
Agents produce faster than people verify. That is not a temporary tooling gap — it is the arithmetic of the arrangement. Add a level of autonomy and you multiply output; the review queue does not multiply with it. Review is the new bottleneck, and it is a headcount problem wearing a tooling costume. The term for this does not exist in any of the eight vocabularies, which tells you something about who has been doing the naming.
This is the question the 40th principle asks in a different context — who verifies the verifiers — and it is why SDAD’s insistence on independent multi-agent verification is the most load-bearing word in its definition.[2] An implementer agent checking its own work is not verification. It is the same reasoning run twice.
The practical version: decide which actions an agent may take unsupervised, which pause for a human, and which are never delegated at all. We run that as the Action Heat Ladder — actions ranked by consequence and reversibility, with the checkpoint set accordingly. It is the same model whether the agent is writing marketing copy or merging to main.
What to do with this
Pick one umbrella term and define it in writing. Use agentic software development if you want the one with an analyst definition behind it. The specific choice matters far less than having a single term in your architecture decision records, so that two teams are not solving the same problem under two names.
Locate your actual level before you buy for a higher one. Most teams are at agent-assisted and planning for agent-native. That gap is where budget goes to die. The honest test is the CI comparison above: if a failing test still means a human reads the log, you are not agent-native regardless of what you have licensed.
Move effort upstream before you add autonomy. Specification quality is the constraint. If your acceptance criteria are not machine-readable today, more agent autonomy will produce more work that meets nobody’s definition of done.
Size the review queue before it sizes you. Work out how much output an added level of autonomy generates and who is reading it. If the answer is “the same three seniors”, the autonomy is theoretical.
Make the environment legible first. This is the cheapest item on the list and the one with the best return: an AGENTS.md, documentation agents can actually read, and tests reachable from a command line. Our context file checker lints those files in the browser, free, and takes about a minute.
For the long-form version of how this work actually gets shipped — framing, evaluation, release, supervision — the agent development lifecycle is the field guide, with a 24-question readiness scorer. If the question is one specific workflow rather than the whole practice, the Agent Operability Audit is three weeks and fixed scope.
Method: every definition quoted above was fetched and read on 30 August 2026, and direct quotations are marked. Where a widely repeated claim did not survive that check — specifically, the use of Microsoft’s VS Code documentation to establish agent-first development as a distinct autonomy tier — the correction is stated in the body rather than dropped quietly. The five-level ladder in Figure 2 and the anchor classification in Table 1 are auxfirst’s reading, not industry standards, and are labeled as such.