05. Execution with AI Agents — Vibe Coding Series

The first time I used multi-agent, I sat there watching 3 agents run in parallel and felt like I was coordinating a small dev team. Agent A was implementing hashPassword, agent B was writing LoginForm, agent C was setting up the database schema — all at the same time. Fifteen minutes later, I had 3 branches with complete code, ready to merge.

But that first time also taught me that multi-agent isn’t just “let them loose and watch them go.” Without a clear workflow, those 3 agents would produce 3 different implementations, 3 different naming conventions, and a pile of conflicts at merge time.

---

Context

In article 04, I broke down TaskFlow’s “user authentication” feature into 8 tasks with clear acceptance criteria and test specs for each. This article moves into Phase 4: execution — how to feed those tasks to AI agents and get back code that matches your expectations.

---

Single Agent Workflow

Feeding context correctly

The most common mistake when working with AI agents is starting a new session and typing straight away: “Write a hashPassword function.” The AI has no idea what you’re building, what the tech stack is, or what conventions you follow.

At the start of every new session, I feed context in this order:

1. AI_CONTEXT.md — project overview, tech stack, conventions
2. Relevant spec — OpenAPI spec or task spec for the feature being worked on
3. Task description — specific description of this task, acceptance criteria, test spec

The prompt template I use to open a session:

Here's the context for this session:

[paste AI_CONTEXT.md content]

Task to implement:
- Name: hashPassword utility
- Description: Password hashing function using bcrypt
- Acceptance criteria:
  * hashPassword(plaintext) → bcrypt hash with salt rounds = 12
  * verifyPassword(plaintext, hash) → boolean
  * Unit tests cover happy path and wrong password
- Test spec: [paste test spec from article 04]

Implement the functions so all tests pass. Don't add anything beyond what's required above.

That last line — “Don’t add anything beyond what’s required” — matters more than you’d think. Without it, AI tends to add logging, complex error handling, or abstraction layers you don’t need.

Checkpoint pattern

After each task is done, I commit immediately — even if the task is just a 20-line function.

git add -p                          # review each hunk before staging
git commit -m "feat(auth): add hashPassword and verifyPassword utilities"

The reason: small commits = easy rollback. If the next task breaks something, I can git diff HEAD~1 to see exactly which change caused the problem. With large commits, debugging becomes a nightmare.

Checkpoints are also your review moment. Before committing, you read the diff — not the entire codebase, just what changed. That’s the best time to catch issues early.

Context rot: recognizing and handling it

Context rot happens when AI gradually “forgets” the initial context after many exchanges. Signs to watch for:

• AI starts using naming conventions different from what was agreed
• AI suggests solutions that contradict the established architecture
• AI asks again about information that was already provided
• Code output starts diverging from the codebase’s style

When you see these signs, don’t try to “remind” the AI in the same session. The most effective fix:

1. Reset the session — open a new conversation
2. Re-feed context — paste AI_CONTEXT.md and the task description again
3. Add context about what’s been done — “Tasks 1–3 are implemented, here’s the current code: [paste relevant code]”

Context rot typically kicks in after 15–20 exchanges in a session. For complex tasks, I proactively reset after every 2–3 tasks rather than waiting for the signs to appear.

---

Multi-Agent Workflow

Git worktrees: running in parallel

Git worktrees let you have multiple working directories from the same repository — each worktree on its own branch. This is the foundation of multi-agent workflow.

# Create a worktree for each agent
git worktree add ../taskflow-agent-auth feature/auth-utilities
git worktree add ../taskflow-agent-ui feature/login-form
git worktree add ../taskflow-agent-db feature/user-schema

# Each directory is an independent working copy
# Agent A works in ../taskflow-agent-auth
# Agent B works in ../taskflow-agent-ui
# Agent C works in ../taskflow-agent-db

# Clean up when done
git worktree remove ../taskflow-agent-auth

Each agent runs in its own IDE instance (or separate tab in Cursor), pointed at its corresponding worktree directory. The agents don’t know each other exist — they just do their task on their branch.

Orchestrator pattern

With multi-agent, I use a special “orchestrator” agent — this agent doesn’t write code, it just coordinates.

The orchestrator receives the full task list and dependency graph from article 04, then decides:

• Which tasks can run in parallel (no dependencies)
• Which tasks need to wait for others to finish
• When human review is needed before continuing

In practice with TaskFlow, I used the orchestrator to manage all 8 auth tasks:

The orchestrator is also where I track progress — after each batch, I review the output before letting the orchestrator assign the next batch.

Merge strategy

After agents finish, merge in dependency order:

# Merge in order: base first, dependents after
git checkout main
git merge feature/user-schema        # Task 3 — base
git merge feature/auth-utilities     # Tasks 1, 2 — no dependency on each other
git merge feature/auth-endpoints     # Tasks 5, 6, 7, 8 — depend on above

Before each merge, I run git diff main...feature/branch-name to see all the changes. With multi-agent, conflicts usually happen in shared files like types/index.ts or utils/index.ts — files that multiple agents import. The fix: define shared types before running agents and include them in AI_CONTEXT.md.

---

HITL (Human-in-the-Loop) Checkpoints

When human review is mandatory

Not every task needs deep human review. But there are points where you must stop:

• Security-critical code: authentication logic, authorization checks, input validation, cryptography
• Database migrations: schema changes that aren’t easy to roll back
• External API integration: code calling third-party services, handling webhooks
• Complex business logic: pricing calculations, permission matrices, state machines
• Anything AI “invented” outside the spec: if AI added a feature that wasn’t requested, that’s a red flag

For TaskFlow, I do a mandatory review before merging any auth-related task — even when tests pass.

How to review AI code effectively

Don’t read every line of AI-written code — you’ll spend all day and still miss the important issues. Instead:

Focus on the interface, not the implementation. What does the function take as input, what does it return, when does it throw? That’s what you need to understand and agree with.

Read the tests first, then the code. The test spec is the acceptance criteria — if tests pass and the spec is correct, the code is likely correct. Read the code to understand how it works, not to verify whether it works.

Ask AI to explain anything unclear. “Why use Promise.all here instead of sequential?” — the AI’s answer will tell you whether it understands the trade-off or is just pattern-matching.

Check edge cases against the spec. For auth, I check: what happens when a token expires? When the database is down? When a user sends concurrent requests? If the spec doesn’t cover it, that’s a gap that needs filling.

---

Real-World Example: TaskFlow Auth + UI

3 auth tasks with single agent

Tasks 1, 2, and 3 of auth (hash, JWT, user model) have no dependencies — but I chose to use a single agent for all three because they share many type definitions.

Session flow:

1. Feed AI_CONTEXT.md + task spec for all 3 tasks
2. Ask AI to implement Task 1 first, run tests, commit
3. In the same session, ask AI to implement Task 2, run tests, commit
4. Task 3 the same way — AI still has context from Tasks 1 and 2, so type definitions stay consistent
5. After Task 3, reset the session before starting Task 4

Result: 3 tasks in ~45 minutes, consistent code, 100% tests passing.

2 UI tasks with multi-agent

After the auth backend was done, I needed LoginForm and RegisterForm — two independent components with no dependencies between them.

# Set up 2 worktrees
git worktree add ../taskflow-login feature/login-form
git worktree add ../taskflow-register feature/register-form

# Open 2 Cursor tabs, each pointing to a different worktree
# Feed both agents: AI_CONTEXT.md + design system tokens + task spec

Agent 1 implements LoginForm, agent 2 implements RegisterForm — in parallel. Both were fed the design system tokens from article 03, so the styling stays consistent even though they ran independently.

After 20 minutes, I had 2 branches. Reviewed each branch, merged login-form first, register-form second. No conflicts because the two components live in separate files.

---

Pitfalls

Approving AI code you don’t understand. “Tests pass, good enough” is a dangerous mindset — especially for security code. Tests only verify behavior that was specified, not behavior that wasn’t thought of. If you don’t understand the code, you can’t know whether the spec is complete.

Letting agents run too long without checkpoints. An agent running for 2 hours without a checkpoint means 2 hours of code that might be going in the wrong direction. Checkpointing after each task isn’t just about git commits — it’s your chance to verify direction before AI goes too far.

---

Summary

• Feed context in order: AI_CONTEXT.md → spec → task description, at the start of every new session
• Commit after each task: small checkpoints = easy rollback, effective review
• Context rot kicks in after ~15–20 exchanges — reset the session and re-feed instead of trying to remind
• Git worktrees let multiple agents run in parallel on separate branches
• HITL is mandatory for security code, database migrations, and anything AI adds outside the spec

---

What’s Next

The code is implemented and committed. The next step is making sure that code is good enough to merge into main — automated QA, AI-assisted code review, and a PR workflow built for codebases where most of the code was written by AI.

→ Article 06: QA, Code Review & PR Workflow

← Article 04: Task Planning & Test Strategy