cubic

Code review has two jobs. One is catching defects, which tools have been attempting for decades. The other is transmitting how this particular team writes code, which is entirely social and has never been automatable.

That second job is why review comments from a senior engineer are valuable and a linter's output is merely tolerated. The linter knows rules; the engineer knows why the rules exist here.

cubic's most interesting design decision aims squarely at that gap: it reads what your senior engineers have written in past reviews, and treats that as the specification.

cubic: AI Code Review In Pull Requests

• Reviews in GitHub and your IDE, with inline feedback and AI-written PR summaries.
• Rules in plain English rather than configuration files, so standards are written the way they are spoken.
• Learns from senior engineers' comment history — an unusual and effective way to acquire unwritten conventions.
• Nightly codebase scans using thousands of agents, with automatic triage and ticket creation.
• Free for public repositories, and it pulls context from Linear, JIRA, Notion and Confluence.

Can An AI Reviewer Learn Your Standards?

cubic states that it enforces your team's standards written in plain English, identifies senior engineers and learns from their activity, and onboards by reading their PR comment history.

The plain-English part matters more than it sounds. Most team standards are not expressible as a linter rule — prefer early returns in handlers, do not add a cache without a way to invalidate it, keep database calls out of view code — and every attempt to encode them into configuration loses the nuance.

Writing them as sentences preserves the reasoning, which is what makes a rule apply correctly to a case the author did not anticipate. It also means the person who holds the standard can write it down without learning a rule syntax.

The comment-history onboarding is the cleverer half. Most conventions were never written anywhere; they exist as a decade of review comments, and any new hire learns them by having the same corrections applied to them personally.

Reading that history is a genuinely good idea. The risk is that it also inherits whatever was wrong or outdated in it — a preference somebody abandoned three years ago, a defensive pattern adopted for a system that no longer exists, or one strong personality's habits mistaken for team consensus.

Most conventions were never written anywhere. They exist as a decade of review comments, and every new hire learns them by having the same corrections applied to them personally.

Learning From Senior Engineers' Comments

The mechanism raises a question worth asking before you turn it on: who does the system consider senior?

If seniority is inferred from activity — comment volume, merge counts, tenure — it may identify the most prolific commenter rather than the best reviewer, and those are frequently different people.

It also encodes a moment in time. A team improving its practices will have a comment history that is worse than its current standard, and a tool trained on that history will pull work backwards towards the average of the past.

The mitigation is to treat learned conventions as a draft that gets reviewed. Read what the tool inferred, delete the rules nobody believes any more, and promote the good ones into the plain-English set where they are explicit and editable.

Done that way, the feature is genuinely valuable: it surfaces the tacit rules of a codebase, which is useful even if you never let the tool enforce them. Structural quality tools such as CodeScene measure whether the code is healthy; this measures what the team believes.

Nightly Agents Scanning For Bugs

cubic describes an early-access capability that runs thousands of agents each night to find and fix bugs across a whole codebase, with automatic triage, ticket creation and one-click fixes.

The premise is stated bluntly on the site: your codebase is full of bugs. That is true of every codebase, and it is also why the feature is harder than it sounds.

The difficulty is not finding candidate issues — any sufficiently thorough scan finds thousands. The difficulty is that a finding is only useful if it is real, reachable, and worth someone's morning.

Automated triage and ticket creation therefore cut both ways. Routed well, they put the right issue in front of the right owner; routed badly, they generate a backlog of low-value tickets that trains everyone to ignore the tool's tickets specifically.

The honest way to evaluate this is on precision rather than volume. Run a scan, take the first twenty findings, and count how many you would actually fix. That ratio decides whether the feature is an asset or a source of noise — the same test that applies to any static analysis platform, including DeepSource and Codacy.

• Review the conventions the tool infers before letting it enforce them.
• Judge scan findings on precision, not on how many it produced.
• Turn on a narrow rule set first and widen it once comments are trusted.
• Watch whether reviewers start skimming — that is the sign of too much noise.
• Keep humans reviewing design decisions, whatever the tool catches.

Rules Written In Plain English

Writing standards as sentences instead of configuration is the feature most likely to change how a team actually works, and it has a failure mode worth anticipating.

The benefit is accessibility. A tech lead who would never write a custom lint rule will write down never call the payment API from inside a transaction, and that sentence is both a machine instruction and documentation for humans.

The failure mode is ambiguity. Natural language rules are interpreted rather than executed, so two changes that look similar to a person may be judged differently, and an occasionally-wrong rule erodes trust faster than a missing one.

This makes the review of the rules themselves important. A rule that produces false positives should be rewritten more precisely or removed, and somebody needs to own that maintenance or the rule set decays.

Started narrowly it works well: five rules everybody agrees on, tightened over a month, is a far better foundation than thirty aspirational ones that generate arguments in pull requests.

Where AI Review Adds Noise Instead Of Value

The failure mode of automated review is not wrong comments — it is too many correct but unimportant ones.

A reviewer facing forty machine comments will not read forty machine comments. They will scan for anything alarming, approve, and from that point the tool has made review worse rather than better, because it has trained people to skim.

Nit-picking is the specific danger, and it is the thing teams most hope automation will remove. cubic's own customer quote claims nit-picks are gone, which is the right thing to promise and the thing to verify in your own repository.

What automation genuinely cannot judge is whether a change is the right change. Whether this abstraction is worth its cost, whether this belongs in this service, whether the requirement itself makes sense — those are design conversations, and they are the part of review that is worth a person's time.

The best outcome is therefore a division of labour rather than a replacement: machines take the mechanical layer, humans get their attention back for the design layer. Any tool that produces the opposite result is failing regardless of how many defects it finds.

Adding cubic Without Drowning In Comments

Automated review tools fail in a predictable way: enabled fully on day one, generating hundreds of comments, quietly ignored by week three.

This sequence builds trust first and widens scope only once the comments are being read.

1. Start on one repository rather than the whole organisation.
2. Read the conventions the tool infers from comment history before enforcing any.
3. Enable five rules everybody already agrees on, written as plain sentences.
4. Check whether reviewers are reading the comments or scrolling past them.
5. Delete or rewrite any rule that produces a false positive twice.
6. Only run a full codebase scan once PR review comments are trusted.