Your first AI code reviewer

Introduction

Code review is one of the most valuable parts of software development.

It catches bugs.

It improves code quality.

It spreads knowledge across a team.

It also takes time.

A developer finishes a feature and opens a pull request.

Another developer has to stop what they are doing.

They read through the changes.

They try to understand the requirement.

They look for potential problems.

Then they leave comments.

Some of those comments are important.

Others are things that could have been caught before the pull request was opened.

For example:

• A missing null check.
• A method that has become too large.
• An obvious security issue.
• Missing validation.
• No tests for a new piece of logic.
• A potentially expensive database query.
• A variable name that makes the code difficult to understand.

This is where AI can help.

The goal is not to replace code review.

The goal is to give developers an additional review before another engineer spends their time looking at the pull request.

Think of it as a first pass.

The AI looks at the changes.

It highlights things worth checking.

Then the developer decides what to do.

That distinction is important.

AI should suggest.

Humans should decide.

In this article, we will look at how an AI-assisted code review workflow can fit into a normal GitHub development process.

The companion project will show how to build the workflow using GitHub Actions, a review prompt and an LLM.

The problem with traditional code review

Imagine a team of ten developers.

Every developer creates several pull requests each week.

Each pull request needs another developer to review it.

That is a lot of context switching.

You might be working on one feature when a notification arrives.

A colleague needs a review.

You stop what you are doing.

You read the pull request.

You try to understand the changes.

Then you leave comments.

A few minutes later, you return to your original work.

This is normal software development.

But some of the things we review are repetitive.

For example:

This value could be null.

Or:

Where is the test for this case?

Or:

This method is doing too much.

Or:

This query could load a lot of unnecessary data.

These comments still matter.

But they don't always need to be the first thing a human reviewer sees.

An AI review can catch some of these issues earlier.

The developer can fix them before requesting a human review.

That means the human reviewer can spend more time thinking about the things AI cannot easily understand.

Things like:

• Does this solve the right business problem?
• Does this fit the architecture?
• Are we introducing unnecessary complexity?
• Will this create problems for another team?
• Does this behaviour make sense for customers?

Those are usually much more valuable conversations.

AI review is not automatic approval

This is probably the most important rule in this article.

Do not let an AI model approve your pull request.

An AI review should not mean:

AI found nothing. Merge it.

That would be a mistake.

AI can miss bugs.

It can misunderstand the code.

It can make incorrect assumptions.

It can focus on something unimportant and miss something serious.

Instead, the output should look more like this:

Here are three things worth checking.

For example:

Potential issue

Customer may be null before accessing Customer.Name.

File:
CustomerService.cs

Line:
42

Suggestion:
Validate the customer before accessing its properties.

The developer can then check whether the issue is real.

Sometimes it will be.

Sometimes it won't.

Both outcomes are acceptable.

The purpose of the system is to help the developer think.

Not to become the source of truth.

The workflow

The workflow for our example is straightforward.

A developer creates or updates a pull request.

GitHub Actions starts.

The workflow collects the changed files.

It filters files that should not be reviewed.

The changed code is sent to the AI reviewer.

The AI returns structured findings.

Those findings are posted back to the pull request.

The developer reviews them.

A simple flow looks like this:

Developer
    │
    ▼
Open Pull Request
    │
    ▼
GitHub Action
    │
    ▼
Get Changed Files
    │
    ▼
Filter Files
    │
    ▼
Build Review Context
    │
    ▼
AI Reviewer
    │
    ▼
Structured Findings
    │
    ▼
Pull Request Comment
    │
    ▼
Developer Reviews Suggestions

The human remains at the end of the workflow.

That is intentional.

Start by reviewing the changes

One of the first decisions is what information to send to the model.

You could send the entire repository.

That is usually unnecessary.

It also creates problems.

The repository might be large.

The cost could increase.

The AI could become distracted by unrelated code.

A better starting point is to review only the changes in the pull request.

GitHub already knows which files changed.

The workflow can collect the diff.

For each changed file, we can decide whether it should be included.

For example, we might review:

• .cs
• .ts
• .tsx
• .js
• .py
• .sql

We might ignore:

• generated files
• binaries
• images
• large files
• lock files
• vendor folders

This makes the review smaller and more focused.

It also gives us more control over cost.

Context still matters

In Episode 1, we talked about the importance of context.

The same rule applies here.

If we simply send this to an AI model:

Review this code.

The results may not be very useful.

The model doesn't know whether the project is:

• a small internal tool
• a public API
• a financial system
• a prototype
• a high-volume application

It doesn't know the team's conventions.

It doesn't know what the code is supposed to do.

The prompt should provide enough information to guide the review.

For example:

You are reviewing a pull request for a .NET application.

Focus on meaningful issues.

Check for:

- possible bugs
- null handling
- missing validation
- security concerns
- performance problems
- missing tests

Do not comment on formatting unless it affects readability.

Do not invent issues.

If you are not confident, say that the issue needs human review.

Return findings as structured JSON.

That is already much better than:

Review this code.

The goal is not to create the biggest possible prompt.

The goal is to give clear instructions.

Avoid noisy reviews

One of the biggest risks with AI code review is noise.

Imagine opening a pull request and receiving twenty comments.

Most of them are pointless.

The variable name could be different.

A comment could be rewritten.

A method could be moved to another file.

After a few pull requests, developers will stop reading the AI review.

The system becomes another notification that everyone ignores.

This is why the prompt needs to focus on useful findings.

I would rather receive one useful comment than twenty weak ones.

A good starting rule is:

Only report issues that could affect correctness, security, performance, maintainability or test coverage.

You can also ask the model to assign a confidence level.

For example:

{
  "severity": "medium",
  "confidence": "high",
  "category": "bug",
  "message": "The result can be null before accessing its properties."
}

The workflow could choose to hide low-confidence findings.

Or it could include them in a summary instead of posting them as individual comments.

This helps reduce noise.

Use structured output

Free text is difficult to automate.

Imagine the model returns:

I think there may possibly be an issue in CustomerService around the customer lookup.

That is difficult for software to understand.

Instead, ask for a predictable format.

For example:

{
  "summary": "Two issues found",
  "findings": [
    {
      "severity": "medium",
      "confidence": "high",
      "category": "bug",
      "file": "CustomerService.cs",
      "line": 42,
      "message": "Customer may be null before accessing Name.",
      "suggestion": "Validate the customer before accessing its properties."
    }
  ]
}

Now the application can:

• parse the response
• filter findings
• group them by severity
• post comments
• create a summary

Structured output also makes testing easier.

We can test whether the reviewer understands the response format without depending on how a particular sentence is written.

A simple review model

For the first version of the project, I would keep the categories simple.

Bugs

Look for logic that may fail.

Examples:

• null references
• incorrect conditions
• missing error handling
• incorrect assumptions

Security

Look for obvious risks.

Examples:

• secrets in code
• unsafe input handling
• missing authorisation
• dangerous SQL construction

Performance

Look for problems that could matter.

Examples:

• unnecessary database queries
• loading large collections
• repeated expensive work

Testing

Check whether important behaviour is covered.

Examples:

• no test for a new branch
• missing error case
• no coverage for validation

Maintainability

Use this category carefully.

We don't want AI arguing about personal coding preferences.

Instead, focus on things that make the code genuinely difficult to understand or change.

A real business example

Imagine a software consultancy working with several clients.

The team receives many pull requests every week.

Senior developers are often responsible for reviewing the most important changes.

That creates a bottleneck.

Junior developers may wait for feedback.

Senior developers lose time switching between reviews and their own work.

An AI-assisted first review could help.

A pull request is opened.

The workflow checks the changed code.

It looks for obvious problems.

The developer receives feedback quickly.

By the time the human reviewer sees the pull request, some of the basic issues may already be fixed.

This doesn't reduce the importance of senior engineers.

It allows them to focus on higher-value decisions.

The same idea can work outside software development.

A business might use AI for:

• checking documents before approval
• reviewing customer communications
• validating data before processing
• summarising incidents before investigation

The workflow is the same.

Automate the first pass.

Keep people responsible for the final decision.

Building the GitHub Action

The GitHub Action itself does not need to be complicated.

The basic stages are:

1. Start when a pull request is opened or updated.
2. Check out the repository.
3. Get the changed files.
4. Build the review request.
5. Call the reviewer.
6. Parse the result.
7. Post the summary to the pull request.

Conceptually:

pull_request event
        │
        ▼
Get Pull Request Diff
        │
        ▼
Select Supported Files
        │
        ▼
Limit Size
        │
        ▼
Call Reviewer
        │
        ▼
Parse JSON
        │
        ▼
Create Review Summary

There are several ways to implement this.

The action can call a .NET console application.

It can call an API.

It can run a script.

For this series, a small .NET reviewer makes sense because it gives us something we can test locally as well as inside GitHub Actions.

Test the reviewer

AI systems still need tests.

You should not only test whether your .NET code compiles.

You should test the behaviour around the AI integration.

For example:

Response parsing

Can we correctly parse a valid review response?

What happens if the response is invalid?

File filtering

Are we correctly ignoring files we do not want to send?

Prompt building

Does the prompt include the required project context?

Does it stay within our size limits?

Finding filtering

Do we ignore low-confidence or low-severity findings when required?

These tests don't prove that the AI is always correct.

Nothing can guarantee that.

But they do prove that our system handles the AI response safely and predictably.

Production concerns

Before connecting an AI reviewer to every pull request in a company, there are a few things to consider.

Cost

Every review uses model tokens.

A large pull request costs more than a small one.

Set limits.

For example:

• maximum number of files
• maximum size per file
• maximum total diff size

You don't need to review a 50,000-line generated file.

Secrets

Never place API keys directly in the workflow.

Use GitHub Secrets.

For example:

AI_API_KEY

The workflow reads the secret when it runs.

The secret should never be printed to logs.

Sensitive code

Think carefully about what is being sent to an external AI provider.

Some organisations may have rules about source code or customer data.

You may need:

• an approved provider
• a private deployment
• data retention controls
• file exclusions

Don't add AI to the pipeline without checking the security requirements.

Availability

What happens if the AI provider is unavailable?

The answer should usually be simple.

The AI review fails.

The normal pull request workflow continues.

A failed AI suggestion should not necessarily block the developer from merging code.

AI is an assistant.

It should not become an unnecessary dependency.

Your challenge

For this episode, don't start by reviewing every pull request in your organisation.

Start small.

Choose one repository.

Create a simple workflow.

Step 1

Create a review prompt.

Ask the AI to focus only on:

• bugs
• security
• performance
• tests

Step 2

Collect the changed files from a pull request.

Start with a small file limit.

Step 3

Send the changes to an AI model.

Ask for structured output.

Step 4

Post one summary comment.

Don't create dozens of inline comments yet.

Step 5

Use it for a week.

Ask the developers:

• Was it useful?
• Was it noisy?
• Did it catch anything?
• What should it stop doing?

Then improve the prompt.

This is important.

The first version will not be perfect.

Treat the workflow as a product.

Measure it.

Get feedback.

Improve it.

Key takeaways

AI-assisted code review should not replace human review.

It should improve it.

The best starting point is simple.

Review the pull request changes.

Provide useful context.

Focus on meaningful problems.

Use structured output.

Keep the results concise.

Let developers make the final decision.

If the system catches one useful bug before a human reviewer sees the pull request, it has already provided value.

If it creates twenty useless comments, developers will ignore it.

Quality matters more than quantity.

What's next?

In the next episode, we'll move from individual prompts to something more reusable.

We'll look at building a prompt library that can be shared across a team.

We'll cover:

• organising prompts
• versioning prompts
• project-specific context
• reusable review templates
• prompt testing
• improving prompts over time

The goal is to stop treating prompts as temporary conversations.

Instead, we'll treat them as part of the engineering workflow.

Repository

The companion GitHub project for this episode will include:

• a .NET AI reviewer
• GitHub Actions workflow
• pull request file collection
• structured AI responses
• review prompts
• xUnit tests
• Docker support
• architecture diagrams
• example pull requests with intentional problems

GitHub: github.com/grbzati1/practical-ai-engineering

Final thoughts

AI code review is not about removing developers from the process.

It is about giving developers a faster feedback loop.

Good software teams already use automation.

We run automated tests.

We use linters.

We run security checks.

AI review can become another layer.

Not the final layer.

Not the most important layer.

Just another useful tool.

The most successful AI workflows will probably not be the ones that try to automate everything.

They will be the ones that remove repetitive work while keeping people responsible for the decisions that matter.

That's the approach we'll continue with throughout this series.

Small workflows.

Real examples.

Useful automation.

One step at a time.