I still write code by hand. Just not often, and not first.
Most of the time I write the intent down and a loop takes it from there. I open the editor when a change is smaller than the sentence it would take to describe, or when something is broken in a way I want to feel for myself.
What I can’t do by hand is keep three products moving at once. Typing scales with the hours I have, and I don’t have more hours. Getting anywhere near 100x meant designing the system so typing stopped being the main event.
That sounds like a productivity claim. It’s really an architecture claim. The old lifecycle was built around a human doing the typing, and once that stopped being the main event, every stage around it had to be redesigned.
I run three live products across eight repos on my own. Two of them are agents you use by texting them. beside.chat lives as a contact in your Messages app and tells you what’s good around you. predicts.chat trades prediction markets from a text message.
The main monorepo has taken 858 commits since late April, 726 of them in the last 30 days. A good share of those are the loop’s own bookkeeping, so read the number as a shape rather than a score.
Here is the shape.
The old lifecycle was built around slow typing
Plan, design, build, test, ship. Every handoff in that list exists because writing code is slow, and because the person who wants the thing is usually not the person who writes it.
When an agent does most of the typing, the cost doesn’t disappear. It moves. It moves to four places: getting intent out of my head, giving the agent enough context, deciding what done means, and proving it happened with evidence I can look at.
So I redesigned the stages around where the cost actually landed. I think of it as an agent development lifecycle, because it isn’t the old one with autocomplete bolted on.
1. Capture is an input queue
Running several products at once means intent arrives out of order. That’s the normal state of the job, not a failure mode, so I built for it rather than trying to be more disciplined about it.
Every idea goes in as one line of plain text, wherever I already am. The editor, the terminal, a chat window with an agent. No structure, no ticket, no title. Five seconds, then back to the thing I was already doing.
Notes land in one inbox that only I write to. Agents can read a note and mark it processed. They can’t edit what I said. Capture belongs to me, and everything downstream of it is negotiable.
2. Context is the actual work
A one line note is useless on its own. The agent has to know which of eight repos I mean, what already exists, and which decisions were settled months ago and shouldn’t be reopened.
So the context lives in three layers. A knowledge page holds decisions. 414 specs hold the reasoning behind each non trivial change. And 228 small memory files hold one lesson each.
The memory files do the most work per byte. One of them says a green test suite proves nothing after you delete code, because the test that would have caught it got deleted too. Another says a shipped fix is not a verified fix. Each one exists because something broke and I decided not to pay for it twice.
3. The spec is the unit of work
The agent turns a note into a spec. Problem, solution, phases, risks, and how the thing will be verified. Then I take the design apart and put it back together, usually across a few passes.
That’s where my judgement goes now, and it’s the right place for it. A paragraph is cheap to change. A merged branch is not.
Even numbering the specs needed a rule. Two sessions listed the directory in the same minute, got the same next number, and both shipped it. That happened twice in one day. So I wrote a small tool that unions every branch, every worktree and the working tree before it answers.
4. Rules go in code, not in prose
Writing a rule in a document and trusting the agent to follow it does not hold up. I have a measured failure for it: two applications to the same job, seven minutes apart, with contradictory answers, from a system whose rules were all prose.
The rules that matter are executable now. A gate returns an exit code and the run stops. Guards fail closed, so a missing input is a block rather than a pass.
The unattended loops work the same way. My social comment loop cannot post to the same thread twice, because a ledger refuses it, not because an agent remembers. A run that posts nothing is a good run.
5. Autonomous where it’s safe, human where it isn’t
Not everything should run alone. The split I use is simple: humans own only the irreversible.
A production watcher runs every five minutes across five workers and two Mac services. It pulls the errors, dedupes them against what it has seen before, fixes the clear cut low risk ones, and escalates the rest as tasks. It has a circuit breaker so it can’t deploy in a tight loop.
Well scoped work runs the whole way, spec to deploy, with no PR in between. Anything touching money, migrations or someone’s data stops and waits for me.
6. Done means it ran for real
Green gates are necessary and not sufficient. A typecheck cannot tell me a message actually arrived on a phone.
So every change runs end to end before it deploys, not after. Where there’s a surface, that run is visual. An agent drives the real UI in a real browser, screenshots each step, and records the session. I watch the recording rather than read a summary of it. A screenshot is evidence. “Tests passed” is a claim, and the two are not the same thing.
For the messaging products the rule is the same and the surface is a phone, so a feature sits in QA until someone sends a real message to the real bot and reads the real reply. Until that has happened it’s shipped, not done. Keeping those two words apart is most of what stops velocity from turning into damage.
What carries over
If you want to try this across your own projects, three things do most of the work.
One inbox you never let a tool edit, so capture stays honest. One file per lesson, written the day it hurt, because that’s the context an agent can’t infer from your code. And one executable rule in place of each paragraph you keep re-explaining.
None of that needs a new platform. It’s a text file, a ledger and an exit code.
What actually got better
Context switching got cheap. That’s the clearest result.
The cold start cost of picking a project back up was never the code. It was the decisions: what we settled, what we ruled out, and why. That state lives outside my head now, in files an agent can read, so resuming a project is reading a summary instead of rebuilding a model.
What I do all day now is orchestrate, plan and verify. I decide what gets built, set the work running in parallel, and check every result against what I actually asked for. That’s the job I wanted.
The scarce skill isn’t the typing. It’s the architecture, the specs, and knowing exactly where a human has to stay in the loop.