Os resultados das instalações e atualizações podem ser diferentes a cada vez, mesmo com exatamente o mesmo modelo, mas fica muito pior se você atualizar ou trocar de modelo. Se você estiver oferecendo suporte à infraestrutura por cinco, 10 ou 20 anos, você vai estar atualizando modelos. É difícil imaginar o que o mundo de IA generativa será daqui a ten anos, mas tenho certeza de que Gemini 3 e Claude Opus 4.5 não estarão por aí.
Os perigos dos agentes de IA aumentam com a complexidade
“Aplicativos” corporativos não são mais servidores únicos. Hoje, eles são constelações de sistemas — front-ends da Internet, camadas de aplicativos, bancos de dados, caches, agentes de mensagens e muito mais — frequentemente implantados em diversas cópias em diversos modelos de implantação. Mesmo com apenas alguns tipos de serviços e três áreas básicas (pacotes em um servidor tradicional, hosts baseados em imagens e contêineres), as combinações se expandem em dezenas de permutações antes que alguém tenha escrito uma linha de lógica de negócios. Essa complexidade torna ainda mais tentador pedir a um agente que “simplesmente cuide da situação” – e ainda mais perigoso quando isso acontece.
Em nativo da nuvem lojas, Kubernetes apenas amplifica esse padrão. Um aplicativo “simples” pode abranger vários namespaces, implantações, conjuntos com estado, controladores de entrada, operadores e serviços gerenciados externos, todos unidos por meio de YAML e definições de recursos personalizados (CRDs). A única maneira sensata de executar isso em escala é tratar o cluster como um sistema declarativo: GitOpsimagens imutáveis e YAML armazenados em algum lugar fora do cluster e com versão controlada. Nesse mundo, o trabalho de uma IA agente não é aplicar hot-patch em pods em execução, nem no YAML do Kubernetes; é para ajudar os humanos a projetar e testar os manifestos, gráficos do Helm e pipelines que são salvos no Git.