Em agosto, a Cloudflare publicou o que talvez seja a declaração mais direta do ano: o SDLC é para times de software, e times de software não escalam para o volume que agentes produzem. A proposta é o ADLC — Agent Development Lifecycle. Qualquer entrada (erro de produção, bug report, ideia de feature) é delegada inteira a um agente, do plano ao rollback.

Não é retórica de blog post. Vem acompanhada de uma lista de sete propriedades que cada etapa manual do ciclo precisa ter para um agente conseguir dirigi-la: programática (ClickOps é non-starter), reproduzível, atômica, com permissão escopada, push-based, escalável horizontalmente, auto-melhorável. A analogia é com carro autônomo — não basta enfiar um motor autônomo num carro de humano, é preciso lidar por fio, câmeras, tomada remota. O problema declarado não é acertar 80%; é ir de 80% para vários noves.

E há dado de peso do outro lado da mesa. O whitepaper do Google sobre o novo SDLC (Osmani et al., 51 páginas) registra que, no início de 2026, 85% dos desenvolvedores profissionais usam agentes de código regularmente e 41% de todo código novo é gerado por IA. Mais interessante que a adoção é a prova de alavancagem: no Terminal Bench 2.0, um time tirou um agente de fora do Top 30 e o colocou no Top 5 sem trocar o modelo — mexendo só no harness. A LangChain ganhou 13,7 pontos no mesmo benchmark ajustando system prompt, tools e middleware sobre modelo fixo.

A conclusão que os dois documentos compartilham é limpa: o modelo virou commodity, o harness é o produto. Agent = Model + Harness.

Concordo com a leitura. O que ela não conta é onde a fábrica encosta no chão.

O paper que ninguém cita junto

Em maio, três pesquisadores da EURECOM e da Basilicata publicaram Constraint Decay — 80 tarefas greenfield e 20 de implementação de feature, rodadas contra oito web frameworks. O achado: conforme restrições estruturais se acumulam sobre a tarefa (padrões arquiteturais, ORM, contratos de dados), configurações capazes perdem cerca de 30 pontos em assertion pass rate. As configurações fracas tendem a zero.

A distribuição do erro é o que interessa. Agentes rendem bem em frameworks explícitos, onde a estrutura está escrita no código — Flask. E degradam em frameworks convencionais, onde a estrutura está em convenção implícita — FastAPI, Django. As causas-raiz dominantes são defeitos de camada de dados: composição de query, violação de contrato do ORM.

Traduzindo: framework convencional cobra um imposto de agente. Justamente o tipo de framework que você escolheu porque reduzia o atrito humano.

Isso conversa mal com a narrativa de fábrica. O whitepaper trata restrição como algo que o harness absorve — specs, verificadores estáticos, guardrails. O paper mostra restrição acumulada derrubando trinta pontos em configurações que já são boas. Verificador estático é necessário e não é suficiente.

Restrição acumulada tem outro nome

O ponto cego é o regime de tarefa. Benchmark de agente é predominantemente greenfield: repositório limpo, requisito fechado, sem histórico. É o regime em que a demo funciona.

Codebase corporativo é o oposto por definição. É restrição estrutural sedimentada por anos — decisões de arquitetura que ninguém documentou, um ORM com três padrões de uso conflitantes, contratos de dados que sobreviveram a duas migrações. Restrição acumulada não é um caso adverso do trabalho real. É o trabalho real.

Então o gráfico de degradação do paper não descreve uma condição de laboratório. Descreve a curva que sai do protótipo e entra na sua empresa.

E o modo de falha é o pior possível para uma fábrica: código funcionalmente correto e estruturalmente arbitrário. Passa no teste. Vira outage três semanas depois. É a validação empírica do que o whitepaper chama de “problema dos 80%” — o último trecho não é de capacidade, é de conformidade a restrições que ninguém escreveu.

Um caso de laboratório, em casa

Semana passada rodei um insight report gerado por agentes sobre esses mesmos documentos, em cima do meu acervo pessoal. O resultado tinha dois defeitos, e a natureza deles me convenceu mais do que o paper.

No primeiro, um card de estatística exibia 80% para um resultado que era Top 30 → Top 5. No segundo, um ganho de produtividade de 25-39% aparecia atribuído à Deloitte, quando a fonte real eram duas outras consultorias — a Deloitte estava na footnote seguinte, ancorada a um número diferente.

Nenhum dos dois é alucinação. Todos os tokens existiam no corpus, verbatim. O que quebrou foi o binding: o número certo colado na entidade errada, recombinado entre vizinhanças adjacentes. Presença válida, ligação inválida.

E é aí que a coisa fecha o círculo. Um verificador que checa presença — “esse número existe na fonte?” — passa nos dois casos por construção. Tentei aproximar o binding por co-ocorrência léxica, janela de 400 caracteres: um verdadeiro positivo, quatro falsos. A heurística não separa footnote legítima de contaminação, porque a informação que distinguiria as duas foi descartada no momento da geração.

A correção que funcionou não foi modelo melhor nem prompt melhor. Foi obrigar cada afirmação numérica a declarar o trecho exato de onde veio, e verificar isso por substring com teto de tamanho. Determinístico, sem LLM juiz, reprova o build.

Constraint decay em escala de parágrafo. Mesma forma: o agente tem os elementos certos, e erra a ligação entre eles conforme o contexto adjacente adensa.

O que muda para quem constrói

  • Escolha de framework virou decisão de agente. Se parte do seu roadmap depende de agentes trabalhando sozinhos no repositório, estrutura explícita passou a ter valor operacional, não só estético. Convenção implícita é barata para humano e cara para agente — e o paper diz quanto.
  • A restrição precisa viajar junto do dado. Reconstruir o vínculo depois — por janela, por co-ocorrência, por um segundo modelo que confere — é adivinhação com aparência de auditoria. Ou o passo que gera declara a que se prende, ou o vínculo não existe.
  • Verificação determinística antes de juiz LLM. Um gate léxico cobre menos do que parece: no meu caso, só ancoragem numérica e nominal, nada de prosa. Mas custa quase nada, não tem juiz para enviesar, e reprova o build. Piso baixo é melhor que teto imaginário.
  • A régua é o eval, não a demo. Demo prova sucesso uma vez. Suite de eval com rubrica explícita prova confiabilidade — e é a única coisa que mede o regime em que a fábrica realmente vai operar, que é o brownfield.

O whitepaper fecha com uma frase que vai virar slogan: generation is solved. Está certo. Verificação, julgamento e direção é que viraram o ofício.

Só que “verificação” continua sendo dita como se fosse uma fase do ciclo, e ela não é — é uma propriedade que precisa estar embutida em cada passo que gera alguma coisa. A pergunta prática, para quem está montando uma fábrica de software com agentes neste momento: dos artefatos que os seus agentes produzem hoje, quantos conseguem apontar a linha exata de onde tiraram cada afirmação que fazem?

Fontes: The New SDLC With Vibe Coding (Google, Osmani et al.) · The Agent Development Lifecycle has arrived on Cloudflare · Constraint Decay: The Fragility of LLM Agents in Backend Code Generation (arXiv 2605.06445).