I Don't Write Code Any More - I Manage AI Agent Swarms

This morning, a little after 6 a.m. my time, I asked for a new tagline on this site. One sentence, in plain English, typed into a chat with an agent.

The agent filed it as issue #60 at 12:20:35 UTC. A coding agent claimed it, changed the code, rendered the pages and opened a pull request at 12:24:08. About a minute after the issue was filed, I read it and typed three more words: “Add a period.” The issues agent recorded that on the issue, and the coding agent added the period. A separate reviewer agent checked the change and merged it at 12:26:17. A deploy agent published the site and verified the new release over HTTPS at 12:27:47.

Seven minutes and twelve seconds from filed issue to verified production. My total input was one sentence and “Add a period.”

About twenty minutes after it went live, I changed my mind about the wording. Issue #63 was filed at 12:45:42 and verified live at 12:51:50. Six minutes.

I did not write any code for either change. I did not open the code, create a branch, read a diff or run the deploy. I don’t do those things any more. I manage the swarm that does.

This post is about what that job actually is.

The last line of code I wrote

I wrote code by hand for my whole career. In April I wrote Stop Writing Code, and by then I had not typed a line in six months. In June I stopped solving issues myself. In September I stopped running just one agent.

The numbers since then are in I Make 156 Commits a Day Now and 492 Useful Commits on a Sunday. The machinery is in Building a Software Factory and Building Multi-Harness Multi-Agent Swarms. The argument that everyone in software is becoming a manager is in We Are All Managers of Super Intelligence Now.

I won’t repeat any of that here. This post is the view from my chair. What do I do all day, now that the code is not my job?

A day in the job

Here is what my work consisted of, measured from the GitHub record of this repository.

On Tuesday, November 10, Chicago time, 19 issues of real work were filed, plus four throwaway issues that tested the tooling. The swarm merged 19 pull requests with 56 non-merge commits, and the deploy agent verified 9 releases of this site.

This morning, from 6:00 to 7:00 a.m., the issues agent filed five issues from my requests. In that hour the swarm merged four pull requests with eight commits, and the deploy agent published four releases.

What did I actually do in those hours? Five kinds of things.

I talk to an issues agent in plain language. I don’t write tickets. I say what I want, the way I would say it to a colleague: “change the tagline,” “the contact page looks wrong,” “write a post about this.” The issues agent turns that into an issue with a clear outcome, the files involved and a list of checks that prove it works. It reads the open issues first, so it doesn’t file duplicates. The issue for this post is about 1,200 words. I said a few sentences.

I paste screenshots of things that annoy me. Issue #59 started as desktop screenshots of two pages and one complaint: the page banners don’t go all the way across. The issues agent measured where each banner stopped, found the CSS caps responsible and wrote the fix as a spec. It was filed at 12:14:23 UTC and verified live at 12:32:12, about 18 minutes later. The night before, the same thing happened with page titles that wrapped too early, in #51: filed at 00:59:49, live at 01:18:19.

I make yes/no decisions. When an agent hits a choice that is mine, it asks me, and I answer in a few words. These are my real answers, as the agents recorded them on GitHub this week:

• “Yes, collapse it” (start the Astrohacker card collapsed on the Contact page);
• “Yes, switch it” (change the footer’s contact email);
• “that’s ok. proceed.” (publish my token usage in a blog post);
• “Add a period.”

That is most of what management looks like now. A short answer to a precise question.

I read verdicts and release reports. Every pull request gets an independent review, and every release gets verified over HTTPS. I read the outcomes, not the diffs. If a reviewer requested changes three times, I want to know why. If a release was held, I want to know what broke.

I fix the process when it misfires. This is the part that takes real thought. On November 10, I made a decision on issue #32 at 22:30:06 UTC. Four minutes later, a reviewer passed and merged the pull request without it. The decision had reached the coder but not the reviewer. That was not a bad agent. It was a race in the rules. So the rules changed: #35 made the tool refuse to merge a pull request while its issue has newer, unanswered discussion. That race can’t happen again.

That is the day. Talk, point, decide, read, and fix the process.

What I decide, and what I never touch

What I decide:

• What gets built. Every issue starts from something I asked for.
• Taste and copy. The tagline, the layout, the words on the page. Agents draft. I choose.
• Priorities. What runs first, what waits, what gets dropped.
• Risky operations. Anything that touches production, money or another person waits for my yes. Only I start a deploy shift.
• The rules. When the process breaks, I decide how the rules change. Some rules are just my taste, written down as law. This site has a standing rule that it never turns its motion off. The rule lives in the repository, and a test enforces it, so no agent can “helpfully” reverse it.

What I never touch:

• The code. I don’t write it and I don’t read it line by line.
• The branches. Agents create, rebase and delete them.
• The review. A reviewer in a different session approves every pull request. I am not in that loop, and I shouldn’t be: I would be the slowest and least careful reviewer on the team.
• The deploy mechanics. I say “release it.” The deploy agent builds, publishes, checks every page over HTTPS and records the result.

The line is simple. I own the what and the whether. The swarm owns the how.

Old management skills, new reports

Before agents, management meant people. A surprising amount of it transfers.

Andy Grove wrote the rule that matters most in High Output Management. Ben Horowitz quotes it in his foreword: “A manager’s output = the output of his organization + the output of the neighboring organizations under his influence.” (source). That is the whole job now. My output is not my commits. It is the swarm’s merged, reviewed, released work.

What transfers:

• Delegation. You hand off the outcome, not the steps. Agents do better with “the banners should span the full width on desktop” than with “change line 257 of pages.css.”
• Writing a clear brief. Every issue says what should happen, what doesn’t count, and how we will know it works. A vague brief to an agent produces vague work, exactly as it does with people.
• Span of control. I can’t watch every worker. So I don’t. The code role runs at most three workers at once by default, and each one sees its issue through to merge. I manage the role, not each worker.
• Status meetings. These became events. I don’t ask “where are we?” The tooling tells me when something is waiting for me.
• Escalation. Agents ask for clarification or block an issue for a human decision. Those are the only times they interrupt me.
• Trust, but verify. Independent review on every pull request. HTTPS verification on every release. I trust the system because it checks itself.

What is different:

• They work around the clock. The page-title fix in #51 shipped after 7 p.m. The swarm doesn’t keep business hours, and the queue doesn’t empty when I sleep.
• There is no motivation problem. Nobody is bored, burned out or sulking about a code review. I never have to manage morale. I only manage the work.
• Rules must be written down. A person learns your preferences over months. An agent starts fresh every session. If a rule isn’t in the repository, it doesn’t exist. So my preferences become files: an AGENTS.md, a few skills, and tests that enforce the rules that matter.
• They hit rate limits. Every harness and every API has a ceiling. All of my agents share one GitHub API budget of 5,000 calls an hour. When they hit a limit, the rules tell them to back off and resume at the reset time. A human team never runs out of permission to read the issue tracker.
• They race each other. People coordinate by talking. Agents coordinate through claims, locks and refs. When the rules have a gap, two fast agents will find it, as the reviewer did on #32. The fix is always in the rules, never in a lecture.

What I gave up, and what I got back

I loved writing code. I still miss the flow of a hard function finally working, and the feeling of knowing a codebase so well I could find any bug from the symptom. That feeling is gone, and I won’t pretend otherwise.

I don’t miss the rest: the boilerplate, the yak-shaving, the dependency upgrades, the afternoon lost to a build configuration. I don’t miss waiting for review, or reviewing someone else’s thousand-line diff at 11 p.m.

Do I still need to understand code? Yes, but at a different level.

• Architecture. I need to know what the system is made of, so I can ask for the right things and spot a request that will fight the design.
• Specs and checks. I read the acceptance criteria and the tests, because those are the actual contract. As I put it in CAD for Software, the rules and checks are the design file.
• Outcomes. I judge the page, the release and the behavior. Not the lines.

What I got back is leverage. Between 6 and 7 a.m. this morning, I made five requests, and three of them were merged and verified live within the hour. My ambition is no longer limited by my typing speed. It is limited by how clearly I can say what I want, and how good the rules are.

The identity shift is real. For most of my life, “programmer” was who I was. Now I am the person who decides what the programmers build. That is a different job, and I like it more.

How to make the switch

If you write code for a living and want to try this, here are five steps for this week.

1. Stop typing code for one week. Not less code. None. Every change goes through an agent. You will find out quickly what you need to write down.
2. Write the rules in the repository. Start an AGENTS.md with the commands to build and test, the things that must never change, and how a change is verified. Every time an agent surprises you, add a line.
3. Make every task an issue with a check. Write what should happen and how you will know. If you can’t say how you will know, you aren’t ready to delegate it.
4. Separate the writer from the reviewer. Never let the session that wrote a change approve it. Use a second agent, in a second session, with a review checklist.
5. Add a second worker, then a third. Once one agent can take an issue to a reviewed merge without you, run two at once. That is the day you stop being a programmer and start being a manager.

If you want the hands-on setup, the Astrohacker blog has a guide: Build an Agent Swarm With Claude Code. For how the work gets checked, read Who Checks the Software Factory?

The takeaway

I don’t write code any more. I talk, point, decide, read and fix the rules. The swarm files, codes, reviews, merges and ships.

The new job is still management. Grove’s rule still holds: your output is your organization’s output. The difference is that the organization now runs around the clock, never gets tired, and does exactly what the written rules say. So the most important thing I produce is no longer code. It is clear requests, quick decisions, and good rules.

This is how all of our software gets built at Astrohacker. If you want a complex system built this way, or want your own team to work this way, start at astrohacker.com.