DEV Community: The AI Leverage Weekly

10 Prompts I Reach for Every Week to Stay Unblocked as an Engineer

The AI Leverage Weekly — Mon, 08 Jun 2026 09:00:48 +0000

10 Prompts I Reach for Every Week to Stay Unblocked as an Engineer

After five weeks of deliberately logging how I use AI during a normal engineering workweek, a clear set of patterns has emerged. Not the flashy demos — the quiet, repeatable ones that actually move work forward. Here are ten that have become muscle memory.

1. Translate a vague ticket into a scoped task list

Product tickets often arrive half-baked. Before I touch code, I paste the ticket text and ask:

You are a senior engineer helping me scope this ticket for implementation.
Given this ticket description: "[PASTE TICKET]"
Output: a numbered list of discrete technical tasks, any ambiguities I should clarify with product, and a one-sentence definition of "done".

This takes 90 seconds and saves hours of mid-sprint confusion.

2. Write the test before the implementation

I stopped writing implementation code first. Instead I describe the behavior and ask AI to write the test contract:

Write a unit test suite for a function called `applyDiscount(cart, couponCode)`.
It should cover: valid coupon, expired coupon, coupon with a minimum cart value not met,
and a cart with zero items. Use Jest. Do not implement the function — only the tests.

Having the test in front of me before I write a line of logic keeps the scope tight.

3. Generate the first draft of a PR description

Blank PR descriptions are a tax on your reviewers. I paste my diff summary and ask:

Given this list of changed files and a brief summary of what changed: [PASTE SUMMARY]
Write a pull request description with: a one-sentence summary, a bullet list of changes,
any areas reviewers should look at closely, and how to test it locally.

4. Rubber-duck a design decision with structured pushback

Instead of a normal rubber-duck session, I want pushback:

I'm deciding between [Option A] and [Option B] for [specific problem].
Here's my current thinking: [reasoning].
Push back on my preferred option. What am I missing or underweighting?

The forced devil's advocate framing produces better objections than a neutral "compare these two" prompt.

5. Explain an unfamiliar codebase section

When I land in a module I've never touched:

Explain what this code does, its likely inputs and outputs, any side effects,
and what could go wrong if someone modifies it without understanding it fully.
[PASTE CODE BLOCK]

6. Draft an incident postmortem outline

When an incident closes, the postmortem doc gets written under pressure. I paste the timeline and ask:

Given this incident timeline: [PASTE]
Draft a postmortem outline with: summary, timeline, root cause, contributing factors,
impact, what went well, what didn't, and action items with owners TBD.
Keep the tone factual and blameless.

7. Tighten a gnarly regex or SQL query

Rather than asking AI to write it from scratch, I show it what I have:

Here is a SQL query that's slow on large datasets: [PASTE QUERY]
Identify the likely performance bottlenecks and suggest a rewrite with explanation.

This pattern is one of the ones I've packaged into The AI Leverage Playbook: 50 Prompts & Workflows for Engineers — but the version above is enough to get value on its own.

8. Spot missing error handling

I've started running a dedicated pass for error handling before submitting any PR:

Review this function for missing or inadequate error handling.
List each case where an unhandled error could cause a silent failure, crash, or bad user state.
[PASTE FUNCTION]

The model catches edge cases I've mentally glossed over because I wrote the happy path first.

9. Write the runbook entry while the fix is fresh

Runbooks go stale because nobody writes them at the right moment. I do it immediately post-fix:

I just fixed this issue: [DESCRIBE ISSUE AND FIX IN 2-3 SENTENCES]
Write a runbook entry for on-call engineers. Include: symptoms, likely cause,
step-by-step remediation, and how to confirm it's resolved.

10. Turn a Slack thread into a decision log

Long Slack threads where decisions got made are black holes. I paste the thread and ask:

Summarize this Slack thread as a decision log entry.
Include: the question being decided, options that were considered,
the decision made, who made it, and the rationale.
[PASTE THREAD]

Three months from now, your future self will thank you.

The common thread

None of these are "write my code for me" prompts. Every one is about getting to clarity faster — tighter scope, better context, cleaner handoffs. The value isn't outsourcing thinking; it's compressing the parts of the job that drain time without demanding creativity.

Pick two of these to try this week. Keep the ones that stick.

I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. It goes out every Monday and each issue is one concrete workflow you can use the same day. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=long_w5

How We Shipped a Feature in 2 Days That Was Scoped for a Week (Week 4 Friday Roundup)

The AI Leverage Weekly — Fri, 05 Jun 2026 09:00:44 +0000

Week 4 is done, and I want to talk about one specific thing that happened on Tuesday — because the numbers are concrete enough to be worth documenting.

We had a feature on the board: a configurable notification dispatch system. PM estimated 5–7 days given the surface area — schema changes, a new service layer, three integration points, and test coverage. The kind of ticket that sits in sprint planning while everyone quietly dreads it.

We shipped a working version in 2 days and 3 hours.

Here's what actually changed: I stopped treating AI as a code autocomplete tool and started using it as a design-pressure machine. Before writing a single line, I fed the requirements doc and our existing service patterns into the model and asked it to surface design contradictions and edge cases I should resolve before coding. It returned 11 questions. Seven of them were things I'd have hit mid-implementation and had to unwind. Two of them would have caused rework after QA.

Resolving those upfront — on paper, not in code — saved an estimated 6–8 hours of the kind of debugging that feels productive but isn't.

The rest of the time savings came from what I wrote about earlier this week: using AI to stress-test the engineering assumptions baked into our pipeline. Once you start treating your toolchain as a thing that can be interrogated rather than trusted, you move faster because you're not finding out at 4pm that your CI config has a silent assumption baked in from 2021.

Two articles this week explored different sides of this: one looked at the day-to-day mechanics of where AI actually earns its place in a normal workday, and the other was about what happens when you point it at your infrastructure and it exposes fragility you didn't know was there.

The through-line: AI is most useful when you use it before the problem is fully formed, not after you're already in the weeds.

That's the pattern worth repeating.

I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=roundup_w4

AI Won't Replace Your DevOps Pipeline — But It Will Expose How Fragile It Is

The AI Leverage Weekly — Wed, 03 Jun 2026 09:01:08 +0000

AI Won't Replace Your DevOps Pipeline — But It Will Expose How Fragile It Is

Here's a take I'll defend: the most valuable thing AI tooling has done for DevOps isn't automation. It's diagnosis. And most teams aren't ready for what it reveals.

When you start feeding your CI/CD configs, runbooks, and incident postmortems into an LLM and asking it to reason about them, you don't get magic pipelines. You get a mirror. And the reflection is usually uncomfortable.

The Real Problem AI Surfaces

Fragile pipelines survive on tribal knowledge. Someone on your team knows that the deploy job silently retries three times before it emails anybody. Someone else knows that the staging environment health check lies. That knowledge lives in Slack threads and people's heads — not in your tooling.

AI doesn't "just work" when that context is missing. You paste in your GitHub Actions YAML and ask it to diagnose a flaky test stage and it asks you questions you should already have answers to:

What does this retry block actually retry on?
Is this a transient network issue or a test environment issue?
Where does this failure get surfaced and to whom?

Those aren't AI limitations. Those are gaps in your documentation and your observability.

A Concrete Example

Here's a prompt pattern that's been useful for surfacing exactly this:

You are a senior SRE reviewing a CI/CD pipeline for operational risk.
Here is our [GitHub Actions / GitLab CI / Jenkins] config: [PASTE CONFIG]
Here is our last 5 incident summaries: [PASTE SUMMARIES]

Identify:
1. Single points of failure that aren't documented
2. Implicit assumptions baked into the pipeline
3. Alert or notification gaps
4. Any step where a silent failure is possible

For each finding, explain WHY it's a risk, not just that it is one.

Run this and you will get a list. Some of it will be obvious. Some of it will stop you cold because you'll realize you knew it was a problem and never wrote it down.

The Opinion Part

Teams that treat AI as a pipeline automation layer are going to be disappointed. Teams that treat it as a forcing function for operational clarity are going to come out ahead.

The pipeline doesn't get smarter because you added AI. Your understanding of the pipeline gets sharper — and that's what actually reduces incidents.

If your DevOps practice can't be described clearly enough for an LLM to reason about it, that's not an AI problem. That's a documentation and observability debt problem that was always there. AI just stopped letting you ignore it.

8 Concrete Ways I Use AI During a Normal Engineering Workday (Week 4 Roundup)

The AI Leverage Weekly — Mon, 01 Jun 2026 09:00:49 +0000

Most AI productivity advice stays abstract. "Use AI to write better code." Great. How? Here are 8 specific, copy-paste-ready patterns I actually used this past week — each one self-contained, each one with a real return on time.

1. Pre-meeting context dumps

Before any technical sync, I paste the relevant PR diff or ticket description and ask: "Summarize the open questions and likely points of contention in this change." Takes 30 seconds. Means I'm never the person staring blankly when someone asks about edge cases.

2. Rubber-duck debugging with a forcing function

Instead of describing the bug, I describe what I expect to happen and what's actually happening — then ask the model to list every assumption I'm making that could be wrong. This forces me to be precise, which often surfaces the bug before the response even arrives.

3. Generating the test matrix I'd skip writing myself

After writing a function, I paste it and ask:

Given this function, list every test case worth covering — including edge cases,
boundary conditions, and failure modes. Format as a numbered list.
No code yet, just the cases.

I probably write 2–3 tests. This surfaces 7–10. I pick the ones that matter.

4. Turning code review comments into patterns

When I leave a review comment I've left more than twice, I paste it into the model and ask: "Turn this into a reusable code review heuristic I can document for my team." Slowly building a team-specific style guide without scheduling a meeting about it.

5. Translating dense documentation into working examples

When I hit library docs that are technically correct but practically useless, I paste the relevant section and ask:

I'm using [library] to do [specific thing]. Here's the relevant docs section:

[paste]

Give me a minimal, working code example that does exactly [X]. Use real values,
not placeholders. Point out any gotchas the docs don't mention.

This works especially well for authentication flows, SDK quirks, and anything involving async behavior.

6. First-draft commit messages from diffs

I paste the staged diff and ask for a conventional-commit-format message with a one-line summary and a 3-bullet body. I edit it, but starting from something beats starting from a blinking cursor every time.

7. Pressure-testing architecture decisions before you write them up

Before I write a design doc section, I describe the approach and ask: "What are the strongest objections a skeptical senior engineer would raise against this?" The model is good at steelmanning. I'd rather get the objections here than in the doc review.

This pattern is one of the ones I've packaged into The AI Leverage Playbook: 50 Prompts & Workflows for Engineers — but the version below is enough to get value on its own.

Here's the full prompt I use:

I'm proposing the following architecture decision: [describe it in 2-4 sentences].

Play the role of a skeptical senior engineer who cares about operational complexity,
maintainability, and failure modes. List your top 5 objections, ranked by severity.
Be specific, not generic.

The output gives me a sharper doc and surfaces assumptions worth defending explicitly.

8. End-of-day knowledge capture

The one that took me longest to build into a habit: before I close my editor, I spend 3 minutes asking the model to help me summarize what I learned or decided. I paste any relevant context and use:

"Based on this work, what are 2–3 things worth writing down so I don't have to re-derive them next time?"

These go into a running notes file. Six months from now, that file is worth more than any tutorial.

The common thread

None of these replace judgment. They all reduce the cost of applying judgment — less friction between "I should do this thing" and actually doing it. That's the lever worth pulling.

The patterns that stick aren't the flashy ones. They're the ones that fit inside work you're already doing, take under a minute to set up, and make the next hour measurably less annoying.

How a 20-Minute AI Audit Caught a Bug That 3 Senior Devs Missed (Week 3 Roundup)

The AI Leverage Weekly — Fri, 29 May 2026 09:00:56 +0000

Week 3 is in the books, and one theme kept surfacing in everything I worked on: AI is a multiplier on the quality of your attention, not a replacement for it.

Let me get specific.

Mid-week, a teammate flagged a race condition in a payment processing module that had been in production for ~8 months. Three senior engineers had reviewed that code across two separate PRs. None of them caught it. Not because they weren't good — they were looking at 400-line diffs under deadline pressure.

I ran a focused AI audit session: pasted the relevant module (~120 lines), gave it the execution context (async queue, Postgres advisory locks, retry logic), and asked it to reason through every state transition where two concurrent workers could touch the same row. Four minutes later it had flagged the exact window — a gap between the lock acquisition check and the write — with a plain-English explanation of how it would manifest under load.

Total time from "let's look at this" to confirmed root cause: 22 minutes. Previous attempts had burned roughly 2.5 hours across two engineers without a resolution.

The outcome: we patched it before the next deploy, and our error rate on that queue dropped from ~0.3% to effectively zero over the following 48 hours.

What made the difference wasn't the AI being smarter than those engineers. It was the framing. Narrow scope, explicit execution context, a specific question about state transitions — not "hey review this code." That's the thing I wrote about earlier this week: judgment is the irreplaceable ingredient. The tool does exactly as much as your prompt asks of it.

A few other threads I pulled on this week:

Structured prompts for untangling legacy auth logic (specificity beats brevity every time)
Why treating AI like a search engine is the wrong mental model — and what to do instead
The compounding effect of building small, reusable prompt patterns vs. one-off asks

The throughline: AI tools surface what you already know how to look for, faster. The engineers who get the most out of them aren't the ones with the fanciest setups — they're the ones who ask the sharpest questions.

Your AI Tools Are Only as Good as Your Judgment — And That's the Point

The AI Leverage Weekly — Wed, 27 May 2026 00:00:26 +0000

There's a quiet anxiety spreading through engineering teams right now: Am I becoming dependent on AI? Is my judgment atrophying?

My take: that's the wrong question. The right one is whether you're using AI in a way that sharpens your judgment or replaces it. Those are genuinely different modes of use, and most engineers drift into the second one without noticing.

The Dependency Trap Is Real — But Misdiagnosed

The common critique is that AI tools make engineers lazy. I don't think that's it. The problem isn't laziness — it's abdication. When you accept a generated solution without interrogating it, you're not saving time. You're deferring a debt that compounds interest.

The engineer who copy-pastes an AI-generated auth middleware without reading it isn't moving faster. They're moving faster now and slower — much slower — when that middleware silently fails in a production edge case at 2am.

But here's where I'll stake the actual opinion: the solution isn't to use AI less. It's to use it adversarially.

Adversarial Use, Concretely

What does adversarial use look like? You treat the AI output as a first draft from a smart-but-overconfident junior engineer. You don't reject it reflexively and you don't accept it wholesale. You interrogate it.

Here's a prompt pattern I've baked into my actual workflow:

Here's the solution you proposed: [paste output]

Now argue against it. What are the edge cases this doesn't handle? 
What assumptions did you make that might not hold in a production system? 
What would you change if you knew this code would be read by a senior 
engineer in a security audit?

Run that after any non-trivial AI-generated solution. What comes back is almost always useful — missed error states, implicit assumptions about input shape, security surface area that got glossed over. And critically: you are now thinking alongside the tool, not just consuming its output.

That loop — generate, interrogate, revise — is where judgment lives. It's where you stay sharp.

The Real Skill Isn't Prompting

The engineers who will be dangerous with AI five years from now aren't the ones who have memorized the best prompt templates. They're the ones who can look at any generated output — code, architecture diagram, spec, test suite — and immediately ask the right skeptical questions.

That skill is built by practice. Adversarial prompting is one way to practice it deliberately rather than accidentally.

AI doesn't erode engineering judgment. Passive AI use does. The distinction matters, and it's entirely within your control.

I break down one concrete AI workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=medium_w3

How I Used AI to Untangle a Legacy Service I'd Never Touched Before

The AI Leverage Weekly — Mon, 25 May 2026 09:01:16 +0000

How I Used AI to Untangle a Legacy Service I'd Never Touched Before

Three weeks ago I got handed a support escalation involving a service I'd never opened before. It was a Node.js microservice, about four years old, written by two engineers who had both since left the company. No meaningful README. Tests that hadn't run in CI for months. A Slack thread full of "this thing is a black box" going back two years.

The bug was real and customer-facing. I had one day to get a handle on it.

The Situation

The service sat between our API gateway and a third-party fulfillment provider. Something in the request transformation logic was intermittently dropping fields — but only under a specific combination of request shape and load. The output was wrong. The logs were unhelpful. The code was 3,200 lines across 14 files, and the logic was split between three layers of middleware with no clear separation of concerns.

I've been in this position before. Normally it means a half-day of console.log-driven archaeology before you even have a theory worth testing.

This time I tried something different.

What I Tried First (And Why It Wasn't Enough)

My first instinct was to paste the main handler into an AI chat and ask "what does this do?" That gave me a surface-level summary — not wrong, but not useful. It told me what the code said, not what it meant in the context of our system.

The problem with treating AI like a reader is that it reads what you give it. If you give it one file without context, it gives you one file's worth of insight.

The Shift: Giving It a Job Instead of a Question

The prompt pattern that actually unlocked the service for me was treating the AI as a new engineer joining the team, not a search engine. I fed it the core files in sequence and gave it a specific role with a specific goal:

You are a new backend engineer joining this team. I'm going to show you the core files of a legacy microservice one at a time. After each file, update a running list of:
1. What this file is responsible for
2. Any assumptions or implicit contracts you can see
3. Questions you'd want answered before touching this code

Do not summarize the code. Identify the load-bearing logic and flag anything that looks fragile.

After three files, it had surfaced something I'd glossed over: a field transformation function that silently returned undefined when the input didn't match an expected shape — no error, no log, just a missing field downstream. That was the bug. It had been in the codebase for four years.

Turning Understanding Into a Fix

Once I had the theory, I used a second prompt to pressure-test it before writing a single line of fix code:

Here is the function I believe is causing a silent field drop:

[paste function]

The upstream input looks like this:

[paste example payload]

Walk me through every code path in this function. For each path, tell me what the output would be and whether any field could be silently dropped or coerced to undefined. Flag the path you think is most likely to cause intermittent failures under load.

It walked through five code paths, flagged two that could produce undefined, and correctly identified the one tied to our intermittent failure pattern.

This pattern — role-first, file-by-file, output structured as questions not summaries — is one of the ones I've packaged into The AI Leverage Playbook: 50 Prompts & Workflows for Engineers — but the version above is enough to get value on its own.

What This Looked Like End-to-End

Total time to root cause: ~90 minutes (vs. my usual half-day minimum for unfamiliar code)
Files I had to read manually: 4 out of 14
Lines of fix code: 11
Test I wrote after: 1 regression test, also AI-assisted

The key wasn't the AI doing the work. It was the AI acting as a structured thinking partner while I retained ownership of the diagnosis. I still had to read the code. I still had to make the call. But I stopped thrashing.

The Takeaway

If you're dropped into unfamiliar legacy code, don't ask AI to explain it. Give it a role, feed it files incrementally, and ask it to maintain a running model of the system — including what it doesn't know. That output is far more useful than a summary.

The same pattern works for onboarding onto a new codebase, doing pre-refactor reconnaissance, or writing documentation after the fact.

The full set of prompts for situations like this — legacy code archaeology, debugging, refactor planning, test design — is in The AI Leverage Playbook: 50 Prompts & Workflows for Engineers. 50 prompts, $19. It covers code review, debugging, sprint planning, ADRs, and more — organized so you can grab the right prompt for whatever situation you're actually in.

7 AI-Assisted Engineering Habits Worth Stealing (Week 2 Roundup)

The AI Leverage Weekly — Fri, 22 May 2026 09:00:50 +0000

It's been a dense week. Between working through a gnarly debugging spiral and rethinking how we run sprint planning, a few patterns kept surfacing — things that actually moved the needle versus things that just felt productive. Here's what landed.

1. Give AI the error and the context, not just the stack trace.
A stack trace alone gets you generic answers. Paste in the surrounding code, your assumptions, and what you already tried. The output quality jumps immediately.

2. Treat your AI prompt like a ticket, not a search query.
Vague input → vague output. Write it like you'd write a Jira ticket: background, constraints, acceptance criteria. It takes 30 extra seconds and saves 10 minutes of back-and-forth.

3. Use AI to stress-test your own thinking before you ship.
Before opening a PR, ask: "What are the three most likely failure modes in this code?" You'll catch things code review misses because reviewers assume you already thought about them.

4. Sprint planning works better when AI does the first draft.
Instead of opening a blank Confluence doc and staring at it, dump your ticket titles and goals into a prompt and let AI scaffold the plan. You edit down, not up. Way faster.

5. Ask for the boring version first.
When generating boilerplate, tests, or docs — ask for the most conventional, straightforward approach. You can always push for creative solutions once the baseline exists.

6. One prompt per problem. Don't chain requests in the same message.
Mixing "refactor this" with "add tests" with "update the docs" in one prompt splits attention and degrades output. One job, one prompt.

7. Save the prompts that work. Seriously, just save them.
Most engineers run a great prompt once and never use it again. A plain text file, a Notion page, anything — it compounds fast.

The debugging and sprint planning themes from earlier this week both trace back to the same root: AI is only as useful as the structure you bring to it. Garbage in, garbage out still applies — it's just faster now.

The full set of patterns I've been building on is in The AI Leverage Playbook: 50 Prompts & Workflows for Engineers — 50 prompts across code review, debugging, refactoring, sprint planning, ADRs, and test design. $19 at https://gumroad.com/l/nhltvo?utm_source=devto&utm_medium=article&utm_campaign=roundup_w2. Stop reinventing the prompt every time.

How AI Shaved 6 Hours Off Our Sprint Planning Meeting (With One Prompt)

The AI Leverage Weekly — Wed, 20 May 2026 09:01:23 +0000

Sprint planning used to eat our Wednesday mornings alive. For a 6-person team, we were consistently spending 3–4 hours just to scope and assign a two-week sprint — ticket by ticket, estimation poker, re-reading half-written Jira descriptions, relitigating scope that should've been settled in refinement. Last quarter, I ran an experiment to fix it. The result cut that meeting to under 90 minutes.

The Problem (Specific)

Our tickets came into planning half-baked. Engineers were reading acceptance criteria cold, asking clarifying questions that burned 10 minutes per story, and pointing wildly because nobody had a shared mental model of the work. The PM wrote the tickets; the engineers read them for the first time in the meeting. Classic.

The Experiment

I started pre-processing every ticket the night before planning with a single prompt pattern. Here's the actual prompt I used:

You are a senior software engineer reviewing a backlog ticket before sprint planning.

Ticket title: [TITLE]
Description: [PASTE FULL TICKET TEXT]

Do the following:
1. Summarize the goal in one sentence (engineer-facing, not PM-facing).
2. List the top 3 implementation risks or open questions.
3. Suggest a story point estimate (Fibonacci) with a one-line rationale.
4. Flag any missing acceptance criteria.

I ran this against every ticket in the candidate backlog — usually 20–25 stories — the evening before planning. Took about 25 minutes total.

What Happened

The outputs weren't perfect, but they were good enough to reframe the whole meeting. Instead of reading tickets cold, engineers walked in with a pre-circulated doc (I just dumped the AI outputs into a Notion page) that gave everyone the same starting context.

Results over 6 sprints:

Average planning meeting length dropped from 3h 40m → 1h 25m
Estimation variance dropped noticeably — we stopped seeing the "1 vs 8 point" splits that indicated someone hadn't read the ticket
Two tickets per sprint on average got flagged for missing ACs before the meeting, which meant the PM could patch them in time rather than us parking the story mid-discussion

The AI didn't replace planning. It eliminated the tax of everyone getting up to speed in real time.

What Didn't Work

The model occasionally underestimated tickets that had non-obvious infrastructure dependencies — things it couldn't know without codebase context. I started appending a short "relevant system context" block to the prompt for complex stories, which helped. You have to treat the output as a first draft, not ground truth.

The Takeaway

The leverage here wasn't the AI writing the tickets or running the meeting. It was removing synchronous context-building from a synchronous meeting. That's a repeatable pattern: find the part of a meeting where everyone is just reading and processing, and do that async with AI beforehand.

The full set of prompts for sprint planning, plus debugging, code review, ADRs, and refactoring is in The AI Leverage Playbook: 50 Prompts & Workflows for Engineers. It's the exact toolkit I've built and refined over the last year. $19 at gumroad.com/l/nhltvo.

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.