Devin Review: check a pull request and retain the findings

Use Devin Review findings as leads to investigate: compare each one with the pull request diff, trace the affected behavior, and reproduce the problem before requesting a fix. Keep confirmed defects separate from suggestions and unanswered questions. fenbs can keep those checked findings and the next review step outside the conversation, so another assistant can continue without repeating the same investigation.

This guide explains that verification workflow. Cognition’s general Devin introduction↗ (opens in a new tab) describes coding and testing capabilities, but does not establish the separate Devin Review product’s current menus, repository permissions, or account requirements. Check those in the product before granting access; the steps below do not depend on an assumed review button or automatic pull request comment.

What should you establish before reviewing a pull request?

Write down what the change intends to do and what it must preserve. A reviewer needs both. “Add filtering” is a weak starting point if the existing ordering, permission checks, and empty-state behavior are also part of the expected result.

1. Open the pull request and confirm the repository, target branch, and current commit.
2. Read its description and identify the intended behavior in one or two sentences.
3. List the important boundaries: allowed inputs, permissions, error behavior, and existing behavior that must remain.
4. Check which tests have actually run, and which parts still need verification.
5. If Devin Review is available in your account, confirm its access and the exact change under review before using its findings.

Treat this as your own preparation checklist, rather than a list of documented product controls. If access or coverage is unclear, resolve that first. A detailed-looking result is not useful if you cannot tell which version of the change it describes.

How should you compare a finding with the diff?

Start with the smallest concrete claim. “This may break authorization” is a concern, not yet a defect report. A useful claim identifies the request, the condition, the incorrect behavior, and the changed code responsible for it.

1. Find the changed lines associated with the finding.
2. Read the surrounding function and the relevant caller, rather than only the highlighted line.
3. Compare the previous behavior with the proposed behavior.
4. Look for a guard or alternate path that could make the claim inapplicable.
5. Record whether the issue was introduced by this change, already existed, or is still uncertain.

Suppose a finding says an empty list causes a crash. Check whether the caller can pass an empty list and whether the function rejects it before the changed expression. If either fact is unknown, keep investigating instead of presenting the claim as a confirmed regression.

For help choosing among review products, see AI code review tools. That is a separate question from deciding whether a particular finding is correct.

What evidence turns a concern into a confirmed issue?

The best evidence connects a realistic input to an incorrect outcome. Use an existing test when it exercises the path in question. When it does not, choose a focused reproduction that demonstrates the failure without changing unrelated behavior.

• For an input bug, give the exact input and expected result.
• For a permission bug, identify the actor and operation, and show where the required check is missing or bypassed.
• For an error-handling bug, follow what happens after the dependency fails.
• For a compatibility bug, name the existing caller or supported behavior that the change breaks.

A passing test is relevant only to what it covers. Record the command, environment, and observed result when they matter. Avoid writing “tested” if you only read code or saw that an unrelated check passed.

When you need help locating the surrounding architecture, DeepWiki covers repository exploration. Cognition’s repository wiki documentation↗ (opens in a new tab) describes documentation, diagrams, and source links; those are useful reading aids, while the review still needs evidence from the actual change.

How do you handle a plausible but uncertain finding?

Keep it as a question with a clear next check. Uncertainty is useful information when you say what is missing. “Could not confirm whether this callback can run twice; inspect its caller” gives the next reviewer a specific task.

Separate a false positive from an unverified claim. A false positive has evidence showing the suspected problem cannot occur in the relevant path. An unverified claim still lacks enough evidence either way. Closing both with the same label hides what you actually learned.

Also separate style preferences from correctness. A different naming choice may deserve discussion, but it should not carry the same weight as a reproduced defect. Make the requested action match the evidence and the consequence.

What should a useful review record contain?

A confirmed issue should stand on its own. Another engineer should not have to reopen a long AI conversation to understand the failure or decide whether a fix addresses it. Use a short record like this for each issue.

Change: pull request URL and reviewed commit
Finding: one sentence describing the incorrect behavior
Trigger: the input or condition that causes it
Evidence: source paths and reproduction result
Expected behavior: what should happen instead
Status: confirmed, uncertain, or rejected
Next step: owner and smallest useful action

After the author changes the code, check the new commit against the same trigger. Keep the original evidence and add the result of the fix check. A finding is resolved because the relevant behavior changed and was checked, not because the discussion became quiet.

Which findings should become reusable checks?

Keep a reusable check when the failure exposes a pattern likely to recur. For example, a confirmed missing ownership check can become a review question about every new record lookup. A one-off typo usually needs a fix, not a permanent rule.

Have a person decide which patterns become team rules. Keep the reason and the supporting example beside the rule so future reviewers understand its scope. A useful lesson explains what happened and what to check differently next time, without turning a single mistake into an unlimited ban.

If the review will move into coding work, Devin Desktop and Devin versus GitHub Copilot cover those adjacent tool choices. More AI at work guides explain how to keep useful outcomes when the session ends.

How to keep checked review findings with fenbs?

Keep the confirmed issues, evidence, and checks still to run. You can pick up the review from the same point on any device or in another connected AI without losing the work.

1. Create a free account.
2. Add a task for each confirmed issue. Include the pull request link, reviewed commit, evidence, and expected behavior.
3. Keep unanswered questions clearly marked, and say what needs checking next.
4. Connect Devin to fenbs if you use Devin for follow-up work; its cloud connection requires the relevant administrator permission.
5. Save where you left off, including which fixes were checked. You can carry on from the same point on another device or in another connected AI.

The Devin custom MCP guide↗ (opens in a new tab) documents that administrator requirement. fenbs keeps tasks, lessons, and progress; it does not perform the code review or import review findings automatically. For one small pull request with no follow-up, the pull request discussion may be enough.