As últimas três semanas foram algumas das mais reveladoras que já tive no desenvolvimento de software assistido por IA.
O Claude Fable voltou ao cenário e, no mesmo período, a OpenAI lançou o GPT‑5.6 com Sol, Terra e Luna. O sinal do mercado era óbvio: os laboratórios de fronteira não estão mais lançando avanços isolados, mas sim comprimindo a lacuna entre capacidade, faixas de preço e cadência de implantação. A Anthropic agora vende o Fable 5 como seu modelo de horizonte longo de ponta, a aproximadamente o dobro do preço de tabela do Opus 5, enquanto a OpenAI enquadra o GPT‑5.6 como uma família que escala da capacidade principal até trabalhos mais sensíveis a custos. A xAI, por sua vez, está precificando o Grok 4.5 de forma agressiva o suficiente para que ele seja levado a sério em qualquer discussão sobre custo-benefício.
E, no entanto, a coisa mais importante que aprendi nessas semanas teve muito pouco a ver com páginas de lançamento ou slides de benchmarks.
O verdadeiro avanço no meu ambiente foi a preparação.
Tínhamos histórias prontas. Tínhamos o trabalho dividido em partes que realmente podiam ser executadas por sistemas de codificação agentiva. Uma vez que essa fila existia, a taxa de transferência se tornou absurda. Em todo o Codex, Claude, Cursor, Grok e outras ferramentas no fluxo de trabalho, mais de 2 milhões de linhas de código foram escritas em aproximadamente dez dias. Esse número parece exagero até que você veja o que o tornou possível: não mágica, não autonomia abstrata, mas um fluxo constante de trabalho delimitado com estrutura suficiente para os modelos continuarem avançando.
Essa é a primeira coisa que muitas pessoas ainda ignoram. A explosão de produção não acontece porque os modelos de repente se tornaram engenheiros autodirigidos. Acontece porque os humanos prepararam o campo de batalha.
A segunda coisa que aprendi é que os bugs aparecem mais rápido em escala do que o marketing jamais admite.
O Codex é um bom exemplo. O próprio material da OpenAI sobre trabalho de longa duração deixa claro que threads duráveis vêm com uma compensação: a continuidade é útil, mas threads de longa duração também podem se tornar mais caras e difíceis de gerenciar do que começar do zero. O recurso Goals é projetado precisamente para manter uma thread ligada a um objetivo delimitado, em vez de transformar cada tarefa difícil em um prompt cada vez maior. Na prática, isso corresponde ao que vi. Se um processo for muito longo, o melhor padrão geralmente é interrompê-lo, pedir uma transferência limpa, reiniciar a sessão e continuar com um novo objetivo. Isso não é apenas uma conveniência. Muitas vezes é uma higiene operacional.
Há também um problema mais concreto do Codex que agora tem uma trilha de papel público visível: explosões de subagente e estado local.
A issue em aberto #34061 documenta um caso em que uma thread pai retomada produziu milhares de logs filho JSONL e centenas de gigabytes de histórico de sessão persistido. Outra issue adverte explicitamente que fork_context=true pode fazer com que grandes históricos pai sejam copiados para agentes filhos, amplificando tanto o risco de correção quanto o consumo de tokens. Outro relatório público mostra que inicializações a frio do Codex se degradam em esperas de 1 a 5 minutos assim que ~/.codex acumula grandes logs SQLite e estado de sessão. Em conjunto, esses relatórios descrevem um modo de falha que muitos usuários avançados reconhecerão imediatamente: ligado. Quando a camada de metadados local fica grande o suficiente, a persistência da sessão se torna uma parte séria da experiência do produto.
Isso é importante porque a codificação multiagente sempre parece melhor em demonstrações do que em uma máquina de desenvolvimento sob estresse.
A promessa é clara. Os documentos de multiagente da OpenAI descrevem por que subagentes paralelos podem acelerar fluxos de trabalho independentes, e essa promessa é real. Mas os mesmos documentos também alertam que subagentes aumentam o uso de tokens e podem não ser adequados para tarefas que envolvem gravações frequentes em estado mutável compartilhado. A orientação de agente paralelo no ChatGPT Learn é ainda mais explícita: comece com trabalhos intensivos em leitura, como exploração, testes, triagem e sumarização; seja mais cauteloso com fluxos intensivos em gravação, porque conflitos e sobrecarga de coordenação aumentam rapidamente. Esse aviso não é teórico. Qualquer um que já viu uma frota de agentes avançando em direção a um conjunto completo de testes ao mesmo tempo sabe exatamente o que isso significa.
Na minha própria configuração, este é agora um dos problemas operacionais definidores de toda a categoria.
A questão não é se os modelos são inteligentes o suficiente para paralelizar. Eles claramente são. A questão é que eles ainda precisam de limites de orquestração muito melhores, porque "inteligente o suficiente para delegar" não é a mesma coisa que "inteligente o suficiente para preservar a saúde da máquina, a prioridade local e a disciplina de custos sob contenção".
Essa mesma incompatibilidade aparece na precificação.
O Cursor ilustra o problema nitidamente. Sua precificação atual é transparente: existem dois pools de uso mensal, um para os modelos próprios do Cursor e outro para "Outros Modelos" de terceiros. Também mostra que o Auto não é uma coisa única. O Auto Cost usa precificação fixa de tokens, mas o Balance e o Intelligence cobram pela taxa do modelo roteado, e o roteador pode escolher entre modelos como Composer, GPT‑5.6, Claude ou Grok. Para pessoas que fazem trabalho interativo ocasional, essa flexibilidade é atraente. Para cargas de trabalho industriais e explosivas, pode se tornar uma armadilha. O orçamento premium de um mês pode desaparecer em alguns dias muito produtivos.
Testei exatamente esse modo de falha em um cenário intensivo em revisão.
Um projeto assumiu aproximadamente 500 mil novas linhas de código. Nosso sistema de revisão sinalizou cerca de 1.500 problemas nesse delta, incluindo duplicatas e falsos positivos. O Cursor CLI foi encarregado de processá-los. Os volumes brutos de tokens eram enormes. A saída foi útil. Mas a economia não funcionou para o meu caso de uso. Quando o trabalho intensivo de revisão e correção pode consumir uma cota mensal em uma semana, a ferramenta ainda pode ser boa, mas a assinatura deixa de fazer sentido.
Essa tensão está agora em toda parte.
O Claude ainda é o sistema com o qual mais gosto de trabalhar. Mas também é aquele que me deixa mais consciente dos custos. O Codex, especialmente no ecossistema mais amplo do GPT‑5.6, muitas vezes pode suportar muito mais taxa de transferência do que seus críticos admitem. O Grok 4.5 não é uma piada; sua precificação e posicionamento público o tornam um concorrente legítimo. A própria precificação da Anthropic torna a compensação entre Fable e Opus óbvia o suficiente para quase escrever o editorial para você: a capacidade de fronteira está lá, mas a fatura também está.
E então há o problema mais difícil de todos, aquele que nenhum evento de lançamento realmente resolve.
Em quase todos os modelos de codificação de fronteira que uso, ainda existe uma lacuna frustrante entre subpotente e superengenhado.
A escolha é muitas vezes entre um modelo que não está pensando o suficiente e um que está pensando demais para a tarefa em questão. A própria orientação da Anthropic para o Fable 5 efetivamente reconhece isso. Diz que um esforço maior pode superplanejar, que o trabalho de rotina pode se beneficiar de um esforço menor e que instruções breves geralmente superam estruturas infladas. A OpenAI diz algo semelhante em sua orientação para o GPT‑5.6: ao migrar de modelos anteriores, comece com o mesmo nível de raciocínio e depois teste um nível abaixo, porque os modelos mais novos podem frequentemente preservar ou melhorar a qualidade com menos tokens. Essa é uma maneira técnica de dizer a mesma coisa que muitos de nós estamos descobrindo empiricamente: o botão de esforço ainda é muito fácil de ultrapassar.
Talvez parte disso ainda seja culpa nossa.
Talvez os arquivos de instrução sejam muito longos. Talvez parte da estrutura esteja agora lutando contra os modelos em vez de ajudá-los. Essa teoria é pelo menos consistente com a própria orientação de engenharia de contexto da Anthropic, que diz que o contexto deve ser informativo, mas conciso. Existe uma possibilidade real de que algumas das complicações excessivas que atribuímos aos modelos estejam sendo amplificadas por uma infraestrutura de prompt crescida demais.
Mas mesmo depois de levar isso em conta, a conclusão mais ampla permanece inalterada.
Os modelos estão cometendo menos erros óbvios do que antes. Mas os erros que ainda cometem são muitas vezes mais perigosos precisamente porque são mais difíceis de detectar. Eles se escondem dentro de código que, de outra forma, parece polido, deliberado e profissional. Quanto melhor a implementação parece à distância, mais desconfiado aprendi a ficar.
É por isso que continuo cético em relação à atual onda de triunfalismo da codificação com IA.
Eu entendo de onde vem o hype. Se você não viveu dentro desses sistemas todos os dias, a taxa de transferência por si só pode parecer milagrosa. E parte disso é genuinamente. Mas o uso diário e prático também expõe o outro lado: incerteza na faturação, falhas de orquestração, fragilidade em sessões longas, uma tendência para simplificação superficial ou design excessivamente elaborado, e a necessidade persistente de embalagem, revisão e julgamento humanos.
Ainda estamos muito longe de um mundo ideal de codificação com LLM.
O hype não está completamente errado. Mas ainda é muito menos honesto do que a realidade operacional.
