Si ya vives dentro de Claude Code, ya sabes lo obvio (nativo de terminal, bucle cerrado, verlo correr, grep logs, parchear, volver a ejecutar, hacer commit). Así que aquí va la pregunta más interesante: ¿por qué Codex parece estar poniéndose al día sin simplemente clonar la vibra de agente terminal interactivo? Codex es primero la delegación, no la programación en pareja. El superpoder de Claude Code es el apretado bucle de control interactivo: Tú y el agente compartís una sola cabina. Se puede ver. Intervienes en pleno vuelo. Conduces antes de que se gaste el tiempo por un mal camino. Básicamente es un agente como una extensión de tu carcasa. La apuesta de Codex es diferente: el agente como un compañero paralelo que trabaja en su propio ordenador Ese encuadre implica un montón de consecuencias de producto que son fáciles de pasar por alto si solo comparas los resultados de los modelos: 1) Asincronía como característica (no como efecto secundario) Codex está diseñado para que entregues una tarea, hagas otra cosa y vuelvas a un artefacto revisable El centro de gravedad se convierte en PRs/diferencial. Por eso ves expresiones como "delegar", "mentalidad de abundancia", "poner en cola un montón de tareas". El flujo de trabajo es: generar N trabajos y luego revisar/fusionar. 2) El aislamiento y el sandboxing no son solo infraestructura, es experiencia de usuario. Cada tarea que se ejecuta en su propio entorno aislado cambia el modelo de confianza: el agente puede ejecutar pruebas, modificar archivos, generar commits sin contaminar tu espacio de trabajo local. Tienes límites de seguridad (y a menudo valores conservadores) que facilitan dejar que lo haga simplemente. 3) La capacidad de fusión es la métrica objetivo real. Claude Code se siente genial porque el bucle converge. Mientras que Codex optimiza explícitamente para que vuelva con algo que puedes fusionar. Así que la forma de la comparación se vuelve más clara: Claude Code = mejor cuando la tarea necesita decisiones de juicio a mitad de curso, interrupciones rápidas y dirección humana. Es el "lazo de cabina apretado". Codex = mejor cuando la tarea puede delegarse, paralelizarse y devolverse como artefactos fusionables. Es "compañero de trabajo con su propio espacio de trabajo". La frontera más profunda no es la calidad de autocompletado. Son bucles de control de extremo a extremo con verificación: Contexto -Plan > -Ediciones > -Ejecución > -Verificación de > -> artefacto revisable Y el verdadero foso se construye en la verificación y el gusto: - ¿Hace las pruebas correctas? - ¿interpreta correctamente los fallos de CI? - ¿Produce diferenciales pequeños que coincidan con los modismos de tu repositorio? - ¿Devuelve de forma fiable algo que puedas fusionar sin tener que cuidar niños? Supongo que convergemos hacia un flujo de trabajo híbrido: bucle Claude Code interactivo para trabajo ambiguo + trabajos paralelos en formato sandbox para el rendimiento de rendimiento. El ganador es quien construya el mejor router en esos modos y haga que la delegación se sienta tan fiable como el estado git.

Tinker de Thinking Machines siendo GA es uno de los primeros lanzamientos en mucho tiempo que realmente se siente como un producto de entrenamiento. La mayoría de las APIs de ajuste fino alojadas (incluida la de OpenAI) son geniales cuando solo necesitas una partida limpia de SFT, pero en cuanto quieres hacer algo aunque sea un poco picante: currículos personalizados, evaluación online, postentrenamiento con forma de recompensa, bucles tipo RL, trucos raros de agrupación/empaquetado: llegas rápido al límite y acabas reconstruyendo la mitad de una pila de entrenamiento. Tinker básicamente invierte eso: te da una API de entrenamiento con primitivas de bajo nivel (ejemplo / forward_backward / optim_step / save_state), así que escribes el bucle que realmente quieres y ellos se encargan de las partes que normalmente se convierten en un mes de trabajo de infraestructura (planificación, escalado, preempciones, recuperación de fallos, y por qué murió este trabajo al 93%). Además, es LoRA-primero, que es exactamente el valor por defecto para personalización: iteras más rápido, los costes se mantienen normales, puedes mantener varias variantes sin duplicar enormes puntos de control y el servicio se vuelve mucho más práctico. También me gusta que la historia no sea vaga: LoRA realmente puede igualar el ajuste fino completo en muchos conjuntos de datos post-entrenamiento cuando lo configuras bien, pero si intentas meter un cambio de comportamiento masivo en un adaptador pequeño (o tu conjunto de datos simplemente supera con creces la capacidad efectiva del adaptador), notarás ese cuello de botella y no desaparecerá mágicamente. El único inconveniente real que veo es el suelo de modelos pequeños: si tu objetivo son SLMs de borde pequeño, probablemente esta no sea la herramienta adecuada. Aun así, estoy emocionado por ello. Estoy deseando ver qué construye la gente.

Tras tres años en CRV, me incorporo al equipo fundador de Striker Venture Partners, liderando las inversiones en IA de la firma. Gracias a @BusinessInsider por cubrir la mudanza.