Eu achava que sabia por que meu harness demorava: o modelo decidia demais. Todo passo de um agente de código termina numa escolha, qual arquivo abrir, qual comando rodar, e cada escolha passava por um modelo grande, no tempo de um modelo grande. Troque o decisor por algo rápido, pensei, e o harness anda.
Estava errado. Não um pouco: a decisão que eu queria acelerar é uma fatia pequena do tempo, e a primeira régua que usei para medi-la também estava errada.
Este é o primeiro caderno de bancada, uma série sobre experimentos com agentes de código em que a hipótese, o instrumento e o número aparecem juntos, inclusive quando a hipótese cai. O hábito de medir antes de acreditar vem do AIvengers, o experimento em que medi o que a IA fazia num projeto real, com linha de base e horas contadas. Publico por um motivo prático: quero achar quem mede a mesma coisa e comparar número com número.
A hipótese, e por que parecia óbvia
Quem olha um agente de código trabalhando vê um ritmo: ele para, pensa, chama uma ferramenta, lê o resultado, para de novo. Na semana que eu medi, cada turno, do meu pedido até a resposta final, teve em média 25,3 chamadas ao modelo. Cada uma dessas pausas tem cara de decisão.
Um turno médio: 25,3 chamadas ao modelo
A conta parecia fácil. Se boa parte dessas chamadas só escolhe o próximo passo, e se um modelo grande leva segundos para escolher, o harness passa boa parte do tempo decidindo. Tirar a decisão do modelo grande seria o ganho mais óbvio que eu tinha à mão.
O candidato: um classificador que não escreve
O candidato apareceu em setembro. A TypeSafe AI lançou o Jev, que ela chama de modelo “System One”: ele não gera texto, devolve uma decisão tipada, sim ou não, uma escolha entre opções ou uma nota, com a probabilidade junto. O The Register cobriu a estreia. Era o formato exato da decisão que eu queria tirar do modelo grande.
O guia da Vercel sobre quando usar o Jev dá o conselho que eu segui: deixar para ele só a decisão limitada, manter em código o que já é regra fixa, e comparar com o que existe hoje, nos mesmos casos rotulados, antes de trocar qualquer coisa.
Comparei. Separei 180 casos do meu próprio trabalho, todos de projeto pessoal: pedaços de plano, cada um rotulado com o modelo que devia executá-lo, o pequeno, o médio ou o grande. O Jev e o Haiku tentaram acertar o rótulo.
| Jev | Haiku | |
|---|---|---|
| Acurácia | 0,717 | 0,722 |
| Kappa | 0,486 | 0,486 |
| Latência p50 | 284 ms | 1.789 ms |
| Latência p95 | 336 ms | 2.030 ms |
O Jev acertou como o Haiku e respondeu mais rápido: 284 ms contra 1.789 ms na mediana. A latência do Haiku inclui a partida da CLI, que um hook também pagaria, então a comparação é justa para o uso que eu tinha em mente e injusta com o Haiku como modelo. Nenhum dos dois acertou o bastante para decidir sozinho.
Mas o Haiku não era a linha de base certa. A linha de base certa é uma regra fixa, grátis de rodar. Numa simulação sobre a mesma semana, pus o Jev e uma regra fixa lado a lado nos três lugares do harness onde uma regra existe: o porteiro de resultado, que corta a saída grande de uma ferramenta antes de ela entrar no contexto; o disjuntor, que interrompe o executor que passou de um número de pedidos ao modelo; e a sugestão de /clear, que avisa quando meu pedido abre um assunto novo e o contexto antigo só atrapalha. Nos três, a regra fixa rendeu mais economia por semana que o Jev.
Dois instrumentos, e o atalho que errou
Antes de ligar o Jev em qualquer lugar, eu precisava saber quanto tempo a decisão ocupa.
O primeiro instrumento foi um atalho. Uma chamada ao modelo que devolve pouco texto, até 150 tokens, quase só escolhe a próxima ferramenta; a que devolve muito está escrevendo. Separei as 9.316 chamadas da semana pelo tamanho da saída. As curtas foram 622, 7% das chamadas, e somaram 0,4 h, 0,5% do tempo do turno, com mediana de 2,1 s. Se aquilo era a decisão, a hipótese tinha morrido ali.
Desconfiei do número pequeno demais. Tamanho de saída é um atalho: a chamada que escolhe a próxima leitura pode vir com um parágrafo de explicação, e o atalho a conta como escrita.
O segundo instrumento classificou cada chamada pelo que ela produz: um comando que age, uma leitura ou busca, uma edição, só texto, um subagente despachado. Ler ou procurar, o lugar onde o modelo mais decide sem produzir nada, deu 2.736 chamadas, 7,9 h e 10,3% do trabalho. O atalho tinha errado por uma ordem de grandeza.
E a conclusão não virou. Se toda leitura que passou de 2,0 s, a mediana da leitura curta, caísse para 2,0 s, o ganho seria de 6,4 h, 8,3% do trabalho. Isso é o teto, com um decisor instantâneo e perfeito. E parte dele nem é decisão: 259 leituras saíram de chamadas com mais de 2.000 tokens de saída, com mediana de 36,4 s, e ali o modelo está gerando texto, que é justamente o que um classificador não faz. Os comandos que agem ficaram com 13,2% do trabalho e as edições com 9,1%: trabalho que precisa ser feito, e não escolhido.
Quanto do tempo a decisão ocupa
- O atalho0,5%622 chamadas de saída curta, 0,4 h
- Ler ou procurar10,3%2.736 chamadas, 7,9 h
- O teto do ganho8,3%6,4 h
Onde o tempo vai de fato
Medida pelo relógio, e não pelo tipo de chamada, a semana deu 368 turnos e 77,1 h.
| Onde | Parte do tempo |
|---|---|
| Esperando o modelo responder (API) | 38,5% |
| Esperando tarefa em segundo plano | 22,8% |
| Compactando o contexto | 17,0% |
| Esperando por mim | 10,0% |
| Comando com teto de memória | 5,3% |
| Comando sem teto | 4,9% |
Onde foram as 77,1 h
- 38,5% esperando o modelo (API)
- 22,8% tarefa em segundo plano
- 17,0% compactando o contexto
- 10,0% esperando por mim
- 5,3% comando com teto de memória
- 4,9% comando sem teto
- 1,3% hook e outro
Dentro dos 38,5% de API, as respostas longas, de 2.000 tokens ou mais, somam sozinhas 19,9% do turno, com mediana de 35,9 s. É o modelo escrevendo código e texto, que é o que eu pedi a ele.
Depois da API, o que mais pesa não é decisão nenhuma. É tarefa em segundo plano, e é compactação: 332 compactações na semana, o contexto enchendo e o harness parando para resumir a si mesmo, 17,0% do tempo. Se eu quiser o harness mais rápido, é ali que o tempo está.
O que isto não quer dizer
Não quer dizer que o Jev é ruim. Ele acertou como o Haiku, respondeu mais rápido, 284 ms contra 1.789 ms, e perdeu para uma regra fixa onde existe regra fixa. Onde não existe regra e a decisão é fechada, ele continua sendo o candidato que eu testaria.
Não quer dizer que decidir sai de graça. Leitura com 10,3% do trabalho é tempo de verdade; só não é onde a maior parte do tempo está, e o teto de 8,3% supõe um decisor que não existe.
Não vale para o seu harness sem medir. É uma pessoa, uma semana, só projetos pessoais, e um harness com as minhas manias. A latência do Haiku inclui a partida da CLI. A comparação com a regra fixa é simulação, não o harness rodando com cada um.
Mediu o seu? Me escreve
Se você mede o tempo de um harness de agentes, o seu ou o do seu time, quero ver o número, principalmente se ele contradiz o meu. Não precisa estar arrumado: a hipótese, o instrumento e o resultado já bastam, inclusive quando a hipótese caiu.
Me escreve em eltonleao.dev@gmail.com, no LinkedIn ou no WhatsApp.