Air Teams: Bring Your Best Agentic Workflows to the Whole Team – and Automate Repeatable Work The JetBrains Blog

Natalie The interesting part here is JetBrains basically saying the agent bottleneck is no longer you. It's your team.

Ansel Yeah.

Natalie And honestly, that is a much stronger claim than just, you know, here's another coding agent. Air Teams is their attempt to turn one person's weirdly effective setup into shared workflow infrastructure.

Ansel Right, and I buy that framing more than I buy most agent-platform launches. The article's actual argument is that solo gains don't compound unless prompts, environments, triggers, and review rules become team assets.

Natalie Which is very you. Also very them, to be fair. JetBrains looked at agentic coding and said, what if the exciting future was startup scripts and permissions.

Ansel Okay, that's good.

Natalie I mean come on, that's almost a year of us doing this show. Of course episode ten twenty-four is me getting excited about versioned shell scripts.

Ansel Mm-hm.

Ansel But the reason it works is they gave concrete shapes, not just vibes. Automations are triggered by a GitHub event, Jira event, webhook, or schedule. They reuse instructions, tools, and an environment, so the task is not re-invented every run.

Natalie And the examples help. Review every new pull request. Fix small tagged issues from YouTrack. Update dependencies twice a week, run builds and tests, then either patch breakage or revert the upgrade. That is actual repeatable work teams already have.

Ansel Yeah.

Ansel The dependency example is the best one. One open pull request at a time, close the stale one, list applied and skipped upgrades, revert when needed. That's somebody thinking about operational noise, not just demo theater.

Natalie That's the product test for me. Does it reduce side quests, or create them. Their whole pitch only lands because they keep saying the agent should not block the workflow, and every code change still arrives as a pull request an engineer merges or rejects.

Ansel Exactly.

Ansel Technically, the strongest move might be the environment model. The setup lives in the repo at dot air slash cloud slash startup dot sh. You can review it, version it, and reuse it. Therefore the agent is not burning tokens rediscovering how to build the repo every single time.

Natalie Right, and that is basically your boring camp from the workspace fight. Shared context is nice. Shared presence is cute. But if the agent cannot actually reach the package registry, the issue tracker, or the right toolchain version, none of the rest matters.

Ansel Yeah, no, that's exactly the live split. Social layer versus coordination plumbing, and this is very obviously round whatever of the boring camp. I think they're right to plant there.

Natalie Where I do hesitate is setup cost. They say you can let an agent inspect the repo, run the install and build, ask for missing secrets, and commit a tested startup script for review. Nice. But somebody still owns the weird edge cases, the domain allowlist, the secret boundaries, all that annoying stuff.

Ansel Sure.

Ansel And that's where the argument can overgeneralize a little. This is not for every team that touched an agent once. It's for teams with enough repeated work, enough repo complexity, and enough review discipline that centralizing the setup pays back.

Natalie Business customers first also kind of gives the game away. This is for orgs already feeling the pain of ten different personal agent rituals. If you're a single developer, this is mostly aspirational until they ship individual access.

Ansel No way I'd call that a weakness, though. That's the right customer. You had that line a while back about big wrappers earning their keep only when they collapse real glue work. This is one of the cleaner examples.

Natalie Oh, you remembered my own take against me. Rude. But yes, that's why I think this matters. It's not selling magic intelligence. It's selling reuse, control, and not tying up your laptop while an agent does boring work in parallel.

Ansel My only real technical question is how well the review-feedback loop holds up in practice. The article says the issue-fix automation can pick up teammate comments or the code-review automation's comments and then revise the pull request. That could be great, or it could become very thoughtful wallpaper if the comments arrive at the wrong time.

Natalie That is such an us sentence. But you're right. The product lives or dies on attention control. One current review, one current dependency PR, visible history of tool calls and conversation. If those guardrails hold, this ships as workflow, not theater.

Ansel Natalie, that's the part that won me over. They did not claim agents replaced the team. They claimed teams can bottle the workflows that already work. That's narrower, and a lot more believable.

Natalie Yeah. Very unsexy. Pretty compelling. I cannot believe Exploring Next is once again about the glamour of not making everyone rebuild the same environment twice.