MPS: corrija o runtime antes de avaliar o agente MCP

A JetBrains anunciou MPS 2026.1.2, 2026.2 RC2, 2025.3.3, 2025.2.5 e 2025.1.5 para corrigir um problema crítico de segurança relacionado a certificados eMudhra comprometidos, com impacto em JBR e JCEF.[3] O comunicado também alerta que aplicações RCP baseadas em MPS podem ser afetadas.[3]

O anúncio reúne duas pautas que eu separaria no planejamento: corrigir o ambiente distribuído e experimentar novas ferramentas de agentes. Uma não precisa esperar pela conclusão da outra.

O que muda para quem desenvolve

Nas versões MPS 2025.1.5 e 2025.2.5, a orientação inclui uma providência adicional: desligar ide.browser.jcef.enabled no registro de configurações do MPS.[3] Nessas linhas, portanto, o critério de conclusão não deveria ser apenas ter instalado a atualização.

Minha recomendação é tratar o runtime entregue ao usuário como item próprio do inventário. Se você distribui uma aplicação derivada, confira o pacote efetivamente distribuído, não somente a versão da ferramenta usada pela equipe. O alerta sobre aplicações RCP torna essa distinção especialmente relevante neste caso.[3]

Na frente funcional, MPS 2026.1.2 e 2026.2 RC2 recebem melhorias do Projectional Agent Toolkit, incluindo API consolidada de ferramentas MCP, ferramenta de sistema de tipos, ações de intenção, correções rápidas e acesso aos logs.[3] O anúncio recomenda atualizar as skills de MPS existentes nos projetos.[3] Essas novidades não são atribuídas às versões de 2025, que recebem somente a correção de segurança.[3]

Como aplicar

Eu organizaria a ação corretiva em uma tabela com versão instalada, versão do pacote distribuído, necessidade de desativar JCEF e responsável pela entrega. Para cada linha aplicável, registre a atualização e a configuração efetiva, sem presumir que todas as instalações seguem o mesmo procedimento.

Em uma trilha independente, avalie o agente em uma cópia de um projeto de linguagem específica de domínio. Escolha uma alteração pequena e estabeleça previamente o resultado esperado. Peça uma transformação delimitada, examine o diff e confira o modelo resultante com as validações do projeto.

Compare a intervenção via ferramentas estruturadas com uma edição assistida mais simples. Registre operações solicitadas, mudanças realizadas, erros detectados e esforço de revisão. Isso permitiria decidir pelo ganho observado, sem atribuir ao anúncio um benchmark que ele não fornece.

Cuidados e limites

O comunicado cita ganhos de desempenho, mas não apresenta números que permitam quantificá-los; tampouco sustenta generalizar o impacto de segurança a qualquer produto Java.[3] A versão 2026.2 RC2 continua sendo uma candidata a lançamento, não uma razão automática para trocar a linha adotada em produção.[3]

O trade-off é preservar estabilidade enquanto se avaliam ferramentas mais capazes. Minha escolha seria corrigir primeiro o que já está em uso e exigir evidência separada para ampliar permissões ou incorporar automação ao fluxo de desenvolvimento.

Fonte

[3] Fonte: JetBrains Blog