Coding agents nas empresas: o desafio é a infraestrutura

Do autocompletar à execução de tarefas#

Durante anos, a promessa da IA no desenvolvimento de software se resumiu a uma imagem: um assistente que sugere a próxima linha enquanto você digita. Útil, mas limitado.

Essa imagem ficou para trás. Os coding agents atuais recebem uma tarefa, exploram o repositório, modificam arquivos, executam comandos num terminal, leem os erros, corrigem e tentam de novo até fechar um fluxo que antes levava horas de trabalho humano.

Isso já é medido com benchmarks públicos que simulam engenharia real. O Coding Agent Index da Artificial Analysis, por exemplo, combina tarefas de engenharia de software sobre repositórios, uso agêntico de um terminal e perguntas técnicas que exigem entender o comportamento de uma base de código inteira, e ainda publica o custo e o tempo médio por tarefa de cada agente. A composição do índice é revisada ao longo do tempo, então vale consultar a versão vigente antes de citar números.

O que esses resultados mostram é que os agentes já vão muito além de gerar trechos isolados de código. Por isso, a pergunta útil para uma empresa não é mais qual é o melhor coding agent, e sim se a infraestrutura dela está pronta para operar um.

Documentação: Artificial Analysis · Coding Agent Index ↗

O agente não trabalha sozinho: trabalha na sua infraestrutura#

Um coding agent não existe no vácuo. Ele tem acesso a repositórios, executa comandos num sistema, lê e escreve arquivos, consome tokens a cada interação e deixa um rastro de ações que, sem controles, ninguém consegue auditar nem reverter.

A OWASP classifica esse problema como agência excessiva: dar a um sistema baseado em LLM mais funcionalidade, permissões ou autonomia do que a tarefa exige. Quando o agente opera sem limites claros, os riscos são concretos:

• Segurança: ele pode ler variáveis de ambiente, arquivos de configuração ou segredos se as permissões não estiverem segmentadas.
• Custos: uma tarefa mal definida ou um loop sem limite consome tokens, e dinheiro, sem que ninguém perceba. O custo por tarefa varia muito entre agentes e modelos, então é preciso medi-lo no seu próprio ambiente.
• Erros em produção: se ele puder escrever direto em branches críticas sem revisão, uma mudança incorreta pode acabar em deploy.
• Exposição de dados: sem políticas de acesso, ele pode ler informações sensíveis do repositório ou dos sistemas com que interage.
• Perda de rastreabilidade: sem registro do que fez, quando e por quê, a auditoria é impossível.

Nenhum desses problemas se resolve escolhendo um modelo mais capaz. Eles se resolvem com infraestrutura.

Documentação: OWASP GenAI · LLM06:2025 Excessive Agency ↗

Platform engineering: o habilitador que quase ninguém cita#

A conversa sobre coding agents costuma ficar em modelos, benchmarks e demos. Raramente chega ao lugar onde se decide se eles funcionam numa empresa: o time de platform engineering, que constrói e mantém os ambientes internos onde o software é desenvolvido, testado e colocado em produção.

Esse time agora precisa responder a perguntas novas:

• Onde o agente roda: em infraestrutura própria ou num serviço externo?
• Que permissões ele tem sobre os repositórios? Escreve direto ou só propõe mudanças via pull request?
• Como ele se integra ao pipeline de CI/CD existente?
• Que ambientes isolados existem para ele testar código sem tocar em sistemas reais?
• Como é controlado o acesso dele a segredos, credenciais e configurações sensíveis?

A CNCF define uma plataforma como um conjunto integrado de capacidades apresentado de acordo com as necessidades dos seus usuários, os times internos, e a DORA a descreve como um produto interno com caminhos pavimentados. Um agente conectado a essa plataforma herda os controles dela; um agente solto sobre infraestrutura improvisada é um risco operacional.

Documentação: CNCF TAG App Delivery · Platforms white paper ↗ · DORA · Platform engineering ↗

Isole cada execução num sandbox efêmero#

Cada tarefa do agente deveria rodar num container ou microVM criado para essa tarefa e destruído ao final. Assim, um comando destrutivo não afeta sistemas compartilhados, e cada execução parte de um ambiente limpo e reproduzível.

docker run --rm \
  --user 10001:10001 \
  --read-only --tmpfs /tmp:rw,size=512m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 --memory 4g --cpus 2 \
  --network agent-egress \
  -v "$PWD/worktree:/workspace" -w /workspace \
  agent-runner:1.4.2 run-task --task-file .task.md

Containers compartilham o kernel do host. Se o agente for executar código não confiável, considere uma camada adicional como gVisor ou microVMs e, no Kubernetes, aplique o perfil restricted dos Pod Security Standards ao namespace onde os agentes rodam.

Para se aprofundar: Acesso à sua AWS para plataforma externa com privilégio mínimo

Documentação: Docker Docs · Docker Engine security ↗ · Docker Docs · docker container run ↗ · gVisor · Documentation ↗ · Kubernetes · Pod Security Standards ↗

DevSecOps: a segurança não pode vir depois#

O modelo de construir primeiro e proteger depois não funciona quando um agente pode executar comandos, modificar código e navegar por repositórios. A segurança precisa estar lá desde o primeiro dia:

• Identidade e permissões granulares: privilégio mínimo, com credenciais de curta duração limitadas à tarefa.
• Revisão obrigatória: branches protegidas que exijam pull request e aprovação humana antes de fazer merge de qualquer mudança do agente.
• Varredura de segredos: todo código gerado ou modificado passa por detecção de credenciais, tokens e chaves antes de chegar ao repositório.
• Auditoria de ações: cada arquivo tocado, comando executado e API consultada fica registrado.

No GitHub Actions, um fluxo razoável deixa o agente trabalhar na própria branch, com um token de permissões mínimas e um limite de tempo, e termina num pull request que a proteção de branch obriga a revisar.

name: agent-task
on:
  workflow_dispatch:
    inputs:
      task:
        description: "Tarefa para o agente"
        required: true

# Privilégio mínimo: o token só pode fazer push da branch do agente e abrir um PR.
permissions:
  contents: write
  pull-requests: write

jobs:
  agent:
    runs-on: ubuntu-latest
    timeout-minutes: 30          # corta loops e gasto descontrolado
    steps:
      - uses: actions/checkout@v4
      - name: Executar o agente numa branch própria
        env:
          TASK: ${{ inputs.task }}   # nunca interpole inputs direto em run:
          GH_TOKEN: ${{ github.token }}
        run: |
          git switch -c "agent/${GITHUB_RUN_ID}"
          ./scripts/run-agent.sh "$TASK"      # executa num container efêmero
          git push origin "agent/${GITHUB_RUN_ID}"
          gh pr create --fill --base main --head "agent/${GITHUB_RUN_ID}"

DevSecOps não é opcional com agentes autônomos: é a condição mínima para operar com segurança.

Documentação: GitHub Docs · About protected branches ↗ · GitHub Docs · Automatic token authentication (GITHUB_TOKEN) ↗ · GitHub Docs · Security hardening for GitHub Actions ↗ · GitHub Docs · About secret scanning ↗

Observabilidade: se você não vê, não controla#

Os benchmarks medem o mesmo que uma empresa precisa medir em produção: tempo por tarefa, consumo de tokens, custo por operação e taxa de sucesso. Num ambiente real, é preciso mais:

• O que o agente fez: o log completo de ações, não só o resultado final.
• Quanto custou: o custo real de cada sessão, com tokens de entrada, saída e cache.
• O que mudou: um diff claro de cada modificação, ligado à tarefa que a motivou.
• O que falhou e por quê: em que ponto ele parou e que erro encontrou.
• Como reverter: um processo de rollback simples, rápido e completo.

O OpenTelemetry tem convenções semânticas para IA generativa que padronizam spans e métricas de chamadas a modelos, como o uso de tokens por operação. Instrumentar o agente com elas permite levar esses dados ao mesmo backend onde você já observa o resto da sua plataforma, em vez de depender do painel de um fornecedor.

Sem essa visibilidade, o agente é uma caixa-preta dentro da sua infraestrutura, e uma caixa-preta que pode modificar código não é um ativo: é um risco.

Para se aprofundar: SLIs e SLOs mal definidos: por que geram alertas falsos

Documentação: OpenTelemetry · Semantic conventions for generative AI ↗ · OpenTelemetry · GenAI metrics ↗

Benchmarks medem capacidade; a infraestrutura decide a viabilidade#

É valioso saber quais agentes resolvem melhor tarefas complexas de repositório, quais são mais eficientes no terminal e quais têm a melhor relação custo-desempenho. Mas nenhum benchmark diz se a sua organização está pronta para operar um em produção.

O fato de um agente resolver uma fração das tarefas difíceis de um benchmark não significa que ele vá reproduzir esse resultado no seu repositório. Seu código, suas dependências, suas convenções e seus controles são outros. Essa pergunta só é respondida por uma avaliação honesta da sua infraestrutura, dos seus processos de segurança, da sua observabilidade e da sua maturidade operacional.

O NIST AI Risk Management Framework oferece uma estrutura para esse exercício: governar, mapear, medir e gerenciar os riscos de um sistema de IA ao longo do seu ciclo de vida.

Documentação: Artificial Analysis · Coding Agent Index ↗ · NIST · AI Risk Management Framework ↗

Checklist antes de dar acesso a um agente#

A vantagem competitiva é a plataforma#

As empresas que mais extraírem valor dos coding agents não serão necessariamente as que usam o modelo mais avançado, e sim as que construíram a plataforma certa para operá-los de forma segura, mensurável e escalável: ambientes isolados, permissões claras, revisão humana no pipeline, observabilidade de custos e ações, rollback rápido e times de plataforma e segurança alinhados.

Essa é a diferença entre usar IA de forma oportunista, com resultados inconsistentes e riscos sem controle, e usá-la como uma capacidade organizacional de verdade. O modelo é o motor; a infraestrutura é o chassi, os freios e o volante.