The Self-Driving Startup

The loop started life reading PostHog’s inbox, because PostHog shipped an inbox. That was never a decision; it was an inheritance. And the first three things worth fixing – the dead ad pipelines, three vulnerable dependencies, the seats – were all invisible to it. Not PostHog’s failure. They were outside its remit, and the loop had no other tray to look in.

So the queue moved to Linear, and PostHog became one source among many. That is the first piece of the shape: many things watch, one place holds the findings, and every finding carries a fingerprint so the same problem seen by two sources becomes one issue instead of two. The last source in the picture is the odd one out. Nothing pushes the money path to us, so one of its six steps – from the link in an ad to the page a buyer sees afterwards – is walked by hand every pass.

People ask why Linear and not a dashboard, or something I built. I think it matters much less than it seems. I just have a strong preference for starting with a tool whose makers already have the cutting-edge vision of what the process will look like, and to me the people behind Linear have exactly that for project management with agents. It is free, or ten dollars a month. I start there and see what it looks like. If I am happy, I stay. If not, I can still build it myself.

What I get for it is every finding as an issue, with the commits that fixed it attached and links back to where it was found. That makes it easy for me to review what has been done – and it gives the agents the same thing. The queue is their working memory. A cloud session that starts with no memory of yesterday reads Linear and knows exactly where the last one stopped.

To be clear about PostHog: they are leading this idea, and the way they think about the inbox and the scouts that go looking in regular places is beautiful. They have the product scope. They do not yet see the whole business, and they cannot see every system. So the inbox slips one layer down and becomes a source rather than the operating system. And I cannot yet afford fifteen dollars a pull request to run their whole cycle the way they imagine it.

When a monitor is persistently quiet, verify the monitor before you believe the quiet.

That rule came from the loop’s worst early week. Six passes in a row found an empty inbox and reported a quiet product. Every pass was individually correct. The conclusion they added up to was wrong, because zero scouts existed and the sources that were on only fire on problems created after they were switched on. The loop had been congratulating itself on a silence it had helped produce. I did not notice at the time. My take now is simple: an empty inbox is not a result, it is a prompt to go and find another source.

For its first sixty passes the loop was one agent doing both jobs: sweep the sources, then fix what it found. It fixed a lot. It also spent two full cloud passes improving its own tooling while the signup button on the hackathon page – a P1, six days before the event, on the page we were paying Meta to send people to – sat untouched for three days.

Not laziness. The pass only read untriaged items, and accepting an issue was the act that removed it from view. The most interesting failure is always the one in front of you, and the sweep always runs first. So on 29 August the loop split into two roles with opposite success conditions.

Two roles, not two agents. Today one session plays each; nothing in the shape stops it being three scouts and two fixers next month, each with a narrower beat, and that is where it goes. What must not change is that a finder never fixes and a finisher never goes looking.

The first fixer pass took that button. The issue blamed the login library; the fixer read around the reported lines and found the real cause: five buttons rendered inert until the page finished loading, so every click in that window did nothing. It also caught a number that had fooled everyone – dead clicks had halved, which read as a fix, and was the ad campaign going off air. Per hundred visitors nothing had moved. The fix was plain HTML links that work before any script runs, a test that failed without it, and the issue went into review with a condition to re-measure rather than a claim of victory.

Two sessions need rules for not colliding. A claim is a comment with an expiry, because a state cannot expire and a lock must: a session that dies mid-fix releases its issue in ninety minutes instead of blocking it forever. And the two run on different clocks.

The fixer used to fire every two hours. By 1 September it was draining the queue three times faster than the scout could fill it, and four passes in a row went on internal tidying – correct, untidy, nobody waiting. So it moved to four hours, and a pass that finds only low-priority work now walks the money path instead of taking a task to justify the run. A loop that always finds something to do eventually finds something that should not have been done.

I will be honest about the cadence: I am not sure I have figured out the right one at all. I am also not sure I want to let the loop set its own. I probably will.

By default, nothing in this system waits for a human to approve a change. The fixer merges its own work into the live code and ships it. That is not the same as no review. Three things send a change to me instead: when the loop is unsure, when the change touches what the product is or does, and when it is risky – money, customer data, anything hard to undo. Those exceptions are written into its instructions, and everything else has to clear five proofs, all five, every time.

The rule came from the first fixer run. It built a perfect fix, left it on a side branch “for merging”, and the defect stayed live while the branch waited. Nobody merges. So: a fix that is not in the live code did not ship, and the bar is the review.

Point four is the one I keep coming back to, because every failure it catches looks like success. A cleanup step logged that it had pruned eighty-four files, and two feet below in the same log the warning count it existed to reduce had not moved. The redirect rule from the first section passed twenty assertions for twelve days; every one of them checked the rule was written, and production was checking whether it was reached. The right line existing and the right line running are different claims, and only one of them is what your customers get.

The bar also settled a question I had on day one: should PostHog’s own agent write the fixes? Each side opened a pull request – a proposed change, packaged so it can be checked before it goes live – and it was a fair fight.

One number tells you whether a bar like this is real or ceremony. The test suite was at 335 when the loop split. Ten days later it was at 719, and every one of the new ones was written to fail before a fix and pass after it. The loop did not get a test suite. It grew one, one proven defect at a time.

The system page says “humans required: 0”, and I want to be precise about what that means, because it is not “no human” and it is not “no review”. It means nothing waits on me. The loop is told when to come to me – unsure, product direction, risky – and an issue that needs me drops below every piece of real work, carries a marker, and gets asked as one question at the end of a pass. Meanwhile the loop keeps going. There are two kinds.

Getting the ask right took a few weeks. Early on I was handed lists of commands, and I wrote back: tell me what is changing and allow me to just tell you to do it. So every ask now carries three things – what changes, in consequences not mechanism; why it needs me, genuinely my hands or genuinely my judgment; and whether I can hand it straight back. Most of the time I can, and the answer is one word.

The other thing I asked for was titles I could read. I triage this queue and I am not a developer, and on 1 September I told the loop plainly that I often could not tell what the issues were about. Since then every issue is titled for the person who notices it – the page, the buyer, what is wrong – and opens with a two-line summary before the detail. The detail stays. It just stopped being the first thing I saw.

And there is a short list the loop may never touch on its own, however obvious a report makes it sound: the wording of anything a person reads, what a button does, prices, removing a feature, and spending money. Those are mine by design, not by accident, and the design is what lets me trust everything else.

What changed for me day to day is where all of this runs. My first loops lived on my laptop, where I have the most power and flexibility. The catch with a normal coding agent is that you still have to poke it. In OpenClaw or Hermes it is completely normal to put everything on a schedule – a heartbeat first, then jobs that run once a week, once a day, once an hour – and to let the agent improve its own job a little every time it does it. I wanted that for these.

Moving them into cloud routines meant giving up some convenience. The simple connections that work when I am at the keyboard cannot sign in when nobody is there, so each system got a token instead. It took about two hours, and since then every process has its own running cloud environment with the right access. I can shut my laptop, install the update that arrives almost daily, and nothing I have scheduled dies. Life got a little more relaxed. None of it is specific to Claude; the same shape runs in Codex or most other coding harnesses you would pick.

For the first week I was, again, trapped in the developer fallacy of only looking at product. Then the scope started expanding. I let the loop observe my campaigns, my landing pages, my conversion funnels and my emails, and I would take it into sales. Because the pieces are the same. Here they are in the order they have to exist.

The ads loop was the first business area to get the treatment, and it is the one I wrote about when it still lived on my laptop. It now runs every morning as a review: every live campaign, four sources reconciled – what Meta says, who actually signed up, what they did on the page, what Stripe actually moved. It never spends and never publishes. Every decision comes to me as a coded question I answer with a letter.

The one difference from product is the test. There is no unit test for an ad; there is only whether the number moved. So re-measurement is not a nice-to-have on the marketing side, it is the verification bar. A campaign fix is not done when it ships. It is done when the cost per result was re-read a few days later and went the right way.

It also taught me that the loop’s judgment is bounded on purpose. In late August I paused the loop’s creative generation. Not because the creatives were bad: seven runs had produced fifteen images into one ad set, Meta concentrated delivery on three, and the honest reason was our inability to properly use them the way the campaigns were set up. Making more of something the structure cannot test is manufacturing, not marketing. The loop still pitches ideas as text every morning. It builds one when I say so.

Two decisions made this a startup loop rather than a product loop with extras. First, one queue for everything, not a loop per area. The best findings keep landing on the seams – a renamed article found in the edge logs, bot traffic that is a product finding and an ads finding at once – and a loop per area cuts exactly those seams. Split the gathering, keep the deciding together. Second, cadence follows how fast the area changes. Spend moves daily; a newsletter does not.

Sales is next, and it is the one I care about most. The daily process I run for it in Claude – who to talk to today, what to say, what happened last time – grew into a real product, which now lives at customermagic.ai. It becomes a sweeper the day it can sign in without my browser. I still send every message myself. That is a decision, not a limitation.

Two more are queued right behind it. The conversion funnels – the landing pages, the journeys behind them and their conversion rates, mostly out of PostHog, where a first watcher for our own offers already runs in dry-run – so a page that stops converting is a finding, not a feeling. And reporting: the weekly numbers I pull by hand today, written and sent without me, which is the point where the loop starts telling me what it did rather than me asking.

These are the processes we have started teaching in the Pirate Forge, one loop at a time, on your own product and your own ad account. And if none of this feels reachable yet, that is fine – the monthly AI Compass session walks one ordinary task from chat to a loop like this, and most people find their own floor somewhere before the end.