LLM no pipeline

Colocar um modelo de linguagem dentro do pipeline é fácil; colocá-lo de um jeito que ajude e não atrapalhe exige escolher bem os casos de uso. O critério que separa os dois: o modelo deve sugerir para uma pessoa decidir, e nunca ser a única barreira antes da produção.

Casos de uso com retorno real

Caso	Valor	Risco
Resumo de PR grande para o revisor	alto	baixo
Sugestão de casos de teste faltando	alto	baixo
Explicar erro de build ou stack trace	alto	baixo
Rascunho de changelog e de release notes	médio	baixo
Análise de log com hipóteses	alto	médio (alucinação)
Detectar padrão inseguro no diff	médio	médio (falso positivo/negativo)
Gerar migration ou manifest de produção	baixo	alto
Aprovar merge sozinho	—	inaceitável

Repare no padrão: o valor está onde o modelo lê muito e resume, e o risco está onde ele escreve algo que executa.

Revisão de código assistida

Bem usada, a revisão assistida cuida do trabalho mecânico e devolve atenção humana para o que importa — projeto, contexto de negócio, casos de borda.

# comenta no PR, não bloqueia o merge
- name: Revisão assistida
  if: github.event_name == 'pull_request'
  run: |
    revisor-ia --diff "$(git diff origin/main...HEAD)" \
               --contexto CONTRIBUTING.md \
               --formato comentario > revisao.md
    gh pr comment "$PR" --body-file revisao.md

Três limites que mantêm isso saudável:

• Nunca como aprovação. A revisão humana continua obrigatória; o comentário do modelo é insumo.
• Comentário marcado como automático, para ninguém confundir com opinião de colega.
• Volume controlado. Uma revisão que gera vinte comentários por PR treina o time a ignorar todos. Peça os três pontos mais relevantes.

Para checagem determinística (formato, segredo, dependência vulnerável, complexidade), use linter e scanner — são mais rápidos, mais baratos e não variam a cada execução.

Análise de log e diagnóstico

O modelo é bom em ler dez mil linhas e apontar o que se destaca. Use no incidente, com duas precauções que não são opcionais:

• Redija dado sensível antes de enviar. Log carrega token, CPF, e-mail e corpo de requisição. Nenhum disso deve sair para um serviço externo — o mesmo cuidado da página de compliance.
• Trate o conteúdo do log como não confiável. Log e ticket contêm texto escrito por terceiros, e texto pode conter instruções endereçadas ao modelo. É o assunto de riscos de IA, e é uma ameaça real, não teórica.

Custo e latência no CI

Cada chamada custa dinheiro e tempo, e o pipeline roda muitas vezes por dia:

• Rode só no pull request, não em cada push.
• Envie só o diff e o contexto necessário, não o repositório.
• Cacheie por hash do diff — reexecuções idênticas não deveriam pagar de novo.
• Defina limite de gasto e alerta; um laço de retry com modelo caro é uma fatura desagradável.
• Coloque timeout curto e falhe aberto: se o serviço de IA estiver fora, o pipeline continua. Nenhuma entrega deve depender da disponibilidade do modelo.

Não deixe o modelo aprovar o próprio código

Com geração assistida no editor, boa parte do código já nasce de um modelo. Se o mesmo tipo de sistema também revisa e aprova, você fechou um ciclo sem julgamento humano — e os erros correlacionados passam pelos dois lados.

Mantenha as barreiras que não dependem de opinião: teste automatizado, política como código, revisão por pessoa, e o pipeline de segurança de sempre. O modelo entra como mais um par de olhos, nunca como o último.

Governança mínima

Antes de ligar qualquer coisa em produção, deixe escrito e acordado:

• Quais dados podem ir para qual provedor (código, log, dado de cliente — cada um com resposta própria).
• Se o provedor treina com o que você envia. Verifique no contrato, não no marketing.
• Onde o processamento acontece — é transferência internacional de dados, com as obrigações que isso traz.
• Registro de uso: o que foi enviado e quando, para auditoria.
• Alternativa se o fornecedor mudar preço, política ou desligar o modelo.

Próximo passo: quando a sugestão vira ação executada, mude o nível de cuidado. Continue em Agentes de operação.