# Refine first or react later? · Factory diary URL: https://www.edugalbs.com/fabrica-24x7/en/chapters/refine-first-or-react-later > When generating gets cheap, a working increment becomes the cheapest specification there is. Chapter 07 · October 28, 2026 ## Refine first or react later? When generating gets cheap, a working increment becomes the cheapest specification there is. ⏱️ 7 min read **TL;DR** When generating gets cheap, reacting to a finished delivery is often worth more than refining everything up front. I tested that idea with a new screen in Automatic mode, and it went wrong: more than 12 problems and an interface reviewer that found none. The right question isn't refine or react. It's how much it costs to find the mistake. For screens, the answer was a proof of concept as the specification and a design system from day one. In the previous chapter, [**Git was made for humans**](https://www.edugalbs.com/fabrica-24x7/en/chapters/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**](https://www.edugalbs.com/fabrica-24x7/en/chapters/woke-up-to-finished-work) (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**](https://www.edugalbs.com/fabrica-24x7/en/chapters/ai-took-the-wheel) (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. ![Table with the two ways of working a roadmap item. Refine first, in Validated, where I approve before moving on: the roadmap waits for me to look, a question about a screen becomes a pause, less rework and more time stopped, good when a mistake is expensive, such as data, money and security. Deliver and fix later, in Automatic, where the agent decides and delivers: the roadmap keeps going 24/7, I react to what exists, some rework and almost no time stopped, good when a mistake is cheap and visible, such as screens, layout and text. The table was made before the city experiment](https://www.edugalbs.com/fabrica-24x7/media/capitulo-07-dois-jeitos.png) ### "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. ![Who finds the mistake, in two flows. In the engine, tests and workflows: the agent develops, the engine runs the tests, which find the mistake, and the work goes back to the agent in a short loop, within the same run, before the engine merges the code. On a new screen: the agent develops, the tests pass, the screen reviewer agent approves with no findings, the engine merges the code, and only then do I open the app and find the mistake; each fix becomes a new task and goes through the whole flow again. Engine in teal, agent in orange, me with a white outline](https://www.edugalbs.com/fabrica-24x7/media/capitulo-07-quem-descobre.png) 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. ![Three ways to replace the 74 dropdowns, spread across 27 screen files, drawn as 27 squares. A: the agent reads and edits everything, the 27 squares filled in orange, reading the 27 files and writing the 74 replacements one by one. B: the agent writes the replacement rule, with 4 orange squares, the examples it reads, and 23 dashed in teal, changed by the rule without the agent reading them; the odd cases go back to the agent. C, marked as a hypothesis: one line in the base stylesheet, which tells the browser the app is dark, and no screen file changes. The order goes from cheapest to most expensive: first the line, then check in the app, and only then the rule for what's left](https://www.edugalbs.com/fabrica-24x7/media/capitulo-07-tres-caminhos.png) 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**](https://www.edugalbs.com/fabrica-24x7/en/chapters/a-system-ai-can-read), I tell that scare and why keeping the state in files an AI can read became an architecture decision. [Next chapter**A system AI can read is a system AI can fix**All the state in readable files: when two copies of the app scrambled the roadmap, the AI read it, understood it and fixed it in two minutes.](https://www.edugalbs.com/fabrica-24x7/en/chapters/a-system-ai-can-read) [← All chapters](https://www.edugalbs.com/fabrica-24x7/en) Newsletter ### Get the next chapters. One email when a new chapter is out. No spam, unsubscribe anytime.