Claude Code escreveu a busca em 3 dias, mas a equipe do Jmix levou 3 semanas para aceitar o código

Agentes escrevem código rápido, mas alguém ainda precisa ler, entender e assumir esse código. A equipe da plataforma open source Jmix descreveu o problema a partir da própria experiência. Eles escreveram a nova busca e o índice do assistente de IA em três dias, junto com o Claude Code. Para surgir na equipe uma pessoa pronta para responder pelo resultado, foram necessárias quase três semanas.

Dois cronômetros em vez de um

Antes de responder, o próprio assistente procura trechos da documentação em um banco vetorial. A equipe adicionou ali fichas de classes extraídas do Javadoc e dividiu a documentação em exemplos curtos e completos. A qualidade é verificada por um circuito de avaliação: 74 perguntas de controle, cujas respostas são avaliadas por um modelo-juiz.

A primeira versão do código foi escrita pelo Claude Fable 5, e trechos isolados foram revisados de forma independente pelo GPT-5.6 Sol. O resultado foi um diff de 122 arquivos e quase 15 mil linhas. Os autores haviam calculado de antemão dois a três dias de revisão. Eles viram cada alteração, e era possível perguntar ao agente sobre qualquer decisão. Mesmo assim, percorrer o diff e entendê-lo a ponto de responder por ele sem o agente mostraram ser coisas diferentes.

A equipe descreve isso como dois cronômetros. O primeiro corre até existir código funcionando e parou em três dias. O segundo corre até que a equipe tenha alguém capaz de consertar o sistema de memória.

Os autores chamam esse momento de code adoption (adoção do código); no fundo, é ownership. Os sinais são estes: a pessoa consegue seguir o caminho dos dados da entrada até o resultado, explicar os invariantes, prever o que uma alteração vai afetar e mudar um contrato sabendo o que precisará ser reverificado. O build verde não garante nada disso, porque ele só responde a perguntas definidas de antemão.

Por exemplo: alguém verificou se, numa falha no meio da reindexação, os trechos antigos continuam no lugar?

Para onde foram as três semanas

A velocidade de leitura explica apenas parte do tempo. Segundo dados da SmartBear e da Cisco, uma sessão de revisão deve abranger 200–400 linhas em 60–90 minutos. Das 15 mil linhas, cerca de três mil são fixtures HTML, que não precisam ser lidas. Sobram aproximadamente 12 mil, ou seja, 30 sessões e 30–45 horas de leitura. Isso equivale a cerca de uma semana útil, e os testes são lidos mais rápido. Os autores reconhecem que a estimativa é grosseira e que a pesquisa tem quase vinte anos.

O restante foi consumido por três fatores. Primeiro, o agente alterava o código "de passagem". No terceiro dia de revisão, o suporte a várias versões do Jmix desapareceu do código.

O agente mudou o formato de resposta de /api/search no primeiro dia, e o contrato antigo teve de ser restaurado, enquanto o novo formato foi movido para /api/v2/search. Também foi preciso remover do repositório capturas de tela e exportações de 3,5 MB, além de logs do Playwright. Por quase uma semana, saiu uma série de commits "Restore …

as in main". Segundo, o agente explica com a mesma confiança coisas corretas e incorretas, então suas explicações precisavam ser conferidas no código e confirmadas por testes. Terceiro, vieram as alterações tardias: o limite de aprovação virou um campo separado da execução, as regras do juiz foram endurecidas, e a forma abreviada de consulta do DataManager entrou no gabarito.

Tudo o que a equipe já havia entendido sobre o significado da nota teve de ser reverificado.

Pelo histórico de commits: 44 nos três primeiros dias, depois 53 ao longo de uma semana e meia de análise e mais 47 nos últimos nove dias.

O contexto dos dados do setor é este. Segundo o DORA 2024, um aumento de 25% no uso de IA está associado a melhor documentação e revisão mais rápida, mas a vazão das entregas caiu cerca de 1,5% e a estabilidade, 7,2%. É uma correlação obtida em pesquisa, não um experimento. No DORA 2025, a relação com a vazão passou a ser positiva, e a relação com a estabilidade continuou negativa. No experimento da METR, desenvolvedores experientes que usaram IA gastaram 19% mais tempo nas tarefas, mas acreditavam ter ficado 20% mais rápidos. As ferramentas eram do início de 2025, e uma nova medição em fevereiro de 2026 mostrou-se estatisticamente pouco confiável.

O que a equipe faz agora

A ideia central é distinguir três fronteiras. A entrega define o que entra por inteiro no main. A iteração do agente leva o trabalho a um estado estável, que pode ser executado e verificado. O ponto de code adoption mostra qual parte uma pessoa já mantém por conta própria. Antes, a equipe juntava as três em um único pull request grande, e o segundo cronômetro só começava depois do primeiro.

Agora o trabalho é dividido em três fatias: ciclo de vida do corpus, busca com API e circuito de avaliação. Cada fatia é verificada e aceita por uma pessoa antes da seguinte. As fatias seguem em uma pilha de branches, e o main recebe um único pull request final, no qual só as junções são verificadas. Por exemplo: após uma reindexação malsucedida, a busca continua devolvendo a geração antiga dos dados.

São seis práticas: descrever o contrato de todo o sistema antes da primeira sessão; dividir o trabalho em estados estáveis e deixar uma nota entre as sessões; pedir ao agente uma confirmação em vez de um relatório; entregar a verificação a outro agente, com contexto novo; envolver uma pessoa após cada fatia; e encerrar com uma aceitação de integração completa. Ideias semelhantes aparecem nos experimentos da Anthropic com tarefas longas de agentes e nas recomendações do Claude Code para verificar o diff com um subagente.

Limitações

Os autores fazem ressalvas: isto ainda não é um regulamento, e eles não têm medições comparáveis às três semanas daquela branch. Resta saber se o revisor separado ajudou por ter um olhar novo ou simplesmente por ser outro modelo. A fatia aceita também não fica congelada: o significado da nota teve de ser revisto no último dia. A conclusão prática para as equipes é simples: meça não só o tempo de geração do código, mas também o tempo até surgir uma pessoa pronta para responder por ele, e inclua pontos de aceitação no plano antes da primeira sessão do agente.