I Promoted My AI

My wife Melissa looked at the blog and asked why it was written in code font.

I had been working on it for weeks. Claude Code had touched nearly every file. Nobody had said a word about the font.

"Claude said nothing," I told her.

"Well," she said. "I know better."

She was right. We fixed it. But the thing that stuck with me was not the font. It was the silence. Claude had all the context. It had built half the thing. It never once offered an opinion.

That is what a code monkey does. It executes. It never tells you the thing is ugly.

The first question that mattered

I started asking. Not "make this smaller" or "move this up." Just: "What do you think?"

The answers changed immediately. Not always right, but never just compliance. It started to feel less like a terminal and more like a conversation.

The font was the first test. "Your wife is right," Claude said. I pushed back. I liked the mono font. It was the terminal identity of the whole blog. Instead of folding, it said "let me show you," and built three sample pages in three different fonts. I read two paragraphs and caved. The mono stayed in the headers and the navigation, where identity lives. The body got a font built for reading.

The problem was I kept forgetting to ask.

Making the pushback permanent

I added an instruction to the project memory, the notes Claude keeps between sessions about how I like to work:

Push back and give a candid editorial opinion on every change.
Flag anything that weakens the work even when I didn't ask.
Do not wait to be prompted.

One instruction. Every session changed. I stopped getting "Sure, here's the updated version" and started getting "I'd keep the original here because..." and "This section is doing two things at once."

Now I ask questions I would ask a teammate. The answer is not always yes. I asked whether the blog needed a search box. Instead of building it, Claude told me the blog was too small for search to earn its place, and to come back when there were more posts. It was right. I shelved the idea. A code monkey would have just built the search box.

🃏 The refinement session

That exchange has a name. On a healthy team it is a refinement session: you put the work on the table before anyone builds it, and people poke holes in it. They question the scope. They challenge the assumptions. Sometimes they talk you out of the thing entirely. It is the most honest hour a team spends, because nobody in the room is there to agree with you. They are there to protect the work.

That is the moment Claude stopped being a tool I operated and started behaving closer to a senior engineer. That was the promotion.

I wrote more about why execution and correctness are two different things in It Compiled. It Was Still Wrong. Melissa knew the difference in two seconds. The AI needed to be told.

Once it is a teammate, you treat it like one

A teammate gets two things a code monkey never does: an onboarding, and instructions you do not have to repeat every morning.

The context lives in CLAUDE.md at the project root. A new hire needs to know the conventions, the architecture, the gotchas. So does Claude. Every session now starts with it already knowing:

## Branch strategy
Never commit directly to `main`, `development`, or `preview`.
Every change goes through a `fix/` or `blog/` branch first.

## Tooling gotchas
RTK rewrites raw grep and find commands. Use the dedicated Grep tool instead.

You write it once and the re-onboarding cost goes to zero. Any convention you find yourself explaining twice belongs in that file.

The repetition is the other tax. Every session opened with the same setup. Claude Code lets you define slash commands as markdown files in .claude/commands/, so I wrote one for every pattern I kept repeating:

.claude/
  commands/
    new-post.md      # branch + frontmatter + scheduling
    hot-topics.md    # trend scan + dedup against published posts
    ux-test.md       # Playwright accessibility + mobile checks

Versioned with the code, available every session, no re-explaining. And when a command turns out to be useful beyond one project, it graduates to a plugin. /handoff pauses a conversation so you can pick it up the next morning without losing the thread. Too useful to leave in one repo, so I published it. Project things stay in the project; the ones useful everywhere get pulled out.

The part I did not expect is that it learned when to reach for them. I wrote down once which command fits which moment. Now, after a big UX change, Claude suggests running /ux-test before I remember it exists. When a conversation piles up more good ideas than we can build in one sitting, it offers a /handoff so nothing gets lost. Nobody asks it to. A code monkey waits for the next instruction. A teammate knows the process and nudges you through it.

Well. Most teammates. Haiku, the smallest and fastest of the models, reads the same file and still tries to commit straight to protected branches. The guardrails catch him every time. God bless him, he is doing his best. Which is fine. You do not fire the intern for being an intern. You just stop handing him the architecture.

What actually changed

Melissa told me what Claude never volunteered. The fix was not a better model. It was a different question.

The memory instruction forces the pushback. The context file spares the re-onboarding. The commands cut the repetition and carry the useful pieces between projects.

Ask for the opinion. Write it down so you never have to ask again.