⏱️ 7 min read
In the previous chapter, Git was made for humans (chapter 6), the answer to the conflicts was planning ahead. This chapter is about the other side of that math. Almost everything I learned in software engineering says to invest at the start: refine, prototype, predict where every button goes. With agents working all night, I started to doubt that, and then I tested the doubt until it broke.
The morning of October 1st
The factory's first full night, told in I went to sleep and woke up to the work done (chapter 3), ran with everything in Automatic mode, screens included. In the morning, I wrote to 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."
What I had in front of me wasn't a description of a screen. It was the screen. "That's not it, it's like this" is a short sentence. Describing "what it is" before anything exists takes meetings.
The working increment is the cheapest specification there is.
That math only works because generating got cheap: that night, each delivery cost about three quarters of one made during the day, with me following along. Getting it wrong and redoing it costs less than the hours spent trying to get it right the first time.
Refinement didn't go away. The PO from The day AI took the wheel from me (chapter 2) still only lets a task into the roadmap with 85% clarity or more. What changed was the size: enough to start, not enough to predict everything.
The city experiment
Two weeks later, I wanted to take the idea further: in the middle of the day, with a new screen. It was the 3D city, a map of the code where each file becomes a building and each area of the project, a neighborhood. That afternoon, in a separate session, I had made a proof of concept of the city, the POC: a quick version, outside the system, just to see if the idea looked good. It did, and I approved it.
To bring the city into the app, I wrote:
"The city stage I didn't ask to validate, I asked to develop it straight away. [...] It's faster to ask it to deliver the way the AI thinks best, take the risk that it works and fix it later, at a bit more cost, but without stopping the roadmap. [...] Isn't it better to ask it to do it, wake up and validate what has been done, than to keep refining and thinking about how to do it?"
The agent would decide the details and deliver without stopping at any approval of mine, the engine would merge the code and move on to the next stage, and whatever I found while testing would become a task in the stage after. Before seeing the screen, I already had a hunch: "the city doesn't open full screen, and I'll most likely want that". It's the kind of detail nobody writes in a task and that jumps out at the first click. It was exactly the case for reacting later.
"I should have validated"
The hunch was right, but it was the smallest of the problems. Testing the city and the tab it lives in, I found more than 12:
- White controls: dropdowns and date fields with a white background in a dark app.
- Small checkbox: hard to hit with the mouse.
- Too much text: a screen so crowded it didn't look made for a person to read.
- The city: it looked like a pile of squares, didn't open full screen and flickered with the mouse over it.
I wrote, that night:
"I thought it would be good, but since it involves front-end, it was terrible. A bunch of things wrong, the whole screen crooked. [...] Going through the whole flow to fix it will cost more hours and tokens. It was a terrible decision, I should have validated."
There were 6 fix tasks that same night. The roadmap didn't stop, as the experiment predicted. But every fix would go through the whole flow.
And the number that bothered me most was another one. The factory has an interface reviewer agent, which looks at the screenshots of every delivery. On the same screens, it found zero problems. It checked whether colors and spacing followed the project's variables, not whether the screen looked good; the screenshots used little data, and a screen that only breaks with 50 rows doesn't break in the test; and "approved, no findings" didn't require saying what had been checked. It got a readability checklist and accessibility checks right after, but a reviewer filters the obvious. On a new screen, the one who knows whether it looks good is me.
The POC was the specification
One of the fix tasks asked, in those words, for the app's screen to look like the approved POC, at real scale. In other words, the good result existed before the stage began. The flow treated the POC as inspiration, not as a specification, and the agent reinvented the screen.
The chapter's idea still stood, just somewhere else. The working increment really was the cheapest specification: it was the POC. The mistake was not tying the stage to it. The next night, one run brought the POC's layout and geometry into the app, and another gave the city its full screen.
How much it costs to find the mistake
The experiment showed the question was badly framed. It wasn't "refine first or react later". It was how much it costs to find the mistake, and who finds it.
In the engine, the tests and the workflows, the tests find the mistake on their own, and the fix is a short loop within the same run. There, reacting later wins easily. On a new screen, only I find the mistake, by opening the app, and each fix becomes a new task with tests, review and merging behind it. Interfaces need many short "look and adjust" loops, and the full flow makes each one expensive. In the interface, the judge is me.
The rule that stuck:
- 🤖 A new screen is born in a POC: in a separate session, with me watching, until it's acceptable.
- 🤖 The POC becomes the specification: the task carries the reference screenshot and the POC's code, runs in Validated, and the review compares side by side.
- ⚙️ Automatic keeps the rest: whatever a test can judge.
Never start without a design system
The other half of the damage had an older cause. The app never had a design system, the set of ready-made components and visual rules every screen uses. Each dropdown was written the way the agent of the moment thought best. There were 74, spread across 27 files, plus eight date fields, none styled for the dark theme. A crooked screen wasn't one fix. It was 74.
"This is going to become a lesson: never start a project without a design system, even if it's one from the internet, some well-known one. Now the project is huge, I'll have to go around refactoring, and imagine the AI cost on the front-end to find all the selects in the files and read all of it."
The cost might not even be that high. Finding the 74 places is a job for a text search, not for an AI reading file after file: the agent writes the replacement rule once, tests it on a few files, and code applies the rest. And the AI raised an even cheaper hypothesis: part of the white came from a single line missing from the base stylesheet, the one that tells the browser the app is dark.
A design system is only worth something if someone checks it; a rule that's only written down is exactly what the reviewer approved. Two days after the experiment, the app got a single dropdown component, a date range field with shortcuts, an 18-pixel checkbox and an engine check that flags when a raw control comes back into the screens' code. For a new project, a short list stuck:
- Design system in the first commit: a well-known one, with the dark theme defined and colors and sizes in a single file.
- A check that flags: the screens' code doesn't accept raw controls or hardcoded colors outside that file.
- Accessibility in the screen tests: low contrast and small click targets get caught without AI.
- The rule written for the agents: in the instructions file every agent reads when it starts.
The next step
This chapter ended with new rules in the code. But there was a fix no check foresaw. On the first night, at 10:23 pm, a second copy of the app scrambled the roadmap, and the one who fixed it was the AI itself, reading the app's state files.
In the next chapter, chapter 8, A system AI can read is a system AI can fix, I tell that scare and why keeping the state in files an AI can read became an architecture decision.