issues & features

Bugs confirmed against the code. Features planned before they're built.

A built-in tracker that understands your codebase. Reported bugs are checked against the code and traced to the line; feature requests become implementation plans you can revise, lock and hand to AI to build.

Start free trial Talk to sales

Totals off by a cent on 3-way splitsp1

reported by QA · 2 screenshots attached

✓ reproduced against the code: money/format.ts:87
✓ root cause: decimal division on cent values
✓ fix PR opened · checks passing
• awaiting QA sign-off to close

the problem

Triage is where tickets go to wait.

Bug reports arrive vague, and a developer burns an hour just reproducing them.

Plenty of tickets turn out to be duplicates, already fixed, or not bugs at all.

Feature requests jump straight to code without anyone agreeing on the plan.

how it works

From trigger to result.

Report it

Describe the bug or feature in plain words, with screenshots or attachments.

It's validated against the code

Bugs are confirmed and traced to file and line; features are checked for feasibility and scope.

A fix or plan is drafted

Confirmed bugs can become fix pull requests; features get an implementation plan you can revise.

QA closes the loop

Once it ships, QA checks it and closes it. CodeReviewer also notices when a developer fixed something by hand.

capabilities

What you get.

AI bug validation

Each report is checked against your code, with the likely file and line identified before a developer picks it up.

Fix pull requests

A confirmed bug can go straight to a pull request with the fix, reviewed like any other change.

Feature plans you control

Requests get a feasibility check and a draft implementation plan. Revise it, lock it, then let AI implement it as a pull request.

Real triage

Priorities p0 to p3, comments, attachments, a full timeline, reopen, and platform tags for web, backend, mobile, desktop and infra.

QA-controlled close

Shipped isn't closed. QA verifies the fix and closes the issue, so nothing is marked done by the person who built it.

Database-aware checks

Connect a database and bugs get checked against real data as well as the code.

A tracker that has read the code

Most trackers store text. CodeReviewer’s issues are connected to the repository they describe, so the first thing that happens to a new report is a check: can this happen in the code as it stands, and where? By the time a developer opens the ticket, it already names the likely file and line. Or it explains why the report doesn’t hold up.

Plan first, then build

Feature requests go through a short, deliberate loop. CodeReviewer checks whether the request is feasible and in scope, drafts an implementation plan, and waits. Your team revises and locks the plan; only then is it implemented, as a pull request. There’s also a plain task type for work that doesn’t need a plan at all.

faq

Questions, answered.

Do we have to move off our current tracker?

No. Many teams use CodeReviewer's issues for the bugs that touch code it reviews, alongside whatever they already use for planning.

How does validation work for bugs that depend on data?

Connect a PostgreSQL, Supabase or SQL Server database and CodeReviewer can check the report against real records as well as the code.

Can AI implement a feature without us approving the plan?

No. A plan must be locked by your team before implementation starts, and the result arrives as a pull request that's reviewed like any other.

What's "magic rewrite"?

It's a button that turns rough notes into a clear description that knows your code. Handy for quick bug reports and test guidance.

Who can close an issue?

The QA flow is built so shipped work is verified before it closes. Permissions for QA, fixes and AI runs are set per member.

Give every PR the review it deserves.

Start your 15-day free trial. We onboard a few teams every week.