Dev Execution, When Agents Write Code That Ships

Last issue the CTO Orchestrator handed you a package: requirements, an architecture record, a task list. A plan is not a pull request. Someone still has to write the code, and this is where most agent systems start shipping garbage into your repo.

A plan is not a pull request

Planning hallucinates a paragraph. Execution hallucinates a commit, and that commit lands in your history and your git blame. A bad paragraph you delete before anyone reads it. A bad commit ships and gets built on, then detonates as an incident weeks later. The stakes go up the moment an agent stops describing work and starts writing it.

One caveat before the walkthrough. The dev-execution profile, its workflow, and the engineering-lead agent file are real files, and every id, field, and step below is read straight from them. The delegation tree and the code diff I show are an illustrative pass on the exact auth feature Issue 6 planned. The machinery is real. The diff is a demonstration of the real structure, not a captured production run. A clean live capture waits on the execution-engine fixes noted in the ground truth.

The Engineering Lead

Dev Execution keeps the Crew's cast, the cto-orchestrator up top and the same planning perspectives underneath, and adds one required agent that reorders everything under it: the engineering-lead. Its role, from the agent file: "Implementation orchestrator. Reads task breakdowns, distributes work to coding workers via hierarchical delegation, coordinates parallel implementation, and ensures all tasks are completed with tests passing." Its default stance is three commands: "Break it down, assign it, verify it."

It never writes a line of code. capabilities.can_produce_files: false, delegation_style: delegate-only. The CTO Orchestrator plans and the Arbiter deliberates. The Engineering Lead does neither: it hands out work and assembles what comes back. It reads the task breakdown, spawns workers, and folds their results into an implementation report. The writing happens one level down, in the workers.

Those workers are domain-scoped. The Lead's own Scope Guard heuristic says it plainly: "Each worker gets only the file paths their task requires. Never give broad write access." A worker gets a bounded slice, a file set or a module, not the keys to the repo. That single constraint is what keeps a code-writing agent from trashing the rest of the tree.

Hierarchical delegation

The profile sets delegation.default: targeted and opening_rounds: 0. No all-hands round, because there is no question on the table, only work to route. Then the field that matters this issue: max_delegation_depth: 2. The Engineering Lead can delegate to workers who do not delegate further. The Lead spawns a crew (up to max_children: 5); the workers execute and stop. They do not spawn crews of their own.

The cap is the whole point. Unbounded delegation is how agent systems fan out into chaos, a worker spawning a worker spawning a worker until nobody can say what has write access to what. Depth 2 draws a hard floor. Here is the illustrative tree for the auth feature:

engineering-lead  (delegate-only, depth 1)
├─ session-store worker   scope: prisma/schema.prisma, src/server/auth/session/**
├─ oauth worker           scope: app/api/auth/callback/**, src/server/auth/google/**
└─ rate-limit worker      scope: src/server/middleware/rate-limit/**

Three workers, three non-overlapping scopes. The Lead's Dependency-First heuristic sequences them: the session table migration lands before the OAuth callback that opens a session against it. Independent slices, like the rate limiter, run in parallel. Nobody touches a file outside their scope, because they were never handed it.

Working-directory writes

Two steps in the workflow carry action: execute-with-tools, and that is the difference between an agent that documents work and one that does it. The implement step runs the Engineering Lead: workers read the existing code, write changes into the working directory, and run the relevant tests (the Lead coordinates them through spawnSubAgent and messageChild). The test-verify step runs the full suite with real bash, bun test or npm test or pytest, with max_retries: 2 to fix and re-run.

The guardrail is that these writes are scoped, gated, and reviewed. A worker writes only inside its domain scope. The Lead's red lines forbid the rest: "Never give a worker write access outside their task scope," "Never merge work that breaks existing tests," "Never skip the test verification step." Same discipline that made the planning issue trustworthy, now aimed at real code.

The same discipline that caught the lie

Between implement and test-verify sits a code-review step: the sentinel, review_gate: true. Four steps in the workflow carry a gate, all user-approval, after understand, design, plan, and this one. The same Sentinel that flagged the unprotected password-reset endpoint in Issue 6's planning pass now reads the actual diff.

Here is the OAuth worker's first pass at the task Issue 6 wrote: a valid Google callback creates or links a user, opens a server session, sets the cookie, and an invalid state is rejected with no session created.

+// app/api/auth/callback/google/route.ts
+import { cookies } from "next/headers";
+import { exchangeCode, fetchGoogleProfile } from "@/server/auth/google";
+import { upsertUserFromGoogle, createSession } from "@/server/auth/session";
+
+export async function GET(req: Request) {
+  const url = new URL(req.url);
+  const code = url.searchParams.get("code");
+  const state = url.searchParams.get("state");
+  const expected = cookies().get("oauth_state")?.value;
+
+  if (!code || !state || state !== expected) {
+    return new Response("Invalid OAuth callback", { status: 400 });
+  }
+
+  const tokens = await exchangeCode(code);
+  const profile = await fetchGoogleProfile(tokens.access_token);
+  const user = await upsertUserFromGoogle(profile);
+  const session = await createSession(user.id);
+
+  cookies().set("sid", session.token, {
+    httpOnly: true, secure: true, sameSite: "lax", path: "/",
+  });
+  return Response.redirect(new URL("/dashboard", req.url));
+}

It looks done. It checks state, it rejects the bad case, the session cookie is httpOnly and secure. A demo would pass. The Sentinel fails it:

Critical. The oauth_state cookie is validated but never cleared, so state is not single-use. A valid callback URL, captured from server logs, browser history, or a Referer header, can be replayed to mint fresh sessions. The acceptance criterion says a valid callback opens a session; it does not say the same one may open ten. Burn the state before the code exchange. Send it back.

That finding is what you reject on at the gate; on_rejection: retry_with_feedback sends the work back through the Engineering Lead to the OAuth worker, scope unchanged, and the fix is one line:

   if (!code || !state || state !== expected) {
     return new Response("Invalid OAuth callback", { status: 400 });
   }
+  cookies().delete("oauth_state"); // single-use: burn state before the exchange

The commit that would have shipped a session-replay hole never leaves the working directory. The discipline that caught the lie in planning caught the bad commit in execution. The bar for evidence never dropped. Only the thing under review changed, from a plan to a diff.

What we trust, and what we do not

Here is the whole envelope. An agent writing code is safe here for three reasons, and only those three: workers are scoped to their files, a Sentinel reads the real diff, and the tests actually run against the working tree. Pull any one and you are back in the graveyard.

And you are still in the loop. Those four gates are user-approval, not auto-proceed. The code-review gate is the one where you, not the model, read the diff and click approve. The Harness makes the bad commit cheap to catch. It does not pretend you were never here. The full contract is at harness.aos.engineer.

Next

That is the Crew writing code, on one vendor CLI. Next issue we run a profile across four of them, Claude Code, Codex, Gemini, and Pi, and watch where the adapter layer holds and where it leaks.