My Playbook for Agentic Software Development

Most developers using AI coding agents today are still operating in the paradigm of conversational autocomplete. They open a single long-running chat session, type a vague prompt, watch the model generate a thousand lines of code, and then spend the next four hours manually debugging subtle regressions in a loop of growing frustration.

This approach—often called “vibe coding”—treats the human engineer as the working memory (RAM) of the system. You don’t actually save cognitive load; you merely trade the fatigue of typing syntax for the fatigue of babysitting a probabilistic generator.

Over the past two years of building autonomous workflow engines and production software with multi-agent systems, I have had to unlearn that habit completely. To get deterministic, high-acuity results from AI agents, you have to stop treating them like junior pair programmers in a chat window and start orchestrating them through an explicit engineering protocol.

Here is my operational playbook for agentic software development.

---

1. Shift from Laborer to Reviewing Authority

The fundamental failure mode in agentic coding is starting implementation before the outcome is bounded. When you give an agent an open-ended instruction like “redesign the dashboard” or “refactor the email queue,” the model is forced to guess dozens of unstated architectural and product decisions simultaneously.

Instead of acting as the laborer who nudges the model line by line, the engineer must operate as a Reviewing Authority:

• Decompose work into Outcome Contracts: Break initiatives down into a clear hierarchy—from macro trajectory to bounded Epics, down to atomic Stories.
• Write the contract before the code: Every atomic task must specify its exact scope, target files, architectural invariants, and what is explicitly out of scope before an execution agent is invoked.
• Preserve human bandwidth for high-leverage sign-off: If a task is properly specified and verified, human review should take thirty seconds of inspecting diffs and verification artifacts—not thirty minutes of untangling spaghetti.

---

2. Lock the Specification on Disk First

Ambiguity compounds exponentially across agent tool calls. If an agent has a 90% chance of making the right assumption on a single step, after ten sequential steps its probability of staying aligned with your mental model drops below 35%.

Before any agent touches production code, I lock down a canonical specification directly in the repository:

• For user interfaces (Visual-First Interrogation): Never ask a code agent to invent visual design on the fly in CSS. I first generate side-by-side visual mockups, interrogate the proportions, typography, and surface physics, and distill the winning direction into a strict Markdown specification (SPEC.md). Only when the visual contract is frozen does an agent write the stylesheet.
• For backend and runtime systems: Codify the state machine transitions, data schemas, and boundary rules in repository-level guidelines (AGENTS.md).

When the specification lives in version control rather than in a transient prompt, every agent invocation starts from the exact same ground truth.

---

3. The Brake Check: Separate Execution from Verification

Language models are inherently optimistic. Left to their own devices, they will write a happy-path implementation, see that the compiler exits with code 0, and confidently declare the task complete.

To build production-grade software with agents, the executor cannot be the sole auditor. Every outcome contract must pass what I call The Brake Check—a two-tier verification gate:

Tier A: Deterministic Code & Coverage Gates

1. Strict Structural Discipline: Agents naturally gravitate toward deeply nested if/else blocks and sprawling god-functions. Enforcing strict structural rules—single-level indentation, early returns instead of else branches, small cohesive modules under 200 lines, and zero-dependency core logic—keeps the codebase legible to both humans and models.
2. Muscular, Clutter-Free Test Suites: Tests are not machine logs; they are declarations of system truth. I ban bureaucratic filler words (should, properly, correctly, works as expected) from test descriptions. Every test title must lead with an active, present-tense verb (compiles, clamps, isolates, preserves, rejects) and enforce 100% branch coverage on core domain modules.

Tier B: Semantic & Visual Verification Checklists

Unit tests alone cannot tell you if a layout looks broken or if an agent left dead legacy routes behind. Alongside the specification, I maintain a written Verification Checklist that an independent pass—using a fresh LLM context and headless browser automation (Puppeteer)—executes before sign-off:

• Did the build complete with zero warnings?
• Does the live rendered DOM at desktop and mobile viewports match the visual specification?
• Were all deprecated files and unused configuration entries cleanly purged?

---

4. Ruthless Context Hygiene

Long chat transcripts are where agentic reasoning goes to die. As a conversation stretches across dozens of turns, failed experiments, stack traces, and superseded instructions pollute the model’s attention mechanism.

My rule is simple: treat the context window as ephemeral compute, and the filesystem as persistent memory.

• Never rely on chat history as your source of truth. If you discover a new constraint or make a design correction during a session, write it into the specification file or issue tracker immediately.
• Dispatch isolated subagents for heavy execution. Once the spec and verification checklist are written on disk, spawn a fresh worker agent with a clean context window pointed strictly at those files. It reads the spec, executes the changes, runs the verification suite, and reports back a clean summary without dragging megabytes of intermediate tool noise into your primary planning context.

---

5. Build on Lean Substrates for Handover Readiness

Finally, agentic velocity depends heavily on the underlying technology stack.

When a project is buried under forty layers of framework magic, implicit decorators, and heavy runtime dependencies, agents hallucinate APIs and struggle to trace side effects. When you build on lean, transparent substrates—standard web primitives, explicit state flow, static builds, and single-command task runners (task gate, task dev)—agents can reason about the entire system with surgical precision.

Every repository should be engineered from Day One for Handover Readiness: a state where any engineer—or any autonomous agent—can clone the repo cold, read the architectural doctrine in two minutes, run a single verification command, and ship changes with total confidence.

---

The Bottom Line

AI agents do not replace software engineering discipline; they penalize its absence and multiply its presence.

If your requirements are vague, your architecture is entangled, and your verification is manual, agents will only help you generate technical debt at ten times the speed. But when you pair autonomous agents with crisp specifications, strict structural boundaries, and uncompromising verification gates, a single Staff Engineer can operate with the output and reliability of an entire platform organization.