Visão geral

A BoxOffice tem doze engenheiros e faz merge de cerca de sessenta pull requests por semana. Um PR espera, em média, quase um dia útil inteiro pela primeira revisão humana; a abertura das vendas de um show em estádio é daqui a três semanas. Na reunião de planejamento, alguém diz o óbvio: "Vamos colocar IA no pipeline." Duas semanas depois, o time tem um bot que deixa quinze comentários em cada PR (as pessoas pararam de lê-los no terceiro dia), um agente que "consertou" um build vermelho apagando o teste que falhava, notas de versão anunciando uma funcionalidade de reembolso que ninguém construiu e uma fatura que ninguém previu.

Nada disso é problema dos modelos. As mesmas ferramentas, bem projetadas, reduzem a latência da revisão, encontram bugs reais, escrevem testes úteis e encurtam incidentes. A diferença está no projeto do sistema: onde a etapa de IA fica no ciclo de entrega, que contexto recebe, o que tem permissão para fazer, como sua saída é verificada, quanto custa e como o time sabe se ela ajuda. Esta aula aplica a caixa de ferramentas do curso — componentes, modos de falha, números, trade-offs — à IA dentro do pipeline de entrega de software.

Roteiro

1. Esta visão geral — IA ao longo do ciclo de entrega, o espectro de autonomia, o contrato de uma etapa de IA, métricas DORA e custo.
2. Revisão de código — em que a revisão por IA é boa e ruim, engenharia de contexto, achados estruturados, controle de ruído, gates, precisão, conformidade com a arquitetura.
3. Testes — testes gerados e testes de mutação, testes de contrato e baseados em propriedades, scripts de carga a partir do OpenAPI, triagem de testes flaky, seleção de testes, dados sintéticos, o problema do oráculo.
4. Agentes no CI — agentes de correção do build, de dependências e de migração; execuções headless; sandboxing, permissões, orçamentos, idempotência e auditoria.
5. Liberação e operação — notas de versão, pontuação de risco de mudanças, análise de canary, resposta a incidentes, postmortems, ChatOps: a IA propõe, políticas e humanos decidem.
6. Segurança e governança — prompt injection no pipeline, exfiltração, slopsquatting, SLSA, SBOM e assinatura, política como código, licenciamento, privacidade, governança de custos e avaliação de ferramentas de IA.
7. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Pré-requisitos de aulas anteriores

Esta aula não repete dois fundamentos; leia-os antes, se necessário:

• Cloud-native — Entrega: CI, GitOps com Argo CD, estratégias de deploy, análise de canary com Argo Rollouts e as métricas DORA. Cada etapa de IA aqui se encaixa nesse pipeline.
• Sistemas de IA e agentes: o LLM como dependência (tokens, latência, custo), o LLM gateway, o loop do agente e segurança e avaliações. Aqui os "usuários" do modelo não são fãs, mas engenheiros e pipelines.

IA ao longo do ciclo de entrega

O ciclo de entrega de software é uma sequência de etapas, cada uma com suas entradas, saídas e modos de falha. A IA pode ajudar em todas elas — mas o que "ajudar" significa, e o que pode dar errado, varia muito:

flowchart LR
    plan["Planejar<br/>IA rascunha ADR"] --> code["Codificar<br/>assistente / agente"]
    code --> pr["Pull request"]
    pr --> review["Revisão por IA<br/>comentários consultivos"]
    pr --> tests["Testes no CI<br/>+ testes gerados por IA<br/>julgados pelo mutation score"]
    review --> human{"Aprovação humana<br/>(proteção de branch)"}
    tests --> human
    tests -->|"build vermelho"| agent["Agente de correção<br/>PR em rascunho"]
    agent --> human
    human --> build["Build · scan · SBOM · assinatura"]
    build --> release["Notas de versão<br/>rascunho ancorado"]
    release --> canary["Canary<br/>veredito da política + explicação da IA"]
    canary --> operate["Operar<br/>resumo de incidente pela IA"]
    operate -->|"rascunho de postmortem"| plan

Repare na forma: as etapas de IA se ramificam a partir do caminho principal e voltam por uma verificação determinística ou um humano antes que qualquer coisa mude em produção. É esse o padrão que o restante da aula desenvolve.

O espectro de autonomia

"IA no pipeline" abrange ferramentas com autonomias muito diferentes. Uma escala útil, emprestada da forma como a indústria fala de automação na direção de veículos, é quem decide a próxima ação e quem responde por ela:

Subir na escala compra vazão e custa controle. O nível certo depende do raio de impacto de um erro e de quão verificável é a saída: a correção de um erro de digitação na documentação pode ser nível 4; uma mudança no travamento de assentos do inventory fica no nível 2–3, por melhor que seja o modelo. A responsabilidade nunca passa para a ferramenta: o engenheiro que faz o merge de uma mudança escrita por IA é dono dela.

O contrato de uma etapa de IA

Toda etapa de IA em um pipeline — revisão, geração de testes, agente de correção, notas, explicação de canary — pode ser projetada com o mesmo contrato de cinco partes. Escrevê-lo para cada etapa é o jeito mais rápido de descobrir o que está faltando:

Duas propriedades decorrem do contrato. Privilégio mínimo: a permissão da ação é o máximo que a etapa pode fazer, diga o modelo o que disser. Direção segura de falha: decida de antemão se uma indisponibilidade da IA bloqueia o pipeline (fail closed) ou pula a etapa (fail open). Etapas consultivas falham abertas; um gate de segurança do qual você depende deve falhar fechado — e então precisa ser muito confiável.

O que acontece com as métricas DORA

As métricas DORA — frequência de deploy, lead time de mudanças, taxa de falha de mudanças e tempo de restauração — são definidas em Entrega. A IA muda as entradas das quatro, nem sempre na direção esperada:

• O lead time pode cair (primeira revisão mais rápida, correção mais rápida de builds vermelhos) — ou subir, se os PRs ficarem maiores porque gerar código é barato e revisá-lo é lento.
• A frequência de deploy acompanha o lead time, mas só se os lotes continuarem pequenos.
• A taxa de falha de mudanças pode subir se a atenção na revisão cair ("o bot já olhou") ou se código gerado for mergeado sem ser entendido; pode cair se a revisão e os testes por IA pegarem defeitos reais.
• O tempo de restauração pode cair com bons resumos de incidentes e diagnóstico mais rápido; pode subir se uma explicação errada e confiante mandar o engenheiro de plantão pelo caminho errado.

A pesquisa até agora é um alerta contra supor a direção boa. O relatório DORA de 2024 estimou que um aumento de 25% na adoção de IA estava associado a uma queda de 1,5% na vazão de entrega e a uma queda de 7,2% na estabilidade da entrega, mesmo com as pessoas relatando maior produtividade e melhor qualidade de código e de documentação¹; os autores apontam lotes maiores e fundamentos mais fracos como causas plausíveis. A pesquisa DORA de 2025 descreve a IA como um amplificador do que a organização já é — plataformas fortes, lotes pequenos e bons testes ficam mais fortes; os fracos ficam mais fracos². E, em um ensaio clínico randomizado de 2025, desenvolvedores experientes de código aberto levaram 19% mais tempo com ferramentas de IA, acreditando estar cerca de 20% mais rápidos³.

A resposta de engenharia não é evitar a IA, mas medi-la como qualquer outra mudança — com um período de referência (baseline) e métricas por etapa:

Os números: quanto custa uma etapa de IA

Uma etapa de IA tem três custos: tokens (a conta do provedor), minutos de runner (tempo de CI) e atenção (cada comentário ou proposta que um humano precisa ler). Os dois primeiros são fáceis de estimar; o terceiro costuma ser o maior.

A tabela estima o custo em tokens de uma revisão de um PR típico e a conta mensal da BoxOffice (12 engenheiros, ~250 revisões por mês, contando as re-revisões após novos pushes) e de uma organização de 500 engenheiros (~20.000 revisões por mês). Premissas, todas ilustrativas: um prefixo estável de 8.000 tokens (instruções, convenções, ADRs), 6.000 tokens de diff e texto do PR, 1.500 tokens de saída (achados mais raciocínio). Os preços são os de tabela dos provedores por milhão de tokens quando esta página foi escrita — confira os preços atuais antes de usá-los.

O que os números dizem:

• Tokens são baratos em comparação com pessoas. Mesmo com o maior modelo, uma revisão custa centavos; a organização de 500 engenheiros paga por mês aproximadamente o que custam alguns dias de trabalho de um engenheiro. A falha cara não é a conta, é o ruído: um revisor com 40% de precisão que posta quatro comentários em cada uma de ~5.000 revisões por semana produz cerca de 12.000 comentários inúteis por semana — a um minuto cada, 200 horas — cinco semanas inteiras de 40 horas de engenheiros gastas para lê-los.
• Os tokens de saída são cerca de metade da conta no modelo grande, embora sejam um décimo dos tokens: cada token de saída custa 5× um token de entrada. Pedir "sem elogios, sem repetir o código" também é uma otimização de custo.
• Fazer cache do prefixo estável ajuda mais à medida que o prefixo cresce (arquivos de convenções grandes, muitos ADRs) — mas só se o prefixo for idêntico byte a byte entre as execuções.
• Modelos locais eliminam a conta de tokens, mas não o custo: um runner de CPU gerando poucos tokens por segundo deixa o job com minutos de duração, e um recall menor significa defeitos não detectados. Compare-os em um golden set antes de escolher.
• Minutos de runner: um job de revisão de ~1,5 minuto em um runner Linux hospedado custa na ordem de um centavo de dólar aos preços típicos por minuto (confira com seu provedor de CI) — comparável aos tokens. Um agente que roda o build completo três vezes custa muito mais em minutos do que em tokens.

Agentes se comportam de outra forma: cada passo reenvia o contexto crescente, então o custo cresce aproximadamente de forma quadrática com o número de passos (Sistemas de IA — os números). A página Agentes no CI faz essa conta para um agente de correção do build.

O LLM gateway é infraestrutura compartilhada

Bots de CI são clientes do modelo assim como o assistente da BoxOffice. Na escala de uma organização, eles devem passar pelo mesmo LLM gateway: um único lugar para chaves, cotas e orçamentos por repositório, roteamento de modelos ("modelo pequeno para notas de versão, modelo grande para revisão de segurança"), fallbacks quando um provedor cai e atribuição de custo por time. Sem ele, cada repositório guarda sua própria chave de API, e um loop descontrolado de agente em um repositório pode esgotar o rate limit da organização durante a abertura das vendas.

Experimente: abra o cenário abaixo com o perfil spike e imagine que o pico não são fãs, mas uma atualização em massa de dependências que dispara 300 revisões de PR e 300 agentes de correção ao mesmo tempo. O playground tem um só tipo de cliente, então mostra o que faz uma cota compartilhada: ao longo da execução cerca de 70% das perguntas falham, contra 37% na carga normal. Selecione o LLM Gateway e baixe a Cota do provedor de 10 para 5 chamadas/s: os erros passam de 90% — para todos. É por isso que o gateway precisa de uma cota por cliente (por repositório, por time) com prioridade para o tráfego interativo: os bots devem esperar, os fãs não. O playground não modela cotas por cliente; o seu botão Modelo reserva mostra a outra alavanca, capacidade comprada a um preço (os erros caem para cerca de 3%, o custo por mês dobra).

Abra o playground completo para alterar os componentes você mesmo. O componente de gateway está descrito no catálogo de componentes.

O mapa de conceitos da entrega assistida por IA

Cada etapa de IA no pipeline é um pequeno sistema de IA: um orquestrador em volta de um modelo, ferramentas com permissões, uma camada de políticas e telemetria que diz se ela ajuda. O mapa liga os componentes da paleta (verde) que reaparecem aqui aos conceitos desta aula (azul):

flowchart LR
    ev["PR or pipeline event"] --> orch["orchestrator<br/>(reviewer, fix agent)"]:::comp
    orch --> llmgw["llmgw"]:::comp
    orch --> toolreg["toolreg<br/>tool allow-list"]:::comp
    orch --> safety["safety"]:::comp
    orch --> logs["logs<br/>audit trail"]:::comp
    obs["metrics · alerting"]:::comp
    orch -.- c1["autonomy levels,<br/>contract of an AI step"]:::tech
    llmgw -.- c2["per-repository quotas,<br/>routing, cost attribution"]:::tech
    toolreg -.- c3["least privilege, sandbox,<br/>draft PRs"]:::tech
    safety -.- c4["injection in PR text,<br/>slopsquatting, policy as code"]:::tech
    obs -.- c5["canary verdict by policy,<br/>AI explains"]:::tech
    obs -.- c6["DORA, reviewer precision,<br/>mutation score"]:::tech
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Hands-on 13 — IA no CI/CD: construa o revisor, o gerador de testes com PIT, o agente de correção, as notas de versão, o canary explicado, o hardening e a medição.
• Hands-on 11 — Entrega e Hands-on 12 — Assistente de IA: o pipeline e o LLM gateway sobre os quais esta aula se apoia.
• Projeto: o marco de K8s + CI/CD pode incluir uma etapa de IA, medida.
• Preparação para entrevistas: a pergunta acima é um enunciado comum de "projete uma ferramenta para desenvolvedores".

Pontos-chave

O que quebra em seguida

Toda etapa de IA desta aula julga uma mudança: um diff, uma classe de teste, um build vermelho, um canary contra a sua baseline no tráfego de hoje. Nenhuma responde à pergunta que a próxima abertura de vendas faz ao sistema inteiro: com a borda, os caches, a sala de espera, os breakers, o Kubernetes e um assistente no lugar, a BoxOffice mantém o p99 abaixo de 300 ms quando 2 M de fãs chegam às 10:00, qual componente quebra primeiro, e quanto custa operá-la? Catorze capítulos acrescentaram caixas; nenhum provou que elas aguentam juntas. Provar isso com carga, perfis e um modelo de custo — e corrigir o que a prova encontrar — é a aula 15 — Engenharia de Desempenho.