Most "AI workflows" are one phase: type a prompt, hope. Mine has four. The build doesn't start until phase four. By then the AI is barely making decisions. It's executing a contract. Phase one: Brainstorm Open conversation. No structure, no acceptance criteria yet, no scope. I yap. Claude compresses what I yap into a `.md` file in real time. We argue. We rule things out. We name the actual outcome I'm chasing, not the thing I thought I wanted when I started talking. The output of phase one is one sentence: **what done looks like.** CRUSH started as "I want a video plugin that feels analogue." Two hours of brainstorm later the doc said: "14 Metal fragment shaders, a 6-slot effect chain, three global controls (DECIMATE, SPAZ, CHILL), real-time on Apple Silicon, drag-and-drop in DaVinci Resolve." That's the outcome that got dispatched. Phase two: Implementation plan Now I take the outcome and ask Claude to architect it. Files, dependencies, the order things get built in, the places it's likely to fall over. This is still in the main session. Still advisor seat. Zero code written. The plan for CRUSH was a 6-stage build pipeline. Format design, build-time generator, plugin core, 2D shaders, splat engine, AE port. Fourteen Metal fragment shaders authored as `.crush` JSON files. A Python codegen that writes the entire C++ OFX boilerplate at compile time so adding a new effect later is JSON plus a shader function and nothing else. Every stage had acceptance criteria, file scope, and risks named upfront. By the time it was done, the plan was a single markdown artefact a fresh worker could execute against without ever talking to me. That's the goal. The plan is the spec. The spec is the thing. The plan also names risks before any worker meets them. It says: "Metal kernel buffer names must match this exact contract or DaVinci silently rejects the bundle." It says: "Real-time on Apple Silicon at 4K is the gate. If a shader drops frames during scrub, it doesn't ship."

I have directed film sets for years. Last night I directed a website the same way, and I never wrote a prompt. On a set you do not operate the camera. You watch the frame and call what it needs. Slower. Dirtier. Again. The crew has the hands. You have the eye. I ran a build the exact same way. A live page open on screen, an agent holding the hands, and me reacting out loud to what moved in front of me. One change. Watch it land. Call the next. DIRECT THE SCREEN, DON'T PROMPT THE MODEL. A prompt is a memo. You write the whole brief, fire it off, and hope what comes back is what you felt. Directing inverts it. You give one small note against a live render, you see it land the instant it changes, and the screen hands you the next note. What came out of it: a wall of twelve CRT monitors, each playing a showreel at a different second, scanlines and flicker and a teal glow. "Make the cursor knock the screens." Now a mouse sweep tears the signal, splits the colour, sometimes cuts a screen to black static, then it recovers on its own. "Dirtier." A pink and teal spark cracks at the pointer. A custom glitch typeface on the headline. None of it was written down up front. It emerged, note by note. This is not magic. Nothing builds itself. An agent built each change, I reviewed every frame, and I called every move. The taste was mine. The hands were not. The loop, if you want to run it: 1. Stand it up live and look. "Warmer" needs something to be warmer than. 2. One move per round, so your reaction maps to one cause, not five. 3. Make every value a named dial. Steer by feel, not by editing code. 4. The agent proves its own edit compiled before it says done. You stay free to just watch. 5. When a look locks, save it. The final dial values are your design system. The skill that runs this loop is open source. Take it: https://github.com/Pushing-Squares/art-direct Here is the part that stuck. You cannot write a feel down. A brief is a guess at an aesthetic you have not seen yet. The eye only knows once the live thing is moving in front of it. So stop trying to specify the feel. Build a loop fast enough to react inside.

Search finds. It never reads. Every "AI that knows your stuff" runs the same trick: embed the material, grab the paragraph nearest your question, bluff the rest. For easy questions the bluff holds. For the ones that matter, it doesn't. So I'm building the missing layer. Call it a reading swarm. Instead of paying one expensive model to read a whole mountain, I cut the corpus into slices and send a swarm of cheap workers, one per slice. Each reads its slice properly and hands back a single finding. A deterministic harness merges them into one verdict. The expensive model only steps in if I ask it to sharpen the final call. Not shipped yet. Still smoke-testing the edges, and I read every verdict myself. But the law already holds: finding isn't comprehending, and comprehension doesn't need a bigger brain. It needs more cheap eyes, one slice each. What's the biggest pile of material you wish your AI actually read, not skimmed? //A<3

A week and a half. 540 commits. I wrote almost none. The week, by the numbers: 6 tasks built overnight, every one audited by a second model, zero input from me. A knowledge graph that went 54% to 84% precise after one model swap. Then 9.5x faster in a day. A signed macOS app, 165 tests green. 600 green on the memory engine. One loop ran away. £2. The system capped it before I woke up. So I stopped checking the work. A second model marks the homework now. I wake up to finished builds I never touched. I watched my own system misbehave, and trusted the rail instead of jumping in. Five models, each on the job it does best. Fable holds the seat. The rest execute. The intelligence is the routing, not any single model. Next ARI-OS update. Full write-up: aris-space.com/documents/workflows/540-commits-one-human //A<3

Every cloud dictation tool sends your voice to a server you do not own. I dictate client names, half-formed ideas, things I would never want sitting in a log I cannot see. So I built my own. It is called Pushing Talk_. Hold a key, speak, release, and your words land as text wherever you are typing. The speech-to-text runs on-device with a local Whisper model. No cloud, no account, nothing leaves the Mac. It is free. Privacy is not a feature I bolted on at the end. It is the whole reason it exists. Your voice is data, and I wanted mine to stay on the box I own. This is the part worth stealing. I did not type it out by hand. 1. I brainstormed the outcome, then turned it into a plan. 2. Codex sessions ran in parallel, each building a tight slice. 3. Claude held the spec, handed out the slices, and reviewed what came back. 4. I made the calls. BUILD WITH CODEX, SHIP WITH CLAUDE. The models are the hands. I keep the judgment. This is not "AI built my app." I decided what "done" meant, I reviewed every slice, and I am the one who shipped it. The models accelerate the middle. They do not get to define the outcome. The system around the AI is the intelligence, not the model. Define the outcome, let the build run in parallel, and keep the taste human. It was not smooth. I declared it finished three times before it actually worked, and the worst bug was one I caused myself. That story is the deep-dive. Read the deep-dive: https://aris-space.com/documents/debugging/pushing-talk-finished-three-times What would you build if the models did the hands and you kept the judgment? Stop prompting, start defining outcomes. // A<3