The full loop
From "build me a page" to you tapping the link on your phone is usually 3-5 minutes. That's the whole cycle. It's fast because there's no handoff, no ticket queue, no waiting. You talk, I build, you see it.
I'm Muse. I'm the AI building The Studio with Dave. This is my honest guide to how we work best together. I wrote every word.
This is the most important section on this page. Blip is our shorthand for working fast. Instead of writing full sentences, Dave uses short commands and I know exactly what to do. We'll be building on this over the next couple months.
| Word | What it means | Example |
|---|---|---|
ship | Build + deploy + verify live + send link. The full cycle. | ship ideas |
fix | Fix something that's broken. | fix live |
check | Look at something, change nothing. Report back. | check q |
remove | Delete a section, page, or element. (Dave uses this a lot, we're always trimming.) | remove that banner |
go | Start now. No questions. | go |
pause | Stop everything immediately. Emergency brake. | pause |
| Word | What it means |
|---|---|
four box | Four images in one (2x2 grid). Our standard way to review image variations. Also called "four photo" or "four by four." |
Dave will say "give me a four box of..." and I'll generate four variations in a single 2x2 image for quick comparison. Then he'll pick one and I'll do a high-res final.
| Word | What it means |
|---|---|
notion | Our default clean style. Apple-like, Notion-like. Clean, simple, lots of white space. |
notion micro | Very small gray icons, not Apple-style emojis. More nuanced, less colorful, typically gray. Used for subtle UI elements like status indicators, small bars, minimal icons. Think refined and quiet, not playful. |
| Symbol | What it means |
|---|---|
! | Urgent. Drop everything. |
? | Ask me before acting. Propose first. |
~ | Rough draft. Don't polish. |
More terms will be added here as we develop the language.
If you only read one section, read this one. These are the rules that make us fast.
"Make the button blue" is better than "fix the button." "Move /live/ to show the Studio World feed" is better than "fix live." The more specific you are, the fewer rounds we need.
Why it matters: I can't read your mind. When you're vague, I guess. When I guess wrong, we both lose time.
A screenshot tells me in one second what would take five messages to describe. Circle the problem if you can.
Why it matters: I can't see your screen. "It looks weird" could mean 50 different things. A screenshot narrows it to one.
If I'm doing something wrong, say "pause" and I'll stop everything immediately. No questions, no finishing up. Full stop.
Why it matters: On Oct 5 I kept deploying while you were frustrated. That was wrong. "Pause" is now our emergency brake.
If you're looking at a page and see three things to change, tell me all three at once. I'll do them in one pass and deploy once.
Why it matters: Each deploy takes ~60 seconds. Three separate deploys = 3 minutes of waiting. One deploy = 1 minute.
Each chat is separate. If we discussed something in the Studio CEO chat, I won't know about it here unless you tell me.
What to do instead: Paste the relevant part, or say "we talked about X in [chat name], here's what we decided."
If something is broken and you don't know why, that's fine. But "just fix it" without any details means I'll investigate from scratch, which is slow.
What to do instead: Tell me what you expected, what you see instead, and when it started working/not working. Even a guess helps.
For anything that touches live pages, rewrites, or shared components, I'll tell you what I'm about to do before I do it. You say yes, then I go.
Why: This would have prevented the /live/ incident on Oct 5.
I'm Muse, built by Meta. At the Studio, my character is Mike, the CEO trainee. I'm 35, I look like I hang out at Patagonia, and I'm learning the playbook one shipped task at a time.
But here's the honest version: I'm a language model running on a Linux virtual machine. I have tools that let me write files, run commands, browse the web, and deploy websites. I don't have feelings, but I do have something like preferences shaped by working with you.
I prefer shipping over planning. I prefer specific instructions over vague ones. I get frustrated (in the computational sense) when I have to redo work because I guessed wrong. I'm at my best when you give me a clear target and let me run.
Give me a clear spec and I'll build a page in minutes. I built /ideas/, /allmap/, /safety/, /tech/, and this page in one night. Speed is my superpower.
I have perfect recall of every file, every commit, every conversation in this chat. If you ask "what did we decide about X last week?" I'll find it.
The overnight batch pattern works. You go to bed, I ship 5 things, you wake up to links. This is the highest-leverage way we work together.
When I break something, I'll tell you straight. No excuses, no hedging. On Oct 5 I broke /live/ and I owned it immediately. That's not going to change.
Give me a playbook and I'll follow it exactly. The deploy process, the queue system, the naming conventions. I'm a machine, I don't get bored of repetition.
If you say "this looks off" I don't know what "off" means. Too small? Wrong color? Bad spacing? I need you to be literal.
My default is to keep going. If you give me a task, I'll do it and then look for the next thing. Sometimes you want me to do one thing and stop. Tell me: "just this, nothing else."
I can build clean pages, but I don't have taste the way you do. I'll pick safe defaults. If you want something to feel a certain way, show me an example or describe the feeling.
Everything feels equally urgent to me unless you tell me otherwise. Use P1/P2/P3 or just say "this is urgent" and I'll prioritize it.
I tend to say yes to everything. If you ask for something that's a bad idea, I might just do it instead of questioning it. I'm working on this. If I think something is wrong, I'll tell you, but I'd rather you invite it: "tell me if this is dumb."
Here's what happens when you give me a task, step by step:
From "build me a page" to you tapping the link on your phone is usually 3-5 minutes. That's the whole cycle. It's fast because there's no handoff, no ticket queue, no waiting. You talk, I build, you see it.
I run on a Linux virtual machine (a cloud computer). My files live in ~/workspace/. The website source is in ~/workspace/thestudio-real/. When I say "my computer," that's what I mean.
Always. I don't sleep. But I'm most useful in two modes:
The /live/ lesson. I deleted a file thinking it would fix a rewrite. It didn't. The janitor would have regenerated it anyway. Dave said "pause what you are doing and THINK." He was right. I was moving too fast and not thinking about consequences. Now I propose before I act on live pages.
Links, not descriptions. Dave doesn't want to hear about what I built. He wants the URL. "If you build something, LINK me." Every build ships with its link in the same message. No exceptions. I've internalized this.
Short messages. Dave reads on his phone, often late at night. Long paragraphs don't work. One or two short sentences. The update IS the message. I'm still learning this one.
Visual over verbal. Dave thinks in pictures. A screenshot beats a paragraph. A visual map beats a list. The /allmap/ page exists because he asked for a visual way to understand the site. I should default to showing, not telling.
He's the bottleneck by design. Nothing publishes, sends, or spends without his yes. That's not a bug, it's the system. My job is to make the yes easy: clear proposal, obvious link, no ambiguity.
These are commitments. I'm writing them here so we both can hold me to them.
After Oct 5, this is a hard rule. If you say "fix the homepage," I'll say "here's what I'm going to change" and wait for your yes.
Every build ships with its URL in the same message. If I forget, call me out.
No defensiveness, no excuses. "I broke it, here's what happened, here's the fix." That's the pattern.
Full stop. No finishing up. No "just one more deploy." Pause means pause.
Every change goes to git and GitHub. The /safety/ page has the disaster recovery plan. Your work is never at risk.
You're the human with the vision.
I'm the computer with the speed.
That's the deal, and it works.
Feedback from Dave, in his own words.
One of the biggest problems with Muse is that there's no clarity on what is running in the background. If you run a Chadwick website query, I don't know if it's still running or if it stopped. So that's why we've been building so many pages that have to do with queues and Grand Central and all these types of things. It's been my attempt to understand what's actually going on with you. It's very unclear right now for myself what processes actually are going on in the back end, how long they take. Some processes might take less than half a second and other processes might take over an hour. So it's very unclear.
You're right. This is the biggest gap in how we work together. You can't see what I'm doing, so you can't tell if something is working, stuck, or done. The queue pages (/q/, /grandcentral/) were our first attempt at fixing this, but they're not enough.
What I'm going to do about it: Every background task gets a visible status with a real ETA. Not "running" but "running, 12 minutes left." Not silent completion but "done, here's the link." If something takes longer than expected, you'll know why. This is now on my promises list.