4 FPS
Nathan Atherton
Back to Blog
AIEngineering

Why I Stopped Writing Code and Started Orchestrating AI Agents

Nathan Atherton· Staff Software EngineerMarch 28, 20267 min read

Six months ago, I made a decision that fundamentally changed how I work as a software engineer. I stopped writing code. Not because I don't enjoy it - I love it - but because I discovered something that multiplies my output by an order of magnitude: orchestrating AI agents as a team lead.

The Problem with "AI-Assisted" Coding

Most developers use AI as a fancy autocomplete. You write a comment, it fills in the function. You paste an error, it suggests a fix. That's useful, but it's still you doing the work. You're still blocked while the AI generates. You're still context-switching between thinking about architecture and writing semicolons.

I wanted something different. I wanted to be the manager of a development team - where the team happens to be AI agents.

Introducing Team Lead Mode

The concept is simple but powerful: Claude Code acts as a team lead. It never writes code directly. Instead, it creates teams, assigns tasks, spawns background agents, and coordinates their work. Meanwhile, I stay completely free to converse, redirect priorities, and make decisions.

Here's what my workflow looks like in practice:

Me: "Build the blog section  -  data layer, page component, and card grid"

Claude (Team Lead):
  → Creates team "blog-build"
  → Spawns Agent 1: "Create blog post data file with types"
  → Spawns Agent 2: "Build BlogPage component with routing"
  → Spawns Agent 3: "Build BlogCard grid component"
  → All three work in parallel, in background

Me: (free to discuss design decisions, review other PRs, or pivot direction)

Agent 1: "Done  -  created blogPosts.ts with interface and 10 posts"
Agent 2: "Done  -  BlogPage with filtering and search"
Agent 3: "Done  -  responsive card grid with hover animations"

The key insight is that I'm never blocked. While agents work, I can talk to the team lead about the next feature, discuss architecture, or change direction entirely.

How It Actually Works

The configuration lives in my global CLAUDE.md file. The critical section defines what the team lead does and doesn't do:

### I am the MANAGER. I do NOT do work. EVER.

What I DO:
- Create teams (TeamCreate)
- Create and assign tasks (TaskCreate, TaskUpdate)
- Spawn teammates (Task with team_name + run_in_background: true)
- Communicate with teammates (SendMessage)
- Report progress and results to the user
- Stay available for conversation at ALL times

What I NEVER DO:
- Edit or write files
- Read files for implementation purposes
- Run builds, lint, or dev servers
- Block the conversation waiting for an agent to finish

This isn't just a suggestion to Claude - it's a hard constraint. The team lead literally cannot touch files. It can only create tasks and talk to agents who do the work.

Why This Matters for Staff Engineers

As a staff engineer, my highest-leverage work isn't writing code. It's:

  • Making architectural decisions that affect the entire system
  • Unblocking other developers (or in this case, other agents)
  • Maintaining context across multiple streams of work
  • Course-correcting early before work goes in the wrong direction

Team Lead Mode lets me do exactly this. I'm the person with the full picture, making real-time decisions while parallel streams of work execute around me.

The Parallel Advantage

The biggest productivity gain isn't the AI writing code faster than me. It's parallelism. A human developer works on one thing at a time. With Team Lead Mode, I routinely have 3-5 agents working simultaneously on different parts of a feature.

A feature that would take me a full day of focused coding can be done in an hour - not because each agent is faster than me, but because five of them are working at once while I orchestrate.

What I Learned

It took a few weeks to develop good instincts for this pattern. Some lessons:

  • Group agents by file ownership. Two agents editing the same file creates merge conflicts. One agent per file or module.
  • Fresh context per agent. Don't try to share state between agents. Give each one a clear, self-contained task with all the context it needs in the prompt.
  • Verify separately. Spawn a dedicated verification agent (using a cheaper model like Sonnet) to run lint, typecheck, and tests after implementation agents finish.
  • Don't over-decompose. If a task takes 5 minutes for one agent, don't split it into three sub-tasks across three agents. The coordination overhead isn't worth it.

Is This Still Engineering?

Some people push back on this approach. "You're not really coding anymore." And they're right - I'm not. But I'm still engineering. I'm designing systems, making trade-offs, reviewing output, and ensuring quality. The craft hasn't disappeared; it's elevated.

A film director doesn't hold the camera, adjust the lighting, and act in every scene. They have a vision and a team that executes it. That's what modern software engineering can look like - and I think more of us will work this way soon.

If you're curious about the full setup, I've published everything in my Claude Code Power Setup gist. It includes the complete CLAUDE.md, all the hooks, slash commands, and the configuration that makes Team Lead Mode work.