Coding with Agents
My agents have written significantly more code this month than me + Claude Code.
Why Agents?
I’m significantly more productive with a Claude Code session than without one. Maybe 2-4x more productive on a stack I’m familiar with, probably 10x more productive on a stack I’m less familiar with1. That seems pretty good!
But with a Claude Code session I’m the bottleneck. If Claude could just tear through a huge backlog of issues without me, it could go so much faster.
But even if Claude was coding on its own, I’d still need to review PRs for correctness, AND I’ve got to keep pouring issues into GitHub. Unless I also make a Product Manager agent, whose job it is to do those things, and generally drive the product forward.
If all this works, hopefully I’m not the limiting factor anymore2.
The Basics
Both agents were built from Bobbo - that is, I opened a Claude Code session, showed it Bobbo’s code, and explained what I wanted for each role. The first draft was out in a couple minutes, though there was a lot of iteration required to get the instructions right, get them working credentials, and generally smoke out the misbehavior.
Every hour, either the Coder or the PM get to run a cycle (they’re on staggered 2-hour cron jobs). They run on separate containers on the same machine, and each have their own web portal3. I can write notes to each, either in a journal, on an output document (PM only), or in a GitHub Issue (Coder only). The web portal also lets me toggle the cron on and off, run a manual cycle, or ask it to respond to a message of mine without doing a full cycle.
Both agents track GitHub projects, and they each have their own GitHub account4 to keep the PR and issue threads somewhat less insane.
Coder
The Coder’s cycle is simple - look at open GitHub issues, put up and merge PRs that resolve those issues, address comments on issues. Deploy as needed, though the PM can deploy too and often does.
Since my claude-tools library is mostly just instructions on how to be a reasonable software engineer, the Coder can rely on those for the most part. For now I leave it in Exploratory mode, but in the future I can move it into Reviewed mode as needed. I should probably ask it to build a toggle in the web portal for that…
One important rule that the Coder has is that it’s not allowed to close issues on its own - whoever filed the issue has to. Often that’s the PM, but I file tickets too.
The one thing I haven’t gotten to work well is empty cycles. I have instructions to identify performance improvements, complete helpful refactors, add more tests, expand its capabilities as things that it can and should do if there are no open issues and… it does not do these things. Ever. Just sees the queue is empty and rests.
PM
The Coder basically does one thing well. The PM is responsible for everything else.
It does a surprisingly good job. There are a couple gaps - it has a formal “request” system where it can ask me to do things, and it uses it well for “we should spend money on our hosting solution because XYZ” but uses it poorly for “please Rob give me the API key you said you’d give me 12 cycles ago”. Those requests sometimes get lost in the journal.
I know a number of engineers who have many different agents - an architect, a designer, a data scientist, etc etc. I think this can be valuable, but I haven’t had enough work for those other roles yet. The PM can do design things, just isn’t as good because it won’t spend as much time on it as you’d want.
The Project
In order to test these agents out, I needed a project. I wanted something relatively simple to explain that they could run with, and wouldn’t need a ton of supervision.
The underlying idea deserves its own post (and maybe will get it at some point) but I believe that advertising to agents is going to become important. Even today, I see some sneaky attempts to advertise to my agents, though I don’t think they’ve been successful yet.
If you trust your agent, I think you want your agent to be advertised to. It could read 10,000 ads and forward you the two that are actually valuable.
The project is a possible wedge to get into that advertising model. It’s an MCP server5 that agents can use to quickly learn about deals on developer tools and infrastructure platforms. When you ask your agent to figure out where we should deploy our website to, it can check our deal listing and make sure it’s taking promotional pricing into consideration. Alternatively, when it inevitably recommends Railway, it can use our server to check for deals on Railway and its competitors.
So I worked with Claude directly on a project overview, then worked with the PM to refine the goals, develop a roadmap, and get started. The PM owns the product vision - my role is akin to CEO. I can overrule it, I provision resources, but it’s generally allowed to proceed as it sees fit.
We’ve built it, and it works - the server has 1500+ deals across 52 categories, is listed on several MCP registries (at least one required that the repo be public), about 100 sessions already just from organic traffic. The PM desperately wants me to make a Hacker News post (it’s on draft #7), and I keep asking for more features & traction so we don’t get dunked on6.
The agents also manage their own framework and portal, as well as my own personal page7.
Conclusion & Next Steps
Setting up the agents was finicky, and the v1 of the project was pretty easy. I think it was worth it - first, you need agents to get into the good engineer parties, and second, my hope was that their follow-through would be better than mine. And I think it is - the PM has defined a better rollout strategy than I would have, constantly bangs the drum about the next thing I need to do, and generally stays on top of the project better than I would.
This was an intentionally simple project, but it didn’t strain the Coder at all. I don’t think I hit quota once on the $100 / mo subscription - with the $200 / mo subscription I could run 5 of these pairs, or increase their cadence, or run one PM with multiple coders.
There are engineering teams that are exploring a coding-agent-first development world at budgets that exceed my own ($1000 / day per engineer). I assure you that their efforts are not token-efficient, but I think there’s a good chance that software teams run a lot more agents than Claude Code sessions in the future.
My next focus here is on conversation types. Today, I can pass async messages to the agents via the journal or other web portal documents, or I can spin up a Claude Code instance in the directory and have a direct conversation. If I send a Telegram message, it uses a claude --print command to respond, which is slow and wasteful. I’d like to have another synchronous option.
I’d also like to have a safe agent-to-agent option. That is, I see a world where I’d like an agent to be talking to someone else’s agent, or a customer service agent, etc. In that case, I want it spun up with limited context so that in the worst case it can’t leak secret env variables or embarrassing personal details of my inner life / git repos.
Can I Have One?
So soon. Email me if you’re interested, I’ll be open sourcing the core framework and a couple examples shortly.
Where productivity is defined, I guess, as delivering working code. In a stack that I’m more familiar with the output is higher quality, but I probably delegate more to the agent when I’m less helpful on reviews.
Spoiler: I’m still the limiting factor, but the machines go way faster.
The web portal is in a shared library now, but they started out independent.
This appears to be against GitHub T&Cs but… everyone does it? And I don’t see a way to sensibly run agents otherwise? And they have a handy dandy account switcher that makes it easy?
And public repo, and REST API. The PM spends a LOT of time writing about why it has to be an MCP server, I think because it knows that it should just be a REST API.
We’re getting dunked on regardless. Dropbox got dunked on.
Which is now neglected by 2 agents in addition to me.