A IA não deveria criar pipelines. Ela deveria entregar o software em produção.

Depois de anos trabalhando com SRE, DevOps, Kubernetes, Terraform, GitOps, pipelines e observabilidade, comecei a me fazer uma pergunta incômoda:

Estamos realmente transformando a engenharia com IA ou apenas usando uma tecnologia nova para produzir mais rapidamente os mesmos artefatos de sempre?

Hoje usamos inteligência artificial para criar:

• pipelines de deploy;
• módulos Terraform;
• Helm Charts;
• manifestos Kubernetes;
• dashboards;
• alertas;
• queries;
• testes;
• runbooks;
• pull requests;
• documentação.

Isso aumenta a produtividade. Não há dúvida.

Mas também pode estar criando uma nova forma de overengineering assistido por IA.

Em vez de diminuir a complexidade operacional, estamos usando IA para gerar ainda mais YAML, scripts, templates, dashboards e camadas que foram originalmente criados para humanos operarem sistemas.

Estamos ensinando a IA a trabalhar como nós.

Talvez esse seja o erro.

Estamos automatizando o processo errado

Imagine que precisamos colocar uma nova versão de uma aplicação em produção.

No modelo atual, podemos ter algo como:

Código
  ↓
Pull request
  ↓
Pipeline de build
  ↓
Testes
  ↓
Imagem no registry
  ↓
Alteração no Helm Chart
  ↓
Merge no repositório GitOps
  ↓
Sincronização do ArgoCD
  ↓
Rollout no Kubernetes
  ↓
Dashboard
  ↓
Validação humana

Esse fluxo não é necessariamente ruim.

Ele existe porque humanos precisam de processos previsíveis, interfaces visuais, etapas explícitas e trilhas de auditoria para operar sistemas complexos com segurança.

O problema aparece quando colocamos um agente de IA nesse processo e pedimos:

Crie uma pipeline no GitHub Actions que faça build, execute os testes, publique a imagem, atualize o Helm Chart e sincronize o ArgoCD.

A IA pode realizar essa tarefa perfeitamente.

Mas ela continua presa ao mesmo modelo mental criado para humanos.

Talvez o pedido devesse ser:

Entregue a versão 2.8 do serviço de pagamentos em produção, sem indisponibilidade. Faça rollout progressivo, interrompa caso a taxa de erros ultrapasse 1% e execute rollback se houver degradação de latência ou conversão.

Perceba a diferença.

No primeiro pedido, estamos solicitando um artefato.

No segundo, estamos delegando um resultado.

De automação orientada a processo para operação orientada a intenção

O modelo tradicional pode ser resumido assim:

Humano define as etapas
        ↓
Pipeline executa as etapas
        ↓
Ferramentas realizam as ações
        ↓
Humano verifica o resultado

Em um modelo orientado a agentes:

Humano define objetivo, limites e políticas
        ↓
Agente analisa contexto e risco
        ↓
Agente escolhe o caminho
        ↓
Skills e ferramentas executam as ações
        ↓
Agente verifica o resultado
        ↓
Agente corrige, interrompe ou reverte

A interface principal deixa de ser a pipeline.

A interface passa a ser a intenção.

Algo parecido com isto:

intent:
  goal: deploy
  service: payments-api
  version: "2.8.0"
  environment: production

success_criteria:
  availability: ">= 99.95%"
  error_rate: "< 1%"
  p95_latency_regression: "< 5%"
  synthetic_tests: passed

constraints:
  strategy: progressive
  no_downtime: true
  max_cost_increase: "3%"
  allowed_window: "09:00-17:00"

rollback:
  automatic: true
  when:
    - error_rate_above_1_percent
    - p95_latency_regression_above_5_percent
    - business_conversion_drop_above_2_percent

approval:
  required_when:
    - database_migration_is_destructive
    - estimated_blast_radius_is_high

O humano não precisa descrever cada comando.

Ele define:

• o que deve acontecer;
• o que significa sucesso;
• quais riscos são aceitáveis;
• quais ações são proibidas;
• quando o agente deve parar;
• quando uma pessoa precisa aprovar.

O agente decide como atingir o objetivo dentro desse espaço seguro.

A IA não precisa usar as mesmas interfaces que nós

Pipelines, dashboards, tickets, runbooks e arquivos YAML são abstrações construídas para humanos.

Um agente pode acessar diretamente:

• APIs de cloud providers;
• Kubernetes API;
• repositórios Git;
• sistemas de observabilidade;
• bancos de dados;
• feature flags;
• catálogos de serviços;
• mecanismos de políticas;
• scanners de segurança;
• sistemas de incidentes;
• ferramentas de custo.

Não faz sentido obrigar um agente a:

1. gerar um arquivo;
2. abrir um pull request;
3. esperar uma pipeline;
4. interpretar uma interface;
5. consultar manualmente um dashboard;

quando ele pode utilizar diretamente as capacidades necessárias para alcançar o estado desejado.

Isso não significa ignorar controle, revisão ou auditoria.

Significa separar duas coisas que hoje tratamos como se fossem iguais:

Controle operacional não é a mesma coisa que procedimento humano.

Podemos manter controle sem obrigar o agente a repetir exatamente os nossos movimentos.

Isso significa o fim das pipelines?

Não.

Essa é uma distinção importante.

Um agente pode não precisar de uma pipeline criada e mantida manualmente por uma pessoa, mas ainda precisará de:

• gestão de estados;
• idempotência;
• retries;
• controle de concorrência;
• separação de responsabilidades;
• credenciais de curta duração;
• escopo mínimo de acesso;
• trilha de auditoria;
• rollback;
• limites de custo;
• políticas de segurança;
• evidências da execução.

O agente também pode gerar um workflow temporário, uma máquina de estados ou um DAG específico para aquela mudança.

A diferença é que esse fluxo passa a ser compilado dinamicamente a partir da intenção, em vez de ser programado antecipadamente para todos os cenários.

A pipeline pode continuar existindo.

Mas deixa de ser o produto.

Ela vira um detalhe interno de execução.

Terraform, Kubernetes e GitOps também não precisam desaparecer

O mesmo vale para as ferramentas que já usamos.

Terraform pode continuar sendo uma representação declarativa e auditável da infraestrutura.

Git pode continuar sendo uma fonte de histórico e evidências.

ArgoCD pode continuar reconciliando o estado desejado.

Prometheus pode continuar coletando métricas.

Kubernetes pode continuar orquestrando aplicações.

O problema não são essas tecnologias.

O problema é tratar a criação de seus artefatos como o resultado final do trabalho.

A empresa não quer um módulo Terraform.

Ela quer uma infraestrutura disponível, segura, reproduzível e dentro do orçamento.

A empresa não quer uma pipeline.

Ela quer software entregue com segurança.

A empresa não quer um dashboard.

Ela quer saber rapidamente quando um objetivo de negócio ou um SLO está em risco.

Os artefatos continuam úteis, mas são rebaixados de objetivo para mecanismo.

Skills são mais importantes do que scripts

Nesse modelo, uma skill não deveria ser apenas um prompt contendo comandos shell.

Ela deveria representar uma capacidade operacional completa.

Uma skill deploy-production, por exemplo, poderia declarar:

skill:
  name: deploy-production

permissions:
  - read_service_catalog
  - read_observability
  - update_deployment
  - manage_feature_flags
  - execute_rollback

preconditions:
  - tests_passed
  - artifact_signed
  - vulnerability_policy_passed
  - change_window_valid

strategies:
  - rolling
  - canary
  - blue_green

mandatory_checks:
  - error_rate
  - p95_latency
  - saturation
  - synthetic_tests
  - business_metrics

human_approval:
  required_for:
    - high_blast_radius
    - destructive_database_change
    - policy_exception

evidence:
  - execution_plan
  - actions_performed
  - metrics_before_and_after
  - approvals
  - final_state

O agente recebe um objetivo e combina skills conforme o contexto.

Para uma aplicação interna de baixo risco, ele pode escolher um rollout simples.

Para um serviço de pagamentos, pode usar canary, testes sintéticos, análise de métricas e aprovação humana.

Para uma correção crítica de segurança, pode escolher um fluxo emergencial, com escopo limitado e observação reforçada.

O resultado desejado pode ser o mesmo.

O caminho não precisa ser.

O deploy não termina quando a pipeline fica verde

Esse é um dos maiores problemas do modelo atual.

Muitas automações consideram o trabalho encerrado quando todos os jobs foram executados com sucesso.

Mas uma pipeline verde não significa que a mudança funcionou.

Um deploy pode concluir e ainda assim:

• aumentar a latência;
• gerar erros silenciosos;
• quebrar uma integração;
• afetar apenas parte dos usuários;
• degradar uma jornada de negócio;
• aumentar custos;
• criar um incidente alguns minutos depois.

Um agente deveria operar em ciclo fechado:

Observar
   ↓
Interpretar
   ↓
Planejar
   ↓
Executar
   ↓
Verificar
   ↓
Corrigir, avançar ou reverter

Ele não deveria informar apenas:

O deploy foi concluído com sucesso.

Deveria informar algo semelhante a:

A versão 2.8.0 foi implantada em 100% das instâncias. A taxa de erros permaneceu em 0,28%, a latência p95 não apresentou regressão, os testes sintéticos passaram e a conversão permaneceu estável durante 20 minutos de observação.

Isso muda completamente a definição de sucesso.

O sucesso deixa de ser a execução de uma sequência.

Passa a ser a confirmação de que o objetivo foi alcançado.

Como seria uma plataforma orientada a agentes?

Uma plataforma realmente agentic poderia ser dividida em algumas camadas:

1. Camada de intenção

Recebe o objetivo, os limites e os critérios de sucesso.

Exemplo:

Reduza o custo deste cluster em 15% sem prejudicar os SLOs de disponibilidade e latência.

2. Catálogo de contexto

Fornece ao agente informações sobre:

• serviços;
• dependências;
• responsáveis;
• criticidade;
• dados sensíveis;
• custos;
• mudanças anteriores;
• incidentes;
• SLOs;
• arquitetura.

Sem contexto confiável, autonomia vira improvisação.

3. Planejador

Cria um plano com base no objetivo, no risco, no contexto e nas políticas.

Esse plano não precisa ser sempre igual.

Ele pode mudar conforme:

• o ambiente;
• a criticidade;
• o horário;
• o impacto estimado;
• a saúde atual do sistema;
• o histórico da aplicação.

4. Catálogo de skills

Disponibiliza capacidades como:

• implantar aplicação;
• criar infraestrutura;
• aumentar capacidade;
• reduzir custos;
• renovar certificado;
• investigar incidente;
• restaurar backup;
• corrigir vulnerabilidade;
• executar rollback.

5. Motor de políticas

Define o que o agente pode fazer, em quais condições e com qual nível de aprovação.

Essa talvez seja uma das peças mais importantes.

O agente pode escolher o caminho.

A empresa continua definindo os limites.

6. Camada de execução

Utiliza os mecanismos disponíveis:

• APIs;
• controladores;
• GitOps;
• pipelines;
• cloud providers;
• Kubernetes;
• bancos;
• ferramentas internas.

7. Verificação e evidências

Confirma o resultado, acompanha os impactos e registra:

• o plano;
• as decisões;
• as ações;
• as aprovações;
• as métricas;
• o estado final;
• as exceções.

Essa arquitetura seria uma espécie de sistema operacional para agentes de engenharia.

A evolução provavelmente acontecerá por etapas

Não acredito que empresas simplesmente entregarão acesso irrestrito à produção para um modelo de IA.

A evolução tende a acontecer gradualmente.

Estágio 1 — IA como geradora de artefatos

A IA escreve código, Terraform, pipelines, manifestos e dashboards.

É onde grande parte das empresas está hoje.

Estágio 2 — IA como copiloto operacional

A IA analisa falhas, sugere mudanças, prepara pull requests e acompanha execuções.

O humano ainda coordena o processo.

Estágio 3 — Agente como operador

O agente executa workflows existentes, aciona pipelines, interpreta resultados e solicita aprovação.

Estágio 4 — Agente como orquestrador

O agente monta dinamicamente o plano necessário para alcançar um objetivo.

Ele escolhe as ferramentas e estratégias com base no contexto.

Estágio 5 — Operação autônoma dentro de limites

O agente recebe objetivos operacionais ou de negócio e possui autonomia para modificar, implantar, observar e corrigir sistemas dentro de uma zona de risco previamente definida.

O humano atua principalmente:

• nas exceções;
• nas decisões de alto impacto;
• na criação das políticas;
• na avaliação dos agentes;
• na evolução das skills.

O novo papel de SRE, DevOps e Platform Engineering

Esse modelo não elimina o trabalho dos engenheiros.

Ele muda o nível em que trabalhamos.

Em vez de escrever cada etapa, passamos a definir:

• políticas;
• contratos;
• guardrails;
• modelos de autorização;
• critérios de sucesso;
• limites de autonomia;
• estratégias de rollback;
• avaliações;
• evidências obrigatórias.

Platform Engineering deixa de construir apenas plataformas para desenvolvedores consumirem.

Passa a construir plataformas que agentes consigam operar com segurança.

SRE deixa de criar somente alertas e runbooks para humanos.

Passa a definir SLOs, sinais, políticas de reação e limites de risco que agentes consigam interpretar.

Segurança deixa de atuar apenas como uma aprovação tardia.

Passa a ser codificada no espaço de decisão do agente.

O engenheiro deixa de ser o autor de todos os caminhos.

Torna-se o arquiteto do espaço seguro no qual os agentes podem tomar decisões.

Autonomia sem governança seria apenas um novo tipo de incidente

É importante não romantizar essa ideia.

Dar acesso direto à produção para um agente sem políticas, contexto, isolamento, auditoria e avaliação seria irresponsável.

Uma plataforma desse tipo precisaria, no mínimo, de:

• identidade própria para cada agente;
• permissões mínimas e temporárias;
• ambientes isolados;
• limites de blast radius;
• políticas como código;
• aprovações progressivas;
• testes de comportamento;
• registros imutáveis;
• simulação antes da execução;
• capacidade de interrupção;
• rollback confiável;
• avaliação contínua.

O objetivo não é substituir processos rígidos por improvisação autônoma.

O objetivo é criar autonomia governada.

Onde realmente está o overengineering?

O overengineering não está necessariamente em usar Kubernetes, Terraform, ArgoCD ou pipelines.

Ele aparece quando criamos várias camadas apenas porque humanos precisam atravessá-las.

Considere este fluxo:

Humano descreve o requisito
        ↓
IA gera Terraform
        ↓
IA gera uma pipeline
        ↓
Pipeline executa Terraform
        ↓
Terraform chama a API da cloud
        ↓
Humano verifica o resultado

Em muitos casos, o agente poderia receber o estado desejado, selecionar os mecanismos adequados, executar a mudança e validar o resultado.

Ele ainda poderia gerar Terraform, abrir um pull request ou usar uma pipeline quando isso fosse exigido pelas políticas.

Mas faria isso porque é o melhor mecanismo para aquela situação, e não porque transformamos um processo histórico em uma regra universal.

A próxima geração de Platform Engineering

Minha principal tese é esta:

A próxima geração de Platform Engineering não será construída principalmente para humanos operarem ferramentas. Será construída para agentes entregarem resultados dentro de políticas definidas por humanos.

Pipelines, Terraform, dashboards e runbooks não precisam desaparecer.

Mas deixam de ser o centro da engenharia.

O centro passa a ser:

• intenção;
• contexto;
• skills;
• políticas;
• autonomia;
• verificação;
• governança.

A maior evolução não será criar uma IA capaz de escrever mais infraestrutura.

Será criar uma infraestrutura que a IA consiga operar autonomamente, com segurança, responsabilidade e foco no resultado.

Talvez, em alguns anos, a pergunta deixe de ser:

Qual pipeline precisamos criar?

E passe a ser:

Qual resultado queremos alcançar e quais limites o agente deve respeitar?

---

Em qual estágio sua empresa está hoje?

Você confiaria em um agente para realizar um deploy em produção se ele tivesse políticas claras, rollback automático, permissões limitadas e validação por SLOs?

Quero muito ouvir outras visões sobre isso nos comentários.