Forem: Tal Vardi

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

Tal Vardi — 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.

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

Tal Vardi — Mon, 11 May 2026 09:00:31 +0000

Code review is one of those tasks that looks passive but actually demands a lot of mental context-switching. You're jumping between files, reconstructing intent, and trying to spot problems the author couldn't see. I started using AI as a first-pass layer before I open a PR — and it's changed how much headspace I have left for the review that actually matters.

Here's the exact workflow I use. Everything is copy-paste ready.

Step 1: Dump the diff into context

Before doing anything else, I grab the raw diff from the branch:

git diff main...feature/my-branch > /tmp/review_diff.txt

Then I open my AI tool of choice (I use Claude or GPT-4 depending on context length) and paste the diff in. Don't ask it anything yet — just load the context first. If the diff is huge, trim it to the files that matter most.

Step 2: Ask for a plain-English summary of intent

Most review friction comes from not knowing why a change exists. Start here:

Copy-paste prompt:

Here is a code diff. In 3-5 bullet points, summarize:
1. What this change is doing at a high level
2. Which components or modules are affected
3. Any assumptions the author appears to be making

Diff:
[paste diff here]

This takes about 10 seconds to run and gives you the mental model you'd normally spend 5 minutes building manually. I treat this output like a co-author's explanation before I read their PR description.

Step 3: Surface edge cases and missing tests

This is where AI genuinely earns its keep. After reading the summary, I ask:

Copy-paste prompt:

Based on this diff, identify:
1. Input edge cases that are not handled or tested
2. Any error paths that appear to be swallowed or ignored
3. Potential race conditions or state mutation issues
4. Missing test coverage (be specific about which functions or branches)

Focus on things a human reviewer might miss on a first pass.

Diff:
[paste diff here]

The key phrase is "things a human reviewer might miss on a first pass." Without it, you get surface-level feedback. With it, you tend to get the stuff that slips through.

Step 4: Run a consistency check against your team's patterns

If your codebase has conventions — naming, error handling style, logging patterns — you can paste a representative snippet alongside the diff and ask:

Compare the style and patterns in [EXISTING CODE SNIPPET] with [NEW DIFF].
List any inconsistencies in naming conventions, error handling, or logging approach.
Do not flag stylistic preferences — only deviations from patterns already established in the existing code.

This avoids the AI going rogue and flagging perfectly valid code that just doesn't match its training preferences.

Step 5: Generate your review comment drafts

Once you've identified real issues, AI is useful for drafting the actual comments — especially for sensitive feedback:

I want to leave a code review comment about the following issue: [describe issue].
Write a comment that is direct and specific, explains the risk, and suggests a fix or asks a clarifying question.
Tone: constructive, peer-to-peer. Max 3 sentences.

I almost never paste these verbatim, but they get me 80% of the way there and stop me from writing comments that are either too vague or accidentally harsh.

What this workflow actually looks like in practice

End-to-end, this takes me about 10 minutes before I open the PR in GitHub. I come in with:

A mental model of the change
A shortlist of specific things to probe
Draft comments for the tricky feedback

The review itself is faster and higher quality. I'm not wasting cycles on orientation — I'm spending them on judgment.

A few caveats

AI will hallucinate issues that don't exist. Treat the output as a checklist to verify, not a verdict.
Never paste proprietary code into public AI endpoints. Use local models or your org's approved tooling.
This workflow gets better the more you tune the prompts for your stack.

If you want more prompts like these organized by workflow — standup prep, architecture review, debugging sessions — I put together a prompt playbook that covers the ones I reach for most: check it out here.

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

Tal Vardi — 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

Tal Vardi — 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.