Agentic engineering

What is agentic engineering?

Agentic engineering is building software by directing coding agents that plan, write, run and test code, while you stay responsible for what ships. The agent types. You decide what gets built, check whether it is right, and sign off before anything reaches a colleague or a customer.

A coding agent is a program that wraps a large language model in a set of tools: it can read files, edit them, run a command, read the output and try again. Claude Code, OpenAI's Codex and Google's Gemini CLI all work this way. That loop is what separates an agent from an autocomplete assistant: the agent runs your test suite, sees the failure and fixes it without you pasting anything.

Andrej Karpathy put the name on it in early February 2026, one year after he coined vibe coding. His observation was that working through agents had become the default for professionals, "except with more oversight and scrutiny". He chose "agentic" because you are orchestrating agents rather than typing the code yourself most of the time, and "engineering" because there is skill in it that you can get better at. Simon Willison adopted the term a few weeks later for his guide of patterns, and his short definition is "the practice of developing software with the assistance of coding agents".

The tools are the same ones a vibe coder uses. What changes is that someone reads the result and puts their name on it.

What you still do yourself

Handing the typing to an agent removes the slowest part of the job and leaves the parts that decide whether the software is any good.

Specification. The agent builds what you describe, so a vague description gets you a plausible answer to the wrong question. Anthropic's guidance for Claude Code recommends letting the agent interview you first and writing the outcome to a spec file: which files and interfaces are involved, what is out of scope, and which check proves the feature works.

Architecture and judgement. Karpathy gives an example from his own MenuGen app: the agents proposed linking Stripe purchases to Google accounts by e-mail address. It would have worked, and it would have been a bad design. Someone with enough product and engineering judgement had to insist on a persistent user ID.

Review. The first anti-pattern in Willison's guide is filing pull requests with code you have not read yourself: "The initial review pass is your responsibility, not something you should farm out to others." The agent wrote it, but the name on the commit is yours.

Tests and verification loops

Anthropic's guidance for Claude Code puts it as a rule: if you can't verify it, don't ship it. Tests were good practice before. With agents they become the mechanism the whole approach runs on, because a test is a check the agent can run on its own. Give it a way to tell pass from fail and it keeps going until it passes. Give it nothing and "looks done" is the only signal, and you become the verification loop, catching every mistake by hand.

Willison's guide says automated tests are no longer optional with coding agents, and two of his patterns cost nothing to adopt.

• First run the tests. Start every session by having the agent run the existing suite. It learns how to run them and is far more likely to run them again after each change.

• Red/green TDD. Ask for the failing test first, watch it fail, then let the agent make it pass. Skip the failing step and you risk a test that already passed before the code existed.

The check does not have to be a unit test. A build that exits cleanly, a script that compares output against a known file, a screenshot next to the design: anything that returns a signal the agent can read counts. A second loop worth having is a reviewer that did not write the code: Anthropic recommends a fresh session or subagent that only sees the diff and the plan, so it is not attached to the reasoning that produced the change.

A worked example. A bookkeeper wants incoming supplier invoices matched to purchase orders automatically. Before the agent writes a line, you agree the rule with her (same supplier, amount within 2 percent, order date before invoice date) and turn it into five test cases, including one that must not match. The agent runs the tests, watches the four matching cases fail, writes the matching code and runs all five again. You read the diff, run the tests yourself on last month's export, and only then does it go anywhere near the accounting package.

Agentic engineering versus vibe coding and pair programming

Versus vibe coding

Both use the same agents. The difference is who owns quality and whether the code is meant to last. In vibe coding nobody reads the code, the running result is the only judge, and the code is expected to be thrown away. In agentic engineering a named person reads the code, tests prove it, and the code is expected to be maintained for years. Karpathy's own line is that vibe coding is fine for prototypes and personal tools, and agentic engineering is what serious teams need.

Willison's warning goes with it: the agent removes the cost of typing, and none of the cost of getting it right.

Versus classic pair programming

In pair programming two people share one keyboard: one drives, the other reviews as they go and keeps an eye on the bigger picture. Agentic engineering looks similar from the outside, with the agent driving and you navigating, but two things differ. Review-as-you-go is not automatic with an agent; you have to build it in as a step. And the agent does not learn from a session. Willison's phrase is that LLMs don't learn from their past mistakes but coding agents can, provided you write what you learned into the project's instruction file so the next session starts with it.

When it fits an SME

The approach fits work where the requirement is clear, the check is easy to write and the code has a long life inside the company.

• Internal tools. A small web page where planners move delivery slots, a form that replaces a shared spreadsheet. The spec is a conversation with the people who use it, and the test is whether they accept it.

• Integrations. Syncing customers from the CRM into the accounting package, pushing webshop orders into the ERP. Both ends have a documented API and you can test against a sample record before touching live data.

• Reports and data pipelines. A nightly job that loads sales into a warehouse and refreshes a Power BI model. The check is a reconciliation: the total in the report equals the total in the source.

It fits less well when nobody in the company can read the code, because then the review step has no reviewer and you are back at vibe coding with extra steps. Same when there is no way to verify the output: an agent on an old system with no tests and no documentation produces confident changes that nobody can check. And wherever a wrong result weighs heavily, payroll, a price the customer sees, medical or safety software, treat the agent as a fast junior and keep the human gates heavy.

What to ask a supplier who says they work this way

These questions separate agentic engineering from vibe coding with an invoice attached:

1. Who reads every change before it goes in, and can that person explain the code without the agent?

2. Which automated checks exist, and can we see them run? A test suite that runs in CI on every commit is the answer you want.

3. Where does the agent run and what can it reach? Claude Code, Codex and Gemini CLI all support sandboxing and permission rules. Ask whether they are used, especially for anything that touches production data.

4. If you leave, can another developer take this over? The honest answer depends on the tests, the documentation and the review history, not on which agent was used.