Check it out here: https://3toedsoftware.com/demos/scylla-01/ 146 commits to get to this point Just showing what we can make with Claude Code. I have almost no coding experience. It's clunky and interesting. Built this with Claude Code + Babylon.js. I like this combo for fast prototyping. It's a 3D deep ocean scene. Very small sandbox. Not a full game yet, more of an interactive prototype. You pilot a submarine around a deep ocean environment. There's a control panel for lights, a mining laser, speed boost, and an inventory system for collecting materials. Also a control panel to mess with lighting and other things in the environment. - W/A/S/D (or arrow keys) — move the submarine - Shift — cycle speed modes (normal, boost, super boost) - L (tap) — toggle/cycle lights - L (hold) — toggle light direction - Left mouse (tap or hold) — fire red laser (mining laser) - Right mouse (hold) — hold on object to lock on and move the mouse where you want to move the thing. it's sloooooow - Middle mouse wheel — increase/decrease submarine depth - Middle mouse click — attach tether (doesn't do anything but look weird right now) - Numpad +/- — zoom in/out Use the green laser to interact. I made it weak for now, so it can only move little things. It will be upgradeable. Use the red laser to burn shit. If you hold the red laser button on the big brown cube the animation will change and you can cut pieces off. If the pieces are small enough, use the green laser to move the cut piece onto the platform to collect it. Super excited to see what you guys make. Any games yet? I did a quick search for "Game" and couldn't find one. Also, just saw that basically every major engine has MCP integration now. I wish I could split into several people so I could make games and also productive apps. I feel like I have to choose one and focus. Or just have my sleep removed and inject demon blood into my body to stay moving.

On April 10 I was trying to clean up my Instagram.Tighten the cover graphics. Build a repeatable system. Stop redesigning the same template every week. A one-afternoon job. What actually happened was the first real test of an architecture I had been sketching for writing work — and I tested it on design. I built a sandbox, gave it a governing file, separated references from working material, wrote one clean brief… and let it run. Fifty covers came back in minutes. Same palette. Same typography. Same visual language. None off-brand. That was the moment something shifted. Not because of the output — but because of what it proved: Once an architecture is clear enough, the question is no longer “what can I delegate?”It becomes “what is now worth building?” In 21 days, that small test turned into: - Three working teams (orchestrator, content, design) - Four books shipped or shippable - A new website - Two additional teams already scoped Same operator. Same hours in the day. For those who asked about mindset and process — this is the real answer: 1. I stopped thinking in prompts and started thinking in systems.The model is not the asset. The structure around it is. 2. I separated thinking from doing.The orchestrator doesn’t write. It reads, structures, briefs, and validates.The workers execute. They don’t improvise outside their lane. 3. Everything moves through briefs.No direct “do this” requests. Every handoff is:task → context → scope → acceptance → return checklist.That alone removed most iteration cycles. 4. Context is layered, not dumped.Reference material lives separately from working material.The model doesn’t have to “figure out what matters” — it’s already decided. 5. The human sits outside the system.Not inside prompting.Outside — validating outputs and deciding what ships. The clearest proof this wasn’t theory came from the hardest task I’ve ever tried to coordinate: Mapping TCM meridians, Thai Sen lines, and Anatomy Trains on the human body — in one consistent visual language.

So, after people's comments about longer breakdowns and more graphics in my posts, I decided to make a site where I can share downloads and more visual breakdowns of work I'm doing. 8 hours from concept to live site. 5 sessions. None of them above 50% context. The site is https://www.aris-space.com/ Built on Next.js 15, Tailwind v4, MDX, Zustand and react-rnd, deployed on Vercel. Full breakdown here VVV https://www.aris-space.com/documents/discipline-and-process/building-aris-space I architected. Claude executed. // A<3

I wanted proof that my prompts improved from four months ago. The results turned into this post. Around early January I added these instructions to my Claude.ai user preferences: If required information is missing, ask clarifying questions before answering. Before giving the final answer: list assumptions, identify missing data, state confidence level. If appropriate, advise on how to write a prompt more efficiently in the future. Then I had Claude pull my chat history from before and after, and look for patterns. I figured I'd see changes in what I was asking. The actual change was in how I structured conversations around the asking, in three phases. Phase 1: one-line prompts (early January) Real prompt from January 8: "How do I set up a eSIM on a Windows laptop?" I was asking the way you'd ask a search engine. Claude wrote a generic eSIM tutorial. I bounced because it didn't match my situation, and never came back. That was my default. One sentence prompts. No context, no constraint, no goal. Phase 2: Claude starts showing its work (mid-January) This is where the instructions started doing actual work. The "list assumptions" line forced Claude to write down what it was filling in for me. When a response opened with "Assuming this is a Windows endpoint with standard user permissions and no recent OS reimage," I could correct the wrong guesses before they corrupted the rest of the answer. About half the time, at least one was wrong. "Identify missing data" produced a list of the questions Claude wanted to ask but was about to silently guess at. Reading that list every response taught me what to include upfront. Every "missing data" bullet was a future prompt fix. "State confidence" forced Claude to mark which parts of the answer were solid and which to stress-test. "High confidence that one of the first three checks will identify the cause" is useful in a way that a confident-sounding wall of text just isn't. The prompt-efficiency line pulled the other three together into a habit. After enough rounds of "next time include the OS version and whether the machine is domain-managed," I stopped needing to be told.

If any of you have his twitter/linked in, totally comment and tell him to respond to my email. Want him to come chat with all of us and I think he would be happy to just need him to get eyes on, as someone who gets thousands of emails a day I would not be surprised if he never sees it even if it is valuable.