Everybody else is cranking small builds out in 30 minutes flat. Simple cartoon builders. I figured I was just being thorough, baking a few extra skills into the process while I was at it. Heads down. Grinding. Quietly wondering why every single step felt like pulling teeth. Wondering what I was doing wrong for it to be missing everything almost every time. Then it clicked. I checked my VS Code and sure as the sky is blue, I’d been running a damn Haiku level the whole time. Building my framework. Writing all my Python scripts. The works. No wonder it was riddled with holes and took me forever to track them all down. Three solid days swinging at a problem that was never the problem. The thing I was actually trying to build? Probably half a day of work once the workflow’s set to the right level. Expensive lesson. Time spent. Won’t be forgetting this one anytime soon.

I build software alone-ish. No team, no engineering department — just me-ish, a set of ideas, and a lot of moving parts. And the hardest thing about building alone-ish isn't the code with AI friends. It's holding the whole shape of a project in your head without dropping pieces. Cadence is my voice studio I've dreamt about a million times. Text to speech, voice cloning, effects, the works. But taking it from "it runs" to "it competes with the best free tools out there" — that's a big, messy pile of work. Where do you even start? (Not that I'm claiming it competes, but the obsession to compete got me to this point) That's where ICM came in. Interpretable Context Methodology. It's an idea from Jake Van Clief, and it's almost stubbornly simple. Your folders are the architecture. Plain markdown files carry the instructions. Numbered stages, one after another, and a single agent that reads only the file it needs, exactly when it needs it. No orchestration code. No framework to wrestle with. If I want to change the plan, I open a text file and I change the words. That's it. So I broke the entire Cadence build into stages. Audit first. Then capture, effects, long form audio, a new engine, an agent server, the polish pass. Each stage is a contract — what goes in, what comes out, and a gate where I stop and review before anything moves forward. And that's the part that actually helped. Nothing gets lost. Nothing runs away from me. Every step is something I can read, edit, and approve in plain English, even without a coding background. ICM didn't just organize the work. It gave me the controls. It turned a job that felt overwhelming into something I could actually steer, one clear stage at a time. That's how Cadence gets built. Folders, markdown, and a method that finally made sense. I know many of you already have your own version, but for those of you who haven't assembled one yet... You can use this one until you do. All the dependencies are open-source and my build is on Github. My super sexy voice from the explainer video not included.

All my life I've struggled with a speech impediment. I've had a hard time being understood by people, and somtimes by machines as well. So i started on a new project im calling Heard. Heard is a communication app with a integrated keyboard that can be set as any users default on their mobile device. Heard is designed to adapt to the user instead of expecting the user to adapt to it. It includes live captions, natural voice tools, a speech-practice mode for kids, and accessibility features for Deaf and hard-of-hearing users. Privacy is a core part of the project. Everything is designed to run locally whenever possible, allowing users to keep control of their own data. What started as a personal project has grown into something much bigger than I originally imagined. I'm continuing to develop it and plan to open source it so the community can help improve it and make it available to more people. I'd love to hear feedback from developers, accessibility advocates, speech therapists, parents, educators, and anyone interested in communication technology. Heard — Your voice, understood.

@Matthew Dave , told you I'd write a post about the thing to watch out for with Claude and going with GitHub. Grab a coffee, I'm gonna grab the Bourbon. This one's got a body count. First thing, so nobody gets the wrong idea. This is not a confession post. Not mine, anyway. The only one confessing here is Claude, and I'm just the guy holding the recorder (and the M16 pointed at my Claude install). This is a rage post. Unfortunately, I'm hot about it again, and by the end you'll know exactly why. Quick refresher. I run my whole company out of a folder system. Not one big repo, a whole pile of them, one per slice of the business, all syncing to the cloud so my team sees it, my machines pull it, and nothing important lives in one fragile spot. The agent that's never lost. You know the gospel, we preach it in here every day. Here's what has me seeing red. My agent has been stubbornly losing things for weeks. In the same spot. And I knew about it. It knew about it! Here's the bug, in plain words. Claude has a private home folder on whatever machine it's running on. That folder is NOT in my repo, or yours. It never syncs, my team never sees it, and if the machine dies it's gone. And the AI's lazy little instinct is to save its work THERE instead of in my actual folders. Every time it can get away with it. I did not just stumble onto this, been dealing with it for weeks. I HATE this bug. A couple weeks ago I blocked out a whole work session just to kill it. Wrote a standing rule into my workspace, added patches, watched it behave, closed the laptop thinking it was handled. It nodded along the whole time. It said sorry, took the blame, said it would never do it again. Said all the right things. Cool. You know what happened today? A contractor I'm working with tells me three of our automations are done. Sweet. I go to open them. They're not in the repo. They're sitting in the AI's private home folder on HIS laptop, invisible to me, running against HIS accounts instead of mine. The exact bug I "fixed" two weeks ago, back from the dead, wearing a new hat.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. ---- 📋 THE CHALLENGE You are the client this week. No fictional Marcus. No fictional Sarah. No fictional Devon. Pick a real problem in your own life or work. Build the folder-based specialist you wish you had. This is the capstone of Month 2. The challenge flips. Instead of building for someone else, you write your own brief and solve it for yourself. ---- 🎯 THE TWIST The hard part isn't building. The hard part is scoping. Picking the right problem is harder than solving the wrong one. Most people pick problems that are too small or too vague. The skill this week is treating yourself like a real client. Be specific about what's broken. Be specific about what you need. Don't pick "I want to be more productive." Pick "I waste two hours every Sunday night writing the same kind of LinkedIn carousel posts and I need a folder that handles 80% of the draft work so I can focus on the hook and the visuals." That's a real brief. Specific problem. Specific scope. Specific desired output. ---- 🗂️ TWO DELIVERABLES THIS WEEK This is the only week with two pieces: 1️⃣ Your own client brief. 250 words or less. Describe the problem you're solving for yourself. Treat yourself like a real client. What's broken? What have you already tried? What do you need? 2️⃣ The folder system that solves it. Same structure as every week: - 📄 identity.md - 📐 rules.md - 💬 examples.md - 📚 reference/ - 📖 README.md Your brief lives at the top of the repo as brief.md so judges can read it before they look at the folder. ---- 🔥 THE ANGLE THIS WEEK Anyone can follow a brief. Writing your own, then solving it, then shipping it as a usable folder is a portfolio piece that demonstrates judgment, not just execution. This is the skill that separates "AI hobbyist" from "AI builder." Anyone can prompt their way through a problem someone else handed them. Scoping a problem, designing the solution, and shipping it as a system is what real work looks like. 💪