What is agentic engineering? It is a way of building software in which coding agents do most of the building, and the repository is set up to check what they build. The engineer stops being the person who types the code and becomes the person who decides what gets built and designs the checks that prove it works.
The short version is that an agent is allowed to do more only as fast as the codebase can prove its work is right.
What changes for the engineer
In ordinary AI-assisted work, a person asks for code, reads it, and decides whether to keep it. The person is the check. That does not scale, because reading is slower than generating, and a tired reader approves things.
In agentic engineering the check moves into the repository. Types, lint rules, tests and required status checks block a change that breaks a rule. The agent runs the real thing and shows the output. A person still decides what to build and reviews the change, with the evidence in hand and the mechanical mistakes already caught. We compare the two approaches in vibe coding vs agentic engineering.
The five parts
These five practices are what let a repository check an agent's work. The first is enough to start. Each one is a rule with a concrete done state, not a habit.
| Part | The rule | What you would find in the repository |
|---|---|---|
| Verification loops | An agent is done when it has run the thing and shown the output, not when the code compiles. | One command that runs everything CI runs, and scripts that exercise the app without a person. |
| Feature map | Every user-facing surface is written down with where it lives and how to reproduce it. | A table with one row per route, command or screen, and a check that fails when a surface is missing from it. |
| Hard guardrails | A review comment given twice becomes a lint rule or a CI check. | Import restrictions, server-only modules and required checks, with a table mapping each rule to what enforces it. |
| Colocation by feature | Everything one feature needs lives in one directory. | A folder per feature holding its entry point, rendering, parsing and tests. |
| Evals for instructions | Agent instructions are code, so they are tested with fixed scenarios. | A table of scenarios with pass criteria, and dated logs of each run. |
Two of these get their own posts. How to verify AI generated code covers the first, and guardrails for AI coding agents covers the third.
Autonomy is earned in rungs
Agentic engineering is not the same as letting an agent run unsupervised. Autonomy is granted one rung at a time, and each rung is unlocked by something the repository can check.
- In the loop. The agent edits in an isolated working copy and runs the verify command. A person reads every diff. Unlocked by a single command that proves a change works.
- One pull request per issue. The agent opens a pull request with the verification output pasted in. A person reviews and merges. Unlocked by a feature map, guardrails in CI and a pull-request template that asks how the change was verified.
- Auto-merge. The agent merges its own pull request when every required check passes. Unlocked by instruction evals that stay green several runs in a row.
- Hosted triggers. Work starts from a label on an issue instead of a typed prompt. Unlocked by a tested skill for each job and a workflow that runs it in the cloud.
Do not take a rung the repository cannot back. An agent should never hold more trust than the guardrails support.
What it is not
- Not a tool. The practice names techniques, not products. The work is in the checks, and those are yours to build.
- Not prompt writing. A better prompt is still a suggestion. A failing build is not.
- Not unreviewed code. An engineer still reviews every change, and reads the evidence that it works alongside the diff.
- Not more code. The aim is less code of higher quality. One agent that produces verifiable work is what makes running several safe.
Where to start
- Write the one command that runs everything CI runs. If it does not exist, build it first.
- Make the checks required on your default branch, so a red run blocks the merge.
- Pick the review comment you give most often and turn it into a lint rule.
- Give your agent written working rules. Ours are published as the agentic engineering manual, one file you can save into any repository.
None of this requires a new stack. It requires deciding that a change is finished when the repository has checked it and an engineer has read the proof, not when someone says so.
- agentic engineering
- fundamentals
keep reading
- Vibe coding vs agentic engineering: what changesVibe coding vs agentic engineering comes down to who checks the code. See where each one fits, where vibe coding breaks, and how to move between them.
- How to verify AI generated code before it shipsLearn how to verify AI generated code before it ships. Match the check to the change, run the real thing, and keep a script a reviewer can rerun.
- Guardrails for AI coding agents that the build enforcesGuardrails for AI coding agents hold when the build enforces them. Turn a repeated review comment into a type, a lint rule or a check the agent cannot skip.