For those who missed the first post or just joined: The Lyceum is a 12-week program we're building. Live instruction from Jake and the Eduba team. Small cohorts. Real projects. You build something from week one, not watch tutorials. At the end, a competition with real prizes. Eduba's first certification, backed by the same methodology we've used to train Fortune 500 teams. Now here's what we've locked in since then. The Structure Three 4-week sprints with a 1-week break between each. Not 12 straight weeks of grind. You build, you breathe, you come back sharper. - Sprint 1: Foundation — Core methodology. Everyone starts here. - Sprint 2: Application — You're building. Real project, real progress. - Sprint 3: Capstone — Finish what you started. Demo day prep. The breaks aren't fluff. They're built in so you can catch up, refine, or just live your life without falling behind. The Cohorts Same curriculum across all three. The difference is where your hours go. Technical — Developers, engineers, technical founders. You're building a tool or production system. 30% of your time goes to Claude Code and integrations. Another 30% to production systems and capstone. This is the builder track. Business — Ops, managers, founders, consultants. You're automating a process or designing a system spec. Heavy emphasis on workflow design (30%) and decision frameworks (25%). You direct the work without writing the code. Creator — Marketers, educators, solo operators. You're building a content production system. One person replaces the team. 25% on content pipelines, 20% on workflow design. This is how you scale yourself. Pick the track that matches how you work. The methodology transfers no matter which one you choose. A 4th Cohort? We're considering adding a team cohort if there's enough interest. This would be for companies that want to enroll multiple employees, or for people in the community who want to form their own team and build together. If that sounds like you, let us know in the comments.

What ICM, 60-30-10, and a lot of GitHub stalking taught me. Six weeks ago, I was using Claude to produce daily content artifacts — Instagram squares, captions, blog posts. A publishing operation with a workflow that mostly held together. Today, four public ICM-structured AI repositories live under github.com/NFTYoginis. Three more shipping this week. Each one is a fork-able starter that demonstrates a working architecture: orchestrator dispatches, workers build, briefs serve as contracts, memory persists across sessions. The path between those two states isn't "I learned to code." It's a six-week stretch of reading public repositories, trying patterns, deleting most of them, and slowly understanding what ICM (Internal Coherence Maximization, from Jake Van Clief) actually means when you stop treating it as theory. This is the tour: where I started, what changed, what I built, and where you can fork it. Where I started Six weeks ago, my Claude workflow looked like this: - One Claude session per task. Each session loaded brand-voice files, content samples, and whatever else seemed relevant. Context bloated by lunch. - I'd ask Claude to do something. It would produce something close. I'd correct it. Repeat. - "Memory" was telling Claude "remember our convention is X" at session start, which it forgot the next session. - The token bill kept growing without the output growing proportionally. That setup works at small scale. It collapses under any real production load. The collapse moment, when it came, was specific. I caught one of my daily routines burning roughly 800,000 tokens — for a routine that needed to do one thing: write three dispatch briefs and hand them off. The actual creative work happened in the workers being dispatched. The orchestrator was just routing. Eight hundred thousand tokens for routing. That was the first time I read about ICM. What ICM actually says (the part that mattered) Most "AI architecture" content I'd been reading was either too high-level to act on, or too tied to a specific framework I'd have to adopt wholesale.