[330] Gerando e Revisando Pipelines com IA

O GitHub Copilot foi lançado em 2021. O ChatGPT em novembro de 2022. O Cursor em 2023. Em poucos anos, assistentes de código baseados em LLMs passaram de curiosidade a ferramenta padrão no workflow de uma fração crescente de engenheiros de software e infraestrutura.

A questão não é mais "isso vai ser útil?" — já é útil, e os dados de produtividade são consistentes. A questão é como usar essas ferramentas de maneira eficaz, especificamente para as tarefas de DevOps: escrita de pipelines CI/CD, Terraform, manifestos Kubernetes, scripts de operações e revisão de infraestrutura como código.

Este artigo cobre técnicas práticas de prompting para tarefas de infraestrutura, geração de pipelines completos, revisão automatizada de código de infraestrutura, e os limites que o engenheiro precisa conhecer para não confiar cegamente nas sugestões da IA.

Princípios de Prompting para Infraestrutura

A diferença entre um prompt que gera código útil e um que gera código genérico está no contexto fornecido. Para tarefas de infraestrutura, quatro elementos de contexto fazem a maior diferença: a plataforma de destino (AWS/Azure/GCP, versão), a restrição de segurança aplicável, o padrão que já existe no projeto, e o resultado esperado.

Um prompt fraco para geração de Terraform seria: "Crie um bucket S3". O resultado será um recurso mínimo sem nenhuma das configurações de segurança ou compliance que um bucket de produção precisa.

Um prompt eficaz seria:

Crie um recurso Terraform aws_s3_bucket para armazenar artifacts de CI/CD. Requisitos: versioning habilitado, server-side encryption com KMS (a chave KMS já existe como data.aws_kms_key.ci), block public access em todas as configurações, lifecycle rule para mover objetos para Glacier após 90 dias e deletar após 365, e bucket policy que permita acesso apenas da role arn:aws:iam::ACCOUNT:role/ci-pipeline-role. Provider AWS versão ~> 5.0. Não use o recurso depreciado aws_s3_bucket_acl.

A diferença no resultado é substancial. O segundo prompt gera código que se aproxima do que iria para produção. O primeiro gera um ponto de partida que precisaria de 80% de retrabalho.

Gerando um Pipeline GitHub Actions do Zero

O caso de uso mais comum de assistência de IA em DevOps é gerar o esqueleto de um pipeline para um projeto novo. O processo mais eficaz não é pedir o pipeline completo em um único prompt — é construir em camadas, revisando cada parte antes de prosseguir.

Primeiro prompt — contexto e estrutura:

Preciso de um workflow GitHub Actions para uma API Node.js 20 usando Express, TypeScript e Jest para testes. O repositório usa npm workspaces com três pacotes: packages/api, packages/shared e packages/worker. O workflow deve rodar em push para main e em pull requests. Crie apenas a estrutura do workflow com os jobs definidos (sem os steps internos ainda): lint, testes unitários, build da imagem Docker e deploy em staging. Os jobs de testes e lint devem rodar em paralelo. O build e deploy apenas na branch main.

A resposta vai gerar a estrutura com needs: e if: corretos. Então se aprofunda em cada job:

Agora detalhe o job de testes unitários. Ele precisa de serviços PostgreSQL 16 e Redis 7. Os testes rodam com npm test --workspace=packages/api. A cobertura mínima é 80% e deve ser verificada via script. O resultado dos testes deve ser publicado como artifact. Use ubuntu-22.04 para compatibilidade com bibliotecas nativas.

Esse processo iterativo produz resultados mais confiáveis do que tentar gerar tudo de uma vez, porque permite revisar e corrigir antes de acumular erros em prompts subsequentes.

Revisão Automatizada de Terraform

Além de gerar código, os assistentes de IA são úteis para revisar infraestrutura existente em busca de problemas de segurança, custo e conformidade com boas práticas. O processo funciona bem quando o contexto é fornecido junto com o código:

Revise este módulo Terraform que cria um cluster EKS. Identifique: (1) problemas de segurança, (2) configurações que violam o princípio de menor privilégio, (3) recursos sem tags obrigatórias, (4) ausência de configurações de alta disponibilidade. Para cada problema, explique o risco e sugira a correção específica.

Um exemplo de revisão assistida que encontra problemas reais:

# Código submetido para revisão — com problemas intencionais

resource "aws_eks_cluster" "principal" {
  name     = "meu-cluster"
  role_arn = aws_iam_role.eks.arn

  vpc_config {
    subnet_ids = var.subnet_ids
    # endpoint_public_access não configurado — padrão é true
    # endpoint_private_access não configurado — padrão é false
  }
  # Sem encryption_config — etcd não criptografado
  # Sem enabled_cluster_log_types — sem logs do control plane
  # kubernetes_version não especificado — vai usar a versão padrão atual
  #   e pode mudar inesperadamente em apply futuro
}

resource "aws_iam_role_policy_attachment" "eks_worker" {
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"  # PROBLEMA: acesso total
  role       = aws_iam_role.eks_nodes.name
}

Um assistente bem instruído identificará: o endpoint público habilitado sem restrição de CIDR (qualquer IP pode tentar acessar o API server), a ausência de criptografia do etcd (dados dos Secrets do Kubernetes ficam sem criptografia em repouso), a falta de logs do control plane (sem auditoria de quem fez o quê), a política AdministratorAccess nos nós do cluster (qualquer pod com acesso à metadata do EC2 pode assumir permissão total na conta AWS), e a ausência da versão do Kubernetes (risco de drift de configuração).

Geração de Runbooks a Partir de Alertas

Um uso menos óbvio mas muito prático: gerar runbooks estruturados a partir da descrição de um alerta ou de um incidente já resolvido. O prompt precisa incluir o sistema, o alerta, o que foi investigado e o que resolveu:

Crie um runbook para o alerta "HighMemoryPressureInPod" no Kubernetes. O alerta dispara quando um pod usa mais de 90% do memory limit por mais de 10 minutos. O runbook deve cobrir: diagnóstico inicial (comandos kubectl específicos), causas mais comuns com como identificar cada uma, ações de mitigação imediata (sem downtime), ações de resolução definitiva, e quando escalar. Formato: markdown com seções numeradas e blocos de código copiáveis.

O resultado é um rascunho de runbook que precisa de revisão por alguém que conhece o sistema específico, mas economiza 60–70% do tempo de criação do zero.

Análise de Custos com IA

Uma aplicação prática em FinOps: submeter a saída do AWS Cost Explorer ou do infracost para análise e recomendações de otimização.

O infracost é uma ferramenta open-source que calcula o custo de recursos Terraform antes de aplicá-los. Integrado ao pipeline, ele comenta no PR com a diferença de custo estimada. Combinado com análise por LLM, pode gerar recomendações:

# .github/workflows/infracost.yml
name: Análise de Custo

on:
  pull_request:
    paths:
      - 'infrastructure/**'

jobs:
  infracost:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Gerar estimativa de custo
        run: |
          infracost breakdown \
            --path infrastructure/ \
            --format json \
            --out-file /tmp/infracost.json

      - name: Analisar com IA e comentar no PR
        uses: actions/github-script@v7
        env:
          INFRACOST_JSON: /tmp/infracost.json
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        with:
          script: |
            const fs = require('fs');
            const infracostData = JSON.parse(
              fs.readFileSync(process.env.INFRACOST_JSON, 'utf8')
            );

            // Chamar API para análise contextual
            const response = await fetch('https://api.anthropic.com/v1/messages', {
              method: 'POST',
              headers: {
                'Content-Type': 'application/json',
                'x-api-key': process.env.ANTHROPIC_API_KEY,
                'anthropic-version': '2023-06-01'
              },
              body: JSON.stringify({
                model: 'claude-opus-5',
                max_tokens: 1000,
                messages: [{
                  role: 'user',
                  content: `Analise este relatório de custo do Infracost e forneça:
1. Resumo do impacto de custo desta mudança
2. Os 3 recursos mais caros adicionados
3. Sugestões específicas de otimização de custo
4. Alertas para recursos que possam ter custo inesperadamente alto

Relatório: ${JSON.stringify(infracostData.projects, null, 2).slice(0, 3000)}

Responda em português, de forma concisa, em markdown.`
                }]
              })
            });

            const analysis = await response.json();
            const analysisText = analysis.content[0].text;

            const monthlyDiff = infracostData.diffTotalMonthlyCost;
            const emoji = parseFloat(monthlyDiff) > 50 ? '⚠️' : 
                          parseFloat(monthlyDiff) > 0 ? '💰' : '✅';

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## ${emoji} Análise de Custo — Infracost\n\n` +
                    `**Variação mensal estimada:** $${monthlyDiff}/mês\n\n` +
                    `---\n\n${analysisText}`
            });

Os Limites que o Engenheiro Precisa Conhecer

A produtividade que os assistentes de IA proporcionam vem com riscos que precisam ser gerenciados conscientemente.

O primeiro risco é a confiança excessiva em código gerado sem revisão. LLMs geram código plausível — código que parece correto, compila e até funciona em cenários simples. Mas podem gerar configurações de segurança incorretas, versões depreciadas de recursos, ou lógica sutil que falha em edge cases. Todo código gerado por IA para infraestrutura deve ser revisado com o mesmo rigor aplicado a código escrito por um engenheiro júnior.

O segundo risco é a alucinação de APIs e recursos. Modelos de linguagem às vezes inventam argumentos de funções, nomes de campos em recursos Terraform, ou opções de configuração que não existem. Para infraestrutura, isso significa terraform plan vai falhar — o que é controlável. O risco maior é quando a alucinação é de um recurso que existe mas com comportamento diferente do descrito.

O terceiro risco é o contexto de segurança ausente. Um LLM sem contexto de segurança específico da organização não sabe que determinados CIDRs são proibidos, que certos tipos de instância estão bloqueados por política, ou que secrets precisam passar pelo cofre corporativo. Prompts eficazes incluem essas restrições explicitamente.

A conclusão pragmática é que assistentes de IA são amplificadores de capacidade, não substitutos de julgamento. O engenheiro que sabe o que quer construir e conhece as boas práticas usa a IA para chegar lá mais rápido. O engenheiro que não sabe o que quer construir vai chegar mais rápido ao lugar errado.

Referências para Aprofundamento

• GitHub Copilot — Documentação
• Cursor Editor
• Infracost — Cloud Cost Estimates
• Prompt Engineering para Desenvolvedores
• Anthropic API — Documentação

Exercícios

Exercício 1

O artigo contrasta "Crie um bucket S3" com um prompt de sete linhas, e afirma que o primeiro deixa 80% de retrabalho. Dos quatro elementos de contexto que o artigo lista, qual deles o prompt bom usa para evitar um erro que o terraform plan não pegaria?

Exercício 2

O artigo recomenda construir o pipeline em camadas em vez de pedir tudo num prompt só, e justifica dizendo que isso evita "acumular erros em prompts subsequentes". Descreva o modo de falha concreto que a geração em um único prompt produz.

Exercício 3

Na revisão do EKS, o artigo trata a AdministratorAccess anexada à role dos nós como o achado mais grave, e o justifica com a metadata do EC2. Explique a cadeia: como um pod comum chega às permissões da conta inteira?

Exercício 4

Ainda na revisão do EKS: dos cinco achados, um não é falha de segurança nem de disponibilidade, mas de previsibilidade. Qual é, e por que ele morde num apply futuro e não no primeiro?

Exercício 5

O workflow do Infracost declara permissions: pull-requests: write e contents: read, e roda em on: pull_request. Um contribuidor externo abre um PR de um fork e o step de comentar falha por falta de permissão. Por quê — e qual a saída correta?