This is a new style as well that I'm testing and I'm talking about systems thinking a little bit more in it and how I think that you can do more as a company now, especially if you're a consultancy. If you're thinking of starting your own or already have one, this video might be huge value for you! It's on my YouTube so if you can go like it there and leave a comment that would be amazing I'll probably create a text companion and make a few more videos and add this to a new series called systems thinking In the classroom! We shall see.

📊 You've probably seen this chart floating around LinkedIn and Twitter Each dot is 3.2 million people. ⬜ Grey is the 84% of humans who have never used AI 🟩 Green is the 16% who have used a free chatbot 🟨 Yellow is the 0.3% who pay for one 🟥 Red is the tiny sliver who use AI coding tools Most of the people sharing it have not actually said what it means. So here it is. 🔁 We live inside an algorithm. Mine shows me AI all day. Yours probably does too. Every reel, every post, every podcast clip, every ad. The feed makes it feel like the whole world has moved on without you and you are sprinting to keep up. Inside Clief Notes that feeling gets louder. You log in and see people building agents, shipping side projects, automating their inbox, talking about Claude Code and MCP servers like it is normal. In this room, it is. Step outside and almost nobody is doing any of it. 6.8 billion people have never opened a chatbot. Plenty of the ones who did opened it once, asked it something dumb, got a dumb answer, and decided the whole thing sucked. They are not coming back this year. Maybe not next year either. 🪖 When I was in the Marine Corps I never felt like I was doing anything special. I was surrounded by other Marines. Everyone around me could do what I could do. The standard was the standard. It was not until I left and stood next to people who had never served that I understood. The thing I thought was ordinary was rare. I just could not see it because I was inside it. That is what is happening to you in here. If you feel behind in this community, that is the right feeling to have. It means you are standing next to the people pushing the edge. Step outside this room and the thing you are calling behind is so far ahead of where most of the world is sitting that they cannot see you from where they are. And do not forget. The thing you built last week, the workflow you set up this morning, the conversation you just had with Claude. A version of you from two years ago would have paid good money to do any of it.

Most people use AI coding agents the same way. Open one chat, type, watch it work, copy the output. The model is doing both the thinking and the typing. That's the bottleneck. The interesting move is splitting those two roles. One model holds the judgment. Other models do the typing. The judgment seat never touches a file. The typing seat never makes a decision. I call this the orchestrator pattern. If you've been here a while You'll have seen me developing a system for dispatching workers from within a single Claude Code session. Briefs going out, workers running in the background, results coming back to one main seat without me ever switching windows. I've been running it for months. I just open-sourced the harness. What it does Pushing Dispatch is a multi-model dispatch framework for AI coding agents. You sit in one Claude Code session as the orchestrator. From there, you write briefs and dispatch workers. Workers run in the background on whichever model fits the task. Opus for hard reasoning. Sonnet for steady execution. Haiku for mechanical sweeps. Kimi for long-context. DeepSeek for cheap parallelism. One harness. Many models. One judgment seat. How I use it Three patterns: Brief and dispatch. I write a brief in the orchestrator session, hand it to a worker, and don't read code while the worker runs. I review the output when it's done. Parallel fan-out. When ten files need the same kind of edit, I dispatch ten workers and review all diffs in one pass. Long-context to Kimi. When something needs the model to hold a hundred-thousand-token codebase in working memory, the brief routes to Kimi automatically. The point is never to type the code myself, and never to do the same kind of thinking twice. Quick start Paste this into a fresh Claude Code session: ———————————————————————————————————— Read SETUP_WITH_CLAUDE.md from https://github.com/PUSHINGSQUARES/Pushing-Dispatch_ and walk me through setup end to end.

My Claude Code dashboard: - 430 sessions - 78,537 messages - 112M tokens - 22-day streak - "Favorite model": MiniMax-M2.7 That looks like a small fortune. It wasn't. On top of a Claude Max 20x plan, third-party API spend was probably $10 to $30. The reason it's that low is advisor-driven development. The pattern Opus stays in the orchestration chair. It plans, makes the calls, reviews the work. It does not type out the diff, run the test loop, or grep through 400 files looking for one symbol. That's grunt work. Grunt work goes down the model stack. - Opus for architecture, judgment, debugging the hard ones, anything where my voice is on the line - Sonnet for focused multi-step execution where reasoning still matters - Haiku for mechanical edits, file scaffolding, log parsing, small refactors - MiniMax for long bulk passes where context is huge but the thinking is shallow (asset audits, content sweeps, batch transforms) The bulk of those 112M tokens went through MiniMax and Haiku. That's why the bill is small. The dashboard literally tells you: favourite model, MiniMax. Opus is the rarest model in the mix and it's the one I pay a flat subscription for. Why quality holds Cheap models don't degrade your output if they're never the ones making the call. They're hands. Opus is the brain. If the brain decides what to build and reviews what came back, the hands can be as cheap as you want. The failure mode is asking Haiku to architect, or asking MiniMax to make a taste call. Don't. Route by what kind of thinking the task requires, not by what's available or what's cheapest. The principle Preserve your expensive horsepower for the moments it actually matters. Most of what an AI does in a coding session is mechanical. Move the mechanical work down the model stack. Keep the judgment seat sacred. The bill drops to a fraction of what people assume, and the work doesn't get worse. The power truly comes from when you and Opus are collaborators and co-authors of plans, then dispatch the work to models that can genuinely do this in their sleep.

So I haven't had the chance to dig into the classroom yet so I'm not sure if this is covered anywhere.. but this is my set of general vibe coding rules that I have been working on to use across all projects. This way I have a single "source of truth" for best practices to include on all builds and try to keep things clean. So far it has been working pretty well (from an amateurs perspective haha) and looking forward to stress testing it more. Please take it and use it for yourself if you don't have anything similar yet. Also, I would really appreciate any feedback from the more experienced devs/engineers in the group. 🙏 Edit for clarity: this doc is something I have been applying to all vibe coding projects. Not all projects in general. Another edit for clarity: I am just getting through Jake‘s ICM paper now along with the classroom material. I was not aware that he also refers to the claude.md as a global file to be handed off to the highest level orchestrating agent. This global.md would be better named something more specific and placed around layer 3 of the workflow (someone please correct me if I’m wrong). Anyways, hope this clears up any confusion there may be. Decided to change the name to vibe-code-rules.md for clarity =)