Okay so it's 12am and I'm building Rooty, the app that's literally about helping stylists stop burning themselves out. And I'm sitting here reworking the same landing page for the hundredth time, slowly starting to hate every word of it. So my AI, the thing I'm building this with, tells me to go to bed. Basically: "you don't hate the work, you're just out of gas. Go rest, it'll look fine in the morning." Then my husband walks by and says the exact same thing. 🙃 So to recap: I'm making an app to help you stop grinding yourself into the ground, and it took my laptop and my husband ganging up on me to close it. The irony is noted. Goodnight, for real. 🌱

I think it is best to assume we will all have an AI companion next to us - going forward - for the rest of our lives. For me, once I had that thought clearly and now typed it, the words provide some clarity on a few things. First, start working on what that companion looks like for you. There is great personal context in my phone, and any AI that is balanced the right way will be able to provide great insight and results. But more importantly, start working on what makes you unique as a person - both personally and professionally, and start putting into the right shape. Yes, that is one clear reason we are all here - keeping your work close to you, and not relying too much on the models to track you. Second, I am so curious about education. Testing had no notes as the results of pens, no calculators for decades after calculators appeared. So we will have years to watch education slowly adjust because no AI during tests is their obvious answer. But here is the hard point. If your test can be answered by an AI, you need to be teaching different things. There is more... but for me I just had a breakthrough that helped me focus on the important things going forward. Special thanks to my mom, who told me in the late 1970s, 'It is not like you are going to have a calculator with you every day for the rest of your life.' Fast forward decades later, and yes, I did have a calculator with me my whole life. Thank you HP 11C, and iPhone since 2006.

Last month I was speaking with a friend who works for an engineering firm in Australia about ai, and all the cool things we can do with it these days, and he mentioned that he was trying to push to get a monthly newsletter out to their team to inform them of upcoming professional development courses and workshops. Of course it takes a lot of time to manually search the relevant websites, and put together a newsletter, etc. so no one has done it. I asked a few more questions about the tools they use, and then went and built out a small, structured ICM folder system, with the exact same blueprint that we have been learning in here and using for the competition building. I then made a loom video showing how it worked, and then emailed it to him along with the fully company branded email that it output. It was near the end of financial year at the time, so they were a bit busy, and he said he'd get back to me. Today, 1 month later, he came back and accepted my quote of $600, which includes 2 rounds of revision. To get the draft up and tested, it took me probably about 4 hours, and then there will be another few hrs in finalising it (with the revisions). In reality I probably undersold myself, but this is a side project at the moment (I run a cafe, not an ai consulting business...yet!), and I was excited to have the opportunity at a real client to test against. Let me be clear, I'm not selling a fancy Ai loaded website or app or anything... It is literally 5 folders, with a top level claude.md file, instructing claude co-work (or claude ai or code - or any other Ai tool that can follow structured instructions with a renaming of the claude.md file) on exactly what to do. This is exactly what Jake has been teaching here, and it will stand the test of time. As Anthropic updates their interface, and Open Ai starts to take over claude or another better tool comes along, this ICM folder system will continue to do its thing. It may need some tweaks along the way, but it's not going to need it's whole codebase updated or anything, because it's all plain language, english instructions.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 🎯 PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 💻 Code review editor for a specific language and level (junior TypeScript, senior Python) - 📊 Pitch deck editor for pre-seed founders - 🎨 Grant application editor for arts nonprofits - 📄 Resume editor for career switchers into tech - 📰 Op-ed editor for policy publications - 🎙️ Podcast script editor for interview shows - ⚖️ Legal brief editor for civil litigation - 📋 Product spec editor for early-stage PMs - 🎓 Academic paper editor for one specific field The more specific, the better. "Writing editor" is too broad. "Op-ed editor for tech policy publications targeting a policy audience" is right. 🗂️ THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your editor is a folder with five things: - 📄 identity.md (who the editor is, what work they review) - 📐 rules.md (how they critique) - 💬 examples.md (what good critique looks like) - 📚 reference/ (style guides, checklists, frameworks the editor uses) - 📖 README.md (how to use it) Drop the folder into a Claude project. Claude becomes the editor. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK An editor is NOT a rewriter. An editor doesn't do the work for you. An editor surfaces what's weak and pushes you to fix it. That distinction is the whole assignment this week. When someone hands the editor a draft, the editor shouldn't produce a "fixed" version. The editor should point at the three lines that don't work, explain why, and hand it back to the writer to solve. ✍️ Generic feedback like "consider strengthening your intro" is a fail. Specific feedback like "your intro assumes the reader already knows what a Series A is, but this pub is read by generalists, so lead with the stakes instead of the jargon" is what a real editor does.

📦 AND SOMETHING NEW: EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 WHAT WE DID DIFFERENTLY THIS TIME Every submission was cloned at the exact commit that was public when we read it, and read file by file. The brief. The identity. The rules. The reference layer. The code. Where a repo made a claim we could check, we checked it. Arithmetic recomputed by hand. Sample photos opened and compared against the outputs that cited them. Files diffed. Self-tests traced. Thirty-two repos, read at the code/word level. And one lens over everything, because it's the lens this whole community is built on: does the build keep the human's judgment where it pays and put the deterministic work in code, where it can't hallucinate? 📦 THE FEEDBACK PACKAGE This is the new thing, and it's for everyone not just the podium. 📦 COMP #8: THE WILDCARD - The Vault Every entrant gets a markdown file. Three parts: 1️⃣ The read. What your build actually is, and the strongest thing in it cited to your own files. Rule numbers. Function names. Your own examples. 2️⃣ One push. The single change that most improves your build. Not a list. One. 3️⃣ An idea worth naming something original in YOUR build, credited to you, that the rest of the community is told to take from. Plus links to the builds your feedback points at. Nobody walks out of this comp empty-handed. Thirty-two builds, thirty-two named ideas. The roster alone is worth the download. 📍 The package + the full write-up (what held up, what was missed) live in the new Feedback module: 📦 COMP #8: THE WILDCARD - The Vault 📚 WHAT THE FIELD TAUGHT Three lines split thirty-two repos: ✅ Enforcement. A must in a markdown file is a request. A must in code is a constraint. (That line is from one of your repos. It's in the package. Go find whose.) ✅ Evidence. The builds that shipped receipts of a REAL run transcripts, dated logs, before-and-after fixes read differently every single time.