He wrote code by hand for 16 years. Then he let agents write it.
Mac Anderson spent 16 years writing software by hand. In 2026 he made a decision: agents would write all of the code he shipped. His job would be to direct them, read their work, and decide what merged. Some of it went well. A lot of it went wrong. The hardest part turned out to be managing the agents, and he built Oxagen to do that job. This page follows those seven months from the record he left: his GitHub history, his git history, and the 8,133 prompts he typed to Claude Code.
The chapters come first, then the charts. The counts are at the end, with how each one was counted.
How the seven months went
Each chapter comes from reading the prompts in order. The quotes are his, trimmed, with the swearing taken out.
The calendar
Each square is one day. Each column is one week, with Monday at the top. The colour shows which area of work led that day’s prompts. The brightness shows how many GitHub contributions he made that day. A pale cell is a quiet day, and a bright cell is a busy one.
The prompt log covers 81 days. Shipping work led on 50 of them: CI checks, pipelines, deploys, and the machines that run them. Building the agent led on 19 days, proving it works on 7, and selling it on 5. So when he ran many agents at once, most of his summer went into the systems around the agents, not into the agent itself.
The grey cells are the first four months, before the prompt log started. Their brightness still shows his GitHub contributions, but they have no area colour. What the prompt log covers.
What the prompt log covers
The 8,133 prompts come from one laptop, set up on 29 June 2026. They cover 81 days of the seven months on this page. He also used Claude on other machines, before that laptop and at the same time. Those conversations are not in this log, and there is no way to rebuild them.
So the prompt figures are a sample, not a full count. Every number drawn from them describes those 81 days only. That includes the topics, the calendar colours, the hours, the happy words, and the swear words. Each one is a minimum. The real totals are higher, but nobody can say by how much, so this page does not guess.
The GitHub and git numbers are different. They come from his GitHub account and from 13 local clones. They cover the full dates given for each, and they are complete for what they count.
Good days and bad days
Each bar counts words in his prompts on one day. Happy words go above the line, and swear words go below it. Both count words, so they share one scale. The happy words fall across the July launch weeks. Almost all of the swearing falls in August. That month he was trying to prove that Stella’s work was done when Stella said it was.
What he was building when it went well
- 12 julStella's first week in public. The README brief asked for a project that would
inspire a community that is sick of token waste.
- 19 julA fleet design with no coordinator, where every agent works in one worktree.
BUILD THIS DESIGN I LOVE THIS.
- 31 julWatching the first Terminal-Bench run he trusted reach 58 of 89.
I would have worked hard for a reason.
- 2 augA git-backed journal that can resume any turn.
an amazingly elegant answer to the durability problem.
- 13 augCutting 72 tools down to five.
less is more and way less is best.
- 11 sepStarting Oxagen over from a new spec, with 12 mockups built side by side.
We need to be perfect here.
What he was building when he swore at Claude
- 31 julA “fair” benchmark that had a hidden budget cap.
Dont lie.
- 4 augA Files tab that showed no reads and no writes, and a verifier that never wrote its test.
I WILL NOT TOLERATE WIERDNESS IN THE CRUD SYSTEMS
- 8 augA full day of benchmark runs he could not trust. The code graph was empty, with no error, because init never ran.
NEVER RUN A BENCHMARK WITH A BUDGET CAP
- 11 augCorrect work was thrown away at the sandbox boundary. So a pipeline mode scored below the plain loop.
- 22 augA redesign reported as finished that did not match the drawings.
Burning tokens for what?
Each time, an agent said something was done, and it was not. Stella's regression tests, and later Oxagen's record, were built to answer that problem.
Topics per 100 prompts
Each prompt gets one topic, picked by keyword. Prompts about design have the most happy words. Prompts about verification and model providers have the most swear words. The two columns use separate scales.
The 1 a.m. hour
Each spoke is one hour of the day. A longer spoke means more prompts in that hour. Dots mark swear words, and a bigger dot means more of them.
He sends prompts in every hour except the early morning. The busiest hour is 1 p.m., with 638 prompts. The hours from midnight to 5 a.m. hold 919 prompts, which is 11 percent of the total. They also hold 53 of the 124 swear words, which is 43 percent. The 1 a.m. hour alone holds 32 swear words.
Wednesday is his busiest day of the week, with 1,363 prompts. Monday is his quietest, with 973. He sends more prompts on Sundays than on Mondays.
Oxagen and Stella took turns
This chart shows weekly commits in the two main repositories. Oxagen started first, on 28 May. In the week of 6 July it had 1,421 commits. Then, through August, Oxagen got few commits and most of the work went to Stella. He decided that Stella would be the engine inside Oxagen, and he rebuilt Oxagen around it. In the week of 14 September, Oxagen had 3,501 commits.
What he built
Each tile is one part his agents built from his plans in these seven months. Select a tile to see the day it started in the calendar.
Learning to manage a fleet
With one agent, you give it a task, watch it work, and read the diff. With many agents at once, the job changes, and this page is about that job. It was the hardest thing he learned in seven months, and none of it was about prompting.
He started with one agent on one branch, and he watched it work. That setup works, but it cannot grow, because he can only watch one thing at a time. So he added more agents. In the setup he ended with, six or more agents work in parallel, each in its own git worktree. Background agents are on, so work continues while he reads something else.
More agents caused problems he had not expected. Two agents edited the same branch. A branch merged into main with no conflicts, but it still did not work with code that had merged beside it. He had to repair a broken main three separate times before he understood the cause. A merge with no conflicts says nothing about whether the code works. Agents also finished, reported success, and left their work uncommitted. These problems happened between agents, not inside any one agent.
What running many agents needed
- A separate worktree for each agent, so two agents cannot edit the same files.
- A written definition of done. Without one, an agent decides for itself what finished means.
- Checks that run without him. There are 21 of them, so he does not have to review every agent’s work by hand.
- A trial merge before the real one, because a merge with no conflicts can still break the code.
What he still could not answer
- What each agent did, in order, and what it read.
- What that cost, and which piece of work it paid for.
- Who allowed each action, and under which rule.
- Which agent is stuck right now, and on what.
He could build the first list himself. The second list is a management problem, and it got worse with every agent he added. He built Oxagen to answer it.
The code his agents wrote
The number of lines does not show whether code an agent wrote works. So here is what the repository holds, counted from tracked files on 21 September 2026.
A human reviewer notices when a file imports across a boundary it should not. Many agents working in parallel do not notice. Each may break the same rule in a different place on the same afternoon. A test that fails the build checks every change, however many agents make them. So with many agents, the architecture tests matter most.
The audit
In September he had the operator console checked against its own specification. The reviewer was told to look hard for problems and to assume the work was incomplete. The review returned 14 findings. Two of them must be fixed before a release. Its summary said:
The app has substantial working foundations, but it does not yet close the core operator workflows.
The audit is published, with every finding, its acceptance criteria, and the repository it checked. The audit sits in a different repository from the code. So nobody can quietly edit the findings to match what shipped.
This audit shows how the work is checked. It does not show that the work is finished. The work must still clear the two release blockers the audit named.
Oxagen was built using Oxagen
This claim can sound like marketing, so here is how it works.
The agent's base URL points at 127.0.0.1:51781. That address is Oxagen's own gateway, running on his laptop. So every model call made from this repository goes through the gateway, and there is no other path. Oxagen sees each call, measures its cost, and records it. So Oxagen governed and priced the runs that built Oxagen.
Tool calls work the same way. A hook checks each tool call and can refuse it before it runs. Without a rule, every agent would start its own full test build. So this repository has a hook that denies an agent a full test build. This is Oxagen's main idea: the agent asks, and a rule answers. Here it applies to the agents writing Oxagen.
The prompts that wrote this page went through the same gateway. The prompt log this page uses is the record the gateway kept.
Scope: this is the local gateway and its record, which is what a single operator runs. It uses the same code as the hosted control plane. It is not a separate demo build. But one laptop is not a deployment, and this page does not claim it is.
The rules he wrote down
Most of these started as a frustrated prompt. Later each one became a line in a CLAUDE.md file, a check in CI, or a design rule for both products.
Why Oxagen
The agents could write the code. The hard part was knowing what each agent did, what it cost, and who allowed it.
Oxagen is workforce management for autonomous agents. You give each agent its own identity. You set its authority, budget, tools, and skills in one mandate. For actions routed through Oxagen, the agent asks, a rule your team wrote answers, and Oxagen records the answer with its cost.
Oxagen shows you every governed action, the rule that answered it, the person who approved it, and which agent spent what, on whose behalf.
This page was written from the same kind of record that Oxagen keeps.
The counts
He did not type this code. Agents wrote it. He directed them, read their work, and merged it. These are the totals the record shows.
His agents added 3,906,359 source lines and removed 1,529,699. That counts source files on default branches only, and leaves out lock files, build output, fixtures, and generated code. Most of the removed lines were code added a week earlier and then taken out.
Read these counts with three facts beside them. The repositories are four months old, with no release schedule, no on-call rotation, and no other engineers. When he opened and merged a pull request himself, no second person reviewed it. The prompt count is the least complete number here, because it covers 81 days on one laptop. What the prompt log covers.
Mac Anderson, founder of Oxagen
He built Stella, the open source coding agent where this work started. Then he built Oxagen, the agent control plane that came from it. Stella is AGPL licensed and free to run. You use Oxagen when a team, not just you, is responsible for the agents.