Se già vivi all'interno di Claude Code, conosci le cose ovvie (nativo del terminale, ciclo stretto, guardalo funzionare, grep dei log, patch, riesegui, commit). Quindi ecco la domanda più interessante: perché Codex sembra che stia recuperando senza semplicemente clonare l'atmosfera dell'agente interattivo del terminale? Codex è prima di tutto delega, non prima di tutto programmazione in coppia. Il superpotere di Claude Code è il ciclo di controllo interattivo stretto: tu e l'agente condividete un'unica cabina di pilotaggio. È osservabile. Intervieni in volo. Guida prima che bruci tempo su un percorso sbagliato. È fondamentalmente l'agente come un'estensione della tua shell. La scommessa di Codex è diversa: l'agente come un collaboratore parallelo che lavora sul proprio computer. Quella cornice implica una serie di conseguenze per il prodotto che sono facili da perdere se confronti solo le uscite del modello: 1) Asincronia come caratteristica (non come effetto collaterale) Codex è progettato per farti delegare un compito, andare a fare qualcos'altro e tornare a un artefatto revisionabile. Il centro di gravità diventa PRs/diff. Ecco perché vedi linguaggio come "delega", "mentalità di abbondanza", "metti in coda un sacco di compiti". Il flusso di lavoro è: avvia N lavori, poi rivedi/unisci. 2) Isolamento e sandboxing non sono solo infrastruttura, è UX. Ogni compito che gira nel proprio ambiente isolato cambia il modello di fiducia: l'agente può eseguire test, modificare file, generare commit senza contaminare il tuo spazio di lavoro locale. Ottieni confini di sicurezza (e spesso impostazioni conservative) che rendono più facile lasciarlo fare. 3) La mergeabilità è la vera metrica obiettivo. Claude Code si sente bene perché il ciclo converge. Mentre Codex sta esplicitamente ottimizzando per tornare con qualcosa che puoi unire. Quindi la forma del confronto diventa più chiara: Claude Code = migliore quando il compito richiede decisioni in corso, interruzioni rapide e guida umana. È il "ciclo di cabina di pilotaggio stretto". Codex = migliore quando il compito può essere delegato, parallelizzato e restituito come artefatti unificabili. È "collaboratore con il proprio spazio di lavoro". La frontiera più profonda non è la qualità dell'autocompletamento. È il ciclo di controllo end-to-end con verifica: contesto -> piano -> modifiche -> esecuzione -> verifica -> artefatto revisionabile. E la vera protezione si costruisce alla verifica e al gusto: - esegue i test giusti? - interpreta correttamente i fallimenti CI? - produce piccole differenze che corrispondono agli idiomi del tuo repo? - restituisce in modo affidabile qualcosa che puoi unire senza doverlo sorvegliare? Il mio sospetto è che convergiamo verso un flusso di lavoro ibrido: loop interattivo di Claude Code per lavori ambigui + lavori paralleli sandboxed di Codex per il throughput. Il vincitore è chi costruisce il miglior router attraverso quelle modalità e rende la delega affidabile come git status.

Tinker di Thinking Machines, essendo GA, è uno dei primi lanci da un po' di tempo che sembra davvero un prodotto di training. La maggior parte delle API di fine-tuning ospitate (incluso lo stile OpenAI) sono fantastiche quando tutto ciò di cui hai bisogno è un'esecuzione SFT pulita, ma nel momento in cui vuoi fare qualcosa di anche solo leggermente piccante: curricula personalizzati, valutazioni online, post-training a forma di ricompensa, loop simili a RL, trucchi strani di batching/packing: colpisci rapidamente il soffitto e finisci per ricostruire metà di uno stack di training. Tinker fondamentalmente capovolge tutto questo: ti offre un'API di training con primitive a basso livello (sample / forward_backward / optim_step / save_state), così scrivi il loop che desideri realmente, e loro si occupano delle parti che normalmente si trasformano in un mese di lavoro infrastrutturale (programmazione, scalabilità, preemption, recupero da errori, il perché di questo lavoro è morto al 93%). È anche LoRA-first, che è esattamente il giusto default per la personalizzazione: iteri più velocemente, i costi rimangono ragionevoli, puoi mantenere più varianti senza duplicare enormi checkpoint, e il servizio diventa molto più pratico. Mi piace anche che la storia non sia vaga: LoRA può davvero eguagliare il fine-tuning completo su molti dataset post-training quando lo imposti correttamente, ma se stai cercando di comprimere un enorme cambiamento comportamentale in un piccolo adattatore (o il tuo dataset sovrasta semplicemente la capacità effettiva dell'adattatore), sentirai quel collo di bottiglia e non scomparirà magicamente. L'unico vero svantaggio che vedo è il pavimento dei modelli piccoli: se il tuo obiettivo sono SLMs edge piccoli, probabilmente questo non è lo strumento giusto. Tuttavia, sono entusiasta di questo. Non vedo l'ora di vedere cosa costruiranno le persone.

Dopo tre anni in CRV, entro a far parte del team fondatore di Striker Venture Partners, guidando gli investimenti in AI della società. Grazie a @BusinessInsider per aver coperto il cambiamento.