Use both, with different jobs. The IDE gives fast, private feedback while the author still has context. The pull request gives a shared, recorded check that every change passes. If you must pick one first, pick the pull request, because it is where you can enforce and prove.
What each position is good at
In the editor. Feedback arrives seconds after the code is written. Fixing costs almost nothing, nobody else sees a false alarm, and the author learns. The weaknesses: it depends on each developer installing and configuring it, it can be switched off, and it leaves no team-wide record.
On the pull request. Every change goes through it regardless of who wrote it or which editor they use. The result is visible to reviewers and stored with the change. It can block a merge. The weaknesses: feedback is slower, the author has moved on mentally, and a noisy check is public, which spoils trust faster.
| Question | IDE | Pull request |
|---|---|---|
| Can every change be forced through it? | No | Yes, with branch protection |
| Is there a record for auditors? | Weak | Strong |
| How fast is feedback? | Seconds | Minutes |
| Cost of a false alarm | Low, private | Higher, visible |
| Works for AI-generated code pasted from a chat window? | Only if the tool sees it | Yes |
| Coverage depends on developer setup? | Yes | No |
A sensible rollout order
- Start on pull requests in advisory mode. Comments only, no blocking. Measure noise for two to four weeks.
- Tune. Turn off rule groups that produce wrong flags on your code.
- Add a gate for one narrow class, such as a new secret or a critical issue in a changed file. Blocking everything at once invites bypass. See block, warn or observe.
- Offer the IDE plugin as an option, not a mandate, so developers catch issues before the pull request.
- Compare. If most issues the pull request check finds could have been caught in the editor, push adoption of the plugin.
Things to test in each position
In the IDE: does it slow typing or indexing on a large project, does it work offline, and what leaves the machine?
On the pull request: does it handle large diffs, forks, and changes from bots? How does it treat a pull request from an outside contributor, whose code and comments are untrusted input? That last point matters for AI reviewers specifically, and prompt injection risks in AI code review bots covers it.
What about the command line and CI?
A third position is a command in CI or a local pre-commit hook. It is useful for deterministic checks, such as dependency and secret scanning, and for repositories where a pull request integration is not possible. AI review is usually a poor fit for pre-commit because of latency and cost per run, but it can suit CI on changed files.
Try it yourself
The demo shows a pull request gate evaluating a change. Click through it and look at what the author sees when a check fails, and what a reviewer needs to decide.
Click through it at your own pace, or open it full screen.
Quick check
If developers use the IDE plugin, do I still need the pull request check?
Yes. The plugin can be disabled or missing, and only the pull request check gives you an enforced, recorded control.
Which position gives better evidence for an audit?
The pull request. Results sit with the change, with timestamps, reviewers and outcomes.
Safeguard works in both places: it ships IDE extensions for VS Code and JetBrains, and policies and gates that check changes before merge. You can start with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
