10 Prompts I Reach for Every Week to Stay Unblocked as an Engineer — The AI Leverage Weekly
← All posts<br>10 Prompts I Reach for Every Week to Stay Unblocked as an Engineer
2026-06-08
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.<br>Given this ticket description: "[PASTE TICKET]"<br>Output: a numbered list of discrete technical tasks, any ambiguities I should clarify with product, and a one-sentence definition of "done".
Enter fullscreen mode
Exit fullscreen mode
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)`.<br>It should cover: valid coupon, expired coupon, coupon with a minimum cart value not met,<br>and a cart with zero items. Use Jest. Do not implement the function — only the tests.
Enter fullscreen mode
Exit fullscreen mode
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]<br>Write a pull request description with: a one-sentence summary, a bullet list of changes,<br>any areas reviewers should look at closely, and how to test it locally.
Enter fullscreen mode
Exit fullscreen mode
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].<br>Here's my current thinking: [reasoning].<br>Push back on my preferred option. What am I missing or underweighting?
Enter fullscreen mode
Exit fullscreen mode
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,<br>and what could go wrong if someone modifies it without understanding it fully.<br>[PASTE CODE BLOCK]
Enter fullscreen mode
Exit fullscreen mode
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]<br>Draft a postmortem outline with: summary, timeline, root cause, contributing factors,<br>impact, what went well, what didn't, and action items with owners TBD.<br>Keep the tone factual and blameless.
Enter fullscreen mode
Exit fullscreen mode
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]<br>Identify the likely performance bottlenecks and suggest a rewrite with explanation.
Enter fullscreen mode
Exit fullscreen mode
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.<br>List each case where an unhandled error could cause a silent failure, crash, or bad user state.<br>[PASTE FUNCTION]
Enter fullscreen mode
Exit fullscreen mode
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]<br>Write a runbook entry for on-call engineers. Include: symptoms, likely cause,<br>step-by-step remediation, and how to confirm it's resolved.
Enter fullscreen mode
Exit fullscreen mode
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.<br>Include: the question being decided, options that were considered,<br>the decision made, who made it, and the rationale.<br>[PASTE THREAD]
Enter fullscreen mode
Exit fullscreen mode
Three months from now, your future self will thank you.
The common thread
None of these are "write my code for...