I've been building with Claude Chat (I call Claude) and Claude Code (I call CC) everyday. I've been providing trade knowledge and design decisions with Claude and just copying and pasting over to CC to build it, then I test in browser, take back any additions, critiques, alterations, etc. to Claude and we revise. Rinse and repeat. I've thrown a few ideas at Claude to propose additional work that can be done while I'm not available that we could use CoWork (I call CW) to build. So far it's only been prototypes of what the future model would look like on a grander scale, but nothing has gotten that far yet. My process with Claude and CC feels like it can drag on sometimes... I want to build this thing properly right from the start, so I've come to terms with the speed of it all, but I thought I'd check in with the masters and see if you can think of any holes or gaps I can fill. We'll start with a diagnosis of whatever it is we're going to add or improve to see what kinds of other things might be affected by it's addition. Then we write a spec that goes into our CONTEXT bible. Then we do a build prompt that I hand to CC, who then builds it. Now we've also built a harness for the whole thing, so before each build we also add in a layer of building on to the harness, which comes with it's own checks, both surgical checks and full run sweeps. A full run is starting to take over an hour to get through now, so needless to say some of the progress that I made early on before it got this big felt a lot better than the speed that the whole project is moving at now. After both harness and build have happened I'll do a screen test depending on what was changed. We'll commit after a full green pass, and then move on to the next step up the mountain of steps that this has shaped out to be. Without having to go into too much detail about what the project is about (I've been working full time and just trying to grind this out on evenings for a few hours a night and weekends where I spend usually >12h trying to get through this thing) what do you guys think might make this process run a little more smoothly?

For a long time I was the slowest part of my own work. Everything ran through one chat. One conversation, one me. Good ideas queued up behind whatever I happened to be typing. The model in front of me was fast. I was the line it had to wait in. So I changed the job. Instead of doing the work, I direct it. I stay in one seat and advise, and the building happens in the background, in workers I hand tasks to and check on later. It runs whether I am at the desk or asleep. That last part is the honest claim, so let me be careful with it. This is not ten times faster, and nothing builds itself. I still decide what gets made, and I review every result. What changed is that I stopped being the single point everything has to pass through. The proof: I built part of the setup using the setup. I wrote a short spec for a tool I wanted, handed it to a background worker, and went to bed. In the morning the tool existed, its tests passed, and one question was waiting for me about a naming choice. I answered it. That was my whole night shift. I packaged it and open-sourced it. It is called ARI-OS. Repo: github.com/PUSHINGSQUARES/ARI-OS Install page: aris-space.com/applications/ari-os It is one loop, six steps, and you can learn it in an afternoon: 1. Brainstorm. Talk the idea out until it is a clear outcome, not a vague wish. 2. Plan. Turn that outcome into ordered steps. 3. Dispatch. Hand a step to a background worker and let it run on its own. 4. Watch. Glance at a small dashboard. See what is running and what is stuck. 5. Review. Read what came back. Keep it, or send it back with notes. 6. Ship. Merge the work that passed. You live on steps one, five and six, the judgement steps. The worker takes three and four. Step two is shared. The parts that need your taste keep you. The parts that do not stop waiting for you. If you are just getting started with Claude Code: it is pure Python, it installs with one command, it sits on top of your existing setup, and it is reversible. It distils four habits I lean on every day. A handoff layer, so a fresh session picks up cold without losing the thread. Background-first dispatch, so focused work runs while you stay free to steer. Spec-first thinking, so the work has a target before any code exists. And a memory, so the setup recalls what past sessions decided instead of guessing every time.

I sort every task by leverage — what changes the shape of the whole build if it's right or wrong. On an expensive model, that sort is the whole game. The top of the list gets the frontier. Everything under the line gets offloaded to cheaper and local models through Pushing Dispatch from @Ari Evergreen credit where it's due. So Fable was never running my stack. It sat at the top doing the one slice worth frontier money: deep diagnosis, strategic synthesis, finding the gaps and the false "fixed" claims. The 90% underneath — building, refactors, the delegated volume — ran on MiniMax M3, GLM, Kimi, Codex and local models. When you see Fable delegating or spinning out subagents, that's the offload. Fable decides; the cheaper lanes do the work. Concrete from yesterday: I had Fable audit CheckYourself, my open production-readiness checker. Deep review plus hands-on testing, three real bugs found, fixes shipped. (It also kept bouncing me to Opus 4.8 on anything it decided was "sensitive." Annoying then. Funny now.) So when access got pulled, what broke was that top slice. That's it. The 90% never ran on Fable in the first place. I swapped which model sits at the top, and the machine kept moving. That's the part I keep coming back to. Sort by leverage, and the expensive model becomes a specialist you can fire and replace — not the foundation everything sits on. If losing one model stops your work, the model was never the problem. The wiring was. I don't know if Fable comes back the same, dumbed down, or at all. Doesn't change what I ship Monday. When it got pulled — did your work stop, or did you swap one model and keep going?

Meet QualmGuy. There's a little guy on aris-space.com now. He lives in the corner. You can drag him around the page. Give him a hover and he perks right up. His whole job is to catch your qualms. Wat is a QUALM you might ask? A qualm is just anything that annoys you or breaks your flow. The AI thing that won't do the thing. The step in your day that makes you sigh. The "why is this still so hard" moment. Big or tiny, it all counts. Click him and tell me yours. That's the whole ask. He'll be popping up on all my deep dives, so if you have any questions relating to a deep dive or it sparks a question of its own while reading it, let him know! And while you're here, I want to open the floor properly. Think of this thread as your always-open AI hotline. If you have a question, feel stuck, want a second opinion, or just need a bit of clarity, drop it here. This space is for: Questions about AI, Claude, or any tool you're poking at Help applying what you're learning Feedback on your ideas, content, or next steps "Am I thinking about this the right way?" moments Anything you'd usually wish you could just ask me directly No question is too small. None of them are silly. If it matters enough for you to wonder about it, it belongs here. You don't need the lingo. You don't need to be technical. You just need to be curious. I'll be checking in and answering as much as I can. Send QualmGuy your qualm. Drop your question below. Both doors are open. Welcome to Ari's Space. <3

I woke up this morning to 10 fresh podcast episodes. Fully researched. Scripted. Narrated. Visuals timed to every beat. Published to YouTube, RSS, and my own website. I didn't make any of them. A machine on my desk did. While I slept. I launched these channels at the end of February. It hasn't been a month yet. A channel is even pulling 1,000+ views and gaining subscribers - with zero ads, zero promotion, zero outreach. But here's what I need you to understand: this is not a prompt. When people hear "automated content," they picture someone typing a topic into a chatbox and hitting publish. That's not what this is. That's not even close. What I built is a multi-stage production pipeline. Not a single generation step - a sequence of independent systems, each with its own job, its own rules, and its own quality bar. Every stage has to pass before the next one starts. If something isn't good enough, it gets caught, flagged, and redone automatically. Here's what that actually means in practice: Every episode starts with real research. Not "summarise this topic." Actual source-finding, fact-checking, angle evaluation. The kind of editorial groundwork a good producer would do before writing a single word. Most automated content skips this entirely. Mine can't - the pipeline won't let it move forward without it. Then there's the writing. And this is where I spent most of my 45 days. I didn't just generate scripts - I built an entire set of rules around how spoken language works differently from written language. How rhythm changes when someone is listening instead of reading. How a pause lands. How a transition should feel. Early versions sounded like a textbook. Now they sound like someone talking to you. After the writing comes the part most people don't think about: quality control. Every script gets evaluated across multiple dimensions before it moves on. There's a hard pass/fail threshold. I've watched the system reject its own output dozens of times and come back with something genuinely better. Nothing mediocre gets through. That's not a nice-to-have - it's the reason the content performs.