Lidando com código gerado por agentes de forma responsável: o framework da Vercel

• Agentes de codificação geram código em uma velocidade sem precedentes, mas, se usados sem julgamento rigoroso, tornam-se um caminho eficiente para colocar em produção suposições erradas
• O código gerado por agentes vem com descrição de PR, passa em análise estática e até tem cobertura de testes, então parece ter sido escrito por um engenheiro experiente, mas não reflete em nada os padrões de tráfego, modos de falha e restrições de infraestrutura do ambiente real de produção
• Há uma diferença fundamental entre aproveitar (leveraging) a IA e depender (relying) dela; aproveitar de verdade significa entender completamente e assumir a responsabilidade pelo funcionamento e pelos riscos do que o agente produz
• Com três princípios — deployments autônomos, validação contínua e guardrails executáveis — é possível construir um ambiente em que agentes atuem com alta autonomia sem abrir mão da segurança
• Chegamos a uma era em que sobrevive não o engenheiro que mais gera código, mas o que mantém discernimento frio sobre o que deve ou não ser colocado em produção

---

O problema: CI verde já não é prova de segurança

• Passar no CI apenas reflete a capacidade do agente de satisfazer o pipeline, e não tem relação direta com a segurança real da infraestrutura
  • É possível implantar uma query que passa nos testes, mas faz scan de tabela inteira em produção
  • Uma lógica de retry aparentemente normal pode causar Thundering Herd em serviços downstream
  • Um cache sem TTL pode matar o Redis silenciosamente
• O agente não sabe qual é o estado de capacidade da instância Redis, se o banco tem uma região específica hardcoded, nem que um rollout com feature flag muda o perfil de carga dos sistemas downstream
• A lacuna entre "este PR parece correto" e "este PR pode ser implantado com segurança" sempre existiu, e os agentes só ampliam essa distância

Distinção central: aproveitar vs. depender

• Depender (Relying): assumir que, se o agente escreveu e os testes passaram, então está pronto para deploy
  • O autor não constrói um modelo mental das mudanças
  • Nem autor nem revisor entendem de fato o que o código faz, e surge um PR enorme cheio de suposições ocultas
• Aproveitar (Leveraging): usar o agente para iteração rápida mantendo total responsabilidade sobre o resultado
  • Entender exatamente como o código se comporta sob carga
  • Compreender os riscos envolvidos e estar disposto a assumi-los
• Colocar seu nome em um PR significa dizer "eu li e entendo o que isso faz" — esse é o ponto de referência do processo de engenharia

Critério de julgamento: o teste decisivo

• Teste simples: "Eu me sentiria confortável em ser responsável por um incidente em produção ligado a este PR?"
• Três perguntas que você deve se fazer antes de abrir o PR
  • O que este código faz? Como ele vai se comportar depois do rollout?
  • Que impacto negativo isso pode causar em produção ou para os clientes?
  • Eu me sentiria confortável em ser responsável por um incidente ligado a este código?
• Se a resposta for "sim", você está aproveitando a IA e pode implantar; se for "não", ainda há trabalho a fazer

A solução: três princípios para defender a produção

• Deployments autônomos (Self-driving deployments): toda mudança passa por pipelines com gates e é liberada gradualmente; deployments canário fazem rollback automático se houver degradação de desempenho
  • Não depende de um engenheiro monitorando dashboards
  • Se houver problema, ele fica isolado em parte do tráfego, e não no todo
• Validação contínua (Continuous validation): a própria infraestrutura é testada o tempo todo, e não apenas no momento do deploy
  • Testes de carga, experimentos de caos e exercícios de recuperação de desastres são executados continuamente
  • Foi por isso que o failover de banco de dados ensaiado pela Vercel em produção no verão passado não causou impacto algum aos clientes quando ocorreu a falha real na Azure
• Guardrails executáveis (Executable guardrails): codificar conhecimento operacional em ferramentas executáveis, e não em documentos
  • A skill safe-rollout não é uma página no Notion explicando como funcionam feature flags; é uma ferramenta que conecta a flag, gera um plano de rollout com condições de rollback e especifica como validar o comportamento esperado
  • Quando os guardrails são executáveis, os agentes podem segui-los de forma autônoma, e as pessoas não precisam decorar tudo

Em que a Vercel está investindo na prática

• Reforço de guardrails compartilhados de infraestrutura com validação em runtime em todas as etapas do pipeline de deploy
• Fortalecimento de verificações estáticas na etapa de PR, especialmente em relação a feature flags
• Introdução de testes end-to-end com espelhamento da produção no ambiente de staging
• Operação de agentes somente leitura em produção para validar continuamente invariantes do sistema, além do uso de agentes especializados para auditar as suposições de agentes geradores
• Introdução de métricas como a taxa de defeitos que escapam por commit com defeito para identificar se o risco está aumentando em toda a plataforma

Conclusão: engenheiros com discernimento têm vantagem competitiva

• A implementação ficou abundante; agora, o recurso escasso é o discernimento sobre o que pode ser implantado com segurança
• Acabou a era em que código ruim parecia ruim; as ferramentas de IA vão ficar mais poderosas, os diffs maiores e a tentação de confiar cegamente na saída também vai crescer
• O objetivo não é um mundo em que toda mudança exija rigor extraordinário das pessoas, e sim um mundo em que a própria infraestrutura seja rigorosa — um ambiente em que implantar rápido seja, por padrão, seguro