DEV Community: The AI Leverage Weekly

The AI Workflow That Saved Me From a Debugging Spiral (And How to Replicate It)

The AI Leverage Weekly — Mon, 18 May 2026 09:00:39 +0000

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.

5 Things I Learned About AI-Assisted Engineering This Week (and 1 That Backfired)

The AI Leverage Weekly — Fri, 15 May 2026 09:00:55 +0000

It was a week of experimenting with AI in real workflows — not demos, not toy projects, actual production code. Here's what stuck.

1. The prompt pattern matters more than the model

I spent most of the week validating this. Swapping models with a mediocre prompt gives mediocre results. A tight, structured prompt on a weaker model often beats a lazy prompt on a frontier one. The framing is the work.

2. Refactors are the best use case nobody talks about

Everyone focuses on greenfield generation. But handing AI a gnarly legacy function with a clear "here's what it does, here's what it should do, here's the constraint" prompt is where you get the real time savings. A task that looks like a 3-day slog can collapse into hours if you nail the context window.

3. AI doesn't replace code review — it changes what you're reviewing for

You stop catching typos and start catching logic. That's actually a better use of a senior engineer's brain. Let the machine handle the syntactic noise.

4. Piping AI into your existing CLI tools is underrated

Not everything needs a chat interface. Wrapping a prompt pattern into a shell script or a Makefile target means your whole team gets the benefit without changing their workflow. Low friction = high adoption.

5. ❌ The one that backfired: using AI to write tests first

I tried feeding AI a feature spec and asking it to generate tests before the implementation. The tests were coherent but subtly wrong — they tested the assumed behavior, not the correct behavior. It created a false sense of coverage. Writing the implementation first, then using AI to expand test cases, worked much better.

The throughline this week: AI in engineering is a workflow design problem, not a tool-selection problem. How you structure the interaction — the order, the constraints, the context — determines whether you get a 10x or a 0.5x.

If you want the specific prompt patterns behind the refactor approach I kept referencing, I've packaged them (along with the workflow structure) into a concise playbook: grab it here.

More next week. Stay concrete out there. 🛠️

How I Cut a 3-Day Refactor Down to 4 Hours Using a Single AI Prompt Pattern

The AI Leverage Weekly — Wed, 13 May 2026 09:00:28 +0000

How I Cut a 3-Day Refactor Down to 4 Hours Using a Single AI Prompt Pattern

Last quarter I inherited a 4,000-line Node.js service — no tests, inconsistent error handling, callbacks mixed with promises. My estimate to the team: 3 days minimum.

I finished in 4 hours. Here's exactly what I did differently.

The Setup

The service was a payment webhook handler. Spaghetti, but well-defined inputs and outputs — I knew what "correct" looked like. That constraint matters for what came next.

The Prompt Pattern That Changed the Work

Instead of asking AI to rewrite the file (which produces confident garbage), I used a constraint-first decomposition prompt:

Context: I have a Node.js webhook handler, ~400 lines, mixed callbacks/promises,
no error boundaries. I cannot change the function signatures — external callers depend on them.

Task: Identify the 5 highest-risk sections I should refactor first, ranked by:
1. Likelihood of silent failure
2. How much other code depends on it

For each section, give me: the specific anti-pattern, a one-paragraph explanation of the risk,
and a before/after snippet using async/await. Do not refactor anything outside those 5 sections.

That last line — "do not refactor anything outside those 5 sections" — is the key. It forces the model to act like a scoped reviewer, not an eager rewriter.

What Came Out

The model returned five ranked sections with concrete snippets. Two of them I already suspected. Three I had missed entirely — one was a .catch() that silently swallowed a database timeout and returned a 200 to Stripe anyway. That bug had been in production for months.

I ran each suggested change independently, verified behavior, committed. No big-bang rewrite. No merge conflict nightmare.

The Numbers

Metric	Before	After
Estimated time	3 days	—
Actual time	—	4 hours
Test coverage	0%	74% (added alongside)
Silent failure points found	2 (known)	5 (3 new)

What Made It Work

Constraints in the prompt — scope prevents hallucinated rewrites
Explicit ranking criteria — "likelihood of silent failure" gets better output than "what's bad"
Incremental commits — treated each AI suggestion as a PR, not a paste job

The difference isn't the AI. It's the prompting discipline. Most developers throw a file at a model and hope. Giving it a job description with guardrails is a different skill — and it compounds fast once you have a small library of patterns like this one.

If you want the full set of prompt patterns I've built around legacy code, reviews, and debugging, I've packaged them up here: AI Prompt Playbook for Developers.

How I Use AI to Cut My Code Review Prep Time in Half (Step-by-Step)

The AI Leverage Weekly — Mon, 11 May 2026 22:55:40 +0000

Code review is one of those tasks that looks passive but drains you fast. You're context-switching between your own work and someone else's mental model, trying to be thorough without being slow. I started using AI as a first-pass review layer a few months ago, and it's changed how I approach the whole process.

Here's exactly how I do it — copy-paste ready.

The Problem With "Just Reading" a PR

When you open a PR cold, you're doing three things at once:

Building a mental model of what changed and why
Spotting logic errors, edge cases, and style issues
Thinking about downstream effects (tests, dependencies, API contracts)

Most of us do all three simultaneously, which means we do all three worse. AI doesn't replace your judgment — but it handles the scaffolding so you can focus on the things only you can catch.

Step 1: Dump the Diff Into Context

Start by copying the raw diff from the PR. Most platforms (GitHub, GitLab) have a "view file" or copy-paste friendly diff view. Grab the relevant files — don't paste everything if the PR is large; focus on the files with real logic changes.

Then open your AI assistant of choice (ChatGPT, Claude, Cursor, etc.) and use this prompt:

You are a senior software engineer doing a thorough code review.

Here is a diff from a pull request:

<paste diff here>

Do the following:
1. Summarize what this code is doing in 3-5 sentences.
2. List any logic errors, missing edge cases, or potential bugs.
3. Flag anything that could cause a regression or break an existing contract.
4. Note any readability or maintainability issues worth raising.

Be direct. Skip praise. If something looks fine, just say so.

The "skip praise" instruction matters more than it sounds. Without it, you get a lot of "Great use of early returns here!" filler before the actual issues.

Step 2: Check for Missing Tests

After the logic review, I run a second pass specifically on test coverage. This is separate on purpose — mixing it into the first prompt usually results in the model being too vague about both.

Given this diff and the summary you just provided, what test cases are missing or underdeveloped?

Consider:
- Happy path
- Edge cases (empty input, null values, boundary conditions)
- Error handling and failure modes
- Any async or concurrency concerns if applicable

List each missing test as a one-liner describing what it should verify.

This gives you a concrete checklist you can paste directly into your review comment as suggestions. Reviewees love it because it's specific, not just "needs more tests."

Step 3: Write Your Opening Review Comment

This is the underrated one. A good opening review comment sets the tone and saves everyone time. I use AI to draft it based on the findings:

Paste the AI's summary + issues back in
Ask it to write a 3-4 sentence opening comment that's direct and constructive
Edit it to sound like you (takes 30 seconds)

Total time for steps 1–3: about 5–7 minutes per PR, vs. 20–30 minutes of unstructured reading.

A Few Things That Actually Matter

Context is everything. The more you tell the model about the codebase conventions, the better the output. I keep a short "codebase context" snippet I prepend to reviews for repos I work in frequently — things like "we use Result types instead of throwing exceptions" or "all API responses are paginated."

Don't skip your own read. AI misses things that require understanding the business logic or team history. Use it to handle the mechanical layer, then do your own read with that scaffolding already in place.

Iterate the prompts. The first time you try these, the output will be 70% useful. After you've tuned your prompts to your stack and team conventions, it's closer to 90%.

The Habit Loop

Once this becomes a habit, you stop dreading large PRs. The cognitive cost of "starting" drops significantly when you know your first move is just pasting a diff and running a prompt.

I do this for my own code too before I open a PR — catching things myself before review has probably saved me more embarrassment than I'd like to admit.

If you want to go deeper on this workflow, I put together a prompt playbook that covers code review, debugging sessions, sprint planning, and a few other high-leverage engineering workflows — you can find it at https://gumroad.com/l/nhltvo.

How I Use AI to Cut My Code Review Prep Time in Half (Step-by-Step)

The AI Leverage Weekly — Mon, 11 May 2026 13:31:18 +0000

Code review is where a lot of engineering time silently disappears. You open a PR, context-switch from whatever you were doing, try to hold the whole diff in your head, and write comments that are either too vague to be useful or so detailed they take 20 minutes to type. AI can compress a big chunk of that — but only if you're deliberate about how you use it.

Here's the exact workflow I follow before and during code reviews, with the prompts I actually copy-paste.

Step 1: Dump the diff into context

Before touching anything else, I pull the raw diff and paste it into my AI tool of choice (I use a mix of Claude and GPT-4o depending on context length).

Don't summarize it yourself first. Give it the raw diff and let the model build its own mental model. Summarizing before you prompt it biases the output toward your existing assumptions — which defeats half the point.

git diff main..feature-branch > /tmp/review.diff

Then paste the contents directly into the chat window. If it's a big PR, I split it by directory or logical chunk.

Step 2: Ask for a structured first-pass summary

The first prompt isn't about finding bugs. It's about orienting yourself fast so you can review intentionally instead of just reading line by line hoping something jumps out.

Copy-paste this:

You are a senior software engineer doing a code review. Here is a diff:

[PASTE DIFF HERE]

Give me:
1. A 3-sentence summary of what this change is doing
2. The top 3 areas I should focus my review attention on (e.g. error handling, concurrency, data validation)
3. Any immediate red flags (missing tests, hardcoded values, obvious logic gaps)

Be direct. Skip praise.

The "be direct, skip praise" line matters more than it sounds. Without it, you'll get a paragraph of "This looks like a well-structured change!" before anything useful.

Step 3: Probe for edge cases in specific functions

Once you've done a first human pass, go back to the functions that felt risky or complex. This is where AI earns its keep — it's fast at enumerating inputs you didn't think about.

Copy-paste this:

Here is a function from the PR:

[PASTE FUNCTION]

List every edge case and failure mode you can identify. For each one:
- Describe what input or condition triggers it
- Describe what goes wrong
- Suggest a one-line fix or mitigation

Assume the codebase is a production backend service with real users.

The "production backend with real users" framing shifts the output from academic to practical. You'll get things like "if this returns null and the caller doesn't check, you'll get a 500 on checkout" rather than "consider handling undefined."

Step 4: Draft your review comments

This is the step most people skip, but it's the highest-leverage one. Instead of writing comments from scratch, paste the issues you found and ask for concise, non-condescending phrasing.

I want to leave a code review comment about this issue: [describe issue].
Write 2 versions — one for a junior dev, one for a senior dev.
Keep both under 3 sentences. Be direct but collaborative in tone.

This alone has meaningfully improved my review relationships. It's easy to sound harsh when you're in a hurry. Having two options lets you pick the one that fits the relationship.

Step 5: Final sanity check before approving

Before I hit "Approve," I do one last prompt:

Given everything we've discussed about this diff, what is the single most important thing I should verify manually before approving this PR?

This forces prioritization. You can't manually verify everything, but you can verify the one thing that matters most.

A few things this workflow is not

It's not a replacement for reading the code yourself. The AI misses things, especially around business logic it has no context for.
It's not for rubber-stamping. If the summary doesn't match what you expected the PR to do, that's a signal to dig in harder, not approve faster.
It's not magic. The quality of output is directly proportional to how specific your prompts are.

The biggest productivity unlock isn't any single prompt — it's having a repeatable process so you're not reinventing the approach on every review.

If you want more prompts like these across the full engineering workflow — planning, debugging, writing tickets, and more — I put together a prompt playbook I've been refining for a while: check it out here.

3 things that worked, 1 that didn't — my AI workflow experiments this week

The AI Leverage Weekly — Fri, 08 May 2026 13:29:35 +0000

Happy Friday. Week 0 of doing these roundups publicly. Let's see how it goes.

This week was mostly about figuring out where AI actually saves time in an engineering workflow versus where it just creates a convincing illusion of speed. Here's the honest tally.

✅ What worked

1. Using AI for the first draft of boilerplate, not the logic.
Generating scaffold code — config files, test stubs, README sections — is where I stopped fighting the output and started trusting it. The model doesn't need to understand your domain to write a Dockerfile or a pytest fixture skeleton. Ship the boring stuff fast, think harder on the real problems.

2. Prompt iteration as a debugging loop.
Treating a bad AI output like a failing test — rather than a reason to give up — changed everything. Reframe, constrain, give an example. Three rounds of that usually gets you somewhere useful. The mental model shift is: you're not asking, you're specifying.

3. Writing documentation before the code.
Sounds backwards but it works. Describe the function in plain English, hand it to the model, get a first implementation back. The doc becomes the spec. You catch ambiguity before it's baked into 200 lines of code.

❌ What didn't work

Letting AI "own" a refactor end-to-end.
I handed off a medium-complexity refactor with minimal checkpoints. The output was locally coherent and globally wrong — it made decisions silently that I would have caught immediately if I'd stayed in the loop. The lesson: keep the AI in a copilot seat, not the driver's seat, any time the task spans more than one file or abstraction layer.

The thread underneath all of this

Every win this week came from having a clearer mental model of the task before touching the AI. Every loss came from outsourcing the thinking. That's probably the pattern for a while.

If you want a structured version of these ideas — prompts, workflows, and checklists organized into a repeatable system — I've been packaging what actually works into a playbook: grab it here. No fluff, just the stuff I'd send a teammate.

See you next Friday. 🖤

How to Use AI as a Rubber Duck That Actually Pushes Back

The AI Leverage Weekly — Thu, 07 May 2026 05:04:30 +0000

Rubber duck debugging works because explaining a problem forces you to think clearly. AI can do the same thing — but better, because it asks follow-up questions.

Here's a workflow I use when I'm stuck on a design decision or a gnarly bug. Takes about 10 minutes and consistently gets me unstuck.

Step 1: Dump your context, not your question

Most people open ChatGPT and ask "how do I fix X?" That's too narrow. Instead, give full context first:

I'm working on [system/feature]. Here's what I'm trying to accomplish: [goal].
Here's what I've tried: [approach 1], [approach 2].
Here's where I'm stuck: [specific blocker].
Don't give me a solution yet. Ask me clarifying questions until you understand the problem fully.

That last line is the key. Forcing the model to interrogate you before answering surfaces assumptions you didn't know you were making.

Step 2: Answer its questions honestly

When it asks "what constraints are you working under?" or "what happens if you do X?" — actually answer. Don't shortcut to "just give me the answer." The back-and-forth is the point.

Typically 2–3 rounds of Q&A is enough.

Step 3: Ask for the devil's advocate take

Once you've landed on a direction, run this:

Here's the approach I'm leaning toward: [your plan].
Now argue against it. What are the top 3 reasons this is the wrong call?

This is where AI earns its keep. It'll surface edge cases, scalability concerns, or maintenance debt you glossed over. You don't have to agree with all of it — but you should be able to rebut each point.

Step 4: Synthesize a decision log entry

End the session with:

Summarize our conversation as a short architectural decision record (ADR):
- Context
- Decision
- Alternatives considered
- Consequences

Paste that into your PR description or Notion doc. Future-you (and your teammates) will thank you.

Why this works

The standard "explain this to me" prompt treats AI as a search engine. This workflow treats it as a thinking partner with an agenda: to stress-test your reasoning before you commit to it.

The difference in output quality is significant — especially for decisions that are hard to reverse.

If you want more structured prompts for engineering decisions, code reviews, and career conversations, I put together a playbook of them here: AI Prompt Playbook for Engineers. Practical, copy-paste ready, no filler.