Air
An agentic development environment
Air Teams: leve seus melhores workflows agênticos para toda a equipe – e automatize o trabalho repetitivo
Hoje, apresentamos o JetBrains Air Teams – a camada de equipe para o desenvolvimento agêntico. Ele oferece a humanos e agentes o contexto compartilhado, os ambientes, as ferramentas e as instruções de que precisam para trabalhar juntos de forma eficaz ao longo de todo o ciclo de vida de desenvolvimento.
O Air Teams já está disponível para clientes corporativos da JetBrains, com planos de expandir o acesso a clientes individuais mais adiante.
O novo capítulo: de desenvolvedores individuais para equipes
Apresentamos o aplicativo Air há alguns meses, como nosso primeiro passo rumo ao desenvolvimento agêntico. Desde então, aprendemos bastante e vimos ganhos reais de produtividade para desenvolvedores que trabalham com agentes.
Conforme continuamos a desenvolver o Air, duas coisas ficaram cada vez mais claras. Primeiro, os desenvolvedores não precisam de mais um aplicativo independente: ferramentas e agentes devem ser integrados ao ambiente onde eles já operam. Segundo, à medida que os desenvolvedores individuais se tornaram mais produtivos com agentes, o verdadeiro gargalo começou a se deslocar para o nível da equipe.
É por isso que estamos expandindo o Air, que deixa de ser um aplicativo de desktop independente para se tornar um sistema mais amplo. Agora, o Air oferece suporte ao desenvolvimento agêntico em três níveis: desenvolvedores individuais, equipes e organizações. Vamos dar uma olhada mais de perto no que o Air Teams traz para as equipes de engenharia.
O que é o Air Teams?
O Air Teams é um ambiente compartilhado onde equipes de engenharia executam agentes de programação e reaproveitam o que funciona. Hoje, a maior parte do trabalho agêntico acontece em computadores individuais: cada desenvolvedor tem sua própria configuração e seus próprios prompts, e o que funciona para uma pessoa não é aproveitado facilmente pelo resto da equipe. O Air Teams reúne seus workflows agênticos em um só lugar: o que um desenvolvedor descobre, todos podem usar.
O Air Teams tem quatro partes:
As automações cuidam sozinhas do trabalho recorrente, como revisões de código, correções de issues e atualizações de dependências. Um evento ou um agendamento inicia cada execução.
Os ambientes de nuvem compartilhados dão aos agentes as ferramentas, dependências e credenciais de que precisam para compilar e testar o código. A equipe configura o ambiente uma única vez, e ele é reusado por todos.
As tarefas na nuvem executam nesses ambientes, em paralelo, sem ocupar o computador de ninguém. Você pode iniciá-las e acompanhá-las pelo IDE ou navegador e, em breve, também pelo celular.
Os projetos reúnem tudo isso, com créditos compartilhados, papéis claros e Automations que não dependem de uma única pessoa.
Vamos conhecer cada parte em detalhes.
Automações: não é mais necessário ficar cuidando de agentes
Agentes trabalham rápido, mas ainda dependem de humanos para iniciar tarefas, fornecer instruções e prosseguir para a etapa seguinte. Em algum momento, orquestrar manualmente cada execução se torna o gargalo.
Air Automations são workflows agênticos que rodam sozinhos, na nuvem, acionados por um evento ou um agendamento, em vez de por uma pessoa. Elas são ativos compartilhados da equipe: um desenvolvedor pode criar uma Automation, e toda a equipe pode executá-la, reutilizá-la e aprimorá-la. O que funciona bem para uma pessoa pode se tornar parte de como toda a equipe trabalha. Por exemplo, uma automação pode revisar cada novo pull request assim que ele for aberto, ou atualizar dependências duas vezes por semana.
Como as automações funcionam
As automações servem para trabalho recorrente que segue um padrão: um pull request que precisa ser revisado, uma issue rotulada que precisa ser investigada, ou dependências que precisam ser verificadas toda semana.
Você configura quatro coisas de uma só vez e a automação as reutiliza em cada execução:
Instruções: o que o agente deve fazer.
Ambiente: onde o agente é executado.
Ferramentas: o que o agente pode usar, incluindo Jira, Figma e Linear através de conectores.
O acionador: decide quando o agente é iniciado; pode ser um evento do GitHub ou do Jira, um webhook ou um agendamento. Outros tipos de acionador estão a caminho.
Aqui está um exemplo: uma Automation acionada por uma etiqueta. Quando rotula um issue como um Bug, a automação inicia um agente. O agente lê a issue e o ticket vinculado do Jira, encontra a causa no código e abre um pull request com uma correção proposta para um engenheiro revisar.
As automações pertencem a um projeto de equipe, portanto toda a equipe usa a mesma automação em vez de cada pessoa criar a sua própria. Depois que uma Automation prova seu valor, ela pode ir além do projeto: a equipe pode reutilizá-la em outro repositório ou salvá-la como um modelo que qualquer pessoa na organização pode usar como está ou adaptar.
Exemplos de automações
Aqui estão três automações que usamos na nossa própria equipe:
Revisões de código. Quando um pull request é aberto, um agente lê o código relevante e a discussão, publica comentários inline e um resumo, e pode aprovar o pull request ou solicitar alterações. Cada novo commit inicia outra execução: o agente lê sua revisão anterior e quaisquer respostas, anota quais problemas foram corrigidos e quais permanecem, e recolhe suas revisões antigas para que apenas a mais recente fique visível. Um agente de IA deve ajudar seu workflow, não bloqueá-lo. Quando você decide tratar uma issue em um pull request separado, o agente respeita sua escolha e conclui sua verificação.
Correções de issues. Quando um colega de equipe marca uma issue pequena e bem delimitada no YouTrack, um agente obtém o contexto, tenta uma correção e abre um pull request para revisão. A mesma automação também processa o feedback das revisões. Quando um pull request aberto por uma automação recebe comentários de revisão, seja de um colega de equipe ou da automação de revisão de código, o agente os recebe e os corrige.
Atualizações de dependências. Duas vezes por semana, um agente atualiza as dependências do projeto, ignorando aquelas que suas instruções indicam para deixar de lado. Ele faz o build do projeto e executa os testes. Quando uma atualização quebra algo, o agente corrige o código afetado sem alterar seu comportamento, ou reverte a atualização caso não consiga. Em seguida, ele abre um pull request listando quais atualizações foram aplicadas, ignoradas ou revertidas. Se o pull request anterior ainda não tiver passado por um merge, o agente o fecha, para que a equipe sempre tenha um único pull request atualizado para fazer o merge dele quando estiver pronto.
Vamos abordar mais automações em posts futuros, incluindo como são configuradas e usadas.
Mantenha o controle
Uma preocupação importante em relação aos agentes de IA é o ruído criado: comentários que ninguém lê e pull requests que ninguém pediu. As automações mantêm as decisões nas mãos da equipe. São os engenheiros quem escolhem no que um agente trabalha, e suas instruções podem manter o resultado enxuto, como nos exemplos acima: um único pull request aberto para atualizações de dependências, uma única revisão atual por pull request. Cada execução também mantém a conversa completa do agente e as chamadas de ferramentas, então, quando um resultado parece errado, a equipe pode investigar e descobrir o motivo. Toda alteração de código chega como um pull request, e um engenheiro decide se deve-se fazer merge dela ou não.
Ambientes de nuvem compartilhados: uma configuração que pode ser reusada pela sua equipe e seus agentes
Toda automação, assim como toda tarefa na nuvem, é executada num ambiente, e um agente só consegue trabalhar tão bem quanto for permitido pelo seu ambiente. Antes de conseguir compilar ou testar qualquer coisa, ele precisa do mesmo que um novo engenheiro precisa no primeiro dia: as ferramentas certas, dependências, credenciais e acesso à rede. Um projeto pequeno pode funcionar com as configurações padrão, mas a maioria das bases de código precisa de mais, como um registro de pacotes privado, versões fixas do toolchain ou um rastreador de issues interno que o agente precise acessar. Alguém precisa configurar isso, e uma única vez deve ser suficiente.
No Air Teams, essa configuração fica em um ambiente de nuvem compartilhável. Você cria um para um repositório no projeto da sua equipe. Escolha o tamanho da VM, decida quais domínios a máquina pode acessar e adicione as variáveis e os segredos de que a build precisa. A configuração em si fica no seu repositório em .air/cloud/startup.sh, então sua equipe a versiona e revisa junto com o resto do código.
Você também pode delegar a primeira revisão a um agente. Ele inspeciona o repositório, executa a instalação e a build reais, pede quaisquer segredos que estejam faltando e faz o commit de um script de inicialização testado em uma branch separada. Você faz a revisão dele como qualquer outra alteração.
Quando o ambiente está pronto, o Air o salva como um snapshot e você o compartilha com a equipe. Compartilhar a configuração não significa compartilhar credenciais. Segredos compartilhados permitem que seus colegas de equipe e as automações usem um valor sem vê-lo, enquanto segredos pessoais e o acesso ao repositório permanecem com acesso limitado a cada pessoa.
Daí em diante, os colegas de equipe escolhem o ambiente para suas tarefas na nuvem, e as automações do projeto são executadas nele. Nenhum agente gasta tempo e tokens redescobrindo como compilar o repositório. Toda tarefa começa diretamente com o trabalho real.
Aprenda a configurar ambientes
Tarefas na nuvem: trabalhe no seu IDE e de qualquer dispositivo
Com os ambientes configurados, você pode começar a delegar tarefas aos agentes. Escolha um ambiente e um agente e, depois, descreva a tarefa. Se o seu repositório não precisar de uma configuração personalizada, use o ambiente padrão.
Você pode executar uma tarefa localmente ou na nuvem. A escolha ideal depende da tarefa, da configuração necessária e de quão de perto você quer trabalhar com o agente.
| Agente local | Agente na nuvem | |
| Como começar | Um workspace já existente fica pronto imediatamente. Uma nova worktree ou um novo container pode precisar ser configurado primeiro. | O ambiente precisa iniciar e copiar o repositório primeiro. Configurá-lo com antecedência e salvá-lo como um ambiente compartilhável com estado em cache vai reduzir a espera. |
| Recursos da máquina | As builds e os testes compartilham a CPU e a memória da sua máquina com o restante do seu trabalho. | As builds e os testes são executados em uma máquina na nuvem, preservando os recursos locais. |
| Arquivos e ferramentas | O agente trabalha com suas ferramentas locais e sua cópia de trabalho, incluindo alterações não commitadas. | O agente trabalha a partir de uma branch remota, com as ferramentas, dependências e credenciais configuradas para o ambiente. |
| Agentes e contas | Você pode usar qualquer agente compatível ou compatível com ACP que tenha instalado, com uma conta que ele suporte. | Você pode usar os agentes na nuvem compatíveis que sua organização habilitou. |
| Reutilizando a configuração | Os colegas de equipe podem compartilhar scripts de configuração, mas cada pessoa ainda precisa preparar sua própria máquina. | Os colegas de equipe compartilham um único ambiente, e cada tarefa é executada numa cópia dele. |
| Acompanhamento | Sua máquina precisa ficar ligada. O acesso remoto depende das suas próprias ferramentas. | A tarefa continua em execução mesmo se sua máquina estiver desligada. Você pode acompanhar pelo Air nas IDEs da JetBrains ou pela web, e em breve também no celular. |
A principal diferença é que as tarefas na nuvem não ficam presas ao dispositivo onde foram iniciadas. Você pode iniciar uma tarefa na sua IDE e retomá-la depois pela web. O agente continua trabalhando mesmo depois que você fecha seu computador.
Veja o workflow das tarefas na nuvem
Projetos de equipe: um trabalho que pertence à equipe
Um projeto de equipe é um espaço compartilhado para o trabalho agêntico de uma equipe. Ele reúne membros da equipe, ambientes compartilhados, conectores MCP e automações.
Duas funções definem quem pode fazer o quê. Os administradores do projeto gerenciam a associação de membros, os ambientes, os conectores e as automações. Eles também podem permitir que membros específicos editem um ambiente. Os membros usam os ambientes compartilhados, criam suas próprias automações e veem os resultados de cada execução.
As automações não precisam depender da pessoa que as criou. Cada projeto tem sua própria conta de serviço e seus próprios créditos de IA, e um administrador do projeto decide se as automações do projeto usam esses créditos ou os de seus criadores. Com os créditos do projeto, as automações são executadas na conta do projeto e continuam sendo executadas depois que seus criadores saem.
Saiba mais sobre funções de projeto e créditos
Comece a usar o Air Teams
Com o Air Teams, o trabalho agêntico se torna algo que toda a equipe compartilha. As automações cuidam do trabalho recorrente, os ambientes compartilhados dão a mesma configuração para cada tarefa, as tarefas na nuvem continuam em execução depois que você fecha o computador, e os projetos de equipe garantem que nada disso dependa de uma única pessoa.
Experimente o Air Teams em air.jetbrains.cloud. Tudo o que foi descrito acima foi criado para ser compartilhado, então convide seus colegas de equipe desde o início.
Para conhecer toda a família de produtos Air, visite jetbrains.com/air.
Artigo original em inglês por:
