JetBrains Air Teams gives agentic coding a shared home
JetBrains has taken its Air coding agent beyond the desktop, giving engineering teams shared cloud environments, reusable automations and tasks that keep running after the laptop closes.

JetBrains has introduced Air Teams, a shared layer for agentic development that gives people and their coding agents the same context, environments, tools and instructions. The company frames it as the point at which agentic development stops being one developer's workflow and becomes a team's.
Air Teams is available now to JetBrains business customers, with access for individual customers promised later. It lands a few months after the standalone Air app, which JetBrains launched as its first real step into agentic development.
From one laptop to a shared workspace
JetBrains' diagnosis of the status quo is blunt: most agentic work happens on individual laptops. Every developer has their own setup and their own prompts, and whatever works for one person rarely spreads to anyone else. Air Teams is an attempt to put that work in one place, so that what one developer figures out, the rest of the team can use.
The company is also repositioning Air itself. Having shipped a desktop app, JetBrains concluded that developers do not want another standalone application, and that the real bottleneck shifts to the team level once individuals get faster. Air now spans three levels: individual developers, teams and organisations.
Automations that outlive their author
The centrepiece is Automations: agentic workflows that run in the cloud, started by an event or a schedule rather than by a person. Each one reuses four things configured once — the instructions, the tools available to the agent, a trigger and an environment — and belongs to a team project rather than to whoever built it.
The examples JetBrains gives are the recurring jobs that eat a team's week. A code review Automation reads a new pull request, posts inline comments and a summary, and can approve it or request changes; on each new commit it reads its own earlier review, notes what was fixed and what was not, and collapses the old reviews so only the latest stays visible. An issue-fix Automation picks up a small, well-scoped ticket tagged in YouTrack, traces the cause through the code and opens a pull request. A dependency Automation runs twice a week, upgrading packages, building the project, running the tests, repairing what it can and reverting what it cannot.
JetBrains addresses the obvious objection head-on. Agents generate noise — comments nobody reads and pull requests nobody asked for — so every Automation keeps the decisions with the team: one open pull request for dependency updates, one current review per pull request, and a full record of the agent's conversation and tool calls for when a result looks wrong. Every code change still arrives as a pull request for an engineer to merge.
Automations can also outgrow the team that wrote them, reused on another repository or saved as a template the wider organisation can adopt. Connectors bring in Jira, Figma and Linear.
Environments, tasks and who pays
Every Automation runs in a cloud environment, and the argument is that an agent can only perform as well as its environment allows. A shared environment holds the toolchain versions, private package registries and credentials a repository needs, with the setup committed to the repository at .air/cloud/startup.sh so the team versions and reviews it alongside the code. A configured environment is saved as a snapshot and shared; shared secrets can be used without being seen, while personal secrets and repository access stay with each individual.
Cloud tasks run in those environments, in parallel, and are not tied to the machine that started them. A task begun in the IDE can be picked up later in a browser, and the agent keeps working after the laptop closes, with phone support promised. Two roles govern a project: administrators manage membership, environments, connectors and Automations, while members use the shared environments, build their own Automations and see the results of every run. Each project also gets its own service account and AI credits, so an Automation can keep running after the person who created it has moved on.
Our opinion
JetBrains is late to this fight and appears to know it. GitHub and others have been pushing agent-authored pull requests for a while, and every IDE vendor now claims an agent story. What Air Teams offers that a chat panel does not is a genuine answer to the coordination problem: shared environments and team-owned automations are the unglamorous plumbing that decides whether agents save an hour or cost one.
The dependency Automation is the tell. Upgrading packages, running the tests, fixing what breaks and reverting what cannot be fixed is exactly the low-judgement, high-annoyance work an agent should own, and JetBrains is admirably honest that the value sits in the constraints — one open pull request, no duplicate reviews, every change still a pull request. Anyone whose team has drowned in agent-generated noise will recognise the design choices.
The reservation is the same one that hangs over the whole category. Restricting Air Teams to business customers means JetBrains is selling to the organisations that already pay for its tooling, and the pitch — better collaboration, pooled credits, automation that outlives its creator — doubles as an argument for buying more seats and more credits. The plumbing is sound. Whether it is worth the licence is a question each team will answer against its own cloud bill.