DEV Community: The AI Leverage Weekly

The Best AI Prompts for Refactoring Legacy Code

The AI Leverage Weekly — Mon, 29 Jun 2026 09:00:47 +0000

The Best AI Prompts for Refactoring Legacy Code

Legacy code doesn't come with a manual. You inherit a function that's 300 lines long, has no tests, and the original author is long gone. You know it needs to change, but touching it feels like defusing a bomb blindfolded. AI tools won't rewrite your entire codebase for you — but with the right prompts, they dramatically shrink the time between "I don't understand this" and "I can safely change this." Here are the prompts I reach for, in the order I actually use them.

1. Start with a plain-English explanation of what the code does

Before you touch anything, you need to understand it. Paste the function or module and ask:

Explain what this code does in plain English. Describe:
1. Its purpose (what business problem it solves)
2. Its inputs and outputs
3. Any side effects or external dependencies
4. Edge cases it appears to handle
5. Anything that looks unusual or potentially buggy

Here is the code:
[paste code]

This gives you a mental model fast. Don't skip it — even if you think you understand the code, the AI often surfaces a side effect or edge case you glossed over.

2. Identify the smell before you prescribe the fix

Jumping straight to "refactor this" produces mediocre results. Instead, ask for a diagnosis first:

Review the following legacy code and list every code smell you can identify.
For each smell: name it, quote the specific lines involved, and explain why it's a problem.
Do not suggest fixes yet — just audit.

[paste code]

Getting a structured smell list forces the AI to slow down and reason about the code rather than produce a cosmetically cleaner version of the same mess.

3. Ask for a refactoring plan, not just refactored code

Once you have the smell list, ask for a sequenced plan before asking for any new code:

Given the code smells you identified, produce a step-by-step refactoring plan.
Order the steps from lowest risk to highest risk.
For each step, explain: what changes, why it's safe to do in isolation, and what could break.
Do not write code yet.

This is the prompt that saves the most time. A plan exposes assumptions you can challenge before you've committed a line of code. It also gives you natural stopping points if you're time-boxed.

4. Generate a characterization test suite before refactoring

Legacy code without tests is a minefield. Use the AI to generate "characterization tests" — tests that document current behavior, not ideal behavior:

Write a suite of unit tests for the following function that captures its current behavior exactly — including any behavior that looks wrong.
The goal is not to test correctness; the goal is to detect if refactoring changes the output.
Use [your test framework, e.g. Jest / pytest / RSpec].

[paste code]

Run these tests, commit them, and now you have a safety net. Any refactoring that breaks a test is a regression you need to understand before merging.

5. Refactor one smell at a time, not all at once

Now you're ready to change code. Do it incrementally:

Refactor ONLY the following problem from the code below: [name one smell from your list, e.g. "extract the nested conditional into a separate function"].
Do not change any other logic.
Show me the before and after side by side and explain every change you made.

[paste code]

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.

Scoping the prompt tightly is the key move. When you ask AI to "refactor everything," it over-reaches and introduces changes you didn't ask for, review, or understand. One smell per prompt keeps the diff reviewable.

6. Ask for a risk assessment on your final diff

Before you open the PR, paste your final diff and ask:

Review this diff. Identify any changes that:
- Could introduce a regression
- Change behavior in a way that isn't obvious from the variable/function names
- Should be covered by a test that doesn't exist yet

Be specific. Quote the lines you're concerned about.

Treat this like a second pair of eyes on your PR — one that reads every line without getting bored.

The sequence matters as much as the prompts

These six prompts are most effective in order: understand → audit → plan → safety-net → change → validate. Skipping steps (especially the characterization tests) is how you end up with a "refactored" codebase that breaks in production on an edge case nobody thought to test.

None of these prompts require a specific AI tool — they work with whatever assistant you're already using. The discipline is in the sequence, not the syntax.

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=long_w8

We Saved 6 Hours of QA Time This Week Using AI — Here's the Breakdown (Week 7 Roundup)

The AI Leverage Weekly — Fri, 26 Jun 2026 09:01:03 +0000

We Saved 6 Hours of QA Time This Week Using AI — Here's the Breakdown (Week 7 Roundup)

This week had a clear throughline: AI doing the tedious, time-consuming work that engineers hate but can't skip — and the numbers were actually surprising.

The Case That Made It concrete

Midway through the week, a service I was responsible for had a module with 23 functions, zero unit tests, and a refactor deadline approaching fast. Historically, writing that test suite from scratch would eat up most of a day — probably 5–6 hours of mechanical, low-satisfaction work.

Using an AI-assisted workflow to generate the test scaffolding function by function, I had a working first draft of the full suite in under 90 minutes. That's not a rounding error. That's the difference between shipping the refactor this sprint and punting it to the next one.

The output wasn't perfect — about 20% of the generated tests needed meaningful corrections, mostly around edge cases and mock setup. But starting from a structured draft instead of a blank file changed the whole shape of the work. I was reviewing and refining, not grinding.

The Other Half of the Week

The second major theme was debugging. A gnarly stack trace came in from a service in a part of the codebase I hadn't touched in months. The kind of error where you'd normally spend 45 minutes just reorienting yourself before you even start diagnosing.

Feeding the trace to an AI model with the right context got me to the probable root cause in one structured pass. Not magic — it still took judgment to confirm the fix — but the triage phase that usually burns the most time was compressed dramatically.

What the Week Actually Proved

These weren't toy examples or tutorials. Both were real work, under real time pressure. The pattern that held across both:

AI front-loads the structural work (scaffolding, triage, orientation)
Engineers handle the judgment layer (correctness, context, edge cases)
The split saves hours, not minutes

The engineers who are winning with AI right now aren't the ones with the cleverest prompts. They're the ones who've figured out exactly which part of their workflow to hand off.

How to Use AI to Debug a Stack Trace (Step-by-Step)

The AI Leverage Weekly — Wed, 24 Jun 2026 09:00:33 +0000

How to Use AI to Debug a Stack Trace (Step-by-Step)

You've got a wall of red text, a stack trace you don't fully recognize, and no obvious starting point. AI can turn that trace into a clear diagnosis and a fix — in under two minutes. Here's exactly how to do it.

Why Raw Stack Traces Are Hard to Parse Alone

Stack traces are dense. They mix your code with framework internals, third-party library frames, and sometimes async noise that obscures the actual origin of the error. The mental overhead of filtering signal from noise is where most debugging time gets wasted. AI is surprisingly good at this — not because it "knows" your system, but because it can pattern-match against thousands of similar traces and explain each layer in plain language.

Step 1: Copy the Full Stack Trace — Don't Trim It

Resist the urge to paste only the top three lines. The root cause is often buried lower in the trace. Copy everything, including the error type, message, and every frame.

Step 2: Use This Prompt Template

Open your AI assistant (ChatGPT, Claude, Gemini — any capable model works) and paste this:

You are a senior engineer helping me debug a runtime error.

Here is the full stack trace:
---
[PASTE YOUR FULL STACK TRACE HERE]
---

Please do the following:
1. Identify the root cause of the error in plain English.
2. Pinpoint the exact line or frame where the error originates (not just where it surfaces).
3. Explain why this error occurs — what condition triggered it.
4. Suggest a concrete fix with a code example.
5. List any other places in a typical codebase where this same pattern might cause the same error.

That fifth point is the one most developers skip — and it's where you stop patching and start preventing.

Step 3: Add Context to Get a Sharper Answer

After the initial response, follow up with:

Here is the function where the error originates. Does this change your diagnosis?

[PASTE THE RELEVANT FUNCTION OR METHOD]

This two-pass approach — trace first, code second — gives the model enough context to go from "here's what's probably wrong" to "here's exactly what's wrong."

Step 4: Ask for a Reproduction Case

Write a minimal code snippet that would reproduce this error so I can verify the fix before applying it.

This forces the model to commit to a specific understanding of the bug. If the reproduction case doesn't match what you're seeing, you've caught a hallucination before it costs you time.

Step 5: Validate the Fix, Then Ask for a Test

Here is the fix I applied: [PASTE FIX]. Now write a unit test that would have caught this error before it reached production.

You've just turned a debugging session into a regression test — automatically.

What This Workflow Actually Gets You

A plain-English explanation you can share with a teammate or put in a PR description
A fix you can verify before applying
A unit test that closes the loop
A checklist of similar patterns to audit in the rest of the codebase

This entire flow takes five minutes once you have the prompt structure memorized.

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

How to Generate Unit Tests from a Function Using AI

The AI Leverage Weekly — Mon, 22 Jun 2026 09:01:20 +0000

You have a function, you need tests, and you're staring at a blank file. AI can generate a solid first draft of your unit test suite in under a minute — but only if you prompt it correctly. This walkthrough shows you exactly how to do it, step by step, with copy-paste prompts and real output patterns you can adapt immediately.

Why the Naive Prompt Fails

Most engineers start with something like "write tests for this function" and paste their code. The output is usually technically correct but shallow: happy-path only, no edge cases, no error conditions, no boundary values. It looks like coverage but isn't.

The fix isn't a fancier AI model — it's a better prompt structure.

Step 1: Frame the Function with Context

Before pasting code, tell the AI what the function is supposed to do, what it promises to callers, and what test framework you're using. One short paragraph of context doubles the quality of the output.

I have a TypeScript function that validates a user-submitted email address
before it's stored to the database. It should return true for valid emails
and false for invalid ones. I'm using Vitest with the `describe/it/expect`
pattern. No mocking is needed — the function is pure.

Here is the function:

[PASTE FUNCTION HERE]

Generate a comprehensive unit test suite. Cover: the happy path, boundary
cases (empty string, null, very long strings), malformed inputs
(missing @, multiple @, special characters), and any edge cases implied
by the implementation itself.

That last line — "edge cases implied by the implementation itself" — is the key instruction. It forces the model to read the actual logic rather than generating generic tests.

Step 2: Ask for a Test Plan Before the Code

For non-trivial functions, add one extra step: ask for the test plan first, review it, then ask for the implementation. This costs 30 seconds and catches gaps before they get baked into code.

Before writing any test code, list every test case you plan to cover for
the function above. Group them by: (1) valid inputs, (2) invalid inputs,
(3) boundary/edge cases, (4) error conditions. Use plain English, one
line per case. I'll confirm the list before you write any code.

Scan the list. You'll almost always spot a case the model missed — and more importantly, a case you would have missed too. Add it back in plain English before you proceed.

Step 3: Generate the Tests

Once the plan is approved, run the generation prompt:

Now write the full Vitest test suite based on the test plan above.
Requirements:
- One `describe` block named after the function
- One `it` block per test case, with a descriptive string that reads like a
  sentence ("returns false when the input is an empty string")
- No external dependencies or mocks unless the function requires them
- If any test case requires a fixture or factory, define it at the top of
  the describe block
- Add a one-line comment above any test that is non-obvious

The descriptive it strings matter. They're your documentation. When a test fails in CI at 2am, a string like "returns false when the input is an empty string" tells you exactly what broke without opening the file.

Step 4: Audit the Output for Coverage Gaps

Don't ship the AI output directly. Run this audit prompt against the generated suite:

Review the test suite you just wrote. Identify any of the following that
are missing or weakly covered:
1. Return value correctness (not just truthiness)
2. Side effects the function might have
3. Thrown exceptions or error types
4. Performance-sensitive paths (very large inputs)
5. Any assumption in the code that isn't tested

For each gap, either add a test case or explain why it's intentionally
excluded.

This is where the real value compounds. The model will often find its own blind spots when asked directly — things like checking the type of a return value, not just its truthiness, or confirming an exception has the right message, not just that it was thrown.

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.

Step 5: Parametrize Repetitive Cases

If the audit reveals many similar inputs that differ only in data, ask the model to refactor to a parametrized format:

Refactor any test cases that share the same assertion logic but differ
only in input data into a `it.each` table. Keep non-repetitive tests as
individual `it` blocks.

This cuts file length dramatically and makes it obvious when you need to add another row versus a whole new test.

The Full Prompt Order at a Glance

Context prompt — framework, function purpose, constraints
Test plan prompt — review before any code is written
Generation prompt — structured output requirements
Audit prompt — coverage gap check
Refactor prompt — parametrize repetitive cases

Working through all five steps for a typical utility function takes about 10 minutes. The result is a test suite that would have taken 45–60 minutes to write by hand — and usually has better edge case coverage than the manual version.

One More Tip: Anchor to Your Existing Test Style

If your codebase already has tests, paste one existing test file alongside your prompt and add: "Match the style, naming conventions, and structure of the example test file below exactly." The AI will mirror your patterns, which means the output requires almost no style cleanup before review.

I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. It's the fastest way to build a repeatable AI-assisted engineering practice. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=long_w7

How Switching AI Tools Mid-Sprint Cost Us a Day (And What We Learned) — Week 6 Roundup

The AI Leverage Weekly — Fri, 19 Jun 2026 09:01:06 +0000

This week's two pieces — one on writing better Git commit messages with AI, and one comparing Claude and ChatGPT for code review — were both born from the same messy sprint where I made a mistake that cost real time.

Here's what happened.

Midway through a feature branch, I switched from the AI tool I'd been using for code review to a different one, mostly out of curiosity. I wanted to test a head-to-head comparison in a live context rather than a synthetic one. The model switch was seamless. The workflow wasn't.

The new tool had a different "grain" — it flagged different things, used different idioms in its suggestions, and didn't carry any of the soft context I'd built up through earlier prompts in the session. I had to re-explain patterns we'd already established. I re-reviewed two files I'd already cleared. Net result: roughly a day's worth of focused review time became a day and a half, and I caught one genuine regression — a missing null check on an edge case — that I'm not confident the original tool would have caught.

So the lesson wasn't "tool X is better than tool Y." It was that consistency in tooling during a sprint has its own compounding value, and switching mid-flow carries a real context-switching cost that doesn't show up in any benchmark.

That framing fed directly into the commit message piece too. One thing I tracked this week: AI-assisted commit messages across 34 commits on two branches. Compared to my previous sprint's messages (which I still have in the log), the assisted ones averaged 2.1x longer, contained explicit "why" context in 79% of cases vs. ~20% before, and two of them directly prevented a "what did this change actually do?" question during a sync. Measurable. Mundane. Worth doing.

The throughline this week: AI tooling rewards deliberate, consistent workflows more than it rewards novelty. Picking the best tool matters less than building repeatable habits around whatever you pick.

Claude vs ChatGPT for Code Review: Which Is Better?

The AI Leverage Weekly — Wed, 17 Jun 2026 09:01:18 +0000

If you've Googled this, you've probably already used both and still aren't sure which one to trust with your actual codebase. Here's my concrete answer after running both through real code review workflows: they're good at different things, and picking the wrong one for the job costs you time. Here's exactly how to choose.

The Core Difference That Matters for Code Review

ChatGPT (GPT-4o) is faster and more conversational. It's excellent at quick back-and-forth — paste a function, ask a question, iterate. Claude (Sonnet or Opus) handles larger context windows more gracefully and tends to produce more structured, thorough analysis when you give it a full file or a diff.

That's not a vibe — it's a practical difference. On a recent project, I fed both models the same 400-line service file and asked for a review. ChatGPT flagged the most obvious issues quickly. Claude caught a subtle state mutation buried in a helper that was three function calls deep. Both missed things. But they missed different things.

Where ChatGPT Wins

Iterative, conversational review. You want to ask follow-ups like "why is that a problem?" or "show me a fix" — GPT-4o handles the dialogue better.
Short functions and isolated snippets. Fast, accurate, minimal friction.
Explaining unfamiliar patterns. "What is this doing and is it idiomatic?" — GPT-4o is strong here.

Where Claude Wins

Full-file or multi-file context. Claude doesn't degrade as badly at the edges of a long context. Feed it an entire module and it still reasons about the top of the file when reviewing the bottom.
Structured output. Ask Claude for a review in a specific format and it follows it reliably. Useful when you want output you can paste directly into a PR comment.
Security and logic review on complex code. In my experience, Claude surfaces more non-obvious issues on business-logic-heavy code — race conditions, incorrect assumptions about mutability, edge cases in conditional branches.

The Prompt I Actually Use (Copy This)

For any non-trivial code review, I use this with Claude:

Review the following code as a senior engineer doing a pull request review.
Structure your response as:
1. Critical issues (bugs, security, data integrity)
2. Design concerns (architecture, coupling, testability)
3. Minor improvements (naming, style, readability)
4. Questions I should answer before merging

Be specific. Reference line numbers or function names. Skip praise.

[paste code here]

The "skip praise" instruction is load-bearing — without it, both models pad their output with positive framing that buries the real findings.

My Honest Take

Stop treating this as a permanent either/or. Use ChatGPT for fast conversational review of small pieces. Use Claude when you're doing a serious pre-merge review of a whole module. The engineers who get the most out of AI code review aren't loyal to one model — they know which tool fits which context.

The instinct to pick a winner and stick with it is the same instinct that leads people to use a screwdriver as a hammer. Both tools exist. Use them correctly.

How to Write Better Git Commit Messages with AI

The AI Leverage Weekly — Mon, 15 Jun 2026 09:00:58 +0000

Bad commit messages are a tax you pay forever. You hit git log six months later and find a wall of "fix stuff", "WIP", "asdf", and "final final v2" — and now you're archaeologist instead of engineer. The good news: AI can eliminate this problem almost entirely, and in this walkthrough I'll show you exactly how to wire it into your workflow with copy-paste prompts you can use today.

Why Commit Messages Fail (And Why AI Actually Helps Here)

The root cause isn't laziness — it's timing. You write the commit message right after a long coding session, when your brain is fried and you just want to push. Context is all in your head, not on the screen.

AI flips this. You feed it the diff and your rough notes; it drafts a structured message. You edit for accuracy. Total time: 30 seconds. The output is consistently better than what most engineers write under pressure.

Step 1: Stage Your Changes and Generate a Diff

Before prompting, get a clean diff of what you're about to commit:

git diff --staged

Copy the output. If the diff is large (500+ lines), narrow it to the most meaningful files:

git diff --staged -- path/to/relevant/file.ts

You don't need to paste every line into the prompt — a representative slice plus a plain-English summary of your intent is enough.

Step 2: Use This Base Prompt

Paste this into your AI assistant of choice (ChatGPT, Claude, Copilot Chat, etc.):

You are a senior engineer helping me write a Git commit message.

Here is the staged diff:
<paste diff here>

My intent: <one sentence about what this change accomplishes and why>

Write a commit message using the Conventional Commits format:
- First line: type(scope): short imperative summary (max 72 chars)
- Blank line
- Body: 2–4 bullet points explaining WHAT changed and WHY, not HOW
- If there's a breaking change, add a BREAKING CHANGE footer

Output only the commit message, no commentary.

A real example output for a token-refresh bug fix might look like this:

fix(auth): prevent silent token refresh on expired session

- Remove automatic refresh call when session TTL has already elapsed
- Add explicit expiry check before calling refreshToken()
- Prevents a race condition that caused duplicate refresh requests
  under slow network conditions

That's immediately useful to the next engineer reading git log.

Step 3: Refine With a One-Line Follow-Up

If the first draft is close but not quite right, don't re-explain from scratch. Just correct the specific problem:

The scope should be "session" not "auth", and the first line
is too long — tighten it to under 60 characters.

AI handles surgical edits like this well. You're the reviewer; it's the first-draft writer.

Step 4: Build a Shell Alias for Speed

The friction of copy-pasting manually will kill this habit. Automate it. Add this to your .zshrc or .bashrc:

alias gcm='git diff --staged | pbcopy && echo "Diff copied. Paste into your AI prompt."'

On Linux, swap pbcopy for xclip -selection clipboard. Now your staged diff is on your clipboard in one command, ready to paste into any AI chat.

For teams using the GitHub CLI, you can go further and pipe directly into a script that calls an API — but the manual copy-paste habit alone will get you 80% of the value.

Step 5: Add a Linter to Enforce the Format

Writing good messages is only half the battle — the other half is making sure they don't regress. Add commitlint to your repo:

npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

Now any commit that doesn't follow Conventional Commits format gets rejected before it ever touches your branch. Pair this with the AI prompt above and the format issues go away almost entirely.

This prompt 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 real value on its own.

What Good Looks Like at Scale

Once this habit is set, your git log becomes actual documentation. You can:

Run git log --oneline to get a readable changelog for a release
Use git log --grep="fix(auth)" to find every auth-related fix without grepping source
Onboard new engineers by pointing them at commit history, not Confluence

The commit message becomes a first-class artifact, not an afterthought.

Quick Reference: The Prompt, One More Time

You are a senior engineer helping me write a Git commit message.

Diff:
<paste>

Intent: <one sentence>

Format: Conventional Commits. First line ≤72 chars, imperative mood.
Body: 2–4 bullets on what changed and why. BREAKING CHANGE footer if needed.
Output the commit message only.

Save that. Reach for it every time you're about to type "fix stuff."

We Cut Onboarding Time by 40% Using AI — Here's Exactly What We Did (Week 5 Roundup)

The AI Leverage Weekly — Fri, 12 Jun 2026 09:00:55 +0000

We Cut Onboarding Time by 40% Using AI — Here's Exactly What We Did (Week 5 Roundup)

This week's theme snuck up on me: AI as a knowledge transfer tool, not just a coding assistant.

It started with a practical problem. We had a new engineer joining a team that owned a gnarly 4-year-old backend service. No real docs. Tribal knowledge scattered across Slack threads and the heads of two people who'd since moved to other teams. Historically, getting someone productive on this service took 6–8 weeks. The first two weeks were basically lost — reading code, asking questions, getting lost again.

This time, we tried something different.

We spent about 3 hours upfront running the codebase through a structured AI-assisted audit. We asked it to map data flows, identify the non-obvious entry points, and flag the areas where the code didn't match what the surrounding comments implied it did. That last part alone surfaced 11 spots where the "how" and "why" had quietly diverged over years of patches.

From that, we generated a living onboarding doc — not a static README, but something structured around questions a new engineer will actually ask. Things like: "Why is this service the source of truth instead of the other one?" and "What breaks first when this queue backs up?"

The new engineer was opening meaningful PRs by the end of week two. That's a 40% reduction in ramp time compared to our baseline on the same service.

This connects directly to what I wrote about earlier this week. The piece on prompts I use to stay unblocked? Half of those exist because I got tired of losing hours to orientation problems — not knowing where to start, not knowing what I didn't know. AI doesn't fix confusion automatically, but it compresses the time between lost and oriented dramatically when you ask it the right questions.

The junior devs piece is the other side of this coin. Onboarding faster isn't cheating the learning process — it's front-loading the context so the actual learning can happen sooner. Juniors who use AI well aren't skipping the hard parts. They're getting to the hard parts faster.

That's the pattern I keep seeing: AI as a forcing function for knowledge that was always there but never made explicit.

Junior Devs Who Use AI Are Not Cheating — They're Training Smarter

The AI Leverage Weekly — Wed, 10 Jun 2026 09:01:14 +0000

Take: The engineering community's instinct to gatekeep AI tools from junior developers isn't protecting them — it's handicapping them.

I keep hearing some version of this: "Juniors should learn without AI first. Otherwise they won't actually understand anything."

I get the intuition. It rhymes with real advice — learn fundamentals before frameworks, understand SQL before ORMs. But this specific application is wrong, and it's worth pushing back on directly.

The "struggle builds understanding" argument doesn't hold here

Yes, productive struggle matters. Banging your head against a bug for an hour can teach you something that a quick answer never would. But that principle has limits.

The version of struggle that builds understanding is targeted — you're stuck on a concept, you work through it, something clicks. The version that doesn't build understanding is thrashing — you're stuck on a syntax issue, a poorly worded error message, or a gap in documentation that has nothing to do with the core concept you're trying to learn.

AI is exceptionally good at eliminating the second kind of friction. That's not a bug. That's the point.

A junior dev who uses AI to quickly unblock on a confusing TypeScript error message — and then spends the saved time understanding why the type system works the way it does — is learning better, not worse.

AI is a feedback loop, not a crutch

Here's the practical reality. When a junior developer writes a function and asks an AI to review it, they get:

Specific feedback on their actual code
Explanations tied to what they just wrote
Faster iteration on their mistakes

That's a better learning loop than most code reviews in most companies, which happen days later, are often surface-level, and rarely include pedagogical explanation.

The devs who will struggle aren't the ones using AI. They're the ones using AI without asking why — copy-pasting without reading, accepting output without testing. That's a habits problem, not a tools problem.

The concrete thing to teach instead

If you're mentoring a junior dev, don't tell them to avoid AI. Teach them this prompt habit:

Instead of: "Write me a function that paginate results from a database."

Use: "Write me a function that paginates results from a database, then explain each part of the implementation so I can understand the tradeoffs."

That single shift — demanding explanation alongside output — turns AI into a tutor instead of a vending machine. The understanding is still happening. It's just happening faster.

The gatekeeping instinct comes from a good place, but it's aimed at the wrong target. The question was never should juniors use AI. It's how do we help them use it well.

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.

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.