Autor do gonzo_ML: em sua equipe, apenas os modelos escrevem codigo; as pessoas revisam

Historias sobre «migrar para agentes» geralmente terminam em uma apresentacao bonita. Esta traz uma cronologia, numeros e um relato honesto do que nao funcionou. O autor do canal gonzo_ML conta como, de 2024 a 2026, passou de «os modelos as vezes completam algum codigo» para «ninguem na equipe programa manualmente».

O limiar que os modelos ultrapassaram

Os primeiros projetos concluidos do autor surgiram na virada de 2024 para 2025. Ele acredita que foram os modelos que ultrapassaram um limiar, e nao que ele tenha ficado mais ousado. Em janeiro de 2025, Gemini e Claude montaram para ele o codigo do transformer, das intervencoes e da visualizacao de ativacoes para um projeto de curso sobre interpretabilidade. Na primavera, ele criou um servidor MCP para traducoes sem, por principio, digitar manualmente uma unica linha. Em dezembro, converteu-o para Streamable HTTP e o levou a producao. Como de costume, a parte de producao mostrou-se mais extensa que a propria funcionalidade: logging, monitoramento, seguranca, carga, tratamento de erros e deploy acrescentaram mais codigo que o novo transporte.

A abordagem de trabalho ficou assim: especificacoes com decomposicao de tarefas, testes antes da implementacao e ADRs para as decisoes adotadas. Tudo comecou com o speckit; agora, a equipe segue essas praticas no Claude Code, e ja nao se trata de um trabalho individual.

Por que brownfield nao funcionava e depois passou a funcionar

Em 2025, o autor tentou entregar aos modelos o codigo de uma plataforma com dez anos de idade. As correcoes de bugs e as pequenas funcionalidades saiam «erradas». Ele atribuiu isso ao desenvolvimento brownfield. Mais tarde, descobriu que o problema era outro: o contexto estava na cabeca das pessoas, e nao em algum lugar onde o agente pudesse acessa-lo.

Por isso, a equipe passou a cuidar das fundacoes. Os modelos ganharam acesso a documentacao nos repositorios e, via MCP, ao Confluence; a padroes e ADRs; a tarefas, primeiro no Jira e depois no Linear; a logs de producao via MCP; e, quando necessario, a conversas no Slack. Ou seja, a tudo de que uma nova pessoa no projeto precisaria. Agora, as pessoas atribuem tarefas e revisam, enquanto os agentes tambem assumem a revisao inicial, a documentacao, os documentos de release e os testes. A pessoa entra no processo nos quality gates que exigem aprovacao.

O gargalo mudou de lugar. Escrever codigo ja nao demora, mas a leitura humana final esta no limite. Todos mantem varias sessoes de agentes: enquanto um agente escreve, e possivel usar outra sessao para ler os novos e extensos diffs.

Escolha de linguagem e Rust

Um efeito inesperado: agora e possivel escolher a linguagem de acordo com a tarefa, e nao com as competencias da equipe. O primeiro candidato foi um servico que emulava APIs reais, com todos os seus problemas, e que limitava os testes de desempenho. Ele foi reescrito em Rust e, para comparacao, tambem em Go e Node, com um teste de paridade cobrindo as quatro implementacoes.

No mesmo pod de 100 MB, Rust mantem cerca de 8.900 conexoes abertas, contra aproximadamente 3.400 no original em Python. Em idle, ocupa 1 MiB em vez de 33. Go com fasthttp foi apenas 11% melhor que Python, enquanto a versao com o net/http padrao teve desempenho duas vezes pior. O autor faz uma ressalva: os numeros vieram de uma bancada de testes local e, no paradigma de desenvolvimento manual, ninguem teria reservado nem sequer uma semana para reescrever dessa forma um servico auxiliar.

Nao apenas codigo

Um exemplo separado e um relatorio contabil. Antes, todos os anos o autor conferia novamente o trabalho dos contadores e encontrava erros. Neste ano, Claude fez isso em uma unica noite. Encontrou erros que o autor nem havia pensado em contestar, com referencias a leis e interpretacoes; o autor verificou tudo, e as referencias estavam corretas. Tambem encontrou um calculo incorreto do ano anterior que havia aumentado o imposto e uma restituicao deste ano que nao havia sido solicitada. O quality gate mudou de lugar: agora, o modelo verifica tanto os contadores quanto o proprio autor.

Limitacoes e conclusao

Esta e a experiencia pessoal de uma unica pessoa, sem medicoes independentes. O benchmark de Rust e local, e o caso fiscal e um exemplo isolado, embora o autor tenha verificado manualmente as referencias. As condicoes tambem sao especiais: a empresa esta se reorganizando deliberadamente em torno de uma abordagem AI-first.

A conclusao pratica para as equipes e a seguinte: se um agente entrega algo «errado», primeiro verifiquem onde esta o contexto. Coloquem documentacao, ADRs, tarefas e logs nos repositorios e no MCP; escrevam especificacoes e testes antes da implementacao. E preparem antecipadamente o processo de revisao, porque e justamente ali que surgira o gargalo.