Agentic engineering: building software with coding agents you can actually ship

Agentic engineering is the practice of developing software with coding agents — tools like Claude Code, OpenAI Codex, Cursor, Aider or Gemini CLI that can both write and execute code. The human stays responsible for the plan, the tests, the review and the production system the code lands in. That is Simon Willison’s definition, and it is the one the industry has settled on. The term describes a way of working, not a job title and not a framework.

The word “engineering” is doing real work in that sentence. Coding agents made writing code cheap; they did not make deciding what to build, proving that it works, or keeping it alive in production any cheaper. Agentic engineering is the set of habits that puts those three things back in the loop after the agent has typed the code. This article covers the practice itself: the tools, the instruction files, the loop, the evidence on speed. Then it covers the part most guides stop short of — what has to be true after the merge. That is where the rest of opsagent lives.

Vibe coding, AI-assisted coding, agentic engineering: where the line runs

Three terms describe three positions on one spectrum, and the difference between them is how much of the result a human still owns.

Vibe coding is the term Andrej Karpathy introduced in February 2025 for prompting a model to write code while you “forget that the code even exists”. It is a legitimate way to build a throwaway prototype or a personal script. It is not a way to build something other people depend on, because nobody can answer the question “why does this line exist?”

AI-assisted engineering is the middle: autocomplete, chat-in-the-editor, an agent asked to write one function. The human still writes most of the code, reads all of it, and the tool accelerates typing rather than replacing the developer’s control of the file.

Agentic engineering delegates whole tasks — “add rate limiting to the upload endpoint, with tests” — to an agent that reads the repository, edits several files, runs the test suite and iterates on failures. The human’s role moves up a level. Addy Osmani put it this way in February 2026: “you’re orchestrating AI agents — coding assistants that can execute, test, and refine code — while you act as architect, reviewer, and decision-maker.” His single biggest differentiator from vibe coding is blunt: testing.

The fourth box on that diagram is the one this site exists for. The code an agent writes is increasingly code that contains agents — a support bot with tool access, a pipeline that calls an LLM, an automation that publishes on a schedule. Once that ships, the questions stop being “is the diff correct?” and become “what can it do, who can see what it did, and who stops it?” Those are AgentOps questions, and they belong in the same discipline.

The tools, and what they read before they touch your code

A coding agent is a loop. It reads the repository, proposes a change, runs something — tests, a build, a linter — reads the output, adjusts, and repeats until the task is done or the budget runs out. The products differ in where that loop runs and which file they consult first.

Tool	Where it runs	Instruction file it reads	Worth knowing
Claude Code	Terminal, IDE extensions, cloud	CLAUDE.md (user, project and local levels)	Memory files are hierarchical; a project file can import others
OpenAI Codex	Terminal CLI and cloud sandbox	AGENTS.md	Co-authored the AGENTS.md format
Cursor	IDE	.cursor/rules, AGENTS.md	Agent mode edits multiple files with the editor as the review surface
Aider	Terminal, open source	AGENTS.md, its own conventions file	Commits each change with a generated message; git is the undo button
Gemini CLI	Terminal, open source	GEMINI.md, AGENTS.md	Google’s Jules runs the same idea as a cloud agent

The column that matters is the instruction file. An agent that starts every session with no memory of your conventions will guess them — and it will guess differently each time. The file is how the team’s knowledge survives the session boundary.

AGENTS.md and CLAUDE.md: the contract with the agent

AGENTS.md is “a simple, open format for guiding coding agents”. It was developed jointly by OpenAI Codex, Amp, Google’s Jules, Cursor and Factory, is used by more than 60,000 open-source projects, and is now stewarded by the Agentic AI Foundation under the Linux Foundation. Twenty-plus tools read it, from Aider and Zed to GitHub Copilot and Devin. Claude Code’s equivalent is CLAUDE.md, and a repository can keep both by having one import the other.

The recommended sections — project overview, build and test commands, code style, testing instructions, security considerations, commit and PR conventions, deployment steps — are sensible. What they leave implicit is the section that decides whether the agent is safe to run unattended: the operational boundary. Which commands may it run? Which may it never run? How does it prove a change is done? The template below is the one I keep at the root of the repositories in this portfolio; the last section is the part most published examples lack.

# AGENTS.md

## What this is
Astro 7 static site, TypeScript, content in src/content/blog/{en,pl,de}/*.mdx.
Deploys to Hostinger by `./deploy.sh` (rsync over SSH). Git push does NOT deploy.

## Commands
- Install: `npm ci`
- Build: `npm run build` (must pass before any commit that touches src/)
- Content gate: `npm run audit:content` (blocks AI-slop phrases, missing FAQ/definition)
- Preview: `npm run preview`

## Style
- Two-space indent, single quotes, no default exports in components.
- Articles: definition in frontmatter, FAQ under 25% of the page, every external claim linked to a source.
- Never add a number, percentage or statistic without a URL that contains it.

## Verification — what "done" means
- Build green, `audit:content` green, the changed page renders at `dist/<path>/index.html`.
- For a redirect or header change: `curl -sI` the live URL after deploy and paste the status line in the PR.

## Operational boundary — read before acting
- MAY: edit src/, public/, scripts/; run build, tests, audit; commit on a branch.
- MAY NOT: run `./deploy.sh`, rotate or read secrets, change DNS, delete branches,
  push to master, or touch .github/workflows without a human in the loop.
- If a task needs something in the MAY NOT list, stop and say so instead of working around it.
- Commit as `markus-smile <goodwaj@interia.pl>`; the deploy platform rejects other authors.

Copy the shape, not the content. Every line in the operational section is there because an agent once did the thing it forbids — which is also the honest way to grow the file: after an incident, not before a brainstorm.

What the evidence says about speed

The strongest measured result is not flattering. In July 2025, METR ran a randomized study with 16 experienced open-source developers completing 246 real issues in their own repositories. They used tools of their choice — mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet. Developers predicted the tools would make them 24% faster. Afterwards they believed they had been 20% faster. The measurement showed they were 19% slower.

Two things follow. First, the tools have improved since early 2025, and the study says nothing about a task you delegate whole rather than pair on. It is not a verdict on agentic engineering. Second, and more useful: the gap between perceived and measured speed is the real finding. People are poor judges of whether an agent helped. That is exactly why the discipline insists on things you can measure — tests that pass, a plan that was followed, a diff someone can explain — rather than on how productive the session felt.

Two failures from this portfolio, and what they taught

I maintain 24 repositories with coding agents, all with continuous integration on every push and automated dependency updates merged by a bot. Two mistakes from the last two months shaped the operational section above.

The invented charts. An agent-driven content pipeline produced 108 articles for this site. An audit on 19 August 2026 found that 27 of them contained bar charts with numbers nobody had measured — “62% of teams”, “risk distribution 32/26/20/14/8” — labelled “illustrative” and sourced to “a synthesis of industry reports”. The agent had done what agents do when asked for a chart: it produced one. The fix was a single commit removing every chart without a linkable source, and a new rule in the instruction file: no number without a URL that contains it. The review gate that would have caught it on day one cost less than the audit that caught it on day 40.

The unattended publisher. A second site in the portfolio ran two scheduled agents that refreshed game codes and puzzle answers every morning and pushed the result straight to production. That was 213 URLs with no human between the agent and the deploy. Within a month Google stopped crawling the articles; on 30 August, four of 213 pages were in its index. Nothing in the pipeline was broken. The automation did exactly what it was told, at a scale and cadence no reviewer ever looked at, and the search engine treated the result as what it was. An agent without a checkpoint does not fail loudly; it succeeds at the wrong thing, quietly, every day.

Neither failure was a model problem. Both were the absence of a boundary — one on what the agent may claim, one on what it may publish — and both are cheaper to design in than to discover.

After the merge: where agentic engineering meets AgentOps

Most agentic-engineering guides end at the pull request. That is the point where this site begins. The code that merges is, more and more often, itself an agent — and a coding agent is a production agent from the moment it has a shell and a deploy key.

The same five questions apply to both:

• What can it call, and with what permissions? For a coding agent that is the operational boundary above; for a deployed agent it is tool permissions through an MCP gateway and a defence against excessive agency.
• What did it actually do? A coding agent leaves a git history; a deployed agent needs observability and tracing to leave the equivalent.
• Is it still correct after the change? In the repository, the test suite; in production, regression evals and, where human review does not scale, LLM-as-a-judge with its known biases accounted for.
• What does it see? The instruction file is context engineering for a coding agent; the same discipline decides what a production agent gets in its window at each step.
• Who stops it, and how fast? A human approving the merge is the coding agent’s checkpoint; a deployed agent needs staged autonomy and a human oversight design that is a real barrier rather than a rubber stamp.

The security risks unique to agents — prompt injection, poisoned tool results, runaway permissions — are catalogued in the OWASP Top 10 for agentic applications. Every one of them applies to the agent editing your code as much as to the agent answering your customers. Whether you need more than one agent at all is a separate decision, covered in single agent versus multi-agent and in the orchestration framework comparison. Most teams do not, and a second agent multiplies whatever the first one got wrong.

The loop, in six steps

The order matters here, which is why it is numbered: each step exists to catch what the previous one lets through.

1. Write the plan before the prompt. A short spec — what changes, what must not change, how you will know it worked. If you cannot write the third part, the task is not ready for an agent.
2. Give the agent the contract. AGENTS.md or CLAUDE.md with commands, style and the operational boundary. Keep it under a screen; agents skim long files the way people do.
3. Delegate a task, not a wish. “Add rate limiting to /upload, 10 requests per minute per IP, with a test that proves the 11th is rejected” — not “make uploads safer”.
4. Let the tests be the judge. Red before green: the agent writes or extends the failing test first, then the code. Osmani is right that this is the line between the two disciplines.
5. Review the diff as a reviewer, not as the author. Read the plan, the tests and everything touched outside the task. The METR gap means your impression of the session is not evidence.
6. Observe after the merge. Traces, error rates, cost. If the merged code is an agent, this step is where the rest of opsagent takes over.

Gartner’s June 2025 forecast that more than 40% of agentic AI projects will be cancelled by the end of 2027 names three causes — escalating costs, unclear business value, inadequate risk controls. None of the three is a model capability problem. All three are what this loop exists to prevent, on both sides of the merge.

Terms used here — evaluation, human-in-the-loop, AgentOps — are defined in the glossary, and the seven pillars that pick up where step six leaves off are linked from the orchestration hub.