Master

Making review happen on every push

The best review is the one you never have to remember to ask for. Once you put AI review into your pipeline, every push gets one automatically -- no prompt, no effort, no chance to skip it when you're rushing. The art is keeping it fast enough that nobody turns it off.

What you will see

Review scope: 2 changed files service/checkout.py service/payment.py Faster than reviewing every file: True

About 2 min of reading

Try It

Run the review early and scope it to changed files

Run the review before the tests in the pipeline so problems surface early.

pipeline_stages = ["lint", "review", "test", "deploy"] def run_pipeline(): for stage in pipeline_stages: print("Stage: %s" % stage) run_pipeline()

Before you run it, say out loud what it will print. Then open the answer.

What it prints

Stage: lint Stage: review Stage: test Stage: deploy

Keep the review quick by reviewing only the changed files.

changed_files = ["service/checkout.py", "service/payment.py"] print() print("Review scope: %d changed files" % len(changed_files)) for f in changed_files: print(" %s" % f) print("Faster than reviewing every file: True")

Before you run it, say out loud what it will print. Then open the answer.

What it prints

Review scope: 2 changed files service/checkout.py service/payment.py Faster than reviewing every file: True

A slow review slows the whole pipeline; speed is what keeps it tolerated.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Add a review step to the pipeline so every push is checked automatically, and the result feeds back into testing.

1 Pick a trigger

↓

2 Add the review step

↓

3 Review changed files

↓

4 Post the results

Why this works

Where to put the step

Add the review before the tests run, so problems are caught early in the pipeline rather than surfacing after everything else has passed.

Keep it fast

A slow review slows the whole pipeline, and slow pipelines get disabled. Keep it quick and focused on changed files -- speed is what makes people tolerate it long enough to benefit from it.

Examples

The simplest possible step

# In a CI file
- name: AI review
  run: ai-review my_code.py

Now every push gets reviewed, and no one has to remember to ask. That consistency is the whole point -- you'd be surprised how often the review never happens just because it wasn't a step in the process. This is how teams scale it.

Reviewing only what changed

# Only review the files that changed
- name: AI review
  run: ai-review --changed

Reviewing only changed files keeps the check fast. Reviewing the whole file on every single push is slow and adds noise that people stop reading."

Diff-based review focuses attention on what you actually shipped. That's how mature pipelines stay quick and, more importantly, how they keep people trusting the output.

Turning a bad finding into a gate

- name: AI review
  run: ai-review --fail-on security
  fail-fast: true

With --fail-on security, a critical finding blocks the build. Bad code simply can't merge until it's fixed. It turns a suggestion into a standard everyone has to meet, automatically."

Failing the build enforces standards without anyone having to police them. The review stops being advice and becomes part of the process.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← How much a review is worth is set by the prompt

Previous Lesson

How much a review is worth is set by the prompt

Next Lesson

Deciding whether the review is actually worth keeping

Deciding whether the review is actually worth keeping →