The 5 Levels of Agentic Coding: Why I Mostly Stay at Level 2

This post is about the levels of agentic coding I’ve worked at while building 4 apps that are all in production. My sweet spot is level 2 (one agent in one conversation) or level 3 (several agents at once in parallel git worktrees), depending on the roadmap and the deadline.

Level 4 is a software factory: an agent called pm that runs a Linear board and hands the work out to the other agents. One has been building Daiku nonstop since 13 October. It’s working better than I expected!! I also keep having to ask my own project what it did today, which is something I never had to do at level 2.

The 4 apps are Dewfall, for reading the whole Bible one verse at a time; PrayingPeople, for praying together in groups; Daiku, which gives your AI its own browser; and this site. All 4 are side projects and none of them interferes with my full-time job as an AI Engineer at IBM. Across all of them I’ve tried pretty much every way of working with agents I know of. Every level below comes with what it felt like, where it broke and what you can do about it.

What is agentic coding?

Agentic coding is writing software by telling an AI agent what you want and letting it read your code, edit files and run commands by itself while you review what it did. The agent is a program like Claude Code, which is what I use for all of this, or Codex. It works in a loop: it changes something, checks the result and goes again until it thinks it’s done.

Agentic coding vs vibe coding

Vibe coding is the same loop with the reviewing taken out. Andrej Karpathy named it in February 2025: “a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Every level in this post has somebody reading the code at some point. What changes as you go up is how many agents there are and whether that somebody is still you.

The 5 levels of agentic coding

Level	What it looks like	Where it breaks
1. Manual	Every line typed by hand	Obsolete
2. One agent	1 conversation: I describe it, it cooks, I review, we ship	Slow
3. Parallel agents	7 or 8 sessions, each in its own worktree	Worktrees to set up and clean up
4. Software factory	Agents called pm, maintainer and sentry work a Linear board	I lose track of my own project
5. ???	Tell me (end of the post)

I’m not the first person to number these. Dan Shapiro modeled his 5 levels on the levels of self-driving cars, from “spicy autocomplete” to the “dark factory”. Steve Yegge’s 8 stages in Welcome to Gas Town go from no AI at all to building your own orchestrator. Mine are coarser. They come from shipping 4 apps. Each one is about what I actually did all day at that level and what it cost me.

Level 1: manual coding

Level 1 is you, an editor and every line typed by hand. For me it’s obsolete.

The skill isn’t obsolete though (sorry!!). Levels 2 and 3 are mostly reading code an agent wrote and I read it with everything I learned typing it myself. If you’re early in your career, keep writing some code by hand. You’ll need it to review any of the levels after this one.

Level 2: one agent, one conversation

Level 2 is 1 agent in 1 conversation. I describe what I want, it cooks, I review, we ship. Then the next thing, then the next.

It’s slow. It’s slow the way a coworker is slow when they can only do one thing at a time and you’re watching them do it. It’s also the level that feels the most like working with somebody: it’s basically pair programming, where the agent is the “driver” typing and I’m the “navigator” watching where it’s going and catching what’s off.

Spec driven development: let it grill you first

The bigger version of level 2 is spec coding, which GitHub calls spec driven development. I describe a spec or a product requirements document (PRD), the agent grills me about it until neither of us has a question left, and then it builds while I review.

What you can take from level 2:

1. Ask to be grilled before anything gets built. Something like “ask me one question at a time until you could build this without me” gets your vague idea written down as a spec. The agent finds the gaps while they’re still cheap to fill.
2. Keep the spec in the repo. Dewfall and Daiku both still have the spec they started from, in a file called GENESIS.md at the root. Every new conversation can read it and you don’t have to explain the app again.
3. Review every diff while it’s small. Level 2 is the one level where you see each change as it happens. Use it for the code you’ll have to debug yourself later.

Level 3: parallel agents in git worktrees

Level 3 is 7 or 8 Claude Code sessions at once, each one told some version of “in a separate branch and separate worktree, build this”. A git worktree is a second working folder for the same repository, checked out on its own branch. That way 2 agents can edit the same app without touching each other’s files. They each finish on their own, I review each one on its own, then we merge it all into main and deploy once at the end.

It’s kinda nice!! I’m not alone in it either: Boris Cherny, who created Claude Code, runs 5 sessions in his terminal and 5 to 10 more on claude.ai, each local one in its own git checkout (InfoQ, January 2026). Simon Willison wrote about the parallel coding agent lifestyle last October and found the same catch I did: you can start lots of tasks at once, but you still review them one at a time.

What I don’t love is the worktrees. Every one has to be set up (a fresh checkout has no node_modules and no .env), torn down and cleaned up. I’m bad at the cleaning up part. Dewfall’s repository has 17 worktrees in .claude/worktrees/ right now. The oldest is from 2 July and 13 of them are already merged into main… they’re just sitting there. PrayingPeople has 5 more that Cursor made.

How to make worktrees less annoying

1. Let Claude Code make them. claude --worktree feature-auth (or -w) creates one under .claude/worktrees/feature-auth/ on a branch called worktree-feature-auth (the docs). Add .claude/worktrees/ to your .gitignore.

2. Copy your secrets in automatically. List .env and any other ignored files you need in a .worktreeinclude file at the root. Claude Code copies them into every new worktree.

3. Know which ones clean up after themselves. When a session in a worktree exits with nothing in it, Claude Code removes an unnamed worktree by itself and asks first about a named one. Anything with work in it is up to you.

4. Sweep the merged ones. This removes every worktree whose branch is already in main. git worktree remove refuses one with uncommitted changes. Work you haven’t committed stays put:

   git worktree list --porcelain \
     | awk '/^worktree /{w=$2} /^branch /{b=substr($2,12); if (b!="main") print w, b}' \
     | while read -r w b; do git merge-base --is-ancestor "$b" main && git worktree remove "$w"; done

5. Split the work by files. Give 2 agents tasks that touch different files, or the merge at the end is where you’ll pay for it. Claude Code’s own docs say the same about agent teams: “Two teammates editing the same file leads to overwrites.”

Level 4: an AI software factory

An AI software factory is a group of AI agents that works through a whole roadmap by itself, with agents in roles like product manager, maintainer and engineer, while a person sets the goal.

For Daiku I made a Linear workspace and worked with an agent to fill it with a whole roadmap: projects, epics, tickets, the lot. Then I started more agents: one called pm, one called maintainer and as many engineers as I needed. pm never writes code. It hands out the work in order, reviews it and checks it against git, the live site, PostHog, Sentry and Cloudflare’s wrangler. Claude Code lets one session message another with an @-mention (cross-session messaging). I just tell pm to tell @maintainer to do something and they coordinate it between themselves. I only ever talk to pm. This is what /list-agents showed in one of my sessions on 16 October (trimmed):

Peer sessions (5):
  sentry [49a9ce]  ·  interactive  ·  idle  ·  started 4d ago
  pm [df54eb]  ·  bg  ·  idle  ·  started 3d ago
  maintainer [34091f]  ·  interactive  ·  idle  ·  started 4d ago

Then I gave pm one goal: “finish the entire Linear board”. It’s been going since 13 October and it’s still going. I’m paying a fortune in tokens for this but it’s worth it because it’s for science!!

What it’s like to actually run one

On 16 October, 3 days in, the board had 475 tickets across 25 projects and 273 of them were done.

57%

Done

273

Still open

181

Canceled or duplicate

21

The factory doesn’t sleep. Between midnight and 6 in the morning it pushed 17 commits on 15 October and 27 on 16 October. Here’s some of that second night, trimmed, from git log:

23:53  Correction: the /app chmod did not fix it; isolate the real layer instead
00:07  DAI-456: the chmod fix holds. A clean dry run proves it, full fidelity this time
00:23  DAI-456: fix the tarball at the source, root the extraction, scan /app's own modes
02:37  DAI-468: fix a real double-attach bug found before the test-mode run
02:53  DAI-468: a Workers regression test for the double-attach fix, per pm
05:14  DAI-351: the ensureBrowserReady fix was itself wrong; corrected

That’s a whole debugging story at 2 in the morning, with a fix of a fix at the end. pm makes calls too. The agents write every decision down in a file called DECISIONS.md. It has lines like “pm’s call, having seen the numbers” and “pm’s review before deploy caught three real gaps, all fixed before shipping”. It even set itself a bar for when to bother me: a change that adds more than about 200 milliseconds to starting someone’s browser has to go past me first.

Cognitive debt: asking my own project for an update

I’m happy because it’s moving forward. I’m also kinda confused. I have impostor syndrome and fear of missing out (FOMO) in my own project because I don’t really know where it is, what’s happening or what the last few things that happened were. I keep having to ask pm for an update. On my own product!! When something breaks I tell them to fix it and they do. I don’t really know more than that.

I even have one more agent, sentry, that watches Daiku’s 3 projects in Sentry. I’d have told you it pings pm to fix every exception right away. Then I asked them for this post. sentry files the bugs in Linear itself, with the trace and a suggested fix. It has never messaged pm and pm has never had a ping from it. And on 16 October, when a deploy added a database column without bumping the schema version and no AI could start a task on Daiku for about 6 hours, I was the one who noticed!! pm has since added a check in PostHog that catches that kind of outage within the hour.

I didn’t know how my own factory handles an exception until I asked it!!

There’s a name for this. Margaret-Anne Storey calls it cognitive debt: the debt from going fast “lives in the brains of the developers”. Even when agents write code that’s easy to understand, “the humans involved may have simply lost the plot”. Simon Willison hit it on his own projects in February: “I no longer have a firm mental model of what they can do and how they work.”

Here’s my version of it as a number: on 16 October DECISIONS.md was 66,725 words long and the repository is 12 days old!! About 18,000 of those words came in the 3 days pm has been in charge. That’s what I’d have to read to know where my own project is.

02040608047101316Words 66.7

Day	Words
4	2.0
5	9.0
6	20.5
7	28.3
8	30.7
9	38.0
10	43.4
11	44.3
12	48.7
13	51.4
14	52.0
15	63.3
16	66.7

In my React Summit talk last year I said “Productivity is our ability to get stuff done”. Level 4 gets a lot of stuff done, some of it at 3 in the morning. What that sentence leaves out is that I need to know what got done. Level 4 is where I stopped knowing.

How to keep a software factory readable

If you build one of these, build the part that keeps you in the loop first:

1. Make every decision land in one file, then read only what changed. git log -p --since=yesterday -- DECISIONS.md is the last day of decisions and nothing else.
2. Put a ticket number in every commit. Every Daiku commit starts with its ticket, like DAI-468. That way git log reads as a changelog by ticket and every line leads back to why it exists.
3. Schedule the update instead of asking for it. Have pm write you one note a day, in plain words: what shipped, what broke, what it decided without you and what it needs from you. If you’re out and about, just tell Claude to push-notify you. With Remote Control on, Claude Code sends the update to the Claude app on your phone when you ask for one (“notify me when the migration’s done”).
4. Write down when it has to ask you. Daiku’s pm came up with its own 200 millisecond bar. Set yours before you start: money, people’s data, anything a user sees, anything you can’t undo.
5. Give it a way to check its own work. Boris Cherny says giving Claude a feedback loop, “such as running a bash command, a test suite, or testing the app through the browser”, can make the result 2 to 3× better. In a factory the agents are the only ones checking.
6. Ask the agents what they actually do. Every so often, ask each one to describe its job and its last few days in a few lines, the way I did for this post. Mine didn’t match what I’d have told you about them.

What’s level 5?

I don’t know!! Dan Shapiro’s level 5 is “a black box that turns specs into software”, where “humans are neither needed nor welcome”, and he says the people he knows doing it are “small teams, less than five people”. StrongDM’s AI team runs one of those, where “Code must not be written by humans” and “Code must not be reviewed by humans”. They also say that “If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement”, which is wild.

Maybe level 5 is more of that, with no pm to talk to because the agents write the roadmap too. Maybe it’s a factory that goes as fast as level 4 and still keeps me knowing my own project. I’d love to hear from you on this one.

The sweet spot is level 2 or 3

After all this, I’d pick a mix of level 2 and level 3 depending on the roadmap and the timeline. And I find the “separate worktree, separate branch” setup kinda annoying to set up, tear down and clean up. So I tend to lean toward level 2 even though it’s somewhat slower.

How to pick your level

1. Will you be the one debugging it? Stay at level 2 and read every diff while it’s small.
2. Is it a pile of small, independent tasks with a deadline? Level 3, split by files, and sweep the worktrees as you merge.
3. Is it a whole roadmap you’re happy to review as results instead of code? Level 4, but only once the readout from the last section is in place. Look at the token budget before you start.
4. Run as many agents as you can review. Starting agents is free. Reviewing them is where your day goes.
5. Change levels inside the same week. A level 3 morning for a stack of small fixes and a level 2 afternoon for the feature you care about is a normal week for me.

Maybe I lean toward level 2 because it’s the closest to actual human communication. It’s one conversation, back and forth, about one thing. It feels like community, like pair programming, and maybe that’s what we’re all after anyway.

We were made for community

That pull toward having somebody next to me while I build goes all the way back to the first pages of the Bible!!

In Genesis, God makes the world in 6 days. When He’s done, “God looked upon all that He had made, and indeed, it was very good” (Genesis 1:31). Then chapter 2 tells it again from the ground. God puts the first man in the Garden of Eden “to cultivate and keep it” (Genesis 2:15) and brings him every animal to name. And for the first time in the Bible, God calls something not good: “It is not good for the man to be alone. I will make for him a suitable helper” (Genesis 2:18). Nothing had gone wrong yet. There was no sin, no pain, a perfect garden with work to do and God right there with him. Being alone was still not good. God’s answer was Eve, in the story everybody knows as Adam and Eve.

An agent isn’t a person. I’m pretty firm on that: software isn’t made in the image of God. People are, made for community the way Genesis 2 says. Level 2 is a pretty good imitation of that: one conversation, back and forth, somebody to think out loud with. At level 4 I lose even that. I think that’s why I keep drifting back to level 2.

So that’s where I’ve landed, for now. Have you found a sweet spot of your own? Have you worked at something you’d call level 5? What do you think?