Apparently “I’ll get those videos out soon” needed a clearer deadline. Preferably one I actually followed. 😂 Sorry these took longer than planned, everyone. The new videos for Foundation lessons 4.1–4.4 are now live! These look quite different from most of my videos. I’m trying a mix of animation, actual app screenshots, highlighted instructions, and worked examples to make the ideas easier to follow—and easier to try yourself. Here’s where to jump in: 👉 4.1: Install and First Use — 5:37 Start here if you’re still getting comfortable working with AI and local files. Grab the Foundation Practice download in Resources so you have something concrete to work with. 👉 4.2: Working With Files — 7:45 Take a few meeting notes and turn them into a decision list you can actually check. Who agreed to what? Where did that deadline come from? What’s still unanswered? 👉 4.3: Think, Then Build — 8:24 For those times when you ask AI for a whole plan before you’ve quite decided what you want. Compare your options, choose an approach, and turn it into a short brief before building. 👉 4.4: Project Instructions — 7:09 Give your AI a useful onboarding note: where to find the context, where the draft should go, and what needs checking. Includes the AGENTS.md / CLAUDE.md connection for people using Codex, Claude Code, or both. You can also follow the exercises with a regular chat tool and save the files yourself. I would love some honest feedback on this style. Does the animation help things click? Are the app screenshots useful? Is anything moving too quickly—or taking too long?

Hey Clief Notes fam! 👋 I'm Amy Johnson and I'm happy to be here. 🙋 A little about me: I am a franchisor of a donut business. I have over 50 franchisees and am working on building AI systems for all of us to make business easier. 🎯 My current goal: Building an AI Franchise Kit Biggest Struggle right networking and finding people who can talk ICM with.

I've spent over a decade building software for clients. Small project teams out at the client, with a big core product team behind us. A lot of you are building without ever having worked inside a software shop, so here's the habit from that decade I'd hand you first: https://youtu.be/CnRM0NccyXs Waiting for perfect requirements is how a project stalls out in analysis paralysis. So we didn't. We got the gist, built something rough, put it in front of the client, and then shut up and watched them use it. One client told us flat out they didn't want the imaging side of our system, the part that stores the scanned documents. Theirs was fine. So I built a rough demo: a form with its scanned document sitting right on it, no jumping into their imaging system to go find it. As soon as they saw it, the whole contract shifted to include it. No requirements meeting was ever going to get that out of them. People can't tell you what they want until they see it. That loop used to cost a team weeks per round. With AI it's an afternoon. Most people in the AI space use that speed to finish faster. I'd rather use it to be wrong faster, while being wrong is still cheap and everything is still running on fake data. The video also walks the part of the map most new builders skip after the loops: putting the pieces together, a full run from start to finish, real data with security on, rehearsing go-live. Going from loop one straight to production makes you the TIP guy: test in production. Don't be the TIP guy. Question for the room: who's your first user? If you're solo and building for yourself, who do you hand the rough version to, and how do you keep yourself quiet while they poke at it? P.S. Show your work bit: the slides were an HTML deck with click-through reveals, and the cut came straight off the Screen Studio click log. 27 clicks, 28 slide states, no timeline scrubbing. More soon on the architect/builder side of this, which is the same fresh-eyes idea run with two agents.

I used the production line by @Ry Mac to make my second YouTube video, and I want to share how it went. I started the gameplan Saturday morning. By the end of the night the video was on YouTube, the blog post was live on my site, and the lesson was in my Skool classroom. That included the recording and the edit. The line has 9 stages, and it will not let you skip one. Gameplan, script, spec, reader, storyboard, a 90 second test render, the full render, the package, and the blog. I wanted to skip the spec at one point. It stopped me, and it was right, because the spec is where the problems showed up before I recorded anything. A few things that stood out for me: The reader is a slide page I record my voice from. One line at a time, with a hold marker when I need to pause. I recorded the whole script in one take and only had to fix one line. Everything is timed to my real voice. It listened to the recording and lined every slide up to the words I actually said. When I said a line a little differently than the script, it changed the caption to match me. It checks its own work. Before it showed me the final video, it went through every cut and found 3 captions that came up a beat late, and a banner in one of my screen recordings that should not have been public. It fixed them before I saw them. The renders run in the cloud. My laptop stayed free, and all of the rendering for the day cost less than a dollar. It is built as a folder system, the same ICM idea we talk about here. Every stage is a file I can open, so I always knew where it was at. Thank you @Ry Mac . The production-line is amazing!!!

Something I read in The Age of AI made me rethink how I use ICM. My natural tendency is to approach ICM through business process orchestration. I define the stages, describe the steps, and try to make the whole workflow explicit. But sometimes I take this too far and turn the stages into strict rules. The result becomes over-engineered, uses more tokens, and often works less naturally with AI. I recently had the opposite experience. We replaced a detailed process with a simple skill that described the essential pattern, and the results were much better. That made something click for me. Maybe stages should act as an interpretable scaffold, rather than a fixed algorithm. They can clarify the purpose, context, constraints, handoffs, and expected outcome, while still allowing the AI to work out the best path. AI may free us from having to define an entire process in advance. But if we specify less, evaluating the outcome becomes even more important. We need to check the quality of the result, capture what we learn, and use that learning to improve the scaffold over time. Does anyone else start with ICM and then gradually slip back into rigid, rule-based process design? How do you decide what needs to be specified and what should be left for the AI to infer?