Agentic Engineering in Five Layers: From Specs and Parallel Agents to Rules and Oversight

Vibe coding had a good run. Andrej Karpathy, the person who coined the term, has since declared that era over, and he did more than name the problem. He sketched what replaces it: agentic engineering, in which AI agents plan, write, test and ship code while a human keeps structured oversight. The human sets the intent, the agents carry it out, and the human checks the result. That is a professional method for building with AI and not merely beside it, and it is a long way from casual prompting followed by hope.

An earlier push for specification-driven development, meaning writing down what a system must do before any agent generates anything, turns out to cover only one layer of this discipline. Teams in production have since filled in four more. What follows maps all five layers, shows what each looks like in practice, and ends with a one-week exercise plan for getting started.

Why the name matters

The label is more than branding. It marks the line between two very different ways of working, and Karpathy drew that line with a pair of questions. Vibe coding asks whether something can be made to work. Agentic engineering asks whether it can be made to work reliably, at scale, without introducing vulnerabilities.

The first question lifts the floor. Anyone can prototype now: a weekend builder describes what they want, accepts what comes back and ends up with a working demo. For exploration that is genuinely useful. The second question protects the ceiling. Software that processes payments, handles health data or runs infrastructure still demands professional discipline. The agent may write the code, but a person has to design the system, set its boundaries and verify the output.

Karpathy's own phrasing was blunt: agentic engineering is an engineering discipline, and the agents are spiky, stochastic and extremely powerful, so the real problem is coordinating them to move faster without lowering the quality bar. That problem, speed without a quality sacrifice, is now the defining question of the field. It is not only his view. IBM, Forrester and Anthropic each published formal frameworks for a distinct new discipline within the same quarter, arriving there independently. When organisations that rarely agree converge at the same moment, the idea has substance.

The term stuck because engineers needed a word for work they were already doing: more structured than prompting, more disciplined than vibe coding, and still unlike traditional development. The discipline it names has five layers, and each one rests on the one beneath it. Leave one out and everything above becomes unreliable.

Layer 1: specification

Write the specification before any agent generates any code. State what the system must always do, what it must never do, how to tell it is working and how to tell it has stopped. Put all of it in one document, keep that document current, and measure everything the agent builds against it.

Different voices in AI engineering call this strategic planning, intent definition or simply the spec. The label varies and the practice does not: know what is wanted before asking an agent to build it.

One point is easy to miss. A spec is no launch-day artefact. It is a living document. Whenever the implementation reveals something the spec did not foresee, and it will, the spec gets updated. Teams whose agents slowly drift away from the original intent are nearly always teams that wrote the spec on day one and never opened it again.

A minimal template starts with a header that declares the document the source of truth:

# Feature Spec: [Feature Name]
## Last updated: [Date] — this document is the source of truth

Then come the behaviour checklists, a section of required behaviours and a section of hard limits, such as never processing a refund above $500 without human approval:

## What this must always do
- [ ] [Behaviour 1 — specific, testable]
- [ ] [Behaviour 2 — specific, testable]## What this must never do
- [ ] [Boundary 1 — e.g. "Never process refund >$500 without human approval"]
- [ ] [Boundary 2 — e.g. "Never fabricate a citation"]## Success criteria (measurable)
- Context recall: >0.85
- Faithfulness: >0.90
- Cost per query: <$0.15
- Latency p95: <2s## Failure signals (alert if breached)
- Any metric drops >5% from 7-day baseline
- Cost per task exceeds 3x expected range
- User complaint rate exceeds 2% of sessions## Decomposition (for parallel agents)
- [ ] Task A: [scope] — can be delegated independently
- [ ] Task B: [scope] — depends on Task A output
- [ ] Task C: [scope] — can run parallel with Task A

Keep it to one page. If the spec runs longer, the feature is too big and should be split until each piece fits.

A perfect spec handed to a single agent still meets a throughput ceiling, which is why a second layer exists.

Layer 2: orchestration

Consider a feature that touches the database schema, the API, the frontend and the test suite. Traditionally one engineer works through the pieces in turn, or a team coordinates across a sprint. In agentic engineering four agents take on all four pieces at once. One writes the migration, another the endpoints, a third the frontend components, and a fourth writes tests and reviews the rest for security problems. Each has its own context and constraints, and their outputs are merged into one coherent change.

This is not hypothetical. Stripe runs this pattern in production, with an internal agent system that produces more than 1,000 merged pull requests a week, each written by an agent, reviewed by a person, passing CI and shipping. The gain is an order of magnitude and not a factor of two.

The rhythm is a loop that repeats per feature: plan, execute, verify. Some teams call it the PEV loop.

• Plan. The human writes the spec from Layer 1 and breaks the work into independently delegatable units. A decision with large consequences here is which tasks can run in parallel because they do not depend on each other's output, and which must run in order.
• Execute. Agents work their assigned units, each with its own context window holding only the relevant slice of spec, code and rules. The orchestrator stops agents from editing the same files at the same time, flags conflicts and keeps parallel streams consistent.
• Verify. The human reviews, though not line by line, which cannot scale at this speed. The check is structural: does the output satisfy the spec, contradict other modules, respect the architectural constraints and pass the evaluation suite?

What used to take a two-week sprint becomes a focused working session of hours or a day. The human effort sits mostly in plan and verify, with agents doing the heavy lifting between.

A nuance takes time to absorb: the aim is useful parallelism, not maximum parallelism. Three agents on tightly coupled modules produce conflicts that cost more to resolve than parallel running saved. Two agents on independent modules, with a third reviewing both, yield coherent output. The skill lies in decomposition, carving work so it can be delegated without integration headaches later.

A skeleton orchestrator can state the loop in its docstring:

class AgenticOrchestrator:
    """Plan → Execute (parallel) → Verify"""

and implement the planning step, which splits a feature into delegatable tasks:

    def plan(self, feature_spec: dict) -> dict:
        """Decompose feature into independently delegatable tasks."""
        tasks = []
        for component in feature_spec["decomposition"]:
            tasks.append({
                "id": component["id"],
                "spec": component["scope"],
                "constraints": feature_spec["must_never"] + component.get("local_rules", []),
                "depends_on": component.get("depends_on", []),
                "verification": component.get("success_criteria", []),
            })
        independent = [t for t in tasks if not t["depends_on"]]
        sequential  = [t for t in tasks if t["depends_on"]]
        return {"parallel": independent, "sequential": sequential}    async def execute(self, plan: dict):
        """Run independent tasks in parallel, sequential tasks in order."""
        parallel_results = await asyncio.gather(*[
            self.delegate_to_agent(task) for task in plan["parallel"]
        ])
        for task in plan["sequential"]:
            result = await self.delegate_to_agent(task, prior=parallel_results)
            parallel_results.append(result)
        return parallel_results    def verify(self, results: list, spec: dict) -> dict:
        """Check all outputs against the spec — structural, not line-by-line."""
        issues = []
        for result in results:
            if not self.satisfies_spec(result, spec):
                issues.append(f"{result['id']}: does not satisfy spec")
            if self.conflicts_with(result, results):
                issues.append(f"{result['id']}: conflicts with another module")
        return {"passed": len(issues) == 0, "issues": issues}

The guiding principle is tight context scoping. Each agent should receive only its spec section, its code files and its rules. Pouring the whole codebase into every context window wastes tokens, raises cost and dilutes the model's attention.

Orchestration buys throughput, and throughput without consistency is chaos. Every agent must know the team's conventions, architectural constraints and security policies as well as the spec for its own task. The next layer supplies that.

Layer 3: codified rules

Most tools already have a version of this. Claude Code loads a CLAUDE.md at the start of each session, Cursor reads .cursorrules and Codex reads AGENTS.md. The concept is shared: a file in the project root that tells the agent how to behave.

In 2026 teams have gone further and encode their whole development culture as agent-readable constraints, beyond the tech stack. Practitioners such as Paul Duvall have been documenting the patterns coming out of production teams, and InfoQ has tracked their maturity. Four patterns recur wherever agentic engineering works:

• Spec-driven development, where the specification governs the work (Layer 1).
• Codified rules and architectural constraints: conventions, security policies, error-handling patterns, naming standards and deployment procedures, all in files agents load before starting.
• Atomic decomposition with parallel agents: features cut down to the tiniest pieces that can be handed off on their own (Layer 2).
• Observable development: a trace and an evaluation for each action an agent takes (Layer 5, below).

Scale is where most teams hit a wall. One CLAUDE.md works nicely for a 1,000-line prototype. A 100,000-line codebase cannot be described in one file, and even if it could, the rules would eat the context window before the agent reached the actual task.

Teams that solve this build hierarchical rule systems, much as ESLint configurations inherit from organisation presets and get overridden per project. The folder layout looks like this:

your-company/
├── .ai-rules/
│   └── org-rules.md          ← Company-wide: security, compliance, style
│
├── team-payments/
│   ├── .ai-rules/
│   │   └── team-rules.md     ← Team-level: error handling, testing, deploys
│   │
│   ├── service-checkout/
│   │   ├── CLAUDE.md          ← Repo-level: architecture, tech stack, builds
│   │   ├── src/
│   │   │   ├── auth/
│   │   │   │   └── .ai-rules.md  ← Module: auth-specific constraints
│   │   │   └── payments/
│   │   │       └── .ai-rules.md  ← Module: PCI compliance rules

At the top sits the organisation file, loaded for every agent in every repo. It covers things like never committing secrets, requiring authentication on public APIs and never exposing stack traces in error responses:

# org-rules.md (loaded for every agent, every repo)
- Never commit secrets or credentials
- All public APIs require authentication
- Error responses must never expose stack traces
- Log every state-changing operation with user context

Beneath it a team file inherits those rules and adds its own, such as the Result pattern instead of thrown exceptions, all database access through a repository layer, and tests covering the happy path plus at least two failure modes:

# team-rules.md (inherits org, adds team specifics)
- Use Result<T, E> pattern — never throw exceptions
- All database queries go through the repository layer
- Tests must cover the happy path + 2 failure modes minimum# CLAUDE.md (inherits team, adds repo specifics)
- This repo uses Express.js + Prisma + PostgreSQL
- Run `npm test` before suggesting any PR is ready
- Migrations are append-only — never modify applied migrations# module .ai-rules.md (inherits repo, adds module specifics)
- auth/: All token operations must use constant-time comparison
- payments/: PCI DSS requires field-level encryption on card data

An agent loads the organisation rules, the team rules, the repo's CLAUDE.md and the rules for the module it touches. That keeps context scoped and lean. The agent on the payments module gets PCI compliance rules, and the agent on the frontend does not, since those rules would spend context budget for no gain.

Rules say how to work, but output still needs human judgement. Code can follow every convention and remain architecturally wrong, solving the stated problem in a way that causes a bigger one elsewhere. That is why the next layer is not optional.

Layer 4: human oversight

Three words describe the operating model that has emerged: delegate, review, own.

Delegate. Hand the agent a well-specified task with clear constraints and let it work. No micromanaging the implementation and no watching it type. The spec and the rules are there so the agent can be trusted to follow them.

Review. Treat returned output as a pull request from a capable but junior engineer: fast, competent, and prone to subtle mistakes that only someone who understands the wider system would spot. Check architectural fit and edge cases. Confirm the spec was satisfied, which means the intent was met and not merely that tests pass.

Own. The human owns final quality. The agent did the work, the person signed off, and a production failure is the person's responsibility. This ownership separates agentic engineering from vibe coding, where nobody owns the output.

The bottleneck is real. Agents produce code faster than people can review it, and the temptation is to relax rigour to keep pace. That temptation is exactly how vibe coding took hold: developers accepted output because it looked right, passed tests and a deadline loomed. Agentic engineering exists to stop that pattern repeating.

Anthropic's agentic coding trends report describes how experienced engineers manage this. They delegate tasks whose correctness is easy to check at a glance, or whose stakes are low. The more conceptually hard or design-dependent a task, the more likely they keep it or work through it jointly with the agent. Knowing what to hand off and what to hold is the new core competency. It grows with practice, no framework or tool shortcuts it, and it separates the engineer who uses agents productively from the one who ships impressive output that collapses under scrutiny.

A review checklist helps before anything agent-generated goes to production. Its heading:

## Agent Output Review Checklist

and its body, organised in sections starting with spec alignment (are all required behaviours implemented, are limits respected, are the success criteria met) and moving on to architecture and business sense:

### Spec alignment (does it do what was asked?)
- [ ] All "must always do" behaviours are implemented
- [ ] No "must never do" boundaries are violated
- [ ] Success criteria from the spec are met or tested### Architectural coherence (does it fit the system?)
- [ ] No new dependencies introduced without justification
- [ ] Consistent with naming, patterns, and structure of existing code
- [ ] No duplication of logic that exists elsewhere### Safety and edge cases
- [ ] Error handling covers the failure modes the spec anticipated
- [ ] No hardcoded credentials, keys, or environment-specific values
- [ ] Input validation present on all external-facing boundaries### What the agent cannot check for itself
- [ ] Does this make business sense? (not just technical correctness)

It is worth printing and pinning near the monitor. Linters and CI can partly automate the first three sections. The last, business sense, is the reason a human stays in the loop.

Review catches problems before release. Slow quality drift, subtle regressions and a cost increase nobody notices until the invoice arrives only show up afterwards, and they call for the last layer.

Layer 5: observable development

Monitoring and observable development sound alike and do different jobs. Monitoring says the system is up, with normal latency, few errors and a green dashboard. Observable development says what the system did: which agent handled which task, from which specification, with which tools, producing which code, and whether the result met the intent.

The difference shows at 2am. With monitoring alone, something is broken and the cause is unknown, so the night goes to reading diffs and guessing at modules. With observable development, the trace for the deployment shows that agent 3 changed the authentication flow from a spec that ignored concurrent token refreshes. That is twelve minutes of targeted debugging in place of two hours of speculation.

In practice it comes down to three habits:

• Every agent task produces a structured trace: the spec it received, the tools it used, the files it changed, the model version, the tokens consumed and the verification result. When a bug appears three days later, the trace says what happened and nobody has to remember.
• Every output is evaluated against the specification and not only the test suite. A module can pass all tests and still break an architectural constraint the spec defined. Tests check behaviour and evaluation checks intent, and each catches failures the other misses.
• Every session feeds back into the rules. Patterns learned, failures met and workarounds found become updates to the Layer 3 rules. What Layer 5 observes, Layer 3 encodes and Layer 2 benefits from, so the discipline compounds week over week.

A minimal setup begins with imports for a small trace record:

from dataclasses import dataclass, field
from datetime import datetime

and the trace dataclass applied to every delegated task:

@dataclass
class AgentTrace:
    """Minimum trace for every agent-delegated task."""
    task_id: str
    agent_id: str
    spec_given: str                    # What was the agent told to do?
    tools_used: list[str]              # Which tools did it invoke?
    files_modified: list[str]          # What did it change?
    model_version: str                 # Which model, which version?
    tokens_consumed: int               # What did it cost?
    started_at: datetime = field(default_factory=datetime.utcnow)
    completed_at: datetime | None = None
    verification_result: str = ""      # pass / fail / needs_review
    human_reviewer: str = ""           # Who signed off?
    issues_found: list[str] = field(default_factory=list)

Add a weekly fifteen-minute review. Its heading:

## Weekly Observable Development Review (15 minutes)

and its questions: how many tasks were delegated, how many passed verification on the first attempt (target above 80%), which category had the most issues, and what the top three issues were:

1. How many agent tasks were delegated this week?        ___
2. How many passed verification on first attempt?        ___  (target: >80%)
3. Which task category had the most issues?              ___
4. Top 3 issues found during review:
   - ___
   - ___
   - ___
5. Which issues should become codified rules (Layer 3)?  ___→ Update CLAUDE.md with any new rules from this week's observations.

Fifteen minutes a week closes the loop. Observations become rules, rules improve orchestration, better orchestration produces better output, and the output yields new observations.

Evidence that it works

Two figures stand out. Stripe's 1,000-plus merged pull requests a week are agent-written, human-reviewed, CI-passing and in production, which is no sandbox experiment. It is a throughput that was not possible a year earlier. A different audience hears a different number: McKinsey's survey points to operating cost reductions of 20 to 40 percent, the sort of figure that moves AI from innovation initiative to operational infrastructure, something the CFO demands and not only the CTO.

What it means for an engineering career

The role is changing and not vanishing. Engineers in 2026 write less foundational code and spend more time orchestrating agents, designing architecture, defining objectives and guardrails, and verifying output. The core skill moves from syntax to systems thinking, from asking how to write a function to asking how to design a system in which agents write it correctly.

Karpathy extended this to hiring: skip the puzzle questions and set a substantial project, for instance building a secure Twitter clone and then having agents try to break it, while watching how the candidate handles tools, specs and oversight. That tests discipline and not typing speed.

Three competencies come up repeatedly in conversations with engineering leaders:

• Specification fluency. Writing a spec precise enough for an agent to execute without ambiguity is harder than writing code. Code has a compiler to catch errors, while a spec has only the agent's interpretation. If the spec is vague, the agent will pick a reading with confidence, build on it and present the result as exactly what was requested.
• Orchestration judgement. Knowing what to delegate and what to keep, when parallel runs help and when coupling is too tight, and when output needs a thorough review as opposed to a structural check. It builds through a hundred delegations, each teaching what works and what creates integration pain.
• Verification discipline. Reviewing with the rigour of a senior engineer going through a junior's pull request: no rubber-stamping because tests pass, no rewriting merely because the reviewer would have done it differently. The questions are whether the output meets the spec, whether it adds risks the spec did not foresee and whether it fits the wider system.

Gergely Orosz put it well: there is something much bigger than coding that makes engineers special, and it deserves cultivating. What sets engineers apart in 2026 is the systems they design, the specifications they write, their judgement about delegation and the quality standard they refuse to lower. Those skills are worth more now precisely because mechanical execution has been automated.

A five-day starter plan

Five exercises across one week, each building on the last:

• Monday, encode team knowledge. Write a CLAUDE.md or .cursorrules for the current project. Skip the list of technologies and record conventions: how errors are handled, how tests are structured, how things are named, and the unwritten rules every newcomer should learn on day one.
• Tuesday, specify and delegate. Pick one backlog feature and write its spec from the template: what it must do, must not do, success criteria and failure signals. Delegate it entirely to an agent, and time both the specifying and the reviewing. The ratio shows where the effort really goes.
• Wednesday, run in parallel. Split another feature into two independent tasks and hand each one to its own agent session, loaded with separate context and limits. Afterwards, look at where the outputs conflict. Those spots reveal where the decomposition was too coarse and the tasks were not truly independent.
• Thursday, review with a colleague. Go through the previous day's output together and compare what each person caught. The gaps show where verification criteria need sharpening. Write them down and add them to the spec template.
• Friday, close the loop. Add the three most important lessons of the week to CLAUDE.md: a convention the agent kept getting wrong, a decomposition pattern that worked, a verification check to include in every future review. That is procedural memory, and the agent is slightly better next week than this week. Compounded over eight weeks, the difference is large.

One week will not make anyone an agentic engineer. It does show what the discipline feels like, and whether moving from writing code to orchestrating agents energises or drains. Either answer is legitimate, but it helps to know which is true.

Where a spec-only view falls short

Treating the specification as the whole answer, with write it, follow it and verify against it, is necessary and not sufficient. The spec is the input to an orchestration system and not a standalone practice. A perfect spec given to one agent yields good work. The same spec split across five parallel agents, each bound by codified rules, each reviewed under structured oversight and each traced through observable development, yields roughly ten times the work at the same quality.

Layer 4 is easy to underrate as well. A spec states the intent, and the human decides whether the intent was met. A specification does not enforce itself, and its verification step needs as much discipline as the writing did. Verification, more than the model, the framework or the tooling, is where most teams cut corners once deadlines tighten.

What comes next

Two directions are visible, one near certain and one speculative.

The near-certain one is that agentic engineering becomes the default method for professional software development within about 18 months, not because everyone reads about it but because the economics are irresistible. Three engineers practising it, with strong specs, parallel orchestration and disciplined oversight, produce the output of twelve working the traditional way. When the arithmetic is that clear, the debate ends.

The speculative one is agentic swarms: networks of agents coordinating among themselves and running entire workflows or business functions with minimal human involvement. Some teams are already experimenting. Whether that holds up at enterprise scale with enterprise reliability is unknown, and interest is best paired with scepticism.

What is not speculative is that the engineer's role has already changed. The live question is whether the competencies of the new role, specification, orchestration and verification, are being built, or whether work still proceeds as though writing code were the job. Typing the code used to be the work. The work now is designing the system that produces it and confirming that what it produced is correct.