Build video number three is up — and this one exists because of the two before it (and Alex's comments 🤣). Temper is the crew member whose entire job is quality. A topic near and dear to my heart. Some receipts from this build: 106 work orders. Seven staged increments. And — this is the part I'm still slightly smug about — I went to bed at 10pm mid-run and let it keep going, because the evidence said I could. Eleven files were waiting for me in the morning. The system worked *just fine* without me watching and held everything back for my quality checks, which is either the whole thesis or deeply unsettling, and honestly it's both... The voice for this one has been recorded for over a week. I *could* have shipped it sooner, but instead I realised that making videos is apparently a thing I do now for fun, so I took the time to actually build a visual style that's more me for it. And I took notes so I can build the factory and the next one won't take a week. That one's for a future video. Still long. Still detailed records. You might just know how this goes by now. 🤷🏾‍♀️ https://youtu.be/eEtfXYoTzI8 Tell me what you think of the style. Tell me what you think of the build. I can't wait to talk about this one.

Everyone is building at AI speed right now. That is fine for most of the app. It is a terrible place to freestyle authentication. A half-baked login looks "done" in a demo and fails under real users: broken sessions, weak password flows, MFA bolted on late, multi-tenant gaps, cookies that only work on localhost. The model will happily invent a sign-in form. It will not invent a security posture. This is where a tool like https://clerk.com earns its seat. Not because it is magic. Because it stops you inventing the one surface that should never be improvised. Clerk is an excellent Auth skill and for new SaaS, prototypes, and startups where speed-to-market is the metric and the stack is modern frontend. It is a poor tool when at consumer-scale unit economics are the product constraints. This is not "never build auth." It is "do not invent the front door while the rest of the app is still a sketch." The principle: Velocity is only a win if the you don try and speed run the boring bits. //A<3

I can say I disagree…

I’ve been thinking about what happens when an AI agent causes real financial damage. Not a harmless glitch or sloppy wording in an email. I mean an agent sends the wrong quote, invents information that ends up in a client deliverable, exposes customer data, or anything that costs someone actual money. Who is responsible? or I guess the better question is: Who is liable? That matters, of course. But I’m not sure it is the best first question. I think the first question is, What are we doing right now, before something goes wrong, to make sure we are not completely unprepared when it does? Or, since I'm not building for clients yet, the real question is what are YOU doing? Do you plan for this? Do you actually take ownership of the risk? (Legal, IT, operations, the person who built the workflow). I can see AI insurance companies popping up all over the place. 😄 I do not have any of this figured out. I suspect many of us are building faster than we are defining accountability. What are people actually doing in practice? Do you have checkpoints or review processes you trust, or are you still trying to work this out too?

ICM is the best thing I have come across for making AI work legible, and it is genuinely the reason I can build what I build. What I keep running into is that a folder structure is a map, not an engine - past a certain size, something has to drive it. Three things I ended up adding on top: - A logbook - every job writes a record when it finishes, so the system has a history and not just a current state. - A bundler - one command assembles the right files into a single prime, rather than me picking them by hand every session. - A design layer - brainstorming and prompt writing happen in a chat first, and only the finished work order goes to Claude Code. For context, ICM was one of my first real experiences of what you can actually do with AI, and I am still not over it. This is not a criticism of the methodology, it is a question about where it stops being sufficient on its own. Where I hit that was memory and scale. A folder tells a fresh session what exists, but not what happened last week, what already went wrong, or which of five projects it is sat in. The structure holds state and I kept needing history. Without the layer on top, I am the one remembering, assembling and routing, every single session, and that is where all the manual work quietly goes. So the genuine question. If you are running something big, or anything near enterprise, are you telling me it is a folder structure and Claude Code prompts and you see what happens? Or is there an orchestration layer you have quietly built that you do not talk about much? Interested in the limitations people have actually hit with a bare ICM setup, and what you put on top to get past them?