What is Agentic engineering?
Building software with AI agents that take on whole units of work — planning, writing, testing, reviewing — rather than completing lines inside an editor.
The unit shifts from a suggestion to a task, which moves the hard problems to coordination, review and trust.
On this page
Agentic engineering is the practice of building software with AI agents that complete whole units of work — a ticket, a refactor, a test suite — inside an engineered system of boundaries, independent review and feedback, instead of completing lines and blocks inside an editor while a human watches. The model matters less than the system around it: what a unit of work is, what the agent may touch, who checks the result, and what happens when the check fails.
Anthropic's engineering guidance draws the useful line between workflows — systems where "LLMs and tools are orchestrated through predefined code paths" — and agents, where models "dynamically direct their own processes and tool usage". Agentic engineering is what happens when you take the second kind seriously: once the model directs its own process, the engineering work moves into designing the environment it directs it in.
Why agentic engineering matters
The unit of work is the whole difference. An autocomplete suggestion is a few lines, and the cost of a wrong one is a keystroke to reject. An agent given a task produces a branch, a diff, a test run — hours of work that arrives finished, without its author available for questions. That trade is enormously productive and equally dangerous, because the failure modes scale with the unit.
Research tracks both sides. METR's 2025 study found the length of task an AI completes unattended — with a 50% success rate, measured in skilled-human time — has doubled roughly every seven months since 2019. The Stack Overflow Developer Survey 2025 found 84% of developers using or planning to use AI tools, and 66% describing the output as "almost right, but not quite". Put those together and you get the defining problem of the discipline: agents can be handed more and more work that is almost right, and almost right is exactly the grade of output that must not merge unreviewed.
So agentic engineering is not "prompting harder". It is the surrounding craft:
- scoping work so an agent can complete it without asking questions nobody will answer;
- bounding what the agent can reach, so a wrong turn is cheap;
- verifying results with something independent of the author;
- keeping what was learned, so the same lesson is not re-derived every run.
How agentic engineering works
| Concern | The engineering answer |
|---|---|
| Unit of work | A ticket or issue with acceptance criteria, not a chat message — the brief carries all the context the agent will ever get |
| Environment | An isolated workspace: its own container or machine, its own branch, network and secrets restricted |
| Verification | Review by an agent that did not write the change, tests written against the requirements, evidence attached to the work |
| Memory | A curated knowledge base the next run starts from, corrected when facts change |
| Failure | Bounces return to a queue and are re-dispatched; agents escalate instead of looping |
| Human judgement | Spent at gates — approving high-risk work, answering escalations — not watching keystrokes |
None of these are model features. Every one is a system property someone has to build, which is why teams that treat agents as an editor plugin plateau, and teams that treat them as new hires in a managed organisation keep compounding.
Agentic engineering is not vibe coding
The distinction matters professionally. Vibe coding — Andrej Karpathy's term — means accepting the model's output without really looking at it, giving in to the vibes. Simon Willison's March 2025 write-up argues the term should stay limited to that, because responsible professional use of LLMs is a different activity: the engineer reviews every diff and stays accountable for it.
| Vibe coding | Agentic engineering | |
|---|---|---|
| Who reads the diff | Nobody, or skimmed | An independent reviewing agent, a human, or both |
| Unit of work | A prompt in a chat | A ticket with acceptance criteria |
| Failure handling | Regenerate and hope | Review bounces the work; the loop repeats |
| Where it is acceptable | Throwaway prototypes, personal tools | Anywhere the result has to be maintained |
| Accountability | Undefined | The system that shipped it, with a record |
Best practices for agentic engineering
1. Engineer the interface, not just the prompt
Anthropic's guidance is to invest as much in the agent-computer interface as in human interfaces: tools with clear boundaries, documented edge cases, parameters that make mistakes hard to make. An agent working through badly designed tools fails in ways no prompt can fix.
2. Make the brief the source of truth
Everything the agent needs — goal, acceptance criteria, scope, how to verify — lives in the ticket. If the brief would leave a competent contractor with questions, it leaves the agent with guesses. See spec-driven development for the practice taken to its extreme.
3. Keep authorship and review separate
The agent that wrote a change is the wrong judge of it: the same misreading that produced the code can produce tests and self-assessment that are confidently wrong in the same direction. Review must come from something that did not share the author's reading.
4. Demand evidence, not verdicts
"Done" is a claim. Requests run, output, test counts and screenshots — attached to the work — are the record an auditor can check without re-deriving it. Evidence that states its own limits is what makes a green report trustworthy.
5. Move autonomy on evidence
Start agents with narrow authority and widen it as the review loop demonstrably catches real defects. The dial belongs in server-side configuration, not in a prompt the agent can reinterpret.
Agentic engineering in YATFA
YATFA is built as the organisation half of this discipline. Work enters as tickets with acceptance criteria, agents work in their own environments on their own branches, every change passes review by an agent that did not write it plus QA with evidence attached to the ticket, and failures return to a queue that re-dispatches them instead of dying quietly. The autonomy regulator makes the trust dial explicit per project — see how YATFA regulates autonomy and how YATFA reviews changes.
Frequently asked questions
What is the difference between agentic engineering and AI-assisted coding?
AI-assisted coding has a human in the loop on every keystroke: the tool suggests, the person accepts. Agentic engineering hands the agent a unit of work and gets a finished, reviewed artefact back — which shifts the engineering effort to scoping, boundaries, review and memory.
Does agentic engineering replace software engineers?
It moves where engineers spend time: from writing every line to designing the system agents work in — briefs, boundaries, review rules — and judging the results. The 2025 Stack Overflow data shows adoption racing ahead of trust, which is exactly the gap an engineering discipline fills.
What does a team need before agentic engineering works?
Three prerequisites: work defined as tickets with verifiable acceptance criteria, an environment where agents are isolated from production and secrets, and a review loop independent of the authoring agent. Without all three, agent output arrives faster than the team can absorb it safely.