⏱️ 8 min read
In the previous chapter, AI took the wheel from me during the day. I started defining, following and approving, and the tool did the rest. At night, though, the factory still depended on me: when I went to bed, it stopped.
This chapter is about the first night that did not happen.
The rehearsal
The first attempt was the night before. It was past midnight when I started the first run with two tasks grouped together and went to bed.
The run finished fine, at 1:42 am. After that, the machine stopped, because there was nothing left in the queue. I woke up to two finished tasks and a computer that had been idle for more than six hours.
For the machine to work the whole night, someone had to organize the night beforehand: what runs, in what order, what can run together and what cannot. During the day, that someone was me, between one session and the next. At night, there was nobody.
The first night's roadmap
That someone arrived the next day: the AI Product Owner from chapter 2, still in a much simpler version. And the PO was delivered by the tool itself. The run that built the PO finished at 9:21 pm. Four minutes later, the first stage of the first roadmap it put together started.
There were seven stages. For the ones after midnight, the PO paired tasks that did not touch the same files, so they could run at the same time, in two lanes. The last two stages were different: each one grouped two screen tasks into a single run, because they touched the same places.
Every task was in Automatic mode, the screen ones included: from code to merge, without stopping for me to look.
The night almost did not start. At 10:23 pm, a second copy of the app, opened by mistake, scrambled the roadmap, and it stopped. The AI fixed the file, and at 10:47 pm the roadmap was running again. I told that scare in chapter 1, and it has a chapter of its own: A system AI can read is a system AI can fix (chapter 8).
Hour by hour
At 11:30 pm the third stage started. Shortly after, I sent Claude my last message of the night:
"Cancel the monitor, I'm going to sleep and leaving the PC running."
The monitor was Claude following the runs for me. I cancelled it so I would not spend an AI watching another AI work while I slept. That idea comes back in chapter 5, The most expensive token is the one of an AI waiting.
After that, I did not send a single message until seven in the morning. What happened in between I only saw in the morning, in the logs.
- 11:30 pm. Two runs. One taught Write & Review to enrich a task and save the result back into it. The other built the on-call supervisor. The first took 55 minutes. The second took 80, because the reviewer sent the code back once.
- 12:49 am. The supervisor on every screen, with a chat that knows which screen I am on, and a triage workflow that turns a request into a task, with impact and complexity scores. The triage went through the reviewer three times before it was approved.
- 1:33 am. An index next to the state files, for fast queries, and voice input, transcribed on the computer itself. The index had the night's only conflict: two changes to the same lines. The workflow resolved it on its own, in about a minute, and tested everything again.
- 2:33 am. The first stage with a single run. Roadmap items got titles, badges and a one-click mode switch, and screen changes got their own rules, with a capture of every state and a visual review.
- 3:07 am. The last stage: the approval screen with each run's artifacts and the Run App button, which opens the new version of the app in one click.
- 4:02 am. The last run finished, and the machine stopped.
The logs showed a detail I had not foreseen: each stage only started when the previous one had finished entirely. At 12:25 am, one of the lanes was free and waited 24 minutes for the other. The night moved at the pace of the slowest run in each stage.
What the factory built while I slept
Looking at the list in the morning, one thing caught my attention: everything the factory built that night was for itself. And much of it was exactly what it lacked to work without me:
- the on-call supervisor, to follow the runs I would not be following;
- the triage with impact and complexity scores, the beginning of the PO's triage from chapter 2;
- voice input, the dictation I used to do and that became a feature;
- Run App and the approval screen with the captures, which became the Validated mode.
The tool spent the night building the tools that would let me sleep. Run App, which I use today to approve a screen, was built without me, at three in the morning.
In the morning
The night's result:
- 10 tasks delivered in 8 runs, all of them successful.
- 23 commits and more than 10 thousand lines on main, in four and a half hours.
- No run stopped waiting for me.
- One conflict, resolved by the workflow itself.
- In 3 of the 8 runs, the reviewer sent the work back for fixes before approving it.
What I felt that morning is recorded in a conversation with the AI:
"Thinking about the agile philosophy, it seemed much better to me to go to sleep and wake up to proposals already merged, where I can refine on top of what has already been done."
Instead of imagining a screen before it existed, I had the screen ready to judge. That idea has a chapter of its own: Refine first or react later? (chapter 7).
The morning also showed a risk. The last stage used the screen rules and components created in the stage before. If I did not like the 2:33 am work, the fix would not stay in it alone, because there was already work resting on top. On a night with nobody watching, the cost of getting a screen wrong grows with each stage. The rule that stuck: at night, screens can go on Automatic, but without stacking screens that depend on each other in the same night.
And the morning review has to fit in one hour. Ten deliveries only fit in that time if each one arrives with evidence: captures, logs and the app running in one click. Without that, I would spend the morning reading code.
At 8:47 am, I opened the next stage. The first task of the day was the definitive fix for the 10:23 pm scare: a single copy of the app per working folder.
The numbers for those 24 hours also had a less pretty side. I sent 76 messages, spread over 12 different hours, and 23 of them were at ten at night, fixing the roadmap. After midnight, the factory worked without me. During the day, I was still far from the two hours.
The 4h45 idle
Adding up the 24 hours, from eight in the morning to eight in the morning, the factory had some run going for almost 15 hours. The day before, it had been just over 7.
The number that bothered me most was another one. From 4:02 am to 8:47 am, the machine sat idle for 4 hours and 45 minutes. It did not fail, did not hang and did not wait for an approval. It simply had no more planned work.
That is when I wrote a sentence that became a principle of the project:
"A good developer doesn't sit idle. When the backlog he had runs out, he goes looking for more or asks the PO, and the PO keeps pushing work."
That gap became three tasks:
- Living roadmap: when the last stage ends, the PO is called on its own and adds the next ready tasks. It is the roadmap that refills itself, from chapter 2.
- Computer awake: 24/7 depends on something simple, the PC not going to sleep. A switch keeps it awake while there is work running.
- Night watch: an agent with a few extra permissions at night, to unblock what can be undone and leave to me what is my decision.
The living roadmap was not ready yet the next night. So, with the AI's help, I tacked three small stages onto the end of the roadmap by hand, just so the machine would not stop. It did not stop: about 25 tasks by seven in the morning.
The metric changed too. For a 24/7 factory, the most important question may not be how many tasks it delivers per night, but how many hours of well-defined work are ready when I go to bed. One day, I want to open the backlog and read: "five nights of work ready".
The approval moved to another time
No run stopped to ask for my approval that night. That does not go against the project's rule. The approval did not disappear: it moved to another time. The roadmap I accepted before going to bed already said what could go in without me, in what order and in which mode.
When a task needs me, the night waits. The following night, a task reached a point where the workflow requires my approval and sat for more than two hours, waiting for me to wake up.
The rule is the same as in the previous chapters: automation never crosses a human approval.
The next step
When I added up the time of the stages that night, something did not add up. Testing took longer than developing: about 3h15 against 2h10. And 1h20 of that testing was an agent waiting for a command to finish.
In the next chapter, The bottleneck isn't the code, it's the tests (chapter 4), I tell why writing code stopped being the expensive part of the work, and what I changed so the following nights would not spend the clock waiting.