O GitHub deixa a empresa definir o modelo padrão do Copilot nas IDEs JetBrains. Padrão não é política

A maioria das pessoas nunca muda uma configuração padrão. É por isso que padrões são poderosos, e é por isso que é fácil confundi-los com controles.

A atualização de 10 de outubro do Copilot para as IDEs JetBrains traz duas configurações que os administradores enterprise vão notar. Por meio das managed settings, eles agora podem “escolher qualquer modelo de agente do Copilot disponível como padrão para novas conversas”. E uma nova configuração “permite desativar a inicialização automática de servidores para o Copilot e o Claude”, ou seja, os servidores MCP não precisam mais subir no momento em que a IDE abre. O release também traz uma ação Fix que envia os diagnósticos da IDE ao Copilot, melhorias de confiabilidade em sessões, worktrees e troca de modelos, e uma exigência: JetBrains IDE 2025.2 ou superior, já que o suporte à 2025.1 acabou.

O que um modelo padrão faz

Um padrão orienta. Se a maioria dos desenvolvedores mantém o modelo com que a conversa começa, o padrão da empresa decide a maior parte do gasto e do comportamento em milhares de sessões. Escolher um modelo eficiente como ponto de partida, com o modelo de fronteira a um clique, é uma alavanca de custo sensata, a mesma lógica que aplicamos ao pagar por velocidade só onde alguém está esperando.

Mas o GitHub deixa claro que a escolha explícita do usuário no seletor de modelos é preservada. O padrão define onde as pessoas começam, não aonde podem ir. Restringir quais modelos estão disponíveis é outra decisão, tomada nas políticas de modelos do Copilot da organização. Tratar o novo padrão como restrição deixaria uma distância entre o que o administrador acredita e o que os desenvolvedores conseguem fazer.

O que o início automático do MCP faz

A configuração de MCP é parecida. Desligar a inicialização automática muda quando os servidores MCP configurados sobem: sob demanda, e não junto com a IDE. Isso reduz o número de conexões de ferramentas rodando em segundo plano em cada máquina de desenvolvedor, o que é boa higiene. Não decide quais servidores MCP são permitidos, ao que eles têm acesso nem quais credenciais carregam. O changelog também não diz se a configuração é gerenciada centralmente ou escolhida por cada desenvolvedor.

As perguntas que governam o risco do MCP continuam onde estavam: quais servidores são permitidos, sob qual identidade agem e onde o tráfego deles é registrado, a lacuna que descrevemos em MCP conecta, mas não governa.

Use as duas, com o rótulo certo

Nada disso diminui a atualização. A governança de agentes de código está entrando na IDE, onde os desenvolvedores de fato trabalham, e essas configurações facilitam definir uma base consistente em toda a frota. A disciplina está nos rótulos:

• Padrões definem o ponto de partida: qual modelo, quais servidores sobem. Moldam custo e consistência.
• Políticas definem o limite: quais modelos e ferramentas são permitidos. São elas que o auditor vai perguntar.
• Versões definem o piso: uma frota de IDEs ainda na 2025.1 acabou de perder o suporte do plugin, o que é um risco em si.

Escreva quais dos seus controles do Copilot são padrões e quais são políticas. Se a lista de políticas for curta, o modelo padrão não é um controle. É uma sugestão que a maioria vai aceitar.