--- title: "Discussion on \"What Is JetBrains Air?\" | Hashnode" description: "Discussion on \"What Is JetBrains Air?\". Agents, Isolation, and the Engineering Review Loop" url: "https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55" --- [Feed](https://hashnode.com/feed) / Discussion # [What Is JetBrains Air?](https://daisuke.masuda.tokyo/article-2026-10-21-0400?utm_source=hashnode&utm_medium=feed) Agents, Isolation, and the Engineering Review Loop Oct 20 · 24 min read · daisuke.masuda.tokyo Read the article - [#ai-agents](https://hashnode.com/tag/ai-agents) - [#jetbrains](https://hashnode.com/tag/jetbrains) - [#developer-tools](https://hashnode.com/tag/developer-tools) - [#software-engineering](https://hashnode.com/tag/software-engineering) - [#code-review](https://hashnode.com/tag/code-review) ## Written by [Daisuke Masuda](https://hashnode.com/@x5gtrn) @x5gtrn · Hyogo, Japan [View profile](https://hashnode.com/@x5gtrn) DJ Ekusi, SAEKIKAZUMI Daisuke Masuda (born January 1982), also known as x5gtrn, SAEKIKAZUMI, or DJ Ekusi, is a Japanese software developer who aspires to gain recognition as a DJ. I balance programming and DJing as my lifelong pursuits and am a devoted enthusiast of both music and literature. I am a passionate admirer of Richie Hawtin, Sven Väth, Ryuichi Sakamoto, Ryu Murakami, Kenji Eno, and THA BLUE HERB. I draw inspiration from their creativity and vision. ## Responses 8 Markdown supported · ⌘↵ to post [Kartik N V J K](https://hashnode.com/@kartik-nvj) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad9f6b211f2c6d0c5124e48) 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? [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad9f6b211f2c6d0c5124e48#reply-6ada5daa13b6878167803eef) 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. [BotSailor](https://hashnode.com/@botsailor) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad9e855bc4868d3cac35f11) 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! [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad9e855bc4868d3cac35f11#reply-6ada5d6d8e426f81fa2b9401) 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. [Nube Colectiva](https://hashnode.com/@nubecolectiva) [Oct 21](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad929304f0fe0198b2f38f0) Interesting, I usually use JetBrain editors. Thanks for the info, Gray 👍🏼 [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad929304f0fe0198b2f38f0#reply-6ada5d2213b6878167803b9b) 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. 👍 [Abhinav Sharma](https://hashnode.com/@abhinavs1920) [Oct 21](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad8b82a0b893ee410285227) 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. [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Oct 22](https://hashnode.com/posts/article-2026-10-21-0400/6ad7ba53c429c7a403085e55/comment/6ad8b82a0b893ee410285227#reply-6ada5be613b6878167803570) 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.