Why JetBrains Air is worth a senior engineer’s attention
JetBrains has just introduced Air, a broader system for agentic software development that connects the IDE, coding agents, team coordination, governance, and cost visibility. The interesting part is not that another vendor has announced an AI coding product. The interesting part is the framing: AI can produce code, but organizations still have to produce software. That distinction matters for senior engineers because most real productivity gains no longer come from asking a model to write one function. They come from designing a workflow where agents can do useful work while humans still own architecture, review, risk, and release.
Air is positioned as a multi-surface product family rather than a single chatbot. It includes agentic capabilities inside JetBrains IDEs, team-level coordination for work performed by humans and agents, and governance controls that grew out of JetBrains Central. It also leans on the Agent Client Protocol, an open protocol created with Zed, so that different coding agents can connect to compatible editors without every vendor building a one-off plugin. In practical terms, JetBrains is saying that the future of development will be multi-agent and multi-vendor, but that professional teams need one place to see what is happening.
That thesis is very close to how experienced software teams already work. A senior developer rarely wants a black-box assistant that quietly rewrites a repository. We want a fast collaborator that can inspect code, draft changes, run commands, produce a diff, explain trade-offs, and then stop at a boundary where a human decides what is acceptable. Air is useful to track because it tries to make that boundary visible: agents can be directed from the IDE, their work can be coordinated at team level, and their activity can be governed at organization level.
What the tool is
JetBrains Air is best understood as an operating layer for AI-assisted development around JetBrains’ existing developer tools. At the individual level, Air in JetBrains IDEs gives developers a place to direct coding agents while using the deterministic code intelligence of IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, PhpStorm, and the rest of the JetBrains family. At the team level, Air Teams is intended to coordinate software-delivery workflows where humans and autonomous agents both participate. At the organizational level, Air Governance, previously JetBrains Central, provides policy, auditability, cost management, visibility, and accountability for AI-assisted work.
The product is also connected to Junie, JetBrains’ coding agent for professional development, but Air is not limited to Junie. JetBrains’ AI pages describe support for Junie, OpenAI Codex, Claude Agent, Gemini CLI, GitHub Copilot, Cursor, and other agents through ACP-compatible integrations. That is a significant architectural choice. If your team already has developers using different models for different tasks, a single-vendor mandate may be unrealistic. A governance layer that can observe and control several agents is more aligned with how adoption actually happens.
For day-to-day use, the related AI Assistant documentation gives a concrete view of the experience inside the IDE. Developers can use context-aware chat, invoke coding agents for multi-step work, connect external agents through ACP, use MCP tools, bring their own model keys where supported, and review or roll back changes. The important part is that the agent is not operating in an isolated browser tab with vague context. It is sitting next to project structure, symbols, inspections, refactorings, version control state, tests, and build tooling.
How to install or access it
The exact Air rollout will develop through a series of releases, so the safest way to adopt it today is to start with the components JetBrains already documents publicly. If you live in JetBrains IDEs, update your IDE through JetBrains Toolbox or the normal IDE updater, then install or enable AI Assistant where available. JetBrains documents that AI Assistant is not active by default in IntelliJ IDEA; you install the plugin, activate a JetBrains AI subscription or another supported authentication path, and explicitly accept the AI terms before it can access project context.
For agent workflows, open the AI Assistant documentation and review the pages for coding agents, Junie, Codex, Claude Agent, GitHub Copilot, ACP, MCP, and activation scenarios. The access model matters because teams may choose different modes: a JetBrains AI subscription for a curated experience, bring-your-own-key for approved providers, direct authorization to an agent provider, or local and external agents where policy permits. In an enterprise setting, do not let each developer improvise this alone. Decide which providers are allowed, which repositories are in scope, what data may leave the environment, and which commands require manual approval.
If your interest is interoperability rather than JetBrains specifically, read the ACP documentation. ACP standardizes communication between editors and agents using local subprocesses and, increasingly, remote transports. That means a compatible editor can host an agent without a bespoke integration for every pairing. For platform teams, this is worth watching because it creates a cleaner seam between the developer workbench and the agent harness. Internal agents can target the protocol instead of each IDE separately.
Concrete use cases for a senior developer
1. Repository orientation before touching code. A common senior-engineer bottleneck is not writing the first line of code; it is building a trustworthy mental model of a service. An agent connected to IDE context can summarize module boundaries, identify where a feature is implemented, list tests that cover the area, and point to risky dependencies. The human still decides the design, but the search phase becomes much shorter.
2. Safe multi-file refactoring. JetBrains IDEs are strong because they combine syntax, type information, indexes, inspections, and refactoring operations. An agent that can use that environment is better suited for changes like renaming a domain concept, updating API call sites, or migrating a configuration format. The productivity gain comes when the agent drafts the mechanical changes and test updates while the senior engineer checks semantic intent, compatibility, and migration risk.
3. Test generation and failure triage. Agents are useful when they can run tests, inspect failures, and propose a small patch. In an Air-style workflow, a developer can delegate the repetitive loop: reproduce the failing test, inspect stack traces, identify the likely regression, and prepare a candidate fix. The human should still review the final diff and add missing assertions, but the tedious investigation loop can move out of foreground attention.
4. Pull request preparation. A good PR is not just a diff. It needs a description, test evidence, risk notes, rollback thinking, and links to relevant issues. An agent with repository context can draft that material from the actual changes. This is a low-risk, high-return use case because the human can quickly edit the text while still gaining a more consistent review package.
5. Background maintenance work. The Air announcement emphasizes that work will increasingly be triggered by repository events, schedules, and delivery processes, not just by a prompt inside an editor. That opens practical uses such as dependency update preparation, flaky-test clustering, documentation drift checks, migration inventories, and release-note drafts. These tasks are important but easy to postpone; agents can prepare them for human review.
6. Team-level governance of agent activity. The real scaling problem is not whether one developer can get value from one agent. It is whether a team can understand what all those agents did, how much they cost, which code they touched, and who accepted the result. Air Governance is relevant because it treats visibility, policy, and accountability as first-class concerns instead of afterthoughts.
Where the productivity gain comes from
The realistic gain is not “replace developers.” It is reducing the amount of high-skill time spent on low-judgment loops. Senior engineers lose hours to codebase navigation, repetitive edits, initial test scaffolding, PR descriptions, release notes, and investigation work that follows a familiar pattern. If an agent can do 60 percent of that work and leave a readable diff plus an explanation, the engineer’s time shifts toward deciding whether the change is correct.
There is also a coordination gain. When agents work in isolated tools, knowledge fragments quickly: one conversation in a terminal, one in a browser, one in a desktop app, and one in a pull request. Air’s value proposition is that agent work should be visible in the same system where teams plan, review, and govern software. That is important because the verification cost of AI output can erase the generation benefit if the work cannot be traced.
For organizations already experimenting with several tools, the multi-vendor angle may be the most important part. Different models and agents are better at different tasks, and rankings change quickly. A senior team should avoid hard-coding its process to one vendor’s current advantage. A protocol-based, governable layer gives teams more freedom to choose the right agent for a task while preserving shared controls.
Limitations and risks
Air is a strategic system, not a magic safety net. Some pieces are available now, some are being rolled out, and teams should read the current JetBrains pages before assuming a specific feature is generally available in their environment. The announcement is explicit that the system will develop over time. Treat early adoption as an engineering rollout, not a switch you flip across the company.
Agent output also remains probabilistic. Even with IDE intelligence, agents can make plausible but wrong assumptions, overfit tests, miss business constraints, or introduce subtle architectural drift. The more code they can generate, the more important it becomes to keep small diffs, require tests, preserve code owners, and use branch protection. A senior developer should optimize the workflow so agents produce reviewable increments, not giant unowned patches.
Governance can fail if it is reduced to reporting after the fact. Before enabling broad agent use, define policy: which repositories are allowed, which secrets are blocked, which commands need approval, which data can be sent to cloud providers, how logs are retained, and who is accountable for merged work. AI governance should be close to engineering practice, not a document written after adoption has already happened.
A practical adoption path
Start with one repository and one workflow. For example, use AI Assistant or an ACP-connected agent to investigate flaky tests, draft missing unit tests, or prepare dependency-update PRs. Measure cycle time, review effort, defect rate, and developer satisfaction. Require every agent-produced change to include test evidence and a short explanation of what was touched. Keep the human reviewer responsible for merge decisions.
Next, standardize the project instructions that agents receive. Document build commands, test commands, code style, architectural boundaries, security constraints, and release requirements. If you use MCP or external tools, list exactly which ones are approved. The quality of agent work improves when the environment tells the agent how the team actually works rather than forcing every developer to restate rules in chat.
Finally, connect the governance layer before expanding usage. If agents will work across many repositories, leadership needs visibility into cost, access, audit trails, and outcomes. JetBrains Air is timely because it recognizes this organizational layer. The winners in AI-assisted development will not be the teams that generate the most code. They will be the teams that can delegate implementation safely while keeping humans in control of the software they ship.
