IA em Pipelines de CI/CD

CI/CD pipeline é o ponto de controle mais consistentemente executado no ciclo de desenvolvimento: cada commit, cada PR, cada deploy passa por ele. É também o ponto onde feedback automático tem mais impacto — encontrar um problema no pipeline é ordens de magnitude mais barato do que encontrá-lo em produção, ou mesmo em code review manual que pode ser apressado. LLMs no pipeline adicionam uma camada de análise semântica que ferramentas tradicionais — linters, analisadores estáticos, verificadores de tipo — não oferecem.

A diferença entre análise estática tradicional e análise por LLM é a diferença entre regras explícitas e reconhecimento de padrão. Um linter verifica regras que alguém escreveu explicitamente: comprimento de linha, naming convention, uso de API depreciada. Um LLM pode identificar padrões problemáticos que nenhuma regra captura formalmente: uma função que está ficando grande demais para um único desenvolvedor manter, um padrão de erro handling que diverge sutilmente do restante da base, uma mudança que parece pequena mas tem impacto grande em múltiplos componentes downstream. Não substitui linters — complementa com análise que regras explícitas não cobrem.

Ao mesmo tempo, integrar LLMs em pipeline tem custos reais que precisam ser gerenciados: latência (cada chamada de API adiciona tempo ao pipeline), custo (chamadas de API têm custo que escala com o volume de commits), e ruído (feedback irrelevante ou de baixa qualidade que o time para de ler). Um pipeline com IA que adiciona 5 minutos e produz 15 comentários genéricos por PR vai ser desabilitado em duas semanas. O design correto é focado: análise específica, de alto valor, com output acionável — não análise abrangente que produz ruído.

Revisão semântica automática — linting além das regras

Linters como ESLint, pylint, golangci-lint, e Roslyn analyzers verificam regras que podem ser expressas como padrão sintático ou estrutural. São rápidos, determinísticos, e têm zero falso negativo para as regras que implementam — se a regra diz que usar == para comparar floats é problema, o linter sempre encontra. O limite é que só encontram o que alguém pensou em transformar em regra.

LLMs no pipeline operam em dimensão diferente: reconhecem padrões problemáticos que não foram expressos como regra. Exemplos do que análise semântica por LLM encontra que linters não encontram: uma mudança que remove uma validação de entrada que parecia redundante mas era a única proteção contra um tipo específico de input malformado; um novo endpoint que não tem rate limiting enquanto todos os outros têm; código que funcionou em ambiente de desenvolvimento mas tem hardcoded uma URL de staging que vai para produção; uma função de cálculo que usa variável local com o mesmo nome de uma variável de classe externa, criando shadowing não-intencional que não é erro de compilação mas é bug.

A implementação prática: em um step do pipeline (GitHub Actions, GitLab CI, Jenkins), chamar a API do LLM com o diff do PR e um prompt estruturado de análise. O output — comentários no formato convencional, lista priorizada de observações, ou sumário com severity — é postado como comentário no PR ou como annotation no diff. O step não bloqueia o pipeline por padrão (não há critério objetivo para "o LLM aprovou"); serve como informação adicional para o revisor humano.

A decisão de fazer o step bloquear ou não tem implicações culturais. Um step que bloqueia o merge quando encontra um problema de segurança (categoria de problema de alta confiança) faz sentido. Um step que bloqueia quando encontra observações de design (baixa confiança) vai gerar resistência — e o time vai encontrar formas de contornar o bloqueio. A regra de design: LLM no pipeline bloqueia apenas para categorias onde a confiança é alta e o custo de falso positivo é aceitável; informa para as demais.

Análise de impacto de PR

Uma das aplicações mais valiosas de LLM em pipeline é análise de impacto: dado um diff, identificar quais outros componentes do sistema podem ser afetados por essa mudança — componentes que o PR não toca mas que dependem do que foi modificado.

A análise começa com o grafo de dependências: quais arquivos dependem dos arquivos modificados no diff? Essa parte é factual e pode ser feita com ferramentas de análise estática (ast-based dependency analysis) com mais precisão do que LLM. O LLM entra na segunda parte: dado os arquivos que dependem das mudanças, há algo nos arquivos dependentes que sugere que a mudança pode ter impacto não-óbvio? Um consumidor que espera um comportamento que foi alterado, um teste de integração que valida um contrato que foi modificado, um serviço que usa um campo que foi renomeado?

Essa análise é de alto valor especialmente para mudanças em código compartilhado: libraries internas, contratos de API, schemas de banco de dados, formatos de serialização de eventos. O engenheiro que modifica uma library compartilhada pode não ter visibilidade de todos os consumidores; o LLM com acesso ao repositório completo pode identificar consumidores cujo código sugere dependência no comportamento que mudou.

Triagem de testes: quais rodar dado o diff

Em repositórios grandes, rodar todos os testes em cada commit é inviável — o pipeline demora horas. A solução tradicional é test selection por impacto: rodar apenas os testes que têm relação com os arquivos modificados. Ferramentas como Microsoft's FASTER, pytest-testmon, e Bazel's query calculam essa seleção via análise de dependência de código.

LLMs adicionam uma dimensão semântica à seleção de testes: além dos testes que importam arquivos modificados, há testes que verificam comportamento que pode ser afetado pela mudança mesmo sem importar os arquivos. Uma mudança no algoritmo de pricing pode afetar testes de checkout que não importam o módulo de pricing diretamente — mas o LLM lendo os testes pode identificar que eles dependem do output de pricing de formas que análise de importação não captura.

A implementação: o LLM analisa o diff e sugere categorias de testes que devem rodar ("qualquer teste que menciona pricing, discount, ou checkout"), que são então mapeadas para arquivos de teste concretos via busca no repositório. Isso não substitui análise de dependência determinística — é um complemento para capturar dependências semânticas que a análise estrutural perde.

Geração de descrição de PR e release notes

A geração automática de descrição de PR a partir do diff é uma das aplicações de menor risco e maior adoção imediata de LLMs em pipeline. O problema que resolve é real: PRs com descrições vazias ou genéricas ("resolve issue #X") dificultam o code review, degradam a qualidade do histórico de git, e tornam git blame e git bisect menos úteis meses depois.

A implementação comum: um GitHub Action que, quando um PR é aberto sem descrição (ou com descrição template não preenchida), chama a API do LLM com o diff e posta um rascunho de descrição como comentário no PR. O engenheiro pode aceitar o rascunho (editar o campo de descrição do PR), modificar, ou ignorar. Não há automação sem aprovação humana explícita — o LLM gera o rascunho, o humano decide o que vai de fato para a descrição oficial.

Para release notes, o padrão é similar mas mais estruturado: dado o conjunto de PRs mergeados desde a última release (ou o diff entre duas tags), gerar release notes agrupadas por categoria (features, bug fixes, breaking changes) em formato que pode ser publicado no changelog público ou no GitHub Releases. O nível de qualidade do output depende da qualidade das descrições dos PRs individuais — o que cria incentivo positivo: times que passam a usar geração de release notes por LLM naturalmente melhoram a qualidade das descrições de PR, porque a qualidade do release note depende disso.

Limites: o que o pipeline não pode substituir

Por mais que análise por LLM no pipeline capture padrões que linters não capturam, há categorias fundamentais que a automação não substitui e que tentativas de substituição produzem false security.

Revisão de mudanças de contrato com impacto externo. Uma mudança no schema de evento publicado por um serviço pode quebrar consumidores em outros times ou serviços externos. O LLM pode identificar que o schema mudou; não pode saber quais consumidores externos existem, qual é o acordo de compatibilidade backward, ou qual é o processo de deprecation que o time usa. Essa decisão requer comunicação humana entre times.

Validação de lógica de negócio. O pipeline pode verificar que os testes passam. Se os testes têm lacunas — e sempre têm — o pipeline não detecta lógica de negócio incorreta. Um LLM no pipeline pode apontar que um trecho parece suspeito, mas "parece suspeito" não é critério objetivo de bloqueio, e o LLM não tem o conhecimento de domínio para saber se a lógica é correta.

Avaliação de performance e escalabilidade. O pipeline roda testes unitários e de integração; não simula carga de produção. Performance não-local — o comportamento do sistema quando 10.000 usuários simultâneos fazem a operação que esse PR modificou — requer load testing com dados realistas, que não faz parte do pipeline de CI padrão. LLM pode apontar padrões que parecem problemáticos em performance (N+1 query, alocação em hot path), mas não pode substituir a medição.

// .github/workflows/ai-security-review.yml
name: AI Security Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  security-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD \
            -- '*.cs' '*.json' '*.yaml' > pr_diff.txt
          echo "lines=$(wc -l < pr_diff.txt)" >> $GITHUB_OUTPUT

      - name: AI Security Analysis
        if: steps.diff.outputs.lines < 2000  # skip huge PRs
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          python3 scripts/ai_review.py \
            --diff pr_diff.txt \
            --focus security \
            --output review_comment.md

      - name: Post Review Comment
        if: steps.diff.outputs.lines < 2000
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const comment = fs.readFileSync('review_comment.md', 'utf8');
            if (comment.trim()) {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                body: `### 🔍 AI Security Review\n\n${comment}`
              });
            }

import anthropic
import sys

def analyze_diff(diff_path: str, focus: str) -> str:
    with open(diff_path) as f:
        diff = f.read()

    if not diff.strip():
        return ""

    prompts = {
        "security": """Analise o diff de código abaixo SOMENTE para
problemas de segurança. Foque em:
- Secrets ou credenciais hardcoded
- Validação de input ausente em dados externos
- Vulnerabilidades OWASP Top 10 visíveis no diff
- Mudanças em autenticação ou autorização
- Exposição de dados sensíveis em logs ou respostas

Para cada problema: localização aproximada, descrição,
severidade (CRÍTICO/ALTO/MÉDIO).
Se não encontrar problemas de segurança, responda apenas:
"Nenhum problema de segurança identificado no diff."
Não comente sobre style ou design.""",

        "contracts": """Analise o diff abaixo SOMENTE para mudanças
de contrato que podem quebrar consumidores:
- Campos removidos ou renomeados em respostas JSON/XML
- Parâmetros obrigatórios adicionados em APIs existentes
- Mudanças em schemas de evento ou mensagem
- Comportamentos de erro que consumidores podem depender

Para cada mudança: o que mudou, impacto potencial,
se parece breaking change ou backward-compatible."""
    }

    client = anthropic.Anthropic()
    message = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": f"{prompts[focus]}\n\nDIFF:\n```\n{diff[:8000]}\n```"
        }]
    )
    return message.content[0].text

if __name__ == "__main__":
    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument("--diff", required=True)
    parser.add_argument("--focus", default="security")
    parser.add_argument("--output", required=True)
    args = parser.parse_args()

    result = analyze_diff(args.diff, args.focus)
    with open(args.output, "w") as f:
        f.write(result)

// Conceito: identificar categorias de testes a priorizar
// dado o diff, além da análise de importação estática.
//
// Exemplo de prompt para análise de impacto:
//
// "Dado o diff abaixo de um repositório Go:
//
// 1. Liste os pacotes modificados.
// 2. Para cada pacote, descreva em uma frase o que mudou.
// 3. Com base nas mudanças, quais categorias de testes
//    devem ser priorizadas além dos testes dos pacotes
//    modificados? (ex: 'testes de checkout pois pricing mudou',
//    'testes de autenticação pois JWT validation foi alterada')
// 4. Há alguma mudança que parece ser breaking change
//    (assinatura de interface, campo exportado, comportamento
//    de erro) que consumidores externos podem depender?
//
// Responda em formato JSON:
// {
//   'modified_packages': [...],
//   'change_summary': {...},
//   'test_categories_to_prioritize': [...],
//   'potential_breaking_changes': [...]
// }"
//
// O output JSON é consumido pelo pipeline para:
// - Rodar testes das categorias sugeridas além dos automáticos
// - Adicionar label "potential-breaking-change" ao PR se relevante
// - Notificar revisor senior para PRs com breaking changes

Métricas de qualidade do step de IA

Um step de IA no pipeline que não é medido inevitavelmente se torna ruído. As métricas que importam para avaliar se o step está adicionando valor: taxa de actionability (qual fração dos comentários gerados resulta em mudança no código antes do merge?), taxa de falso positivo (qual fração dos comentários o time descarta como irrelevante?), cobertura de problemas (qual fração dos bugs de segurança que chegaram à produção nos últimos 6 meses teriam sido capturados pelo step?). Sem essas métricas, a decisão de manter ou remover o step é baseada em impressão — e impressões tendem a subestimar o valor de prevenção e superestimar o custo de ruído.

A iteração do prompt do step deve ser tratada como iteração de qualquer sistema de software: mudança, medição, ajuste. Se a taxa de falso positivo é alta, o prompt está sendo muito abrangente — restringir o foco. Se a taxa de actionability é baixa, o output não está sendo acionável — mudar o formato para priorizar por severidade e exigir sugestão específica de correção. O step de IA é um produto que precisa de manutenção ativa.

Como praticar

1. Implementar análise de segurança em PR. Usando o script Python deste conceito como base, configure um GitHub Action (ou equivalente no seu CI) que analisa diffs de PR para problemas de segurança e posta como comentário. Execute por um mês, colete métricas de actionability e falso positivo, e ajuste o prompt com base nos dados. Ao final do mês, você terá dados reais sobre o valor do step para o seu contexto específico.
2. Análise de impacto manual como treino. Para os próximos cinco PRs que você revisar, aplique a análise de impacto manualmente: dado o diff, identifique componentes que não foram modificados mas que podem ser afetados. Depois passe o mesmo diff para um LLM com prompt de análise de impacto e compare os resultados. O que o LLM identificou que você não identificou? O que você identificou que o LLM não identificou? Esse exercício calibra onde o LLM agrega valor na análise de impacto para o seu repositório específico.
3. Auditoria de PRs passados. Pegue 10 PRs mergeados nos últimos 3 meses que introduziram bugs que foram encontrados depois do merge. Para cada um, passe o diff para um LLM com o prompt de análise de segurança e de contrato do seu pipeline. Quantos dos bugs o LLM teria identificado? Para os que teria identificado, como teria precisado ser descrito o problema para o revisor agir? Para os que não teria identificado, por que não? Esse retrospecto calibra o design do step.