Copilot no Air: execução remota não elimina revisão nem controle de orçamento

O JetBrains Air passou a permitir a escolha do GitHub Copilot como agente, executado pelo Copilot CLI oficial via Agent Client Protocol.[7] As tarefas consomem o plano e os créditos do GitHub, não créditos JetBrains AI.[7] O uso local não exige Air Teams; a execução remota exige esse serviço empresarial e uma assinatura Copilot.[7]

Para avaliar a integração, eu separaria conveniência de execução, qualidade da mudança e previsibilidade de custo. São três entregas diferentes, mesmo quando aparecem na mesma interface.

O que muda para quem desenvolve

Cada tarefa remota recebe uma máquina virtual própria; o Copilot roda em um contêiner Docker autenticado com a conta do usuário, o tráfego passa por um proxy e o ambiente não é reaproveitado na tarefa seguinte.[7] A tarefa continua após o notebook ser desligado, e as modificações ficam disponíveis para revisão.[7]

Isso permite deslocar a execução para outro ambiente, mas minha recomendação é preservar um contrato de entrada preciso: repositório, branch, revisão inicial, objetivo e critério de aceite. Sem essa referência, comparar a entrega do agente com a intenção original vira uma atividade subjetiva.

Como o repositório e a branch remotos são selecionados no GitHub, alterações locais precisam ser enviadas antes de iniciar a tarefa.[7] Eu registraria o commit de partida na revisão para evitar atribuir ao agente diferenças que pertenciam a trabalho ainda não sincronizado.

Como aplicar

Comece com uma correção delimitada em um repositório autorizado para processamento remoto. Escolha um defeito reproduzível e forneça um critério de aceite observável. Evite começar por uma refatoração aberta ou pela revisão automática de todas as mudanças.

Avalie o diff, o resultado funcional, o tempo de revisão humana e o consumo correspondente no GitHub. Proponho comparar essa execução com o fluxo local para a mesma classe de tarefa, sem presumir que retirar a carga do notebook reduz o esforço total.

Defina também a saída em caso de interrupção: como localizar a mudança parcial, como identificar a revisão de origem e quem decide retomá-la. Para automações, prefira eventos de escopo estreito e uma política explícita para aceitar ou rejeitar alterações.

Cuidados e limites

O Air não mostra o consumo do Copilot, não impõe teto e não avisa quando os créditos terminam; uma assinatura ativa pode iniciar uma tarefa que falha logo depois por falta de saldo.[7] A aceitação dos planos depende das regras do próprio Copilot CLI.[7]

Portanto, eu não trataria a interface do Air como painel financeiro completo. Também não confundiria isolamento com autorização para enviar código a outro ambiente. A recomendação prática é verificar as condições de uso do repositório, acompanhar o gasto na origem e exigir revisão da mudança produzida. Autonomia na execução não é autonomia para aprovar a própria entrega.

Fonte

[7] Fonte: JetBrains Blog