JetBrains AI Assistant: not every green inspection is an agent task

There’s a specific failure mode that shows up about two weeks after a team turns on AI Assistant. Someone opens a file, sees the inspection gutter lit up like a Christmas tree, and starts feeding warnings to the model one by one. It feels productive. The warnings go away. Everyone is pleased.

What actually happened is that a deterministic transformation with a known-correct result got replaced by a probabilistic one with a diff to review.

The IDE already solved most of this

This is the thing that gets forgotten in the excitement. JetBrains has been shipping static analysis for twenty years, and the inspections that produce those highlights mostly come with a quick-fix attached. Alt+Enter on the warning, pick the fix, done. The transformation is written by someone who knew the language semantics, it is the same every time, and it cannot hallucinate a method that doesn’t exist.

An agent asked to fix the same warning has to infer what the warning meant, decide what the surrounding code is trying to do, and produce an edit. Usually it gets there. Occasionally it gets there by a different route than you’d have taken, and now you have a stylistic argument to have with yourself at review time. Rarely it does something subtly wrong that compiles.

For a warning about a redundant null check, that’s a bad trade at any price. The quick-fix is instant, free, and correct by construction.

The line worth drawing

I’ve ended up with a rough sort that holds up well enough to use without thinking.

If the fix is mechanical and local, use the IDE. Redundant casts, simplifiable conditionals, unused imports, migrating a loop to a stream and back again, anything where the correct output is a function of the input. The IDE wins on speed, correctness and reviewability all at once. There is no version of this where a model is the better tool.

If the fix is mechanical but repetitive across many files, reach for structural search and replace before you reach for anything else. It’s the most underused feature in the entire IDE and it will do in one pattern what an agent would do in forty edits, without the forty edits needing individual review.

Save the model for the warnings that aren’t really mechanical: the ones where the inspection is pointing at a design problem and calling it a syntax problem. A deprecation warning that requires knowing what the replacement API is meant to do. A complexity warning that means the method genuinely needs splitting and the split requires judgment about where the seams are. A thread-safety hint where the fix depends on how the object is used elsewhere in the codebase.

Those are the ones worth spending an agent turn on, and they’re maybe one in twenty of what’s in the gutter.

Why the temptation is so strong

Because the gutter looks like a task list, and a task list wants clearing. That’s the whole psychology of it. A file with fourteen weak warnings feels like fourteen small debts, and a tool that promises to pay them all in one turn is enormously attractive at four in the afternoon.

But most of those warnings aren’t debts. IntelliJ’s weak warnings and grey highlights are, by design, suggestions rather than defects. Plenty of them are stylistic preferences you’d argue with if a colleague raised them in review. Feeding all of them to a model doesn’t clear a backlog, it converts a list of opinions you were free to ignore into a diff you now have to read.

And the diff arrives all at once, mixed together, so the one change that mattered is sitting in the middle of thirteen that didn’t.

A practical rule

Before sending an inspection to the model, ask whether Alt+Enter offers a fix. If it does, take that one. If it doesn’t, ask whether the warning is telling you something about the design rather than the syntax. If it is, that’s an agent task, and it’s worth writing a proper prompt for rather than pasting the warning text.

Everything else is noise, and the correct response to noise is to configure the inspection profile so it stops appearing. Turning off an inspection you consistently disagree with is a legitimate engineering decision. Silently laundering it through a language model twice a week is not.

That’s the whole discipline: the model is the expensive tool, so it should get the expensive problems. Most of what the IDE flags isn’t one.

More field notes on JetBrains AI Assistant

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on JetBrains AI Assistant specifically, browse the full set at /blog/tag/jetbrains-ai/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.