Review code changes with AI in Flame IDE. Get line-anchored findings, choose the review model, discuss suggestions, and turn an actionable finding into a fix.
The actual AI review interface in a source diff. This sample finding explains a division-by-zero regression and suggests a focused fix and test. Select the image to enlarge.
WHY IT HELPS
Keep the finding beside the code it concerns.
A useful code review needs more than a verdict. It needs a location, an explanation, and a next step. Flame's AI reviewer reads a file's working-tree change and returns findings that appear as inline threads in the diff. Start from one file or review selected changed files, then decide which findings deserve action before committing or merging the work.
Find the relevant line
Review findings carry a source location, severity, category, and explanation. Inspect potential bugs, security concerns, performance issues, and missing tests where the changed code is visible.
Give the reviewer your standards
Set standing code-review instructions in AI settings and add project-specific guidance. Choose a provider and model for a review when a particular change needs a different perspective.
Turn feedback into the next action
Reply to a finding, update its review status, or launch a prepared AI conversation to work on a fix. Keep the review discussion connected to the file rather than rebuilding the context in a separate prompt.
AI CODE REVIEW IN PRACTICE
Catch the detail that looked harmless in the diff.
A change can compile, look tidy, and still alter behavior in a way its author did not intend. AI code review gives the edited code another pass before you send it to a teammate or land it. It can surface questions worth investigating while the change is still small and the reasoning behind it is fresh.
Look beyond syntax
Ask whether a refactor changed a boundary condition, an error path, or an assumption about input. A compiler can accept a division that now receives zero, or a promise whose rejection is no longer handled. The review can bring that behavior back into the conversation.
Find the missing test
An implementation may cover the happy path while leaving empty data, failed requests, or repeated calls untested. A finding can suggest which behavior deserves a focused regression test, giving you a concrete next check instead of a vague request for more coverage.
Review before asking for review
Use a focused AI pass to address actionable issues before opening a pull request. Your teammate can then spend more attention on design, product behavior, and decisions that need their knowledge of the system. Measure its value by the useful issues you verify and resolve.
AI CODE REVIEW IN PRACTICE
One removed guard. One broken empty state.
The captured example changes a conversion-rate function. The original returns zero when there are no visitors. The new version converts the visitor count to a number but removes that guard. The code is valid TypeScript, and the normal case can still return the expected percentage. The problem appears when the reporting period has no visitors.
The finding names the consequence
The inline warning identifies the division and explains that an empty period can produce NaN or Infinity. You can read the explanation against both versions of the function, rather than searching for the affected line from a separate report.
The suggestion gives you a next step
Restore or redesign the zero-denominator handling according to the product's behavior, then add a test for an empty reporting period. The suggestion is a starting point: you still decide whether zero, an unavailable state, or another result is correct for the application.
The review becomes a verified fix
Confirm the issue, accept the finding, and make the correction yourself or use Turn into fix to prepare an AI conversation. Run the new regression test and the normal-case tests. Resolve the thread once the underlying behavior is addressed.
AI CODE REVIEW IN PRACTICE
Give the review the standards your project actually uses.
Useful review feedback depends on what matters in the repository. Put recurring expectations into the code-review instructions and add project-specific guidance where the conventions differ. Keep the scope focused enough that a finding can be checked against the edited code and its expected behavior.
Correctness and failure behavior
Tell the reviewer which input assumptions, error-handling conventions, and compatibility requirements matter. For example, ask it to pay attention to empty query results, request cancellation, or changes to a public response shape. Treat a concern as a hypothesis to verify.
Security and performance questions
Review can raise concerns about unchecked input, permission checks, expensive work, or repeated queries when the supplied code supports that concern. Follow up with the appropriate test, security analysis, or measurement. A model's label alone does not establish impact.
Consistent guidance across changes
Settings → AI → Code review holds standing instructions, model defaults, and project overrides. Write concrete preferences such as the expected error format or required regression scenarios. This gives repeated reviews a shared starting point without copying the same guidance each time.
AI CODE REVIEW IN PRACTICE
Keep an independent review step when agents write the code.
An agent completing its task and a change being ready to integrate are different decisions. Open the agent's checkout, inspect the diff, and run a review using the provider and model you choose. The reviewer supplies another set of questions; you connect those questions to the original task and decide what is ready.
Check the actual output
Review the changed implementation, not just the agent's completion message. Compare it with the requested behavior, inspect its tests, and ask whether an apparently complete fix introduces a regression elsewhere in the supplied code.
Keep feedback attached to the change
Inline threads retain their file and line context. Reply with missing reasoning, dismiss a false positive, or accept a real issue. When edits move or invalidate the original code, revisit the finding rather than treating an older comment as current evidence.
Choose how a finding gets resolved
Turn into fix prepares the finding for an AI chat you approve. It does not make the review itself a silent rewrite or a merge action. Inspect the new diff and validation evidence before integrating either human-written or agent-written code.
HOW TO USE IT
From a changed file to a reviewed change.
Choose the change to inspect
Open a project with a working-tree change, select the file in Changes, and inspect its diff. Check the project and worktree so the reviewer receives the checkout you intend to review.
Select a provider and review scope
Use the review control in the diff for one file, or Review in Changes for checked files. With no files checked, the Changes control targets all changed files. Choose a supported provider and model, then start the review.
Read findings in the diff
Inspect the explanation and surrounding code before acting. Discuss or dismiss an unhelpful finding, and mark a finding resolved when the underlying issue is addressed. A severity label is a prioritization aid, not proof of a defect.
Fix, test, and inspect again
For an actionable finding, make the change yourself or prepare a fix conversation. Review the resulting diff and run the relevant tests. Revisit the review if the code changed enough to make an older finding outdated.
REQUIREMENTS & LIMITS
Know what the tool depends on.
AI findings can miss defects or flag correct code. Keep tests, type checks, human judgment, and your team's normal review process in the workflow.
The reviewer uses the selected provider. Code and diff context are sent to that endpoint; configure a local provider when your workflow calls for local inference.
Review context is bounded. Large files or diffs may exceed the information included in a single pass, so review substantial changes in focused pieces.
A review finding is feedback. Starting a review does not automatically commit, merge, or publish the change.
FAQ
AI Code Review: common questions
Yes. The reviewer works with working-tree changes and their diff against HEAD. Open a changed file or select changed files in the Changes panel to start a review.
The Changes panel lets you review checked files, or all changed files when none are checked. File-level review is also available from the diff toolbar.
Yes. Settings includes standing code-review instructions, provider and model defaults, and project-specific instruction overrides. You can also choose the model when starting a review.
The reviewer returns findings. You can inspect and discuss them, make a manual correction, or launch a prepared AI conversation for a selected finding. Review and test the resulting change before landing it.
No. It adds another pass over the diff. Teammates still supply product context, architectural judgment, and accountability, while tests verify behavior that a model may misunderstand.