AI code review, and how it gets smarter over time

Beyond writing code, the AI now also reviews it — and it keeps a memory of what your reviewers care about, so it makes the same kind of mistake less and less often. This article covers what happens in plain terms: the review your merge requests get before anyone on the team looks at them, how the AI learns from your team's feedback, and how you can shape that learning yourselfA first pass before your team ever sees it

Once the AI finishes a task and opens a pull request, it doesn't just hand it over and wait. Before any teammate has looked at the PR, the AI gives it one thorough read of its own — checking the whole change, not just the parts a reviewer happens to comment on — and quietly fixes anything it's confident is worth fixing. It doesn't leave comments or start a conversation about what it found; it either fixes the issue or leaves it alone. By the time a human opens the PR, the obvious problems are usually already gone.

This happens automatically, exactly once per pull request, and it's coordinated safely even if you're running the CLI on more than one machine at once — you never get two AI reviews stepping on each other or duplicating work. There's nothing to configure and nothing to turn on; it's part of how every task now finishes in company mode. Projects in freelancer mode never run any review, neither this first pass nor the follow-up on review comments described below.

Learning from what your team points out

The AI has always been able to respond to a reviewer's comment on a PR — read it, decide if it's right, fix the code, and reply. What's new is that it now also learns from that exchange. When a reviewer flags something and the AI fixes it, the AI asks itself whether that's a one-off or a lesson worth remembering for this project going forward. If it's a real, reusable lesson, it gets added to that project's standing list of review guidance — quietly checking first that it isn't just repeating something already noted, so the list doesn't fill up with the same point said three different ways.

From that point on, every review the AI does for that project — the first automatic pass and its ordinary responses to comments — takes that guidance into account, alongside your repository's own coding standards. In practice, this means the same correction shouldn't need to be made twice: once a reviewer has taught the AI something about how your team likes things done, it tends to stick.

Any change to this list — whether the AI added it or you did — is picked up right away, on the very next thing the AI reviews. There's no waiting, no restart, nothing to redeploy.

Editing the rules yourself

Each project has a "Review rules" box in its settings, right alongside the other AI-related settings. It's just a free-text field — the AI writes its own learnings there one at a time, but you're free to read it, rewrite it, delete parts of it, or add your own guidance directly. Whatever is written there is what the AI takes into account on every future review for that project.

You don't have to wait for the AI to learn your team's conventions the slow way, one review comment at a time. If you already know what matters to your team — a testing habit, a naming convention, a rule about dependencies — you can just write it into the box yourself from day one, and every PR from the very first one will already be held to it.

When it's worth tidying up by hand

The learning process is deliberately cautious — it only adds something when a real reviewer actually raised the point and the AI actually acted on it — but a list that only ever grows can still use a human touch now and then. A few situations where a few minutes of editing pays off:

- Two rules end up saying almost the same thing.** The automatic check catches exact repeats, not every way of phrasing the same idea. If you spot two lines that are really one lesson, merge them.

- A rule turns out to be off.** Occasionally a lesson gets generalised a bit too broadly or too narrowly from a single comment. If something in the list is steering reviews in the wrong direction, just rewrite or remove it — you're always in full control of this list.

- A rule has gone stale.** After a deliberate change in direction — a refactor, a new library, a new convention — some older guidance may no longer apply. The AI has no way to know that on its own; only your team notices when a new comment quietly contradicts something already written down.

- The list is getting long.** A shorter list of genuinely recurring lessons is more useful than a long one full of narrow, one-off notes. Trimming it occasionally keeps reviews sharper.

- Starting a new project.** If another project's list already reflects your team's real conventions, copying the useful parts into a new project's box gives it a head start instead of relearning everything from scratch.

None of this is required for the feature to work — it runs unattended and keeps quietly improving either way. Editing the list by hand is simply a way to speed that up, whenever you have a spare few minutes and a reason to.

‍