the expensive part of using Claude for real work isn't the thinking. it's the doing: hours of running commands, waiting on builds, polling jobs, re-reading output. every one of those steps burns tokens, and that's what pushes you onto the pricier plans. so i split it. Claude Code writes the spec and the plan, and checks the result at the end. a local model does the long, mechanical work in between, on my own machine, for free. i've been doing this with Ornith 9B (8-bit, on my own engine). on my last run it merged 75 commits across two repos and got every test passing. the planning and the final check were a small slice of what doing the whole job with Claude would have cost. the catch: a small local model only works if the plan is written for a small model. so i wrote down everything i learned into a file you hand to Claude along with your task: https://git.teamide.dev/David/TeamIDE-methodology/src/branch/main/Model-Best-Practices/Ornith-q8-best-practices.md what's in it: - what the local model is good at: git work, running and polling long jobs, following written rules - what to expect: its work is more reliable than its reports. it doesn't go looking for context on its own. it doesn't know when it's done. it slows down at long context - how to brief it: exact files and line ranges to read, absolute paths, small edits, every rule written down, every step ending in a command with the exact output it should print, stop rules ("if it's already done, say so and stop") - how to run it: one task per fresh session, keep the context small, make the plan file the memory so any session can pick up where the last one stopped - before anything lands: check its claims against git and the logs, never its summary. on my runs that caught every wrong note it wrote how to use it: give Claude Code the file plus your task, and ask it to write a spec and plan in that style for your local model. run the plan locally, then bring the result back to Claude to verify before you merge.

Congratulations to @Curtis Hays ! Curtis is one our OG's and he takes the lead this week! He already has Lifetime VIP, so this time he gets a 30 minute 1-on-1 with Jake. ⏰ The 7-day clock resets. Next Monday someone new takes the top spot. 🎯 How it works: - 📝 Post things worth reading - 💬 Help people in the comments - 🛠️ Share what you're building, what's working, what's breaking - ❤️ Engage with what others are putting out there The leaderboard tracks all of it. 🎁 The prize, depending on where you're at: 🆓 Free member? You get lifetime Premium, free ⭐ Already Premium? We convert your Premium so you stop paying 👑 Already VIP? We convert your VIP so you stop paying 💎 Lifetime VIP? Get a 30 minute 1-on-1 with Jake. Either way, you stop paying.

Hey y’all, I am just a single dad working in the tech field right now. On the side I am trying to build a company at first I was building custom software for like 2 people and at this point. I do not know how to talk to people very well, sell a thing or find the right idea to build. What do you all think? I work like 50+ hours on top of parenting Hahaha. I did use AI to reverse engineer the Microsoft Zune so I could use it on Linux. But for project and income I am lost, I am very into AI , just not sure how to turn it into actual profit.

@Jacek Dziurko asked a great question in the comments on the last post. The kind that deserves more than a one-line reply, because it names an edge case a lot of you are going to hit eventually. 🧺 ➖➖➖ 💬 THE ORIGINAL QUESTION "My question would be about building a resource for lead capture, etc., where we ask members to test it and see flaws etc.? One of my projects is that and no better way to test than to ask a community like this to try it and give feedback? Would this be allowed if that intent is purely laid out at the front?" Good question. Honest framing. And it exposes a real gap in the rule as written: the rule covers links, but it doesn't cover beta testing. So let's close the gap. 🧵 ➖➖➖ 🔍 THE LINE, DEFINED The rule was never about links. It's about what happens when someone clicks. Ask yourself: where does the feedback happen? ✅ If it happens IN THE POST, that's building in public. Perfectly fine. Share the repo. The code. The architecture. Screenshots of the flow. The prompt structure, the offer copy, the landing page as an image instead of a URL. Then ask: "Where are the flaws?" People will genuinely tear it apart for you, and that thread becomes useful to everyone else building something similar. That's a real post. That's mutual value. ❌ If the feedback requires members to CLICK THROUGH to your own funnel, that's a hard no. "Go try it at [link] and tell me what breaks" is not testing. It's traffic acquisition wearing a clipboard. 📋 ➖➖➖ 🧠 WHY THE DISTINCTION ISN'T SUBTLE Here's the part worth spelling out, because Jacek's case makes it obvious: If the tool is a lead capture resource, then sending members to it IS the lead capture. Every person who clicks through is a lead entering your funnel. Declaring the intent up front doesn't change what the tool does when they arrive. Honest framing doesn't alter the plumbing. 🚿 A signup flow that harvests emails works exactly the same whether the person arriving knows they're a test subject or not. The test is the extraction. The community isn't your beta lab, and 53,000+ members aren't your sample size.

I've been meaning to share this with the community because I suspect I'm not the only one who has experienced it. I've been using @Jake Van Clief's ICM framework for some time now. I've invested quite a few hours in building my systems, organising my projects and trying to move away from relying on individual AI conversations. And yet, I keep falling into the same trap. I'll spend hours working with ChatGPT or Claude, developing an idea, refining it and building on previous discussions. Then I'll ask another question, and suddenly the AI focuses on the last part of our conversation, completely missing the bigger picture. What makes this particularly frustrating is that 𝐈 𝐚𝐥𝐫𝐞𝐚𝐝𝐲 𝐤𝐧𝐨𝐰 𝐭𝐡𝐞𝐫𝐞'𝐬 𝐚 𝐛𝐞𝐭𝐭𝐞𝐫 𝐰𝐚𝐲. 𝐈'𝐯𝐞 𝐛𝐞𝐞𝐧 𝐮𝐬𝐢𝐧𝐠 𝐈𝐂𝐌, 𝐛𝐮𝐭 𝐈 𝐬𝐭𝐢𝐥𝐥 𝐟𝐢𝐧𝐝 𝐦𝐲𝐬𝐞𝐥𝐟 𝐬𝐥𝐢𝐩𝐩𝐢𝐧𝐠 𝐛𝐚𝐜𝐤 𝐢𝐧𝐭𝐨 𝐨𝐥𝐝 𝐡𝐚𝐛𝐢𝐭𝐬. I think that's an important distinction. Understanding a system isn't quite the same as consistently applying it. In medicine, we often distinguish between knowing what to do and actually doing it reliably in everyday practice. I'm beginning to realise that working with AI isn't so different. This experience prompted me to write a LinkedIn article about the importance of context, why AI sometimes loses sight of what we're trying to achieve, and how Jake's approach offers a more structured way forward. I've also shared a shorter LinkedIn post to introduce the idea to people who may never have heard of ICM. I wanted to share both here, partly to give something back to a community I've learned so much from, but also to hear what others think. It would be good to help more people discover what Jake is teaching here. LinkedIn article: https://www.linkedin.com/feed/update/urn:li:activity:7516770678604242944/ LinkedIn post: https://www.linkedin.com/pulse/when-ai-loses-bigger-picture-why-context-matters-more-edgar-brincat-sclre/