How Our Technical PM Uses Claude Code to Review a PR, Fix It and Ship It

Utah Tech Labs — Mon, 09 Nov 2026 12:05:47 +0000

Originally published on the Utah Tech Labs blog.

A pull request can look clean and still be broken. The summary reads well, the commit list is short and GitHub says there are no conflicts with main. None of that tells you whether the code runs.

Samprit, a Technical Project Manager at Utah Tech Labs, spends a large part of his week on exactly this gap. He reviews code from other developers, makes sure nothing breaks in any environment, checks that the tests pass, and then writes the deployment scripts that get the work into a target environment. In this 15-minute walkthrough he shows how Claude Code handles most of that loop, from a first local run to a published container image.

The demo uses a simulated repository called golden bot, with three commits from a junior developer waiting to be merged into main. Here is what happens, step by step.

Step 1: Read the PR, then refuse to trust it

The pull request has a detailed summary: new API endpoints, a changelog, and the number of tests the developer ran on his own machine. There are three commits and no conflicts with the base branch. On paper, it is ready.

Samprit's point is that a review on paper is not enough. Tests that pass on one laptop prove little about the next environment. So instead of approving, he runs the branch himself, in isolation.

Step 2: One prompt to build a local Docker test environment

With the repository cloned, he opens a new Claude Code session. He uses the VS Code extension, though the CLI and the web version work the same way. He pastes the PR link and asks Claude Code to check every change listed in the PR by running it inside a Docker container on his machine. He also asks it to create a Dockerfile, a .dockerignore and test files to validate the changes.

Claude Code pulls the PR details, works out what the project needs to run, and writes the Docker files. The first run fails: the container runs as a non-root user, but the app hard-codes a path it can't write to. Claude Code finds the root cause, fixes it, and gets the container up and healthy. It then writes a pytest suite that gives each test its own temporary database.

One habit Samprit stresses: watch what it does. Claude Code is changing files in your repository, and you should understand every change it makes on your machine.

Step 3: What the review found

With the app running, Claude Code tests each endpoint and gives a verdict on every one. Only two of the routes work the way the changelog says they should. It also flags two security issues: a SQL injection vulnerability, and a crash when input contains an apostrophe.

This is the gap the PR summary hid. The developer reported passing tests, and the code still failed most of its own spec.

Step 4: Post the findings back to the PR

Next, Samprit asks Claude Code to post everything it found as a comment on the pull request. A minute later the comment appears on GitHub, grouped into critical, major and minor issues, plus a short list of what the changes got right. The developer gets specific, reproducible feedback instead of a one-line "doesn't work".

Step 5: Fix, re-run and re-test

He then tells Claude Code to fix all the issues, re-run the project and test every endpoint again. It works through the list, rebuilds the container and repeats the tests. This time every endpoint returns the expected response and the test suite passes.

Samprit is clear that in a real team, the developer who owns the PR should make these fixes. He does it himself here only to show the full loop in one video.

Step 6: Generate the CI/CD pipeline

The last prompt asks Claude Code to create a deployment pipeline that builds the image on merge, pushes it to GitHub Container Registry, and commits the files to the current branch. It writes a GitHub Actions workflow (docker-publish.yml) and pushes two new commits.

The CI run on the PR passes: the image builds and the health check succeeds. Samprit merges with a merge commit to keep the full commit history. The workflow then runs on main: lint and tests, image build, a smoke test, login to the registry, metadata extraction, and finally publishing the tagged image. Every stage goes green. Samprit wrote none of the workflow file himself; he only told Claude Code what it needed to do.

What this changes for a review

The value here is not that Claude Code writes code. The review that actually matters, running the branch and testing it in a clean environment, usually gets skipped because setting it up takes longer than reading the diff. Claude Code removes that setup cost. Building the environment, testing the endpoints, writing up the feedback, fixing the bugs and writing the pipeline each became one plain-English instruction.

Three things still need a person:

Judgment on the findings. Claude Code flagged the SQL injection. A reviewer still decides what blocks a merge.
Ownership. The fixes belong with the developer who wrote the code, not the reviewer.
Watching the session. It edits files and runs containers on your machine. Read what it does.

This is one of many ways our team uses Claude Code day to day. It's the same approach we bring to client teams: engineers who work inside your codebase and set up AI-assisted workflows that hold up in production.

Work with UTL

Want this kind of review and deployment workflow running on your own codebase? See how UTL's forward-deployed engineers work with your team.

DEV Community: Utah Tech Labs