As últimas três semanas foram algumas das mais reveladoras que já tive no desenvolvimento de software com assistência de 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 foi ó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 alto nível por aproximadamente o dobro do preço de tabela do Opus 5, enquanto a OpenAI está posicionando o GPT‑5.6 como uma família que escala da capacidade principal até trabalhos mais sensíveis a custo. A xAI, por sua vez, está precificando o Grok 4.5 de forma agressiva o suficiente para ser levada 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 agentivos. Uma vez que essa fila existia, a produtividade se tornava 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é você ver 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 não entendem. A explosão de produção não acontece porque os modelos de repente se tornaram engenheiros autodirigidos. Acontece porque os humanos prepararam o terreno.
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 vinculada 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 tenho visto. Se um processo durar muito tempo, 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ública visível: explosões de subagentes e estado local.
A issue aberta #34061 documenta um caso em que uma thread pai retomada produziu milhares de logs JSONL filhos e centenas de gigabytes de histórico de sessão persistido. Outra issue adverte explicitamente que fork_context=true pode fazer com que históricos pais grandes sejam copiados para agentes filhos, amplificando tanto o risco de correção quanto o consumo de tokens. Outro relatório público mostra que cold starts 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: uma vez que a camada de metadados local fica grande o suficiente, a persistência de 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 estressada.
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 sobre agentes paralelos 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 custos de coordenação aumentam rapidamente. Esse aviso não é teórico. Qualquer um que já viu uma frota de agentes investir ao mesmo tempo em uma suíte de testes completa 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 perfeitamente. Seu preç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 preço fixo por token, 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 em rajadas, 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 estava errada para o meu caso de uso. Quando o trabalho intensivo de revisão e correção pode consumir um limite 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 produtividade do que seus críticos admitem. O Grok 4.5 não é uma piada; seu preço público e posicionamento o tornam um concorrente legítimo. O próprio preço da Anthropic torna a compensação entre Fable e Opus óbvia o suficiente para que quase escreva o editorial para você: a capacidade de fronteira está lá, mas a fatura também.
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 subdimensionado e superengenhoso.
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. Ela diz que um esforço maior pode resultar em planejamento excessivo, que o trabalho rotineiro 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 dial 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 algumas das estruturas estejam 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 prompts crescida demais.
Mas mesmo depois de levar isso em consideração, 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 frequentemente mais perigosos, precisamente porque são mais difíceis de detectar. Eles se escondem dentro de um 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.
Entendo de onde vem o hype. Se você não viveu dentro desses sistemas todos os dias, a produtividade por si só pode parecer milagrosa. E parte disso é genuinamente. Mas o uso prático diário também expõe o outro lado: incerteza na faturação, falhas de orquestração, fragilidade em sessões longas, uma tendência à simplificação superficial ou ao 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 LLMs.
O hype não está completamente errado. Mas ainda é muito menos honesto do que a realidade operacional.
