MyFinCup is 43 sessions of AI-written screens at this point. Different days, different moods, sometimes weeks apart. If you'd told me on session one that the app would still look like one person designed the whole thing by session forty, I'd have assumed that required a human reviewing every screen before it shipped. It didn't. What it actually required was closer to a constitution the AI re-reads before doing anything — and being genuinely strict about what goes in it.

Colors and spacing are the easy 20%

Every color, corner radius, and spacing value in MyFinCup lives in exactly one place, and every screen references it by name instead of typing the raw value. I won't dwell on this part — any AI coding assistant will reuse a named color once you've asked it to, and it prevents the app from slowly drifting into forty slightly different shades of purple.

What it doesn't prevent is the harder problem: two screens can use the exact same purple and still disagree completely on where the back button goes, how a header behaves when you scroll, or what a date picker is supposed to look like. Color consistency is table stakes. Structural consistency is the part that actually makes an app feel like one product.

The harder 80%: rules written as answers, not advice

The thing that actually keeps 40-plus sessions of screens coherent is a section of my project notes I've come to think of as load-bearing — component rules written not as guidelines but as the literal, finished answer, ready to be copied in directly.

Take the back button that appears on every full-screen page in the app: instead of writing "keep the back button style consistent," the notes spell out its exact size, its exact background color, the exact icon and stroke width to use — and then list, by name, every single screen that's supposed to have it. That last part matters as much as the rest: it means I can glance at the list and immediately spot a screen that's missing from it.

The same pattern shows up for the little rounded pill used to step through time periods — the one pictured above, appearing identically on the dashboard, the budget page, and the spending page, built weeks apart by an AI with no memory of the earlier sessions unless I handed it one. Without an exact answer to copy, "keep the period navigator consistent" would have quietly drifted into three different-looking versions of the same control, each reasonable on its own, none matching. With one, a new screen needing that control produces a fourth instance that's pixel-identical to the first three.

If I had to compress the whole lesson: the difference between "a style guide" and "something an AI can actually execute without supervision" is whether the answer can be copied straight into the file. If a rule needs interpreting, you get one interpretation per session.

The other half: writing down what not to rebuild

Design consistency turned out to be the easier problem. The one I didn't see coming is a running list I keep of mistakes that have already cost me a debugging session — written specifically so the same mistake doesn't get made a second time.

The clearest example: I once had the total balance computed as "last month's number, adjusted by this month's activity." It looked correct and it was quietly wrong, for reasons I covered in the last post. I didn't just fix it — I wrote down exactly what the wrong version looked like, why it seemed reasonable, and why it has to stay banned. That's not a style rule, that's a scar, written down on purpose.

Without that list, every new AI session starts from the same reasonable-sounding first draft that caused the bug the first time — because the reasonable-sounding first draft is exactly what caused it. The AI has no memory of the debugging session that taught me not to write it that way, unless the lesson is sitting somewhere it will actually read before writing new code.

What a session actually looks like

Concretely: the AI reads my project notes before touching anything — the tech stack, the design rules, the list of past mistakes — all before I even describe what I want built. I describe the feature or the bug in plain language; I don't write CSS in my prompts, because the consistency rules already answer "what should this look like" for anything that's a variant of something that already exists. And at the end of every session, the notes get updated — not just "what got built," but why, including the wrong turns, so the next session doesn't repeat them.

The uncomfortable part is that this front-loads work that feels unnecessary in the moment — writing three paragraphs about a fixed bug instead of a one-line note to myself. The payoff shows up later, and it compounds: session forty doesn't repeat a mistake from session twelve because I remembered it, and not because the AI "learned" anything that persists on its own — but because the mistake and its fix are sitting in the one file every session is required to start from. Consistency, it turns out, isn't something the AI has. It's a property of what you make it read before it starts.

Next up: a bug that worked flawlessly every single time I tested it, and failed for absolutely everyone else — and why that gap took weeks to even notice.