This is the "structure beats a better model" thesis, turned into something you can actually run. Everyone's chasing the next frontier model. I went the other way: take a small model running on your own machine, and wrap it in enough structure that it can't be wrong unchecked. The model never decides. It proposes. Folder-structured context (ICM) points it at one small step, and a deterministic check accepts or rejects what it wrote. The model proposes. The oracle decides. A wrong answer gets caught, not trusted. If that sounds like the context-engineering and "verify the chain" ideas we keep coming back to here, that's the point. This is those ideas running on local hardware. What it actually is: - A terminal app you point at whatever model you're running locally through Ollama - Your context and workflows live in plain folders and markdown, so you read and edit everything in VS Code - Two ways to drive it: chat it yourself, or let a frontier model like Claude drive it over MCP. Same engine, two callers - It ships with Windows dev context and workflows built in (.NET and PowerShell), so you can have a frontier model build you a small Windows-native app - It already wrote, compiled, and ran a WinForms app end to end through a local model. Two honest notes. First, this is beta and Windows only right now. One machine, running Qwen 3.5 30B with Nomic for embeddings. It is a working prototype, not a polished product, and I'm building it in public. If something breaks, post it here. Second, the methodology underneath, Interpretable Context Methodology, is Jake Van Clief and David McDermott's work. My part is the local-model port and the deterministic oracle. Go look, and tell me what breaks. Repo: https://github.com/CurtisSlone/ICM_Local_Terminal

https://discord.gg/YfHzRZk939 I'm building a community of like minded builders to gather, talk, and build!

I just dropped a new build video, and it is the most fun I have had proving this school's whole point. I vibe coded a top-down game called Warlord in an afternoon. About two hours, not the thirty-minute fantasy. Then I handed the enemy army's brain to a local AI running on my own machine. No cloud, no API bill. The first version did exactly what an unconstrained model does. It picked moves that do not exist and froze the server while it sat there thinking. In a game loop, that is death. So I fixed it with the same pattern we teach here. The model does not drive, it picks. It gets a closed set of 14 maneuvers and returns an index into the list, so it cannot invent a move and it cannot be prompt injected. I validate the pick, fall back to a deterministic picker when the model is off-list or slow, and I put the model's failure rate on screen so you can watch the honest ceiling in real time. The model proposes. A deterministic rule decides. That last line is the whole school in seven words. Vibe coding got me the game. Engineering got me an enemy that does not fall apart. The video walks the entire thing: - How the AI reads your formation and counters it (clump and it pincers you, hold a line and it flanks you) - The decision chain, step by step - The actual code that holds the leash - 63 tests green, because I did not vibe my way past the tests Warlord is open source: https://github.com/CurtisSlone/Warlord The vibe-code game companion that scaffolds this kind of build: https://github.com/CurtisSlone/ExcaliburJS-Vibe-Companion Come build with us on Discord: https://discord.gg/GtZPPMbX9a This is building in public, so if you clone Warlord and something breaks, post it here or in Discord. Founding members shaping the rough edges is exactly the point right now. Go watch, then go build something the AI cannot wreck.

Two players, top-down dungeon, one rule: any room you're not looking at gets regenerated. Walk back the way you came and the corridors have moved. The part worth talking about isn't the game, it's the constraint that makes it work: the client is never trusted. Every position, every hit, every room the dungeon reshuffles — the server computes it. The browser sends "these keys are down" and renders what it's told. Same reason you never trust a form field: if the client can assert it, a client can forge it. Three decisions I'd make again: - The simulation is pure functions, so it's unit-tested, not hoped at. - The thing that ramps difficulty is weighted rules, not a model — it can't return a room that doesn't exist. - The maze reshuffles as you move, but a spanning tree guarantees it stays solvable. I proved that with a test across 50 seeds, not a vibe. Then I pulled all of it into a free, reusable pattern library, so the next build starts from the tested foundation instead of a blank file. Driftdelve ExcaliburJS Game Vibe Companion