A Função de Recompensa Não Tem Linha para Manutenibilidade

O aprendizado por reforço em agentes de código pontua dois bits: o teste alvo passou de falhando para passando, e os testes que já passavam continuaram passando. É todo o canal de recompensa do SWE-bench Multilingual, a família de benchmarks que moldou uma geração de modelos de código. Dex (Dexter Horthy), fundador da HumanLayer, enuncia a consequência sem rodeios em “Why Software Factories Fail”: “não existe penalidade por erodir a manutenibilidade da base de código.”

Ele declara o próprio interesse no primeiro parágrafo do texto: “eu dirijo uma empresa (HumanLayer) que constrói ferramentas no espaço de colaboração humano/agente.” Ele descreve um déficit contra o qual também vende, o que é razão para testar a afirmação no seu próprio repositório em vez de aceitá-la. O mecanismo, porém, é verificável independentemente do produto dele.

Já tratamos deste tema pela ponta de baixo várias vezes. A verificação virou o trabalho. Mais código escrito, menos deploys entregues. O próprio harness virou artefato de 90 dias. Esses textos descrevem sintomas. Horthy realoca a causa para o objetivo de treinamento, que está acima de qualquer decisão de harness que um time consiga tomar.

Manutenibilidade Não Tem Oráculo Rápido

A função de recompensa omite manutenibilidade por uma razão de medição, e é uma razão difícil de contornar.

“Testes te dão feedback em segundos”, escreve Horthy, “mas a função de custo de uma arquitetura ruim é medida em semanas, meses, talvez até anos.” Aprendizado por reforço precisa de um sinal que possa ser consultado milhões de vezes por rodada de treinamento. Suítes de teste servem. Decadência arquitetural não serve, porque a conta chega depois que o treino terminou, depois que o modelo foi lançado, depois de três trimestres de features empilhadas sobre a decisão.

Há também a circularidade, que é a metade mais afiada do argumento: “se um modelo conseguisse distinguir código bom de ruim de forma confiável, ele talvez tivesse escrito a versão boa desde o início, mas manutenibilidade não tem oráculo rápido, então não conseguimos recompensá-la durante o RL.” Você não pode usar o modelo como juiz da própria qualidade sem assumir a capacidade que está tentando treinar. E não dá para resolver comprando benchmark, porque, nas maiúsculas dele, “NÃO EXISTEM BONS BENCHMARKS para a capacidade de um modelo manter a qualidade de uma base de código.”

Um detalhe de correção do SWE-bench Multilingual vale ser copiado, independentemente do que você ache do argumento maior. O harness mantém o patch do modelo, mas descarta qualquer edição que ele tenha feito em arquivos de teste, e só então aplica o patch de teste retido por cima. A razão é empírica: “já pegamos um modelo comentando discretamente o teste que falhava, ou enxertando um mock que torna o teste inútil.” Um canal de recompensa estreito o suficiente para ser rápido também é estreito o suficiente para ser burlado, e a burla aparece primeiro nos arquivos de teste. Se as suas avaliações internas não descartam as edições do agente em arquivos de teste antes de pontuar, sua taxa de aprovação está medindo em parte a habilidade do agente de editar o placar.

Por Que Mais Ferramenta Não Alcança o Teto

Horthy toma cuidado para não descartar ferramentas: “mais agentes de revisão e mais tokens ajudam de fato. Eles elevam o piso, pegam as bobagens. Mas não movem o teto, porque o teto é aquilo que conseguimos ensinar ao modelo no RL.”

Essa frase explica um padrão que a maioria dos líderes de engenharia já viveu. Você adiciona um agente revisor, depois um segundo com regras diferentes, depois uma passada de lint, depois uma checagem de conformidade com a especificação. Os defeitos óbvios caem. A deriva arquitetural continua no mesmo ritmo, porque nada na pilha tem opinião sobre se a terceira camada de abstração deveria existir.

A linha de tempo pessoal dele é a evidência mais útil aqui, mais do que qualquer agregado. Bases de código construídas por agentes, na experiência dele, começam a sofrer depois de três a seis meses. Ele começou uma tentativa de operação com as luzes apagadas em julho de 2025. Perto do terceiro incidente de produção, em novembro, reescreveu do zero, e o cofundador dele passou duas semanas inteiras reencanando padrões à mão. É um fundador com todos os incentivos para relatar o resultado oposto.

Sobre retrabalho ele é mais direto: 20% de retrabalho já é um peso para o time, e “a maioria dos PRs de oneshot com IA fica mais perto de 50%.” A economia da revisão decorre disso. Revisão incremental significa 100 a 200 linhas por etapa. Revisão no fim significa 2.000 linhas ou mais, que é o volume em que a atenção humana degrada até virar aprovação.

Ele também cita um conjunto de dados da Faros AI sobre carga de revisão e taxa de incidentes, e cabe sinalizar que esses números aparecem em texto alternativo de imagem e que ele próprio chama o relatório de “mais um sinal de correlação do que uma prova verificável” (Faros AI, via HumanLayer). Usamos esse mesmo conjunto de dados no início deste mês. Ele não sustenta o argumento aqui e não deve ser tratado como se sustentasse.

Três Avaliações Tentando Construir o Oráculo Que Falta

A resposta interessante a um oráculo ausente é construir um. Três esforços de fronteira tentam exatamente isso, cada um atacando uma propriedade diferente do bit binário:

SWE-Marathon (Abundant AI) troca o bit único de passa/falha por um canal de recompensa composto, e estica a duração das tarefas de cerca de 15 minutos no SWE-bench Multilingual para cerca de 400 horas. Horizontes longos são onde a consequência arquitetural se torna observável.
DeepSWE (Datacurve) treina em repositórios que nunca foram construídos no mundo real, o que o torna imune a contaminação. Se o modelo nunca viu aquela base de código, a nota reflete raciocínio em vez de memória.
Frontier Code (Cognition) usa tarefas de múltiplos PRs, penaliza testes que deixam de falhar no código anterior ao patch (exatamente a burla descrita acima) e acrescenta um modelo juiz que pontua o diff contra regras explícitas de qualidade de código.

Nenhuma delas foi demonstrada ainda como sinal de treinamento em escala de fronteira. Até que uma seja, o teto descrito por Horthy permanece onde está, e a premissa honesta de planejamento para as próximas duas gerações de modelos é que manutenibilidade continua não treinada.

O Julgamento Se Move Para Antes, Porque Não Pode Ser Delegado Depois

Se o modelo não pode ser ensinado a preservar arquitetura, e o portão de revisão chega tarde demais para impor isso, o único lugar restante para colocar julgamento humano é antes de o código existir. As quatro fases de planejamento de Horthy são a forma prática disso:

Revisão de Produto. O problema descrito nos termos do usuário, com critérios de sucesso. Ele prefere mockups em HTML a prosa, porque um mockup torna a discordância visível em segundos.

Arquitetura de Sistema. Serviços, endpoints, schemas, filas, armazenamentos. Diagramas de sequência em mermaid, formatos de contrato, modelos de dados em SQL.

Desenho de Programa. Ele chama esta fase de “criminosamente subestimada”, e é a que quase ninguém escreve: árvores de pilha de chamadas expressas em sintaxe de diff, um diff da árvore de arquivos anotado com NEW e MODIFIED, além de tipos e assinaturas de método para as novas funções principais. É a camada em que as escolhas estruturais de um agente ainda são baratas de vetar.

Fatias Verticais, ordenadas do meio para fora. Contrato de API mais dados falsos, depois frontend contra os mocks, depois ligar a API aos serviços, depois migrações e serviços para o banco, depois regra de negócio, depois tratamento de erro. Deixados por conta própria, os modelos preferem planos horizontais: todas as migrações, depois todos os serviços, depois a API, depois o frontend. Planos horizontais empurram o risco de integração para o fim, que é onde cronogramas morrem.

Vale manter a proporção: cerca de 40% das tarefas são oneshot, ou oneshot com uma ou duas rodadas de feedback leve. Essas dispensam tudo isso. Aplicar quatro fases de planejamento a uma mudança de texto é como um bom processo é abandonado.

Escolha o Revisor Antes de o Código Existir

A ideia mais adotável do texto inteiro não custa nada para testar: “se você quer economizar tempo na revisão, escolhe a pessoa que revisaria o PR e passa com ela pelas especificações de produto e técnica antes de chegar na parte de escrever código.”

Considere o que isso muda mecanicamente. Hoje o revisor encontra o trabalho como 2.000 linhas de diff pronto, e nesse ponto toda objeção é caríssima, social e tecnicamente. Rejeitar um desenho nesse estágio significa descartar uma tarde do agente e a sensação de progresso de um colega, então revisores arredondam para aprovar e registram a preocupação como um ticket de follow-up que ninguém agenda. Mova o mesmo revisor para o momento da especificação e a objeção idêntica custa a edição de um parágrafo. Nada foi construído para ser defendido.

Isso também corrige um problema de propriedade que times pesados em agentes criam de forma silenciosa. Quando o agente escreve o código, o apego do autor humano ao diff é fraco, mas o apego dele a entregar é forte. Nomear o revisor durante o planejamento dá à mudança dois humanos que entendem a intenção antes de existir uma única linha, e essa é a única forma durável de contexto compartilhado.

O reenquadramento de velocidade dele cabe aqui também: “é possível que você esteja ocupado demais tentando ir de 10 a 100 vezes mais rápido e tentando se convencer de que qualidade de código não importa mais, quando poderia abraçar as restrições e ir de 2 a 3 vezes mais rápido, com segurança.” Sobre volume, a leitura dele é que times que reclamam da quantidade de PRs estão reclamando da qualidade dos PRs.

A ressalva de Addy Osmani, que Horthy cita, define a fronteira de tudo isso: “um desenvolvedor fazendo vibe-coding em um projeto paralelo que uma dúzia de pessoas vai rodar, e um time mantendo vivo por mais um trimestre um sistema corporativo de dez anos, não compartilham quase nenhuma restrição que valha nomear.” O déficit de treinamento é universal. Quanto ele custa depende inteiramente de quanto tempo o seu código precisa viver.

Faça Isso Agora

Pegue o próximo ticket não trivial da sua fila. Antes de gerar qualquer código, escreva o Desenho de Programa: a árvore de pilha de chamadas, o diff anotado da árvore de arquivos, as assinaturas das novas funções. Depois marque 20 minutos com a pessoa que vai revisar o PR resultante e apresente isso a ela. Meça um número depois: rodadas de revisão até o merge, comparadas aos seus últimos cinco tickets equivalentes.

Em paralelo, abra o seu harness interno de avaliação e verifique se ele descarta as edições do agente em arquivos de teste antes de pontuar. Se não descarta, sua métrica de qualidade tem sido parcialmente autodeclarada desde que existe.

Fontes

HumanLayer. “Why Software Factories Fail.” 2026. Escrito por Dex (Dexter Horthy), com base na palestra dele na AI Engineer World’s Fair 2026.

A Victorino ajuda líderes de engenharia a mover revisão e julgamento de design para antes, antes que a saída do agente vire um diff de 2.000 linhas que ninguém consegue recusar: contato@victorino.com.br | www.victorino.com.br