Last month I wrote about how a PM ships software without an engineering team. The short version: Claude Code closed the gap between an idea and a running product, so I could spend my time on the parts of the job I’m actually good at. This time I want to go deeper on one question: what does project management actually look like when the “team” is one person and an agent?
The interesting part was never the code. It’s the connective tissue around it: planning, tracking, documentation. That’s where solo projects quietly rot, and it’s the part I’ve stopped doing by hand.
The code was never the part that rots
Solo builds die in the gap between the commits and the plan. The backlog goes stale. “Done” drifts. You defer something for a good reason and forget the reason. Three weeks later you can’t tell what shipped from what’s half-built behind a flag, so you stop trusting your board, stop updating it, and start coding into the fog.
On a real team, a PM and a tracker hold that line. Solo, you are the tracker, and it’s the first thing you stop maintaining. I didn’t want a prettier to-do list. I wanted the planning layer to stay true to the code without me playing courier between them.
Wiring the agent into the tracker
Ceres, the assistant I’m building for our garden, lives in a Gitea repo with issues and milestones. The unlock was giving Claude direct hands on that tracker through the Gitea MCP. Now the same agent that writes the code reads and writes the issues, milestones, and comments. No more “I’ll update the board later.”
From a spec doc to a populated board
First the board had to exist, and I didn’t hand-write thirty issues to get there. I wrote a detailed spec for Ceres: what it should do, the constraints, the rough phases, what “v1” meant. The kind of document I’d hand a real engineering team before kickoff.
Then I pointed Claude at it. Through the Gitea MCP it read the spec, broke it into milestones matching my phases, and filed issues under each one with descriptions and acceptance notes pulled straight from what I’d written. A few minutes later I had a structured backlog instead of a blank repo and a vague intention to “set up the board sometime.”
It wasn’t perfect, and that’s the point. It over-produced in places and missed a dependency or two. But editing a draft backlog is a completely different job than building one from nothing. I spent twenty minutes pruning and reordering instead of an afternoon staring at an empty milestone list.
Once the board is live, one loop looks like this. I ask for a feature, and the agent:
- Reads the relevant issue and checks it against the Definition of Done
- Writes the code and commits with a message referencing the issue
- Deploys to my homelab box and curls the live endpoint to prove it works
- Closes the issue with the commit hash and verification result pasted in, with my permission of course
The record of what shipped is written by the thing that shipped it, while it still has the context in hand. Documentation stops being a chore I do afterward and becomes a byproduct of the work.
That Definition of Done is its own example. This weekend the agent and I turned thirteen messy issues into a single go-live gate: six bands, from data foundation to documented, each checkbox a gate rather than a nice-to-have. It’s not a doc rotting in a wiki; it’s a live issue the agent reads before it builds and checks off only when something clears the bar.
It cuts the other way too: the agent opens work, not just closes it. My soil sensors kept dropping offline. The agent added a live signal-and-battery readout to the app, pulled the data off the gateway, and worked out it wasn’t the batteries; two sensors just had weak radio signal. So it filed a Gitea issue to reposition the gateway out in the yard, with a checklist and an acceptance bar, linked to the “seven clean days of sensor data” gate it was blocking. A hardware chore, discovered from live telemetry, written into the same tracker as the code, dependency made explicit.
That’s the bridge. Planning, execution, and documentation stop being three separate systems with me shuttling between them. They become one loop the agent can walk end to end, because it can touch both the code and the tracker.
What changes when the plan and the code share a brain
The tracker stops being fiction. Closing the issue and shipping the code happen in the same breath, so the board reflects reality. I can open Gitea cold after a week away and trust what it tells me, which, if you’ve ever run a solo project, you know is not the default.
My job moved up, not away. I’m not hand-writing issues. I’m deciding what’s a gate versus a nice-to-have, where the bar for “done” sits, and which discovered work is worth doing. The agent drafts; I edit. And it will cheerfully over-produce if you let it. The MCP gives it hands, not taste. The judgment is still mine.
The most-skipped part got cheap. “Make sure everything is checked and updated in Gitea” is now a real instruction, and it just does it: reconciles the board against what shipped, checks what’s done, flags what’s blocked, cross-links the dependencies. The most boring ritual in solo building became the cheapest.
Last time I joked that I pay a hundred bucks a month for an on-call senior engineer. The update: the engineer also keeps the project plan honest, writes the release notes, updates documentation, and this week filed me a ticket to move an antenna near the potatoes. The bridge runs all the way from a git commit out to the garden fence. That one still makes me grin.
