What is agentic engineering?

What is agentic engineering?

Agentic engineering is building software with AI agents that write, run and test code themselves, while you set the goal, the limits and the final check. You mostly stop typing the code yourself. You describe what needs to happen, break the work into tasks an agent can handle and check whether the result holds up.

An agent is more than a chat window that suggests code. Simon Willison defines it⁠↗ in one sentence: “An LLM agent runs tools in a loop to achieve a goal.” A coding agent reads files, runs commands, executes tests, reads the error and tries again. That is why people also call it agentic coding. It makes an agent powerful, and also risky: it can do a lot of work before anyone looks.

The word engineering covers everything around those agents: how you scope tasks, how you prove something works and who decides what, when.

Where does the term come from?

Andrej Karpathy proposed the term agentic engineering on 4 February 2026⁠↗, a year after he gave vibe coding its name. Looking back, he wrote that programming through agents is becoming the default for professionals, “except with more oversight and scrutiny”. He wanted a name that set that work apart from vibe coding.

He explains the second half of the name too: engineering, because there is expertise involved that you can learn and get better at. Addy Osmani published his own take⁠↗ the same day, with a line that sums up the division of labour: “AI does the implementation, human owns the architecture, quality, and correctness.”

On 23 February 2026 Simon Willison started a series called Agentic Engineering Patterns⁠↗. He uses the term for “building software using coding agents”: tools like Claude Code and OpenAI Codex that can both write and execute code, so they can test and improve it on their own. IBM now has a definition page⁠↗ as well, describing it as “the practice of using engineering expertise to orchestrate and oversee AI agents through the software development process.”

We deliberately say Karpathy proposed the term, not that he invented it. The idea was already around. In October 2025 Willison was already writing about vibe engineering⁠↗ for the same kind of work. Karpathy gave it a name that stuck.

What is the difference between agentic AI and agentic engineering?

Agentic AI is the umbrella term for AI systems that take steps towards a goal on their own. Agentic engineering is one application of it: building software with such systems, under human direction. The first term describes what the technology does, the second how you work with it.

In Building effective agents⁠↗, Anthropic draws a useful line within agentic systems. Workflows are systems “where LLMs and tools are orchestrated through predefined code paths”. In agents, the models decide the next step: they “dynamically direct their own processes and tool usage”. An agentic workflow follows a fixed path, an agent picks its own. Both count as agentic AI.

An assistant that creates a return in your web shop by itself is agentic AI. An agent that tracks down a bug in your app, writes a test that exposes it and opens a pull request is agentic AI working for agentic engineering. If you want to use agents outside software development, read AI agents for business.

How does agentic engineering work in practice?

You work in a loop: define the goal, split it into tasks, let an agent build and test, have the result reviewed and only then merge. Every step has its own check.

1. Goal. You write down what needs to happen and what the result has to meet. Not “improve the app”, but “the app starts without internet and shows the last known state”.
2. Tasks. You split the goal into tasks small enough to check. If you cannot test a task, it is too big.
3. Agents. An agent carries out the task with the files, tools and background it needs, and nothing more.
4. Tests. The agent runs the tests itself. According to Willison, that is the defining trait of coding agents: they can write and execute code, so they can test and correct their own work.
5. Review. An independent reviewer assesses the work: a different model or a separate context that did not produce it. Then a person decides whether it goes in.

What you need to get started

• Version control, so every change an agent makes has its own branch and its own diff that you can roll back.
• Automated tests and CI. Without tests an agent cannot tell whether it is done, and neither can you.
• A fixed format for tasks: what needs to happen, when is it done and what is off limits.
• A review step that is separate from whoever made the change.
• Agreed decision points: what does a person approve before the work moves on?

Start small. Pick a bounded job in an existing project with tests around it, and see how an agent handles it. You learn more from one task you check carefully than from a whole app you let it generate in an afternoon.

How it went with Plens

Plens, our app that tells cyclists when to leave to stay driest, was built this way. The web repo got its first commit on 31 August 2026. By 10 October it held 1,286 commits, and 604 of its 632 pull requests had been merged. The native app started on 16 September and had 684 commits by 11 October, 397 of them carrying a Co-Authored-By: Claude line. Nearly all commits are in the name of co-founder Alan Abdulla, who worked with Claude Code, Codex and Cursor.

Running that many sessions side by side takes agreements. Every change starts with a recorded product change record, so it does not matter which session starts the change. Sessions in the cloud and on the Mac register their branch on a shared work board, which flags overlap between branches as a merge conflict in the making. And a contract file between web and app makes CI fail as soon as the two repos drift apart.

What is left for people to do?

People set the goal, the limits and the final check, and make the decisions an agent is not allowed to make. You type less and spend more time choosing, weighing and checking.

• Goal and trade-offs. What are we building, for whom, and what do we leave out? An agent works on the task it is given. Whether it is the right task is not its call.
• Limits. Which files, tools and permissions does an agent get? What may it never do without approval, such as deploying to production or paying for something?
• Final check. At moments agreed in advance, a person approves the work, rejects it or asks for changes.
• Demand proof. “It works” is only true if you can show it: a passing test, a screen on a real device, a measurement.

Our own rules for ARCS put it like this: “Money, contracts, and external customer commitments require a visible final human action.”

The Plens documentation turns this into rules: never claim something works on a device because a bundle or EAS build succeeded, and Claude does not deploy to production by itself. Claude does submit builds to the stores, but only after Alan gives the go. Co-founder Melle Doreleijers decides on the public release.

The big choices stayed with people too. Codex wrote up the architecture decision for the native app, weighing four options against each other: Expo with React Native scored 157 points, two fully native apps 106, a web wrapper 104 and a web app alone 92. Alan made the call, on 21 September. He also decided not to build an Apple Watch app for now, and to drop a button that was already finished, because Plens does not want to ask the user anything back.

Our about page lists it as a principle: AI helps us get more work done, while people set the goal, make the trade-offs and adjust course.

What goes wrong without checks?

Without checks you get code that looks fine but that nobody has read, and claims that turn out to be false. An agent that works fast also makes its mistakes fast, and it rarely says on its own that it is unsure.

• Code nobody has read, which means nobody can maintain it.
• An agent reviewing its own work and repeating the same reasoning error.
• Permissions that are too broad: an agent that can deploy, pay or delete data without approval.
• Claims without proof, such as “works on iOS” when only the build passed.

We ran into this in our own build. On 24 September we put the native Plens app through an independent review, with separate read-only agents. The first blocking finding was that the whole app lived in a single file of 317 lines, without deep links. An earlier claim about Siri on the Apple Watch turned out to be wrong. And on an emulator, a test sign-up accidentally created a real account, because a native build never uses sample data.

You can also misjudge what it gains you. In a randomised study by METR from July 2025⁠↗, sixteen experienced open-source developers took 19% longer on their tasks with AI tools, while they believed they had been 20% faster. METR itself calls that a snapshot of early 2025. In an update from 24 February 2026⁠↗, the research organisation writes that developers are now likely sped up more by AI tools than in early 2025, but that its new data are only very weak evidence for the size of that increase.

So do not rely on the feeling that things go faster or work well. Show it with tests, a review and a measurement.

How do we approach it?

We build with ARCS, our own agentic platform, which builds the checks from this article into the way we work. ARCS stands for Agentic Reasoning & Coordination Systems. It splits the work into bounded tasks and assigns them to specialised councils: groups of agents, each with its own specialism.

• Every result goes past an independent reviewer: a different model or a separate context that did not produce the work.
• Work stops when approval is needed, when it is blocked or when the budget runs out. The reason is recorded so the work can pick up again later.
• Every work session saves a checkpoint, so you can trace what happened and resume the work.
• An instruction in text gives an agent no permissions. The ARCS documentation states it as a rule: “Prompt text is never execution authority.” Permissions come from a recorded policy and explicit grants.

Within a task, ARCS runs a fixed quality loop: a candidate, a check that does not depend on a model, a targeted repair and then the check again. By default that is at most three attempts. If the same failure comes back, it counts as no progress and the loop stops. The loop may never skip a human decision point or give an agent more permissions: “Do not let the optimizer override a human gate or widen tool authority.”

Every task is anchored to the long-term goal: the north star. How that works step by step is in how ARCS lets agents build with checks and on our page about how we build. We cover the review step separately in AI code review by a council. And Jev by TypeSafe explained shows how a model that makes one typed choice instead of producing free text fits into this way of working.

Wondering whether this approach fits what you want to build? Our way of working is on the homepage, and you can get in touch to talk it through with us.