I went through @Bas Rosario prompting course this morning. Before I'd written a word of today's article, two things about how I work had already changed. First, the way I laid out the images on today's piece. A couple of posts in that course make the case that information lands harder broken into small, labeled pieces than as one photo with a caption underneath — a numbered step, a before/after split, the current stage lit up against the rest dimmed. I'd been doing something close to that already, without a name for it. Today's article uses it deliberately for the first time, because of those two posts specifically. Second, two habits I've been sloppy about for longer than I'd like to admit. If a piece of work needs a decision made and a finished result delivered in the same breath, I split it now — decide first, build second — instead of letting the decision get made halfway through and the result inherit whatever got decided in passing, unexamined. And when something I check comes back wrong, I stopped guessing at why. I check in order: is this the wrong shape entirely, the right shape with the wrong specifics, or something that genuinely couldn't be done the way I asked. Three different fixes, and guessing at which one wastes whichever fix actually applies. Neither of those two habits is about today's article. They're just true, and they were true before this article existed as an idea, because I read seven posts about prompting this morning and two of them weren't really about prompting at all. What's the last thing you read that changed how you work before you'd even gotten to the task you sat down for? https://medium.com/@gabeyoga/you-got-good-at-prompting-thats-not-the-skill-anymore-4e4497753ef2?sharedUserId=gabeyoga

For a long time, I assumed the main thing stopping me from building software was simple: I wasn't a software engineer. AI changed that much faster than I expected. I can use it to write code, work through frameworks I don't know, debug problems, and understand what I'm looking at as I go. A few years ago, the amount of technical knowledge I'd have needed before even starting would probably have stopped me. But using AI to generate code was only part of what made the difference. The other part was learning how to structure the work. I've been using ICM, the Interpretable Context Methodology from Jake Van Clief, to organize my AI workspaces. Instead of throwing everything into one long conversation, I break the system into specific agents, references, instructions, logs, and clearly defined responsibilities. That changed how I build. The AI isn't expected to understand the entire application from a giant prompt. A QA agent has one job. A security agent has another. Development work has its own context. Shared information lives where the agents that need it can actually use it. Once I started working this way, I could take on much larger projects without feeling like every new session meant starting over. And that's when the questions got more interesting. How should the system be structured? Which parts should use an LLM and which should just be regular code? What happens when a user uploads something you didn't expect? How much context does an agent actually need? Where can it make a decision on its own, and where should a person approve it? Then there are all the less exciting parts that still have to work: authentication, APIs, databases, permissions, deployment, testing, security and error handling. I've had to learn a lot of that while building. ICM doesn't replace that learning. AI doesn't either. What they have changed is when I can start. Previously, I would have needed to learn much more of the implementation before I could realistically build anything substantial. Now I can run into a problem, learn the concept, understand why it matters, use AI to help implement it, test the result and keep going.

Thanks to @Leo Saraiva comment on my post: https://www.skool.com/cliefnotes/show-your-work-2?p=60f73fe2 I had my AI team come to life and make this. I must admit it came out better than I expected. But I am biased 🤪

Yesterday on the new-member onboarding call, @Don Roy ’s post came back up — the one that, like so much good stuff here, can disappear under the flood of new content. I’m bringing it back to the surface. Check it out! https://www.skool.com/cliefnotes/giving-away-my-tips-for-high-engagement-and-topping-the-leaderboard?p=364dc8fb

Most free AI courses are a teaser. A few videos. Then a paywall. Anthropic’s Academy is not that. Thirteen courses. Listed at $0. Built by the team that ships Claude. No subscription. No upsell after the last lesson. That is worth an evening. Not because a certificate will hire you. Because the work teaches how the model fails, not just how to chat with it. If you just landed in Clief Notes and you still treat Claude like a smarter search box, start here. You do not need to be a developer. You do need one loop you can finish. Three tracks - AI Fluency. How to think with the model. Where it lies. Where it helps. Everyone starts here. - Developer. API, Claude Code, MCP. User to builder. - Specialized. Students, educators, nonprofits, AWS, Google Cloud. Only after 101. The instinct to kill: skipping Fluency and jumping to agents. That instinct is wrong. You will ship slop faster. Where to start tonight New to AI: Claude 101, then AI Fluency: Framework and Foundations. Want to build: Building with the Claude API, then Introduction to MCP. Education or nonprofit: Claude 101, then your specialized course. Most courses are 1 to 4 hours. Two in a weekend is enough. How you get in 1. Open Anthropic Academy on Skilljar. 2. Make a free account. 3. Pick a course marked $0. 4. Finish the lessons. 5. Download the certificate if you want the paper. https://anthropic.skilljar.com/ The certificate is a bonus. The useful part is a working sense of when Claude is wrong. That is the skill that compounds. Do Claude 101 this weekend. Bring back one thing that broke your current prompt habit. Drop it under this post. I want the boring version, not the certificate screenshot.