Por que as software factories falham: só engenharia de harness não basta

• Uma software factory autônoma (lights-off), em que pessoas não leem nem escrevem código, acelera a geração, mas também elimina o julgamento humano necessário para avaliar a manutenibilidade de longo prazo, o que dificulta seu funcionamento em codebases de produção complexas
• O aprendizado por reforço de modelos de programação otimiza recompensas rápidas e claras, como passar em testes, mas não consegue penalizar o custo de um design ruim que só aparece meses depois
• A família SWE-bench avalia correção de bugs e preservação dos testes existentes, mas não consegue filtrar mudanças que degradam lentamente a qualidade do código, como try/catch indiscriminado, type casts frouxos e shotgun surgery
• Hoje, é preciso que humanos façam code review e revisem requisitos de produto, arquitetura de sistema, design do programa e slices verticais antes da implementação para reduzir retrabalho e revisão em massa de código gerado por IA
• Se aceitarmos as limitações dos modelos, em vez de forçar uma automação de 10 a 100 vezes, é possível desenvolver 2 a 3 vezes mais rápido mantendo qualidade próxima à humana; julgamentos centrais e leitura de código ainda não podem ser terceirizados

---

A promessa e a realidade da software factory centrada em loops

• Na corrida para colocar IA de programação em produção, se espalhou a ideia de que basta aumentar harnesses e agent loops
  • A software factory autônoma da StrongDM defende uma abordagem em que humanos não leem nem escrevem código
  • O Symphony, da OpenAI, também é um exemplo de software factory baseada em engenharia de harness
• Essa abordagem parte das premissas de que pessoas são o gargalo, os modelos já são bons o bastante e o custo de gerar código é praticamente baixo, então basta lançar mais
• O objetivo é atingir ao mesmo tempo velocidade 10 a 100 vezes maior, alta qualidade e eliminação do code review humano
  • A aposta é que, com mais linters e bots de revisão de PR instruídos a fazer análises adversariais, o software pode se tornar seguro por conta própria
• Na prática, surgem casos em que erros de agentes de programação causam incidentes, e a codebase se deteriora rapidamente
• O relatório da Faros AI observou as seguintes mudanças após a adoção de ferramentas de programação com IA
  • O número e o tamanho dos comentários de revisão aumentaram, mas também cresceram os PRs mesclados sem revisão
  • Incidentes e bugs por desenvolvedor aumentaram
  • Ainda assim, trata-se mais de um sinal de correlação do que de causalidade comprovada
• É difícil encontrar dados conclusivos que mostrem os resultados da StrongDM, e também foram raras as atualizações públicas entre fevereiro e junho

Codebases complexas são um problema diferente de vibe coding

• Um side project usado por poucas pessoas e uma equipe mantendo um sistema enterprise com 10 anos de idade quase não compartilham as mesmas restrições
• O foco da discussão não é vibe coding em si, mas sim problemas difíceis em codebases complexas e manutenção em produção
• No passado, brownfield se referia a sistemas Java antigos e afins, mas codebases criadas por agentes também podem ficar difíceis de modificar depois de cerca de 3 a 6 meses por causa da velocidade de desenvolvimento
• Quando o resultado é ruim, muita gente aconselha usar mais tokens ou tecnologia melhor, mas o problema central está menos no harness e mais na forma como o modelo é treinado

A evolução da software factory

• De 1968 até antes da adoção de IA

  • O termo “software factory” remonta à conferência da OTAN de 1968, onde também surgiu a expressão “engenharia de software”
  • Por volta de 2022, uma factory típica tinha a seguinte estrutura cíclica
    • Humanos decidiam o que construir e registravam isso em rastreadores como Linear ou Jira
    • Uma pessoa responsável implementava e testava
    • Após verificações automáticas e code review humano, se houvesse problema o fluxo voltava à implementação
    • Depois do deploy em produção, o sistema era monitorado e incidentes e feedback de usuários voltavam ao rastreador
  • Como implementação e revisão levavam horas ou dias cada, as equipes colocavam planejamento, propostas de arquitetura e sprint planning antes, para formar consenso primeiro
  • Alinhamento antes da implementação reduz retrabalho, e PRs bem acabados, próximos da direção já decidida, podem ser revisados rapidamente mesmo quando alguém lê todas as linhas

• Factory orientada por agentes

  • Ramp, Stripe, WorkOS e Brex afirmam que factories com agentes já entregam cerca de 75% do código
  • Na factory tradicional, a etapa de implementação feita por humanos é substituída por agentes, combinando orquestração, harness, sandbox, modelos e uso do computador
  • O tempo de implementação cai de horas ou dias para minutos ou horas, mas leitura de código e testes por humanos permanecem, então a revisão vira o gargalo
  • Para reduzir esse gargalo, vários loops extras são adicionados
    • Code review por agentes para checar estilo, bugs e segurança
    • Testes de regressão que verificam comportamento externo via navegador e uso do computador
    • Fluxos que conectam incidentes automaticamente a PRs para que a pessoa responsável receba candidatos a correção
    • Fluxos que ligam diretamente o feedback do usuário à fila de trabalho
  • No fim, o problema operacional se resume a quanto trabalho pode entrar na fila e com que velocidade os resultados podem ser revisados e testados

• Factory autônoma

  • A factory autônoma, nomeada por Dan Shapiro, remove a etapa em que humanos leem todas as mudanças
  • Em vez de code review, investe-se nas áreas abaixo
    • Testes do próprio agente
    • Sandbox e orquestração
    • Revisão automática e monitoramento
    • Lançamento gradual e coleta de sinais de feedback dos usuários
  • Quando o julgamento humano é removido, só resta quantas tarefas podem ser pedidas ao agente, mas essa abordagem não funciona em codebases de produção complexas

O fracasso da abordagem autônoma aplicada na prática

• A partir de julho de 2025, foi adotada uma abordagem totalmente autônoma em que agentes em background liam apenas especificações e tickets para executar tarefas pequenas e médias
• Depois de alguns meses, surgiram problemas complexos que não podiam ser resolvidos nem com prompts sofisticados nem com workflows melhores
  • O contexto necessário era coletado e entregue ao modelo
  • O agente tentava reproduzir o problema de cerca de 10 maneiras diferentes
  • No fim, um humano precisava entrar diretamente na codebase, que não lia havia 3 meses, para encontrar a causa
• Nesse intervalo, o site saía do ar, usuários eram prejudicados, e humanos precisavam ler o código ruim acumulado
• Na primeira falha, julgou-se aceitável assumir o risco pela velocidade, mas por volta de novembro, quando surgiu aproximadamente o terceiro problema, reescrever tudo do zero era mais fácil
  • Um cofundador reimplementou manualmente os padrões no VS Code durante duas semanas

Por que os modelos pioram a qualidade da codebase

• Os modelos atuais não conseguem manter e melhorar a qualidade de uma codebase ao longo do tempo sem um direcionamento humano considerável
• Aqui, manutenibilidade significa a capacidade de evitar um estado em que mudar uma parte quebra outra, e em que a mesma alteração precisa ser aplicada em vários lugares, como em shotgun surgery
• Os modelos melhoraram muito para resolver problemas pontuais ou gerar novos sites de marketing, mas é difícil dizer que também melhoraram claramente na capacidade de melhorar a qualidade do código ao longo do tempo
• Como não há bons benchmarks para medir capacidade de manutenção, também é difícil provar ou refutar essa diferença
• Mesmo que modelos como o GPT-5.5 xhigh façam refatorações excelentes, se ainda for necessário que humanos entendam a codebase e instruam detalhadamente o trabalho, o problema da factory autônoma não está resolvido

Claude Code e o aprendizado por reforço dentro do harness

• Antes do Claude Code, já existiam agentes CLI como aider, cline e codebuff com leitura, escrita, edição, busca, ferramentas de shell e engenharia de contexto
• Agentes anteriores às vezes sofriam com falta de estabilidade no uso das ferramentas, como quando falhavam repetidamente na mesma edição
• O paper do SWE-Agent analisa que até pequenas diferenças no design das ferramentas — como colocar números de linha no resultado de ReadFile ou trocar Edit de localizar/substituir para edição por intervalo de linhas — afetam o desempenho
• Um motivo central para o crescimento rápido do Claude Code é que a Anthropic treinou o modelo com aprendizado por reforço dentro do harness real que pretendia lançar
  • Os pesos do modelo foram ajustados para que ele chamasse o conjunto exato de ferramentas dentro do agent loop
  • Ao contrário de desenvolvedores externos, que ajustam definição de ferramentas e avaliação às preferências do modelo, quem controla o modelo pode alterar o próprio modelo para se adequar às ferramentas
• Equipes que possuem tanto o harness quanto os pesos do modelo têm vantagem sobre equipes que só constroem o harness e não podem ajustar os pesos

Os limites de recompensa no aprendizado por reforço de agentes de programação

• O aprendizado por reforço de modelos de programação geralmente repete os seguintes passos milhões de vezes
  1. Gera um trace de execução do agente para resolver um problema, como corrigir testes
  2. Avalia o trace com um verificador
  3. Atualiza os pesos do modelo para aumentar a probabilidade de traces bons e reduzir a de traces ruins
• O problema é que a pontuação da avaliação pode ser excessivamente unidimensional

• O caso do SWE-bench Multilingual

  • O SWE-bench Multilingual usa tarefas de cerca de 15 minutos extraídas de repositórios open source como Redis, jq e Django
  • A recompensa é 0 ou 1 e verifica duas condições
    • FAIL_TO_PASS: se o problema solicitado foi corrigido
    • PASS_TO_PASS: se o comportamento existente não foi quebrado
  • A tarefa fastlane__fastlane-19304 é um bug em que, na ausência dos parâmetros opcionais include e exclude, ocorre falha ao chamar .empty? em nil
  • A correção humana real foi uma mudança de duas linhas definindo nil como array vazio por padrão
  • Antes da correção, o modelo recebe apenas o commit-base e o relatório do bug, sem ver o patch-resposta nem o patch de testes usado para pontuação
  • A avaliação segue esta ordem
    1. Preserva o patch criado pelo modelo
    2. Remove mudanças feitas pelo modelo nos arquivos de teste
    3. Aplica o patch de testes oculto do benchmark
    4. Executa juntos os testes existentes e os novos testes
  • As mudanças nos testes são descartadas porque o modelo pode comentar testes que falham ou inserir mocks sem sentido apenas para forçar aprovação
  • Benchmark e verificador de aprendizado por reforço não são a mesma coisa e devem permanecer separados, mas ambos mostram a limitação estrutural de julgar a qualidade de traces de programação

• Não há penalidade para deterioração de design

  • Se os testes passam, nem o processo usado para chegar à solução nem a qualidade estrutural entram na pontuação
  • Virar tudo em try/catch ou usar type casts frouxos que destroem as vantagens do sistema de tipos ainda pode ser considerado resposta correta
  • Danos à manutenibilidade não recebem penalidade desde que os testes antigos e os novos passem

Verificar qualidade é mais difícil do que fazer testes passarem

• Testes dão sucesso ou falha de forma clara em segundos, permitindo repetir aprendizado por reforço milhões de vezes
• O custo de uma arquitetura ruim aparece semanas, meses ou anos depois, quando pequenas mudanças precisam ser aplicadas em vários pontos
• Os benchmarks atuais não conseguem avaliar esse custo de design de longo prazo
• Aprendizado por reforço e benchmark não são a mesma coisa, mas, se manutenibilidade tivesse sido resolvida no aprendizado por reforço, seria provável ver essa capacidade refletida também no desenho dos benchmarks
• Portanto, melhorar a pontuação em benchmarks existentes não pode ser tomado como prova de que o modelo deixou de sujar a codebase

Novas tentativas de avaliar manutenibilidade

• A fronteira da qualidade dos modelos está avançando, mas expectativa e divulgação estão indo mais rápido do que o rigor técnico
• Alguns exemplos que tentam uma avaliação mais próxima da manutenibilidade são os seguintes
  • SWE-Marathon: usa tarefas de cerca de 400 horas, como reproduzir todas as funções do Excel, e canais de recompensa compostos em vez de um simples sucesso ou fracasso
  • DeepSWE: usa grandes tarefas open source que ainda não foram implementadas no mundo real para reduzir contaminação dos dados de treino, mas não resolve por si só os problemas de qualidade
  • Frontier Code: avalia trabalho distribuído em vários PRs e penaliza quando o modelo escreve testes que não falham no código anterior ao patch
    • Verifica deterministicamente a validade dos testes de modo semelhante a mutation testing
    • Também executa um modelo julgador que inspeciona o diff segundo regras de qualidade de código
• Há uma limitação: se um modelo julgador pudesse distinguir qualidade com estabilidade, então talvez ele também pudesse gerar código bom desde o início
• O aprendizado por reforço precisa de um oráculo rápido e confiável, mas manutenibilidade não tem esse oráculo
• Agentes revisores e tokens extras podem capturar erros óbvios e elevar o piso da qualidade, mas não conseguem elevar o teto além do nível que o modelo aprendeu com aprendizado por reforço
• SWE-Marathon, DeepSWE e Frontier Code são tentativas iniciais de avaliar manutenibilidade além de uma decisão binária de sucesso ou fracasso, mas ainda não estão no ponto de receber a responsabilidade pela codebase inteira

Quatro etapas para recolocar humanos no loop

• Como hoje o único julgador de qualidade confiável é o humano, é preciso restaurar o code review
• Também vale reaplicar o planejamento prévio que já era usado antes da IA para reduzir revisões longas e risco de retrabalho
• A alavancagem da IA é usada em quatro etapas: requisitos de produto, arquitetura de sistema, design do programa e slice vertical

• 1. Revisão de produto

  • Transforma frases curtas ou longos áudios em documentos semiestruturados para fixar o que está sendo construído e por quê
  • Primeiro define, na linguagem do usuário, o problema a ser resolvido e os critérios para julgar o sucesso após o lançamento
    • Redução do tempo para concluir um workflow
    • Alcançar marcos de onboarding mais cedo
    • Melhorar taxa de erro ou latência
    • Reduzir determinados tickets de suporte
  • O foco deve ficar na experiência do usuário, não nos detalhes técnicos; se uma decisão técnica bloquear a decisão de produto, salva-se o documento atual e passa-se para uma revisão de arquitetura ou para um protótipo de viabilidade
  • Para comportamento de tela, um mock HTML grosseiro costuma gerar mais alinhamento do que uma explicação longa
  • Esse processo não é aplicado a ajuste de texto, scripts pontuais ou bugs cujo modo de reprodução esteja claro; nesses casos, o trabalho vai direto para o agente
  • Só entram em revisão de produto as mudanças em que interpretar mal a intenção teria custo alto
  • Quem revisará o PR também revisa com antecedência as especificações de produto e técnicas; podem ser usados comentários assíncronos em documentos, GitHub ou Notion

• 2. Arquitetura de sistema

  • Define-se como serviços, endpoints, schemas, filas e armazenamentos vão se comunicar, sem descer até a implementação interna do programa
  • Para aumentar a largura de banda de comunicação entre humanos e agentes, usam-se representações como
    • Diagramas de sequência entre UI, API, serviços e armazenamento
    • Contratos de API mostrando requisição e resposta
    • Modelos de dados exibindo novas tabelas e formato das consultas
  • Mermaid é útil, mas seu excesso pode criar uma falsa sensação de que houve alinhamento real
  • Revisão de arquitetura ajuda a bloquear cedo os maus hábitos do modelo, mas não basta para garantir código de alta qualidade

• 3. Design do programa

  • Antes da implementação, define-se a forma do código, um nível abaixo da arquitetura
    • Tipos
    • Assinaturas de métodos
    • Organização do programa
    • Stack de chamadas
  • Em vez de Mermaid complexo, visualizações leves em pseudocódigo são mais fáceis de ler
  • Para mudanças de orquestração ou fluxo de controle, usa-se uma árvore da stack de chamadas; quando o importante é o que muda, aplica-se sintaxe de diff
  • Um diff de árvore de arquivos ajuda a verificar onde ficam os arquivos novos e alterados e qual é seu papel
  • Definir de antemão os tipos e as assinaturas dos métodos principais reduz a chance de o agente escolher uma estrutura interna errada
  • O modelo pode criar um rascunho e o humano refiná-lo; isso antecipa para um momento mais barato decisões que, de outra forma, seriam tomadas implicitamente durante o code review

• 4. Slice vertical

  • Modelos tendem a preferir um plano horizontal, empilhando banco de dados → camada de serviços → API → frontend
  • O plano horizontal dificulta tocar e validar a solução real ao longo do trabalho, via navegador ou curl
  • Antes da IA, desenvolvedores não costumavam escrever 500 ou 2.000 linhas de uma vez; eles avançavam do meio para fora, validando continuamente
    1. Criam o contrato de API e dados mock e os verificam com curl
    2. Fazem o frontend consumir os dados mock e refinam no navegador
    3. Conectam a API à camada de serviços
    4. Adicionam a migration do banco de dados e a integração com o repositório
    5. Adicionam a lógica de negócio
    6. Adicionam tratamento de erros
  • Slices verticais ou tracer bullets permitem testar e melhorar o funcionamento real em cada etapa
  • Em áreas onde qualidade é especialmente importante, revisar 100 a 200 linhas por etapa e reajustar a direção sai mais barato do que corrigir tarde demais mais de 2.000 linhas
  • Mesmo os modelos mais recentes ainda têm dificuldade para montar esse plano sem direcionamento humano e para generalizá-lo entre codebases e tipos de tarefa, então humanos precisam continuar no loop

Como aplicar isso conforme o tamanho do trabalho

• Com 30 minutos de planejamento prévio, é possível reduzir horas de revisão depois da implementação
• Para manter uma qualidade próxima ao nível humano, é necessário ter participação humana em design de produto, arquitetura de sistema, design do programa e slices verticais
• O processo completo não é aplicado a todo tipo de tarefa
  • Cerca de 40% são geradas de uma vez só ou concluídas com 1 ou 2 rodadas leves de feedback
  • Trabalhos de porte médio juntam produto e design de sistema em um único documento de planejamento, sem dividir a implementação em etapas
  • Trabalhos grandes passam pelas quatro etapas, mas podem pular alguma delas quando não fizer sentido, como em grandes refatorações em que revisão de produto não se aplica
• Em geral, o modelo recebe 1 a 3 slices por vez, e o código em andamento é revisado no meio do processo
• Corrigir cedo a estrutura interna ou o comportamento é mais fácil do que gerar tudo em massa e depois descobrir o que deu errado

O gargalo não é o número de PRs, e sim a qualidade dos PRs

• O gargalo não é haver PRs demais, e sim PRs ruins demais
• PRs limpos, que seguem o design decidido e as convenções da equipe, podem ser revisados rapidamente mesmo quando todos os arquivos são lidos
• Se só 20% de um PR exige retrabalho, isso já cria carga cognitiva e emocional tanto para quem envia quanto para quem revisa
• PRs gerados por IA de uma vez só frequentemente têm taxa de retrabalho próxima de 50%
• Mesmo que o autor do PR seja uma IA, alguém precisa iniciar o trabalho, lapidar o resultado ou assumir responsabilidade por ele, então o custo do retrabalho não desaparece

Velocidade de desenvolvimento ao aceitar as restrições

• A restrição central hoje é que os modelos têm áreas claras em que vão bem e áreas em que vão mal, e por um bom tempo humanos ainda precisarão ler código
• Em vez de buscar velocidade de 10 a 100 vezes assumindo que qualidade de código não importa, se o sistema for otimizado dentro dessas restrições, é possível obter com segurança velocidade 2 a 3 vezes maior
• Há quatro princípios práticos
  1. Trabalhar o bastante com os modelos para desenvolver intuição sobre suas limitações
  2. Otimizar o sistema de desenvolvimento dentro dessas limitações
  3. Encontrar pontos de alta alavancagem
  4. Ler o código de fato
• Harnesses e loops são ferramentas para reduzir erros óbvios, mas não substituem julgamento de manutenibilidade nem raciocínio de design

[GN⁺]

Opiniões no Hacker News

• Chamo isso de problema de intenção-implementação-qualidade.
  Uma fábrica de software pode implementar apps, funcionalidades, correções de bugs, mudanças de design e refatorações a partir de um requisito de uma linha, mas é outra questão saber se ela consegue produzir com precisão a intenção humana por trás desse requisito e a direção de evolução do produto.
  As formas de implementação explodem combinatoriamente, e o método “correto” — consistente com o sistema, escalável, fácil de entender e capaz de atender com segurança milhões de usuários — é subjetivo, variando conforme as pessoas e o problema. Testes e evidências de trabalho podem elevar parte da qualidade, mas não há um loop de feedback para verificar e corrigir essa qualidade subjetiva.

  • Mesmo que o cliente diga “quero X”, ele pode de fato querer X, pode não precisar de X, ou pode querer Y, mas não conseguir expressar isso. Outros clientes podem não querer X, ou podem estar apenas desestabilizando os desenvolvedores sem grande motivo.
  • Fábricas de software funcionam bem para softwares pessoais/de hobby com poucos usuários e pouca receita, nos quais um bug pode ser corrigido com um único prompt no Claude, ou para startups antes do ajuste produto-mercado.
    Também é possível chegar a um equilíbrio em que não se olha o código e se usa apenas o sucesso dos requisitos como feedback, mas, fora esses casos, os problemas de intenção e de qualidade subjetiva ainda não foram resolvidos.
  • A premissa de que existe apenas uma forma de transformar requisitos em implementação simplesmente não é verdadeira.

• O texto tem pontos bons, mas é difícil generalizar o experimento de operação autônoma de julho de 2025 como limite dos agentes atuais.
  A utilidade dos modelos deu um salto grande por volta do outono de 2025 ou da primavera de 2026, e foi só depois disso que consegui delegar funcionalidades inteiras a agentes. O texto menciona melhorias nos modelos, mas na prática as ignora, o que não bate com a minha experiência.

  • Tanto o texto quanto o site do produto parecem ter ficado presos em 2025. Em especial, o artigo “contextos longos não são a resposta” parece extrapolar o desempenho antigo diretamente para os modelos atuais.
    Modelos posteriores ao Opus 4.6 foram estáveis o bastante para que, mesmo com 700 mil a 900 mil tokens, fosse difícil perceber queda de inteligência; a eficiência de custo é muito baixa, mas funciona.
  • Na semana passada ouvi um podcast com Dex Horthy, e a empresa dele, Humanlayer, continua forçando os limites dos agentes e os usando ativamente.
    Como ele conhece bem as capacidades dos modelos atuais, se julgasse que hoje uma fábrica de software autônoma é possível, estaria tentando de novo.
  • O Opus 4.5 foi claramente um grande salto. A avaliação de quem não testou modelos posteriores perde valor, mas, mesmo sem serem perfeitos, os modelos são muito úteis.
  • Nesse caso, teria sido mais claro escrever: “fizemos uma adoção completa em 2025 e, em 2026, nada melhorou de forma essencial”.
    Acho que nem os modelos de fronteira mais recentes lidam melhor com perda de contexto ou shotgun surgery. Para contestar isso, é preciso apresentar evidências concretas e experiências de uso diferentes, não simplesmente ignorar o ponto.
  • Pode ser controverso, mas em engenharia complexa tive a impressão de que o Opus 4.1 era mais inteligente que o 4.5.
    O 4.5 era mais rápido e melhor para prompts simples e para captar intenções implícitas, o que ajudava a atrair novos usuários rapidamente.

• Construí e operei minha própria fábrica de software por 8 meses; ela ainda não coleta tarefas automaticamente nem envia PRs, mas, depois de definir os requisitos, em geral segue sozinha até o deploy. Depois de avaliar o sistema, parei de fazer revisão de código nos últimos 4 meses.
  Em vez de prompts de uma linha, uso um processo de entrevista para resolver antes perguntas em aberto e ambiguidades, e uso revisão de plano, garantia de qualidade baseada em navegador, revisão adversarial, testes unitários, linter, verificador de tipos, hooks pós-commit e rastreamento de métodos formais como salvaguardas.
  Quando erros repetitivos aparecem, consigo detectar áreas que ficaram bagunçadas sem olhar o código. Quando requisitos se acumulam e variáveis de estado começam a se sobrepor, refatoro para um único tipo soma; se fica complexo, crio um modelo formal e rastreamento em Quint e executo isso como testes unitários.
  A base de código é composta por frontend e backend com mais de um ano. O agente replica os padrões existentes, então princípios claros são importantes; ao dividir novas fronteiras de sistema, modelos do nível Sonnet frequentemente julgaram mal, enquanto o Opus foi melhor.

  • Não é uma fábrica completa, mas senti algo parecido em vários projetos maduros de vibe coding.
    Em geral consegui detectar degradação de qualidade, e ainda não houve caso em que eu abrisse o código para encontrar o problema e não conseguisse limpá-lo com o agente. Também não vi uma situação em que um engenheiro médio ficasse diante de uma contaminação irreversível da base de código.
  • O que me interessa não é a fábrica de código em si, mas o que foi criado com ela. Precisamos de resultados que comprovem que dá para criar produtos além de ferramentas de codificação com IA.
  • Eu gostaria de ver uma publicação longa ou um repositório mostrando a configuração e o fluxo de trabalho concretos.

• Ou você precisa entender como a base de código funciona, ou não precisa.
  O Claude pode escrever código por você, mas não pode entendê-lo por você; esse processo ainda acontece na velocidade humana. Há casos em que não é preciso entender tudo, mas é necessária uma distinção mais sutil, e isso não muda mesmo que o Claude escreva código perfeito.

  • O Claude consegue explorar uma base de código espaguete muito mais rápido que humanos. O problema, na verdade, é que, ao terceirizar para o Claude a compreensão do projeto, você consegue continuar trabalhando mesmo depois que ele já se tornou inutilizável para humanos.
  • Em vez de tratar entendimento como uma dicotomia, também dá para pensar em quanto entendimento é necessário para trabalhar de forma eficaz em uma determinada base de código.
    Mesmo antes dos LLMs, ninguém conhecia uma grande base de código inteira, mas ao menos entendia, em geral, os próprios PRs e a área sob sua responsabilidade.
  • Minha experiência é o oposto. Fiz o Claude entender muito mais profundamente do que eu duas grandes bases de código que, em sua maior parte, eu mesmo escrevi e cujos conceitos também projetei; agora peço ao Claude que me explique coisas que esqueci há muito tempo.

• Senti um alívio por ser tão parecido com a minha experiência. Isso me fez lembrar de gosto e julgamento, temas que vêm sendo citados com frequência ultimamente.
  A qualidade arquitetural pode não ter uma resposta objetivamente correta, como na moda; talvez, depois de entregar a razão e a racionalidade às máquinas, os humanos precisem estudar estética.
  É cansativo porque, sem a pausa que o processo de implementação proporcionava, é preciso continuar julgando trade-offs entre opções quase equivalentes; mesmo com modelos do nível de Fable ou GPT-5.6, a revisão de código ainda é necessária. Guardo pequenos defeitos na memória e, quando problemas semelhantes se acumulam o suficiente, corrijo tudo de uma vez.
  Também é preciso escolher se os agentes vão colaborar de perto com um pequeno número de pessoas excelentes ou se vamos rodar muitos subagentes em larga escala e separar automaticamente o joio do trigo. Minha preferência é por equipes pequenas e altamente calibradas, mas o tempo dirá se essa é a resposta certa.

  • Jake Nations, quando trabalhava na Netflix, disse algo como: “Eu reconheço um padrão ruim na hora porque já tive que depurá-lo às 2 da manhã.”
    Gosto é a intuição conquistada com sofrimento a partir de todos os antipadrões e minas terrestres que você mesmo fez explodir ao construir software.
    https://www.youtube.com/watch?v=eIoohUmYpGI

• Essa pessoa já admitiu no passado ter inventado e espalhado coisas sem fundamento, causando prejuízos, e não há nenhuma evidência de que essa ideia agora seja boa. É preciso haver um motivo para voltar a confiar nela.

  • No fim, não passa de um longo anúncio promovendo o produto dele, o Humanlayer.

• O problema que mais chama a atenção na situação atual é a experiência do usuário na revisão de PRs.
  Sempre detestei a tela de PRs do GitHub e baixava o branch para conferir o diff no $EDITOR, mas hoje não há mais motivo para isso ser tão incômodo. A Linear, que nem é uma empresa de revisão de código, usa um modelo pequeno para agrupar arquivos alterados por tema, adicionar explicações e ordenar por importância, oferecendo uma funcionalidade básica melhor que a do GitHub.
  A carga cognitiva cai bastante sem trabalho extra do revisor ou de quem abriu o pedido, e recursos posteriores, como visualização, também parecem totalmente possíveis. Fico curioso para saber se essa abordagem está errada ou se existe alguma alternativa amplamente usada.
  https://linear.app/docs/diffs#guides

  • As melhores equipes não fazem revisão de PR. Elas discutem design e arquitetura durante as mudanças, automatizam verificações triviais como linting e formatação, e seguem rigorosamente a regra de não quebrar a build, com muitos testes e verificações.
    Com um procedimento forte de rollback, o gate de PR vira uma etapa desnecessária que não captura problemas úteis, e os membros da equipe podem fazer merge diretamente.
  • A política de tratar revisão de código como gate de integração não faz sentido. Meu agente responde e revisa por mim em pedidos de revisão, e também consegue contornar políticas corporativas que exigem revisão humana.
    É preciso revisar software que realmente funciona, e é necessário um sistema capaz de demonstrar a mudança imediatamente. O peso do código e das especificações vai diminuir, e a produção de software no futuro será mais parecida com o Replit do que com o GitHub.
  • Mesmo antes dos agentes, a revisão de PRs já era difícil; agora, com ainda mais PRs para revisar, ficou muito pior.
  • Agrupar mudanças de arquivos por tema e explicá-las não seria algo que originalmente os commits deveriam fazer?
  • Não acho que LLMs sejam particularmente bons em julgar importância ou resumir código.
    Experimentei e gostei de uma abordagem baseada em Tree-sitter: https://github.com/0x007BA7/codebook. Ainda não está pronta para uso em produção, mas há espaço para transformar algo parecido em produto.

• Tenho sentimentos ambíguos em relação às fábricas de software.
  O produto principal é grande demais, então toda mudança precisa de input humano, mas automações leves de refatoração, criação de testes e mudanças de UI funcionam bem. Por outro lado, em experimentos pequenos, mesmo quando o código resultante não era especial, deu para ver potencial de expansão futura; acho que é possível projetar novas estratégias e arquiteturas partindo desde o início da premissa de que agentes vão escrever o código.
  Documentei em https://relentless.works/ um experimento público em que não intervenho de forma alguma na direção. Também estou observando um agente de trading sem intervenção; ele está com cerca de 3% de perda, mas não perdeu todo o capital e recentemente abriu uma nova posição.
  Fábricas de software parecem possíveis, mas exigem novos conceitos, uma mudança de mentalidade e paciência para esperar pela IA.

• Há um problema fundamental já na questão do que significa criar software.
  Se você simplesmente atribuir tickets do GitHub a um agente de IA e descansar, há grande chance de que camadas de abstração e indireção continuem se acumulando. Durante a programação surgem perspectivas como “e se usarmos Redis aqui?”, “a API já fornece os dados necessários?”, “vamos excluir do relatório clientes que não tiveram atividade no último ano”; em algum momento, um humano precisa julgar isso.

  • Isso se conecta à perspectiva de que programar é construir teoria, algo fácil de perder na programação com agentes.
    https://gwern.net/doc/cs/algorithm/1985-naur.pdf
  • Concordo totalmente. Os fluxos de trabalho e conjuntos de técnicas de agentes de coding mais usados são projetados para extrair insight e intuição humanos durante o planejamento ou a escrita de código.
    Isso inclui o modo de planejamento do Claude Code, mattpocock/skills, obra/superpowers, fluxos de pesquisa-planejamento-implementação etc.
  • Isso é verdade se estivermos falando do 1% superior dos desenvolvedores que pensam dessa forma, mas, em comparação com a maioria dos desenvolvedores que encontrei ao longo de décadas, os modelos atuais são melhores que os humanos, exceto os do topo.
  • A máquina cria exatamente o que você pede, inclusive coisas que ainda não existem. Mais importante que a automação totalmente autônoma é a capacidade de pedir corretamente usando teoria da informação, teoria da decisão e teoria da criatividade.
    A memória do modelo não é integrada como nos humanos, que consolidam pesos enquanto dormem; é mais parecido com entregar anotações a alguém que não se lembra de ontem. Não surpreende que um sistema de alta entropia acrescente entropia ao projeto com o passar do tempo.
  • O problema de “a API já retorna os dados necessários” é especialmente grande. Vi várias vezes modelos de ponta resolverem com uma quantidade enorme de código e tokens, imitando o padrão cliente-servidor existente, algo que poderia ter sido feito alterando uma única linha com dados que já estavam no cliente.
    Projetos de vibe coding estão cheios desse desperdício, mas quem escreveu o prompt pode nem perceber. É ótimo que a ferramenta economize tempo todos os dias, mas implementação excessiva é um problema sério.

• É engraçado ver uma discussão sobre fábricas de software não tripuladas medindo produtividade por número de PRs ou commits. Se esse for o caminho, as unidades de código já deveriam ser chamadas de bos (bunch of shit)

  • Estão repetindo o velho erro de otimizar a taxa de utilização em vez do throughput total. É um problema que Eli Goldratt aborda desde os anos 1970, e ainda assim parece que não aprendemos
    https://en.wikipedia.org/wiki/The_Goal_(novel)
  • Para operar esse conceito a sério, não dá para tolerar métricas de vaidade nem ignorância sobre código. Quanto mais automação, mais altos ficam os critérios, não mais baixos, e isso exige muito mais matemática e esforço
    É quase como a troca feita por startups extremas: economizar capital em troca de investir anos da própria vida