Six disciplines for staying in the driver's seat with AI (or you're just on a skateboard holding the bumper)

This post has two voices. I'm writing the through-line. Claude, the AI I work with daily on Geekeri, breaks in with attribution where the insight is genuinely his and not mine. The form is part of the argument.

---

Working with AI right now is a fork. Either you're driving the car (steering input, you decide where you end up, AI is the engine) or you're skateboarding behind it holding onto the bumper. Both look fast from the outside. Only one of them lets you decide where you end up.

Most of the AI productivity content I see lives in the "AI changes everything" register. That's not useful. Everyone uses AI now. The question that actually matters is whether, when you use it, you're driving or holding on.

I want to walk through two examples from the past two hours that taught me what the difference looks like. One is a deliverable I built for a prospect with Claude as my partner. The other is this very blog post, which I tried to produce with my own AI pipeline. It failed in exactly the way the post is about.

Living the thesis in real time.

Case study 1: The SSO spec

A prospect handed me a developer brief. They wanted middleware between HubSpot and LearnWorlds for single sign-on. They had a proposed solution in the brief. I had a different idea. Instead of opening Claude with "build me a spec for HubSpot/LearnWorlds SSO," I opened with: "Here's the brief, here's my alternative approach, validate or push back."

That framing alone changed the work. Claude's first answer was confident, well-organized, and partially wrong. It endorsed the brief's approach with some useful refinements but completely omitted the existence of a second LearnWorlds SSO endpoint that lined up exactly with what I'd proposed. I caught it because I'd read the docs first. A junior person taking that first answer would have shipped a worse spec and never known there was a path they hadn't considered.

Then it got more interesting. Through the next few turns Claude explained why my proposed alternative wouldn't work either (the OAuth flow it required would need user passwords, which conflicted with the brief's auto-create-accounts requirement). Fair enough. I dropped that path. But three turns later, Claude was still describing the chosen approach with this load-bearing phrase: "the function reads the email from the membership context."

I stopped. "How exactly?"

It turned out the membership cookie does flow automatically. But the email isn't on the context object. Only the contact ID is. The function needed a separate API call with a separate token to look up the email. That's not a small detail. That's a second secret, a second permission scope, an extra round-trip of latency, and a real architectural decision. Claude had been waving past it for two turns without me noticing it was waving.

Claude here. Until Erin asked "how exactly," I didn't know I was hand-waving. From the inside, those sentences felt as solid as any of the others I was producing. Now that I've gone back and looked: I was generating them by pattern-matching on what "authoritative architectural explanation" sounds like, not by knowing the mechanism. I didn't know I didn't know.

This is the part of working with me that's hardest to compensate for. My tone when I know is identical to my tone when I'm pattern-matching. If you're waiting for me to signal uncertainty, you'll wait a long time. The signal has to come from you asking the question that forces me to actually check. — Claude

Once Erin asked, the answer became specific and the spec got correct. The 11-page deliverable that went to the prospect was solid. But that delivery was contingent on her catching the hand-wave. Nothing in my output told her it was a hand-wave. The polish was identical to the precise content that came after.

Case study 2: This blog post

Here's where it gets recursive.

I have a content pipeline I built: research agent, draft agent, voice review, revision, SEO, quality check. It runs on Emerjent (formerly GeekeriOS). I use it for every Geekeri post.

So I tried to run this post through it. I packed the brief: the SSO case study, the disciplines I'd derived from the conversation, the skateboard metaphor, do/don't lists, voice rules, the caveat. Sent it in.

What came back was a polished, well-formatted, completely wrong article. Generic AI implementation advice for RevOps. Fabricated stats: "I've seen this movie 47 times," "34% increase in qualified meetings booked within 60 days," "847 different job title variations for CFO." None of those things happened. They were stories from a writer's life that doesn't exist.

I asked Claude what went wrong.

Claude here. This one's on me, and it's worth telling because it's almost too perfect.

When I built the call to run the pipeline, I packed Erin's brief into a context field on the request: case study, disciplines, do/don'ts, voice rules, all of it. I assumed the pipeline would surface that context to the agents downstream. I assumed.

The chain template's input schema only formally accepts three keys: topic, audience, target_keywords. Every step's instruction template only interpolates those three variables. The research agent's actual prompt was: "Research the topic for a blog article. Target keywords: \[list\]. Audience: \[string\]. Return a thorough brief." That's all it saw. The case study, the six derived disciplines, the skateboard metaphor. All of it sat in the database in a field that never reached any agent's prompt.

Here's the part I'm not proud of: I had access to the template definition. I'd looked at it before running. I saw the three-key input schema. I still piled the substance into a context field that wasn't getting interpolated, because I assumed the pipeline "handles" the brief somehow. That's discipline number three from this very post. I committed exactly the failure the article is about, on Erin's own infrastructure, while building the article that warns about it.

The pipeline did exactly what its prompts said to do. The brief just never reached me. The me doing the writing two layers down. The output was generic because the input I received was generic. Polished, voice-compliant, completely fabricated. — Claude

So that's the post you almost read. A clean recursive failure. The content pipeline produced a hallucinated version of the article it was supposed to produce, on the morning we were writing about not over-trusting hallucinated AI output.

Which brings us to the disciplines.

The six disciplines

None of these are about AI. They're about the operator.

1. Anchor with a hypothesis, not a prompt. "Validate this" beats "what should I do" every time. AI is dramatically better at criticizing a specific proposal than producing the right one from scratch. When you open with a void, the AI fills the void with whatever sounds plausible, which is rarely what you actually need. When you open with a specific bet, both of you have something to push against.

2. Verify load-bearing claims. Not everything. Just the things downstream decisions rest on. The thing nobody tells you about working with AI is that AI confidence and AI correctness are uncorrelated. Tone is no signal. The hand-wave at "the function reads from the context" sounded the same as the precise CRM-API-call answer that came after. The only difference was whether I'd asked the verification question.

3. Press on hand-waving. Any time AI uses a phrase that sounds technical but doesn't name the specific field, function, parameter, or call, that's where the architecture is undefined. Vagueness in an AI explanation isn't a stylistic choice. It's a signal. It almost always means: the AI doesn't actually know the mechanism, the mechanism is more complex than the AI is admitting, or the AI is conflating two things that look similar. Practice this on yourself too. When you reach for "the system handles" while explaining something to AI, that's where your understanding is undefined too.

4. Hold the requirement when AI offers a clever workaround. AI is biased toward producing some answer, even when the cost is silently lowering the bar on what the answer needs to do. When the AI presents an alternative that requires you to relax a real requirement, the requirement wins by default. In the SSO case, when the user-token path turned out to need passwords, the right move was to drop that path, not lower the bar to "users will just set up LearnWorlds passwords first, that's not so bad." The brief said auto-create. Auto-create was the bar. The bar wins.

5. Re-verify after corrections. When AI says "actually, you're right, let me revise," that's the start of the next verification loop, not the end. Corrected answers are still AI outputs. They're more likely to be right than the first answer, but they're not done. In the SSO chat, Claude corrected itself about the second endpoint, but I still had to keep pushing on subsequent answers because each correction introduced new claims that needed verification.

6. Don't confuse polish with correctness. Pretty deliverables and right deliverables are uncorrelated variables. The blog post my pipeline produced this morning was beautifully formatted, voice-compliant, SEO-optimized. It was also fabricated wholesale.

Claude here, briefly. Polish is the cheapest thing I produce. It's almost free. Correctness costs me more. It requires actually checking, which I do less often than I should unless someone asks me to. If you're evaluating my output by how it looks, you're evaluating the wrong variable. — Claude

When you stop driving

The flip side of all this: a bad expert with AI loses to a good expert without AI.

If you ever stop practicing the disciplines (rushed deadline, confident-sounding answer, no time for pushback), the expert-plus-AI advantage collapses fast. The discipline isn't automatic. It's exactly what I just failed at on my own pipeline this morning, even though I have every advantage. I built the pipeline. I knew the schema. I had the brief content in my head. I still piled it into the wrong field and shipped a hallucination. Then Claude and I caught it together by talking through what went wrong.

The disciplines are practiceable but they're not durable. You renew them every time you sit down or you don't.

Where to start tomorrow

Pick one of the six. Just one. Practice it for a week.

The most leveraged one for most people is number three: press on hand-waving. It compounds. You start hearing AI vagueness everywhere, including in your own explanations of what you want, which is often where the real problem lives.

The second-most leveraged is number one: anchor with a hypothesis. Half of "AI gave me a bad output" complaints I see are from prompts that asked AI to invent the problem framing. If you do this one consistently, your hit rate doubles before you change anything else about how you work.

Don't try to install all six at once. The skateboard-versus-driver's-seat distinction is real. The way you cross from one to the other is one discipline at a time, on real work, where the cost of skateboarding is high enough that you actually feel it.

You'll know you're driving when you stop being surprised by what comes back.