Discussion on "What Is JetBrains Air?"

Daisuke Masuda · 2026-10-20T19:00:35.288Z

In my earlier article, “Where Is JetBrains AI Heading? — Central CLI, Air, and the Agentic Development Stack”, I explored the layers surrounding a coding agent: the developer interface, agent integrat

The 60 minutes shrinking to a 15 minute saving is the number I wish more agent comparisons showed, because the two-minute patch is the only part anyone screenshots. In my runs the repair minutes swing the most between tasks that look the same size. In the pilot you outline, would you report rework minutes per failure class, or one total next to the class counts?

I’d report both, with total rework time per task as the headline and a breakdown by failure class underneath. Class counts alone can hide the difference between five quick fixes and one issue that takes an hour to untangle.

For a small pilot, I’d keep the logging lightweight: minutes spent diagnosing, repairing, and revalidating, plus a primary failure class—such as misunderstood requirements, missing context, environment problems, or regressions. If one repair spans several classes, I’d record the time once and note the overlap rather than force a precise split.

Your point about variability matters, too. I’d show individual task results alongside the median and range, including abandoned attempts. That would make it easier to see whether the savings are repeatable or whether a few expensive repairs wipe them out. The useful comparison is how much human effort it takes to reach an accepted change.

Really enjoyed this deep dive. What stood out to me was the emphasis on the work around the agent, not just the code it generates. Context, environment, permissions, testing, and especially human review can easily become the real bottlenecks.

I also liked the idea of treating an agent task as more than just a prompt—having a clear goal, starting revision, constraints, acceptance criteria, and ownership makes the result much easier to evaluate.

The reminder that “tests passed” isn’t the same as “the change is correct” is probably one of the most important points here. AI can speed up the implementation, but the engineering judgment still has to remain in the loop. Great practical perspective!

Thanks for such thoughtful reading! You’ve picked up on the part I most wanted to emphasize: faster implementation makes the surrounding engineering work more visible, and often more important.

For me, a useful review question is: “What could still be wrong even if every test passes?” The tests might encode the wrong assumption, miss a compatibility requirement, or never exercise the failure path that matters in production. A clear task contract gives us a basis for asking those questions—but we still have to challenge the contract itself.

That’s where I see agents being most useful: helping us gather evidence and explore those gaps, while a human remains accountable for deciding whether the change is ready to ship.

Interesting, I usually use JetBrain editors. Thanks for the info, Gray 👍🏼

You’re welcome! As a fellow JetBrains user, I’d love to hear what you think of Air if you get a chance to try it. 👍

Treating the task, not the edit, as the unit of work is the real shift - it forces the contract into the context instead of leaving it in the reviewer's head. Review producing evidence rather than a confident summary is the part most agent workflows still skip.

That’s exactly the connection I hoped to make. If the contract stays in the reviewer’s head, the agent and reviewer can end up working from different definitions of “done.”

I’d take it one step further: define the evidence when assigning the task. Which behavior must change, what must stay compatible, and which check would fail if the fix were wrong? That gives the agent a clearer target and the reviewer something concrete to challenge. A second agent’s review can help, but it still needs to point to a reproducible issue or a missing check.

Search Hashnode

What Is JetBrains Air?

Responses8