Last quarter I lost a full afternoon to a bug that, in hindsight, took 11 minutes to fix once I changed how I was talking to my AI assistant.

Here's what actually happened.

The Situation

We were mid-sprint. A new webhook integration kept silently dropping events under specific payload conditions — no exception, no log line, just gone. I'd been staring at the same three files for two hours. The code looked fine. The unit tests passed. My rubber duck was useless.

My first instinct, like most engineers who've been using AI tools for a while, was to paste the function into the chat and ask: "Why isn't this working?"

I got back a confident, well-formatted, completely wrong answer. The model explained a race condition that didn't exist in my codebase. I spent another 45 minutes chasing it.

The Problem With How I Was Using AI

The real issue wasn't the tool. It was that I was treating it like a search engine with better grammar. I handed it a decontextualized code block and asked for a conclusion. No wonder it hallucinated one.

When you strip context and ask for answers, you get pattern-matched plausibility — not debugging insight. The model has no idea what should happen. It only knows what the code says.

The fix wasn't a smarter model. It was a smarter prompt.

What I Tried (and What Actually Worked)

I stopped asking "what's wrong" and started asking the model to reason out loud about expected vs. actual behavior — with me supplying both sides.

Here's the exact prompt structure I switched to:

You are debugging with me, not for me.

Context:
- What this function is supposed to do: [one sentence]
- What it's actually doing: [one sentence]
- What I've already ruled out: [bullet list]

Here is the code:
[paste]

Do NOT guess at a root cause yet. First, ask me up to 3 clarifying questions that would most change your hypothesis.

That last line is the unlock. Instead of getting a confident wrong answer, I got three sharp questions — one of which was: "Does the payload schema validation run before or after the event is queued?"

I didn't know. I checked. It ran after. That was the bug. A malformed payload was being queued before validation could reject it, and the queue consumer was silently swallowing the schema error.

Eleven minutes.

A Second Prompt That Now Lives in My Rotation

The debugging prompt fixed my immediate problem, but I noticed a broader pattern: I was also losing time during code reviews by catching things too late. So I built a pre-review prompt I run before I open a PR:

Review this code as a senior engineer who is skeptical but fair.

Focus only on:
1. Logic errors or edge cases I may have missed
2. Any place where my stated intent and the actual implementation diverge
3. One thing you'd change if this were your codebase

My intent with this code: [one sentence]

[paste code]

Do not comment on style, naming, or formatting.

The constraint at the end matters. Without it, you get four paragraphs about variable naming and one throwaway line about the actual logic bug.

What Changed After

I don't use AI less now — I use it differently. The prompts are more structured. I treat the model like a sharp junior engineer who needs good questions more than they need free rein. I give it constraints, context, and a specific job to do.

The productivity gains got real when I stopped optimizing for getting answers and started optimizing for getting the right thinking surface. Sometimes that means asking the model to poke holes. Sometimes it means asking it to steelman a bad approach before I throw it out. Rarely does it mean just dumping code and waiting.

One More Thing

These patterns didn't come together overnight. They came from a lot of failed prompts, a lot of confidently-wrong AI answers, and a lot of "wait, why did that work?" moments.

If any of this resonates, I put together a prompt playbook with the full set of patterns I now use across debugging, code review, and architecture decisions — you can grab it at https://gumroad.com/l/nhltvo.