What I mean when I say agentic development

What I mean by agentic development is something different. It's a change in the unit of work. Instead of writing code line by line — or even function by function — you're operating at the level of intent. You describe a system, a behavior, a constraint. The agent reasons about how to implement it, asks clarifying questions, proposes approaches, identifies edge cases you hadn't considered. You evaluate, redirect, and iterate. The code is an output of that process, not the process itself.

The shift is from author to director. You're not writing the sentences; you're responsible for the story.

A concrete version: when I wanted a production deploy that could never take the site down, I didn't sit down and write the shell script. I described the behavior I wanted — snapshot the live config, validate the new one before committing to it, roll itself back automatically if the check fails, then poll the real endpoints to confirm the service actually came up. The agent turned that description into the exact sequence of commands. My work was the specification and the judgment about whether the result was right. The code was downstream of both.

This sounds like a small distinction. It isn't. It changes what you need to be good at. The bottleneck moves from implementation to specification. The hard part is no longer "can I write this function" — it's "can I describe precisely what this system should do, including the parts I haven't thought of yet." That's a different skill. It's closer to architecture than to programming.

The rigor this demands is not rhetorical. I write the instructions I give agents in a deliberately constrained English — active voice, short sentences, one idea per sentence, the same word for the same idea every time — because ambiguity in the specification does not stay ambiguous. It becomes a wrong guess in the output, and a wrong guess is a bug you have to find later, when it's expensive. Precision in the description turns directly into precision in the result. The discipline of describing a system cleanly is not a writing exercise; it's the actual engineering.

It also changes what's possible for a solo builder. The constraint on a solo developer has always been time and cognitive bandwidth. You can only hold so much in your head. You can only write so much code. Agentic development doesn't remove those constraints entirely, but it shifts where they bind. The constraint becomes judgment — knowing what to build, in what order, with what tradeoffs — rather than execution. And judgment doesn't scale the same way execution does. One person with good judgment can now direct a system that produces the output of a small team.

That's why I can build across as many domains as I do. Not because I'm faster at writing code. Because the domains that interested me were always bottlenecked by execution, and now they're bottlenecked by curiosity and judgment instead. Those are resources I have more of. The same is true structurally: once execution is cheap, the leverage moves to reusing one engine across many subjects rather than rebuilding from scratch each time.

The picture most people have of AI coding is a pair: one human, one assistant, one file open on the screen. That is not the shape my work takes. The command center that runs this portfolio hands work to several agents at once, and my job across all of them is to be the gate and the direction, not the hands on every keyboard. I review, I redirect, I approve. The throughput of the whole system stops being bounded by how fast I personally type and starts being bounded by how well I can specify, sequence, and judge.

Running several agents against the same repository the naive way is a fight over shared state. Two of them editing the same files at the same time produces half-finished edits landing in the middle of each other's work, and a build that makes no sense. The fix is unglamorous. Each agent gets its own copy of the working tree — a separate git worktree — so parallelism stops being a coordination problem and becomes simple isolation. They can't clobber each other because they were never writing to the same place. This is the difference between a fleet that multiplies output and one that multiplies conflicts.

Directing agents only works if handing off doesn't mean losing control, and the thing that makes it safe is not trust — it's structure. The first piece is reversibility. Every change an agent makes near production snapshots the state it is about to overwrite, so the undo exists at the same instant the change does. Nothing important gets replaced without a known-good version set aside first. That turns a bad change from a disaster you reconstruct under pressure into a state you simply restore.

The second piece is memory that survives across sessions. An agent that starts every task with an empty head relearns the same context every time, which is slow and where subtle mistakes creep in. So the command center keeps a small, curated set of facts — one idea per note, sorted into categories, some of them deliberately scheduled to be forgotten — that an agent reads before it begins. Continuity lives in the system, not in whatever happened to survive inside one conversation's context window. Reversibility bounds the downside; memory raises the floor. Together they make delegation something other than a gamble.

There's a version of this that sounds like hype, so let me be specific about what it isn't. It isn't magic. The agents make mistakes — sometimes subtle ones that are harder to catch than obvious syntax errors, plausible-looking code that is quietly wrong in a way you only find when it runs. The specification problem is genuinely hard; describing a system precisely enough for an agent to implement it correctly requires a kind of rigor that most people underestimate. And there are classes of problems — novel algorithms, deep domain expertise, systems that require intuitions built over years — where the human judgment component is so large that the throughput gains are modest.

What it is, in the domains where it works well, is a genuine multiplier. Not 10% faster. A different order of magnitude.

The persona I created in 2019 — AutonomousAJ — was a way of naming this before I had the tools to practice it. Alan Turing and John McCarthy: the theorist of machine intelligence and the man who named the field. The name was aspirational. It described someone who builds with intelligence as a collaborator, not just a tool. At the time, the tools weren't there. Now they are, imperfectly and unevenly, but recognizably.

The interesting question isn't whether agentic development is real. It is. The interesting question is what it means for what gets built. If the bottleneck shifts from execution to judgment, then the things that get built are the things that someone with good judgment and genuine curiosity decides to build — not the things that are feasible given a team's bandwidth. That's a different selection pressure on software. I think it produces different software. More idiosyncratic, more domain-specific, more genuinely curious about the problem it's solving.

That's the theory, anyway. The practice is: I keep building things, and they keep working, and the domains keep expanding. That's evidence enough for now.

This piece is part of my series on running a fleet of autonomous agents. Start with One operator, a fleet of agents.