⏱️ 7 min read
In the previous chapter, Refine first or react later? (chapter 7), the factory ended up with new rules in the code. This chapter is about a fix no rule foresaw, and that came before all of them: on the first night, at 10:23 pm.
I've already told that scare in a few lines in 6x1? Here it's 24/7 (chapter 1) and in I went to sleep and woke up to the work done (chapter 3). Here I tell the full 24 minutes, and why a decision I had made without giving it much thought became an architecture decision: keeping all of the app's state in files that a person, or an AI, can read.
A decision made almost by accident
From the start, the app has had no database. Everything it knows lives in text files in a work folder: the backlog, the roadmap and every run, with a log of what happened step by step. That log only gets new lines at the end. It never deletes or rewrites anything.
I didn't choose this with AI in mind. It was just the fastest way to start. That night, I found out about an effect I hadn't planned.
10:23 pm: two copies, one roadmap
The first stage of the PO's first roadmap had started at 9:25 pm. At 10:23 pm, I opened a second copy of the app by mistake, and it pointed to the same work folder.
The new copy scrambled what was running:
- It marked as interrupted runs that were alive in the other copy.
- It created three duplicates, to redo the work it thought was lost.
- It paused the roadmap, pointing to cancelled runs.
At the peak, the dashboard showed six runs at once, counting the duplicates. The factory's first full night was stopped before it began.
"Can't you fix it for me?"
I spent a good while trying to understand what had happened, until I asked the question I should have asked first:
"Can't you fix it for me?"
I'll use the legend from The bottleneck isn't the code, it's the tests (chapter 4): ⚙️ the engine is the orchestrator, a regular program, with no AI; 🤖 the agent is an AI doing the work. That fix was all the agent's, Claude, in the session where I was talking to it, outside the app:
- 🤖 Read before touching: it read the code that writes the roadmap and confirmed that the app rereads the file on every operation. A change to the file would take effect right away, without closing anything.
- 🤖 Backup: it copied the roadmap file before touching it.
- 🤖 Re-point and release: it cancelled the three duplicates, pointed each item to the real run, resumed the two that had been marked as interrupted and lifted the pause.
In two minutes, the roadmap was running again, with no work lost. At 10:47 pm, the night was back on its feet. That same night, I wrote in the project's diary:
"Having the files local lets me have an AI that fixes problems in real time. [...] I fixed it through AI, it's like having superpowers."
What if it were a database?
The problem would be the same: two copies writing to the same place. The fix wouldn't. The AI would have to figure out how the database is organized, get access to it and write a migration or a script to correct the records. All of that with the roadmap stopped, at ten at night.
A database is made for a program to read and write. A text file is made for anyone to read, and today that anyone includes an AI. It read the roadmap the way I would, only in seconds.
A system AI can read is a system AI can fix.
The flaw and the superpower
Chapter 1 had already warned: the flaw and the superpower have the same origin. A database has locks: when one program writes, the other waits. A file doesn't. The same openness that let the AI fix the state let the second copy break it. And the fix only happened because I was awake. At three in the morning, I would have woken up to a lost night.
For the superpower to be safe, three locks were missing. The first stage of the next day, which I started at 8:47 am, was about them, and by 9:11 am all three were in the code:
- ⚙️ One writer at a time: only one copy of the app opens each work folder. Each run knows which copy owns it, and the roadmap only touches a run that is actually dead.
- ⚙️ All or nothing writes: the state file is never left half written. Either the new version goes in whole, or the old one stays.
- ⚙️ State taken from the events: the status of each roadmap item is now calculated from the runs' log, the one that only gets new lines. If the roadmap goes wrong again, fixing it means recalculating.
That night's fix was an agent's job, because nobody knew what had gone wrong and it took judgment. The locks are an engine's job, because now we know, and what is already known doesn't need an AI to do it every time.
AI first
Two days later, on the night of October 2, watching the factory run, I wrote:
"I think I understood what building AI first applications means. Since everything is integrated with the AI (the file system and the permissions), I can go to sleep, and Claude can carry on the development flow and also the running of the app. This is incredible."
The AI doesn't just write the app's code. It also runs it: it reads the roadmap, understands where each run stands and, when something gets stuck, changes the state.
I asked whether anyone had written about this. They had. The name that caught on out there is agent-native: an app designed to be operated by AI agents, not only by people. Claude found a small group of texts from 2025 and 2026, and they agree on the essentials:
- Readable state: the agent needs to read what the system knows, in files or in an event log.
- The same actions: everything the screen does, the agent can do too.
- Permission in proportion to risk: the agent does on its own what can be undone and asks for permission for the rest.
The texts that talk most to the factory:
- Every, in Dan Shipper's guide: files are the universal interface, and the agent does everything the screen does.
- HumanLayer, in 12-Factor Agents: the event log is the single source of truth, and the rest is a view calculated from it. That's the third lock, which I learned the hard way.
- Builder.io: it also puts people and agents operating the same product, but coordinates everything in a database.
- Ink & Switch, with local-first, from 2019: the data is yours, in files on your computer. My decision not to have a database is, at heart, that. I would just add one ideal to their list: being operable by an AI.
What I didn't find in any of these texts was both things together: the same AI developing the app at night and fixing its state when it gets stuck.
The price of files
Readable files don't come free. A few days after the scare, I wrote:
"There's also the other side of the decision not to have a database. The number of files is growing, and some screens are getting heavy."
On the night of the scare, the work folder already had about 4.4 GB, with 67 runs. Almost 4 GB were the project's isolated copies, each with its own copy of the app's libraries. And the screens got slow because, to build a list, the app read the log of many runs. The ways out don't give up the files:
- An index on the side: a small table, generated from the files, only for the screens' queries. It went in on the first night itself, at 1:33 am. If it breaks, you just generate it again.
- Pagination: the screens already load one piece of the list at a time.
- Archive: the next step, moving old records to storage off the computer.
The cost that weighs most isn't disk. A state the AI reads can also be manipulated by malicious text: an instruction hidden in a task or in a run's output. The more autonomy the AI has at night, the more that matters. That's why chapter 3's night watch treats what it reads as information, never as an order, and only does on its own what can be undone. Answering an approval is still only up to me.
The next step
That night's fix was made by Claude from outside the app, at my request. The natural next step was for the app itself to do it from the inside, without me asking. A few days later, it was going further: reading its own logs, finding its own bugs and writing the code that fixes them.
In the next chapter, chapter 9, The ship of Theseus: when software rewrites itself, I tell what happens when the tool starts replacing its own parts, one by one, and the question it made me ask: is it still the same software, and what's left for me?
References
- Agent-native Architectures, Every, Dan Shipper
- Agent-Native: The Next Architecture for Software, Builder.io, Vishwas Gopinath
- 12-Factor Agents, HumanLayer, Dex Horthy
- Effective harnesses for long-running agents, Anthropic
- Effective context engineering for AI agents, Anthropic
- Ralph Wiggum loop, on Geoffrey Huntley's idea
- Software 3.0, Andrej Karpathy
- Local-first software, Ink & Switch, Kleppmann and others