I’ve done a master’s thesis before: genetic algorithms, XGBoost, Monte Carlo simulations, graph optimization. Lots of ML, long before modern AI could meaningfully help me. Back then, the hard part wasn’t having ideas. It was turning those ideas into structured experiments, reliable evidence, useful visualizations and clear conclusions, without losing weeks to setup, documentation and context switching. ICM changed the game. In one week, I’ve done more research than I managed in six months of my master’s thesis. The difference is not just speed. It’s the number of ideas I can now explore, test and refine: - Turn a vague idea into a concrete research question. - Convert that question into an experiment or proof obligation. - Generate the code, tests and evaluation structure. - Produce visualizations and evidence automatically. - Inspect the results and use them to guide the next idea. - Keep the reasoning, context and decisions connected throughout. - Do all of the above concurrently. The ICM becomes a research operating system. It helps separate what the code proves, what the experiment observes, what the data supports and what still requires human interpretation. That distinction matters. A test can show that the implementation works. It cannot prove that the model is useful. A result can show that one approach performed better. It cannot automatically explain why. A paper can inspire an architecture. It cannot validate that architecture on your dataset. ICM gives each of these things a place—and connects them into a traceable research loop: question → hypothesis → experiment → evidence → interpretation → next question The most powerful part is that ICM does not replace the researcher. It amplifies the researcher’s ability to think. The human provides judgment, curiosity and scientific direction. The ICM provides structure, memory, continuity and execution. That is why it feels so transformative for ML research. It turns research from a sequence of disconnected tasks into a living system that can continuously generate, test and refine knowledge.

I don't want a progress percentage today. I want to know what's actually changing. If you've been working through Building Your Stack, what is one decision you've made because of it? - Maybe you added something. - Maybe you removed something. - Maybe you realized part of your current stack makes absolutely no sense. 😂 Whatever it is, post it below. What did Building Your Stack make you rethink? And if you've been flying through the lessons but skipping the quizzes or accountability posts... Go back. Those are there to make sure you can actually explain and apply what you're learning rather than just consuming it. Drop your biggest realization below. 👇 And keep going. New roadmap next Friday, September 25th.

Subject: Am I misunderstanding "build inside your workspace"? I'm working through "Building Your Stack" and stuck on something Jake says in lesson 1.1: "Build inside your workspace. Don't create a separate folder. Build where your context already lives." Right now, every time I start a new project, I create a new folder and ask Claude to use the ICM architecture to design it. But based on this lesson, it sounds like I might be doing something wrong. My current approach: - New project = new folder - Each folder gets its own CLAUDE.md and structure - I reference ICM architecture in the setup What I think Jake is saying (but not sure): - Build tools and projects inside an existing workspace that already has context - Don't spin up a new isolated folder every time Questions: 1. Is there a "main workspace" I should be building everything inside of? 2. Should custom tools live alongside my regular AI work files, not in separate repos? 3. Am I overthinking this, or am I actually setting things up wrong? Would appreciate any clarity from people who've gotten this working.

I am the biggest fan of the ICM-architect and I have been running many projects hours on end in parallel that all started with building the ICM structure and routings via the ICM architect. Most of my projects are pretty similar either software, hardware/IoT or business and the architect offers robust routing and coordination of the projects. A few things I noticed: - Similar project but gets completely different ICM structure (still gets the job done) - New project assumes information off one running in parallel - Some run fully autonomous goal-based and others require constant YES-ing I dont want to go and read all md files anymore (we are lazy) What would you add to make it behave in the same "structured" way like how ICM was intended to be? Share your ideas

I am rigorously using the ICM-architect as my first step when starting new projects. Also must admit I'm running at least 3 projects in parallel at almost any point in time and all day. I always have compute enough but the Context Windows are filling up faster than I'd like. Was hoping using ICM would cure this by design but I'm having to switch models constantly to keep AI awake here. What is the general approach to this? What's your take on this?