The Agentic Engineering Playbook

Philosophy

AI agents are senior engineers on your team, not interns with API access.

The mindset shift is fundamental. Most teams treat AI as a glorified autocomplete -- paste some code, get a suggestion, manually review and edit. That is not how you get leverage.

When you treat agents as senior engineers, the workflow changes completely. Agents get specs, not prompts. They work in parallel, not sequentially. Their output is reviewed like a pull request, not copy-pasted from a chat window.

The difference between using AI as a tool and using AI as a team member is the difference between 2x and 20x output.

This means writing clear specs for what each agent should produce, defining the boundaries of their work, and having a human review gate before anything ships. The human stays in the architecture role -- designing the system, reviewing output, making judgment calls. The agents handle implementation at speed.

Parallel Agent Execution

The biggest unlock: running multiple AI agents simultaneously on different parts of the same project.

Instead of working on one file at a time, you decompose the work into independent tasks and assign each to a separate agent session. Each agent works in its own worktree or branch, completely isolated from the others.

# Parallel agent execution pattern
# Each agent gets its own isolated worktree

Agent 1: Build the API routes
  -> worktree: feature/api-routes
  -> spec: "Create REST endpoints for /users, /posts, /comments"

Agent 2: Build the UI components
  -> worktree: feature/ui-components
  -> spec: "Create Card, Badge, Modal components per design system"

Agent 3: Write integration tests
  -> worktree: feature/integration-tests
  -> spec: "Write tests for auth flow, CRUD operations"

Agent 4: Set up CI/CD pipeline
  -> worktree: feature/ci-cd
  -> spec: "GitHub Actions: lint, test, deploy to staging"

# All 4 run simultaneously. Human reviews PRs as they come in.
# Total wall-clock time: ~15 min instead of ~3 hours sequential.

The key constraint is that tasks must be decomposed so they do not have write conflicts. Two agents editing the same file will create merge conflicts. The human architect must think about the dependency graph before assigning work.

Think of it like managing a team of fast, focused contractors. You would not assign two contractors to paint the same wall. You give them different rooms.

Blast-Radius Scoping

Why your agents need boundaries -- and how to define them.

Every agent task should have a clearly defined blast radius: the maximum scope of files, systems, or functionality it can affect. If an agent goes off the rails, the damage should be contained to a single, reviewable unit of work.

This means scoping tasks so that a failure in one agent does not cascade to others. Each agent operates in isolation. Their changes are reviewed independently. If one agent produces bad output, you discard that branch -- the rest of the system is unaffected.

# Blast-radius scoping example

GOOD: "Add a /users API route in src/app/api/users/"
  -> Blast radius: 1 directory, 2-3 files
  -> Failure impact: Only the users endpoint is broken

BAD: "Refactor the entire API layer and update all imports"
  -> Blast radius: Every file in the project
  -> Failure impact: Everything breaks simultaneously

# Rules of thumb:
# 1. One agent = one feature or one module
# 2. Max blast radius = files you can review in 5 minutes
# 3. If you cannot describe the scope in one sentence, split it

The cost of an agent making a mistake should be measured in minutes, not hours. If a bad commit takes more than “git revert” to fix, your blast radius was too wide.

Atomic Commits

Ship small, ship often. Each agent task produces one reviewable commit.

An atomic commit is a single, self-contained unit of change that can be reviewed, tested, and reverted independently. When every agent task produces exactly one atomic commit, you get a clean git history that tells a story.

This is not just a nice practice -- it is a safety mechanism. When agents produce large, sprawling changes across many files, the review burden becomes overwhelming and bugs slip through. When each commit is small and focused, review is fast and confident.

# Atomic commit workflow

1. Agent receives spec: "Add email validation to signup form"
2. Agent creates branch: fix/signup-email-validation
3. Agent makes changes:
   - src/lib/validators.ts  (add email regex)
   - src/components/SignupForm.tsx  (wire validation)
   - src/tests/signup.test.ts  (add test case)
4. Agent creates ONE commit:
   "Add email validation to signup form

   - Add RFC 5322 email regex to validators
   - Wire validation into SignupForm with error state
   - Add test for valid/invalid email inputs"
5. Human reviews PR -> merge or request changes

# One task. One branch. One commit. One review.

If you cannot describe what a commit does in one sentence, it is doing too much. Split it.

When to Use What

Claude Code vs Codex vs custom agents -- each has a sweet spot.

Not all agentic tools are interchangeable. The right choice depends on the task type, codebase size, and level of autonomy required.

The general principle: use the highest-autonomy tool that your task safely allows. For isolated, well-scoped tasks with clear specs, give the agent maximum autonomy. For exploratory work or tasks that touch shared state, keep a human closer to the loop.

The goal is not to remove humans from the loop. The goal is to move humans from implementation to architecture.