Welcome back. Your agent can write a feature in minutes, but you still spend the entire afternoon reviewing it. Multiply that across every PR, and code review quickly becomes the biggest bottleneck of your week. The Claude Code team has now solved this even with Claude writing 90% of their code.
Today, you’ll set up 3 workflows that catch more bugs while you read far less code.
Today’s Brief
How the Claude Code team and Uber review code now
Workflow #1: Prove an agent’s PR works
Workflow #2: Catch mistakes before the PR
Workflow #3: Save human review for risky code
DEEP DIVE
Click here to see how the Claude Code team does code review.
What changed? The Claude Code team no longer waits for a teammate to read every line. Agents review each PR first. Low-risk changes like docs merge without any human review. Standard changes need just one reviewer. High-risk code like billing requires two.
Uber uses a similar setup to clean up old code. They run four agents that each check one specific detail. Any change that fails gets thrown out before an engineer ever sees it.
To get started, open Claude Code and run “/code-review”. It checks your current branch and lists the bugs it finds right in your chat.
That’s the most basic version. Here are 3 more ways to level up your code reviews this weekend:
WORKFLOW #1: VERIFICATION
How to know an agent’s PR works without reading the code
Source: X.com/poteto
The agent says it’s done. The tests pass and the diff looks clean, so you merge it. Then you open the app, and the button it built doesn’t do anything, because nobody ever clicked it.
A Cursor engineer, Lauren Tan, says the fix is to give your agent a way to check its own work the way a real user would. The agent then hands you proof, like screenshots or a video, that’s faster to review than the diff. Her Cursor plugin, pstack, builds that checker for your project.
Here’s how you can implement it:
Step 1: Install pstack from Cursor’s chat:
/add-plugin pstackStep 2: Run this in your project. It asks a few questions, then builds a skill that lets the agent open and use your app.
/create-verification-skillStep 3: Give the agent a real task and tell it to use the new skill to prove the fix before it opens the PR:
Fix the search filter that resets when I change pages. Reproduce the bug first, then fix it, then attach screenshots from the running app. Do not open a PR until the proof is attached.Your opinion matters!
This is our sixth Saturday Special. It’s a quick 5 min email designed to show how to use the latest and most relevant AI tools to code faster. Let us know what you think of this email in the poll at the bottom of this email (or by replying to this email).
We’re writing this email just for you, so your feedback will shape what we write next!
WORKFLOW #2: PRE-PUSH GATE
How to catch an agent’s mistakes before they reach a PR
Source: X.com/kunchenguid
A former Meta engineer created an open‑source tool that catches issues before your agent’s code reaches a pull request. Instead of pushing directly to the origin, you push to the tool first.
The tool runs reviews, tests, linting, and continuous integration on a disposable clone of your repository. It automatically handles minor fixes itself.
Here’s how you can implement it:
Step 1: Install it on your Mac:
curl -fsSL https://raw.githubusercontent.com/
kunchenguid/no-mistakes/main/docs/install.sh | shStep 2: Inside your repo, run this command:
no-mistakes initStep 3: Commit your work, push your branch to the gate, then open the run to see what it found. When every check passes, it opens the PR for you.
git push no-mistakes
no-mistakesWORKFLOW #3: RISK TIERS
How to save human review for the code that can actually break
Addy Osmani, who works on Claude Code at Anthropic, sorts pull requests by the damage they could cause. Agents review every pull request first. Low-risk changes skip a deep human review once the agents sign off, while sensitive code always needs its owner’s approval.
You can set up the “always needs an owner” part on GitHub in just a few minutes.
Step 1: Create a CODEOWNERS file that lists your riskiest folders and who owns them. GitHub then asks those owners to review any PR that touches their folders.
# .github/CODEOWNERS
/billing/ @your-org/payments
/auth/ @your-org/security
/.github/ @your-org/platformStep 2: In Settings > Branches, add a rule for the main branch. Turn on “Require a pull request before merging.” Then enable “Require review from Code Owners.”
Also select “Do not allow bypassing” so that admins cannot skip the rule. After you apply these settings, pull requests cannot be merged until the owner approves them.
Step 3: Add a PR template so every author, human or agent, says how they tested the change and how to undo it:
mkdir -p .github && \
cat > .github/pull_request_template.md << 'EOF'
## Testing
## Risk (low, medium or high)
## How to revert
EOFFUN WEEKEND PROJECTS TO TRY
Have your agent write tests that prove your code never does the wrong thing, like refunding more than a customer paid (link).
Add one line to your CLAUDE.md that stops your agent from writing tests that just repeat the code (link).
Ask your agent to split big features into small PRs, so each one is short enough to actually review (link).
Get every AI-written PR to arrive with a video demo, a risk table and a checklist of what to test before you merge (link).
Use one prompt to scan your old review comments and find the mistakes your agent keeps repeating (link).
P.S. Here’s the Claude Code team’s full guide to how they review code.
TOP TOOLS FOR CODE REVIEW
CodeRabbit: An AI reviewer that leaves line-by-line comments and a summary on every pull request in GitHub or GitLab. You can teach it your team’s rules in plain English, and open-source repos pay nothing.
Greptile: It maps your whole codebase first, so its review agents catch bugs that reach beyond the diff. It also learns your team’s standards by reading your past PR comments, and it can send each issue straight to Claude Code, Cursor or Codex to fix.
PR-Agent: An open-source PR reviewer you run yourself, so your code stays on your own setup. Add it as a GitHub Action, then comment “/review” or “/improve” on any PR to get a review or suggested fixes.
STARTING POINT
How to start this weekend. By Sunday morning, you could have “/code-review” catching bugs on your branch, an agent that attaches screenshots to its PRs, and a gate that opens clean PRs for you. Once that works, lock your riskiest folders behind a code owner so human review only goes where it counts.
Whenever you're ready to dive deeper
If you enjoyed this newsletter, you should definitely check out our IT and cybersecurity newsletters. Subscribe using the links below:
We put together 20+ hands-on guides covering coding agents, agentic engineering, and leadership frameworks to help you level up your career. You can get them here.
Advertise with us: Join companies like Google, IBM, and Datadog. Showcase your product to our 350K+ engineers and 150K+ followers on socials. Get in touch.
What did you think of today's newsletter?
You can also reply directly to this email if you have suggestions, feedback, or questions.
Until next time — The Code team
