Coding agents tornam barato produzir uma mudança plausível. O novo trabalho da plataforma é tornar evidências obrigatórias: qual especificação autorizou o trabalho, quais checks o provaram, qual identidade o criou e qual caminho controlado o entregou.
O workflow de coding agent do GitHub já reflete a nova forma do desenvolvimento: um agente trabalha em seu próprio ambiente, cria um pull request e solicita revisão. O GitHub também documenta que workflows de pull requests criados por agentes precisam de aprovação antes de executar. Essa fronteira importa. O agente produz mudança rapidamente; automações confiáveis e revisores responsáveis decidem se ela merece privilégios de execução e entrega.
Uma plataforma AI-native, portanto, não é uma IDE com chatbot. É um control plane de entrega de software que assume que alguns autores são autônomos, rápidos, não humanos e ocasionalmente errados de formas convincentes. Ela transforma intenção e evidências em regras de promoção aplicadas por máquina.
Tickets escritos por humanos frequentemente deixam premissas na cabeça do autor. Coding agents precisam de um contrato mais executável: comportamento esperado, comportamento proibido, interfaces, exemplos, restrições não funcionais, migrações e testes que devem existir. O pipeline deve ligar cada diff gerado à spec e rejeitar mudanças que não demonstrem cobertura dos critérios de aceitação.
O Secure Software Development Framework do NIST enfatiza preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Coding agents não substituem essas práticas; aumentam o volume em que a plataforma precisa aplicá-las.
Um check verde é grosseiro demais quando mudanças chegam mais rápido do que humanos conseguem lê-las. A plataforma deve preservar por que cada check existe, qual requisito cobre, qual artefato avaliou e se o ambiente era confiável. Protected branches e rulesets exigem revisões e status checks. Dependency review expõe mudanças arriscadas de pacotes. Code scanning encontra vulnerabilidades. Artifact attestations estabelecem proveniência de build. SLSA define garantias progressivamente mais fortes para a supply chain.
O output útil não é “pipeline passou”. É um grafo de evidências conectando tarefa, identidade, commits, dependências, testes, findings, exceções, reviews, artefatos, attestations, deploy e sinais de runtime.
| Etapa | Responsabilidade do coding agent | Gate da plataforma | Responsabilidade humana |
|---|---|---|---|
| Intenção | Reformular requisitos e identificar ambiguidades. | Exigir spec, owner, escopo, classe de risco e contrato de evidências. | Resolver tradeoffs e aprovar intenção de negócio. |
| Implementação | Alterar código, testes, docs, migrações e manifests. | Ambiente isolado, least privilege, identidade, orçamento e captura do diff. | Revisar arquitetura e decisões consequentes. |
| Verificação | Executar checks, diagnosticar falhas e propor correções. | Runners confiáveis independentes executam checks obrigatórios. | Aprovar exceções; nunca aceitar apenas auto-attestation do agente. |
| Segurança | Explicar findings e corrigir dentro do escopo. | Code scanning, dependency review, secret scanning, política e risk score. | Aceitar ou rejeitar risco residual. |
| Supply chain | Declarar arquivos gerados, tools e materiais usados. | Build confiável produz artefato assinado e attestation de proveniência. | Definir nível exigido de proveniência e política de exceções. |
| Entrega | Propor plano de rollout e rollback. | Proteções de ambiente, aprovações, canary e rollback automático. | Autorizar promoção de alto impacto e responder pelo resultado. |
Agentes são excelentes para gerar testes ausentes, explicar falhas, propor diffs menores, atualizar documentação e reparar violações de política. Eles devem receber feedback estruturado do pipeline e iterar dentro da mesma tarefa limitada. Não devem conseguir enfraquecer checks obrigatórios, aprovar o próprio workflow, dispensar findings, criar credenciais de produção ou fazer merge contornando proteções.
Use credenciais OIDC curtas para workflows confiáveis em vez de secrets cloud duradouros. Separe workspaces de agentes dos ambientes de deploy. Exija builders confiáveis para criar attestations. Trate mudanças em workflows, permissões, rulesets ou configurações de segurança como classe de risco maior.
Eu construiria um portal de plataforma onde cada tarefa de coding agent nasce de uma spec versionada e produz um dossiê de entrega. Ele conteria identidade do agente, permissões da tarefa, plano, diff, manifest de arquivos gerados, mapeamento de testes, scans, exceções, reviews, proveniência, rollout e resultado de runtime.
O visual central seria uma timeline de evidências para cada mudança. Um revisor poderia inspecionar um teste falho, rastreá-lo até o requisito protegido, ver como o agente reagiu e verificar que o artefato final veio do commit aprovado e workflow confiável.
Quando geração de código se torna abundante, confiança precisa vir de restrições e evidências, não do esforço de digitação. A plataforma AI-native não pergunta se humano ou agente escreveu o código. Ela pergunta se a mudança satisfez o contrato explícito, passou por verificação independente, preservou proveniência e entrou em produção por um caminho controlado.
Artigo sobre plataformas de desenvolvimento AI-native e CI/CD depois dos coding agents, cobrindo specs executáveis, verificação independente, gates de segurança, proveniência, artifact attestations, reviews e deploy controlado.