Se você já vive dentro do Claude Code, você conhece as coisas óbvias (nativo do terminal, loop apertado, assista-o rodar, grep logs, patch, rerun, commit). Então aqui está a pergunta mais interessante: por que o Codex parece estar alcançando sem apenas clonar a vibe do agente de terminal interativo? O Codex é primeiro em delegação, não primeiro em programação em par. O superpoder do Claude Code é o loop de controle interativo apertado: você e o agente compartilham um único cockpit. É observável. Você intervém no meio do voo. Você direciona antes que ele desperdice tempo em um caminho ruim. É basicamente o agente como uma extensão do seu shell. A aposta do Codex é diferente: agente como um colega de trabalho paralelo que trabalha em seu próprio computador. Essa estrutura implica uma série de consequências de produto que são fáceis de perder se você apenas comparar as saídas do modelo: 1) Assincronismo como uma característica (não um efeito colateral) O Codex é projetado para que você delegue uma tarefa, vá fazer outra coisa e volte para um artefato revisável. O centro de gravidade se torna PRs/diff. É por isso que você vê linguagem como “delegar”, “mentalidade de abundância”, “enfileirar um monte de tarefas”. O fluxo de trabalho é: gerar N trabalhos, depois revisar/fundir. 2) Isolamento e sandboxing não são apenas infraestrutura, são UX. Cada tarefa rodando em seu próprio ambiente isolado muda o modelo de confiança: O agente pode rodar testes, modificar arquivos, gerar commits sem contaminar seu espaço de trabalho local. Você obtém limites de segurança (e muitas vezes padrões conservadores) que facilitam deixá-lo fazer isso. 3) A mesclabilidade é a métrica alvo real. O Claude Code é ótimo porque o loop converge. Enquanto o Codex está explicitamente otimizando para voltar com algo que você pode mesclar. Então a forma da comparação se torna mais clara: Claude Code = melhor quando a tarefa precisa de julgamentos no meio do fluxo, interrupções rápidas e direcionamento humano. É o “loop apertado do cockpit”. Codex = melhor quando a tarefa pode ser delegada, paralelizada e retornada como artefatos mescláveis. É “colega de trabalho com seu próprio espaço de trabalho”. A fronteira mais profunda não é a qualidade do autocomplete. É loops de controle de ponta a ponta com verificação: contexto -> plano -> edições -> execução -> verificação -> artefato revisável. E a verdadeira barreira é construída na verificação e no gosto: - ele roda os testes certos? - ele interpreta corretamente as falhas do CI? - ele produz diffs pequenos que combinam com os idiomatismos do seu repositório? - ele retorna algo que você pode mesclar sem supervisão? Meu palpite é que convergimos para um fluxo de trabalho híbrido: loop interativo do Claude Code para trabalho ambíguo + trabalhos paralelos do Codex em sandbox para throughput. O vencedor é quem construir o melhor roteador entre esses modos e tornar a delegação tão confiável quanto o git status.

O Tinker da Thinking Machines, sendo GA, é um dos primeiros lançamentos em um tempo que realmente parece um treinamento como produto. A maioria das APIs de fine-tune hospedadas (incluindo as do estilo OpenAI) são incríveis quando tudo o que você precisa é uma execução limpa de SFT, mas no momento em que você quer fazer qualquer coisa que seja um pouco mais ousada: currículos personalizados, avaliação online, pós-treinamento com recompensa, loops semelhantes a RL, truques estranhos de batching/packing: você atinge o teto rapidamente e acaba reconstruindo metade de uma pilha de treinamento. O Tinker basicamente inverte isso: ele lhe entrega uma API de treinamento com primitivas de baixo nível (sample / forward_backward / optim_step / save_state), para que você escreva o loop que realmente deseja, e eles cuidam das partes que normalmente se transformam em um mês de trabalho de infraestrutura (agendamento, escalonamento, pré-emissões, recuperação de falhas, o porquê deste trabalho ter morrido a 93%). É também LoRA-first, que é exatamente o padrão certo para personalização: você itera mais rápido, os custos permanecem razoáveis, você pode manter várias variantes sem duplicar enormes checkpoints, e o serviço se torna muito mais prático. Eu também gosto que a história não é vaga: LoRA realmente pode igualar o fine-tuning completo em muitos conjuntos de dados pós-treinamento quando você o configura corretamente, mas se você está tentando enfiar uma mudança de comportamento massiva em um pequeno adaptador (ou seu conjunto de dados simplesmente ofusca a capacidade efetiva do adaptador), você sentirá esse gargalo e ele não desaparecerá magicamente. A única desvantagem real que estou vendo é o limite de modelos pequenos: se seu objetivo são SLMs de borda pequenos, provavelmente esta não é a ferramenta. Ainda assim, estou animado com isso. Mal posso esperar para ver o que as pessoas constroem.

Após três anos na CRV, estou a integrar a equipa fundadora da Striker Venture Partners, liderando os investimentos da empresa em AI. Obrigado ao @BusinessInsider por cobrir a mudança.