What agentic engineering means for an engineering team

Agentic engineering, vibe coding and AI-assisted coding

Simon Willison, whose guide to agentic engineering patterns is one of the clearest treatments of the subject, uses the term for developing software with the assistance of coding agents: agents that can both write and execute code. He describes an agent as software that runs tools in a loop to achieve a goal, and names code execution as the capability that makes the practice possible, because the agent can iterate towards software that demonstrably works.

Willison keeps vibe coding, the term Andrej Karpathy coined in February 2025, for its original meaning: prompting a model to write code while forgetting the code exists. That leaves vibe coding for unreviewed, prototype-quality output and agentic engineering for code someone has brought up to a production standard. Agentic development and agentic software development are used for the same practice. Autocomplete-style assistants that suggest lines without running anything sit outside it.

Where the work moves

Typing code becomes a smaller share of the job. Willison's point is that the craft was always deciding what code to write, and that work stays with people. In practice it shows up in four places:

• Specifying: tasks written with enough context and acceptance criteria for an agent to work without guessing
• Building the harness: instruction files, tools, sandboxes and permissions that let an agent run the build and tests safely
• Verifying: tests, CI and human review strong enough to catch what an agent gets wrong
• Keeping the lessons: models don't learn from their mistakes, but a team can update its instructions and harness each time an agent fails

Spec-driven development with coding agentsHarness engineering for coding agents

What the research says about results

The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, describes AI's main role in software development as an amplifier of an organisation's existing strengths and weaknesses. 90% of respondents used AI at work and more than 80% believed it had raised their productivity, while 30% reported little or no trust in AI-generated code. The report found that AI adoption now improves delivery throughput but still increases delivery instability.

Measured results can differ from perception. In METR's randomised trial with 16 experienced open-source developers and early-2025 tools, tasks took 19% longer with AI allowed, although the developers had expected a 24% speed-up and afterwards believed they had been 20% faster. In February 2026 METR wrote that developers are likely faster with current tools, but that selection effects in its follow-up study make its new data only very weak evidence of how much. The practical conclusion is to measure on your own work rather than rely on impressions or vendor figures.

Foundations that decide whether it pays off

DORA's AI Capabilities Model names seven practices that amplified AI's benefits in its data: a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus and quality internal platforms. None of them is a coding agent feature. In practice they translate into questions a team can check before scaling agents:

• Do engineers know which tools, data and repositories agents may use?
• Can an agent build and test the code in a fresh environment without a person's help?
• Are changes small enough that a reviewer can understand each one?
• Do agents run with their own narrow permissions, in an environment where a mistake can't reach production?

The last question echoes Anthropic's engineering guidance on agents, which recommends extensive testing in sandboxed environments with appropriate guardrails because autonomy brings higher cost and compounding errors.

Coding agent security for engineering teams

A first step for one team

A hypothetical example: a team takes twenty recently completed tickets from its own backlog, with their merged changes as a reference. It sets up one agent with the repository's build and test commands, a short instruction file and permissions limited to a branch. Each ticket is run again with the agent, and the team records review time, rework, failed CI runs and model cost per accepted change, next to the same figures for the original human changes. Twenty tickets won't settle the question, but they show where the harness or the specifications are missing, which is what the team fixes before it widens the trial.

Where it tends not to pay off yet: code without tests an agent can run, work whose requirements live only in people's heads, and environments that need manual steps to build. Those gaps slow people down too, and fixing them is often the first piece of agentic engineering work.

Designing a coding agent pilot that compares tools on the same workRolling out coding agents