A year ago I was a sceptic. I’d tried the tools, got bad results, and dismissed them. Today I run multiple agents in parallel on a daily basis. Nothing dramatic happened in between. The tools quietly crossed a threshold where ignoring them started costing more than learning them, and I grudgingly came along.
The wider discussion is rarely as measured. One camp expects agents to replace developers; another dismisses the entire category as hype. My experience sits somewhere between those positions, which is more interesting than either extreme.
Along the way I noticed something I don’t see discussed enough: the journey from “this is just autocomplete” to “I’m shipping with multiple agents in parallel” isn’t a smooth ramp. It’s a series of uncomfortable jumps.
This chapter is the introduction to a series where I’ll break down that journey: what it actually looks like in practice, what the hard parts are, and what I wish someone had told me earlier.
The Stages
The progression from AI-sceptic to agent-native follows a rough path that several people have mapped in different ways. Steve Yegge described it in his “Welcome to Gas Town” essay, Geoffrey Huntley documented his own progression in a six-month recap, and Justin Abrahms synthesised much of this into a clear stage model. Drawing from all of them (and from my own experience), it looks something like this:
- Dismissal. “It’s just hype.” You tried it once, got a bad result, and moved on.
- Fear. Someone on your team ships a feature in an afternoon using Cursor. You start wondering about job security.
- Tentative experimentation. You install Copilot. Tab completions, the occasional chat question. It’s fine, sometimes useful.
- Agent with training wheels. You enable an IDE agent but approve every single action. You’re still firmly in control.
- YOLO mode. Permissions off. The agent fills the screen. You review diffs instead of writing code.
- Breaking out of the IDE. CLI agents. The IDE becomes the bottleneck, not the workspace.
- Multi-agent. Three to five parallel instances. You’re managing a small fleet and shipping fast.
- Autonomous loops. AFK coding. Agents iterate overnight against success criteria you defined earlier.
- Swarm management. Ten or more agents, hand-managed. You spend more time coordinating than coding.
- Orchestrator builder. You build (or adopt) tooling to manage the swarm. This is Yegge’s Gas Town territory.
- “The Matrix” moment. You can build anything. You just do things because it’s faster than explaining why someone else should.
A stage list is only useful if it helps explain where people get stuck. In my own work and in conversations with other developers, three transition points keep appearing. I’m calling them fulcrums.
The Three Fulcrums
Fulcrum 1: Letting Go of Control (Stages 4 → 5)
This is the trust barrier, and it is a common place to stall.
You’ve been approving every agent action, reading every line it produces. Then someone tells you to turn off permissions and let it run. Your gut screams no, often for sound technical reasons: the safeguards and recovery path need to deserve your trust. Even after those are in place, there can be a psychological hurdle.
You go from “AI assists me” to “I supervise AI,” and that reframing challenges how many of us think about our craft. Developers I have discussed this with often describe the transition as giving something up, even when the result is more useful work.
Fulcrum 2: One-to-Many (Stages 6 → 7)
This one is operational, not emotional. By now you’ve accepted that the agent does the work. The problem is that you are the bottleneck. You can’t review everything a single agent produces, let alone multiple agents.
The shift is from code review to designing constraints: tests, lints, CI pipelines, success criteria that validate work without you reading every line. Huntley calls this “backpressure”, and it’s a good term. You’re becoming an engineering manager of machines. If you’ve never managed people, this feels alien. If you have, it feels eerily familiar.
Fulcrum 3: Human Limits (Stages 9 → 10)
In my experience, hand-managing ten or more agents breaks down. At that point you either add orchestration tooling or accept a ceiling. This stops being a personal productivity technique and becomes a systems engineering problem.
You’re no longer only a developer using AI. You’re also building the system that produces and checks the software. The skill set broadens from software engineering into operations and context engineering.
The Pattern
Each fulcrum changes where human attention goes. First you give up writing every line. Then you replace line-by-line review with stronger constraints and targeted review. Finally, you stop coordinating every task by hand. Stage 11 (“The Matrix” moment) is what the model calls the point where all three shifts feel normal.
Whether you find that exciting or terrifying probably says something about where you are in the progression right now.
What This Series Covers
In the chapters that follow, I’ll walk through the practical side of this journey: how to set up your environment, how to write effective CLAUDE.md files, what context engineering actually means in practice, how to work with single and multiple agents, and what security looks like when your code is being written by something that doesn’t understand the concept of “production database.”
I’ll be drawing from my own daily workflow with Claude Code, from the practitioners and writers who’ve been mapping this territory (Yegge, Huntley, Abrahms, among others), and from my own mistakes along the way.
As with most things I write, in a few months I’ll revisit this and realise I was wrong about half of it. A year ago I was the sceptic.