Las últimas tres semanas han sido algunas de las más reveladoras que he tenido en el desarrollo de software asistido por IA.
Claude Fable volvió a la escena, y en el mismo periodo, OpenAI lanzó GPT‑5.6 con Sol, Terra y Luna. La señal del mercado era obvia: los laboratorios frontera ya no están lanzando avances aislados, sino comprimiendo la brecha entre capacidad, niveles de precio y cadencia de despliegue. Anthropic ahora vende Fable 5 como su modelo de horizonte largo de gama alta, a aproximadamente el doble del precio de lista de Opus 5, mientras que OpenAI presenta GPT‑5.6 como una familia que escala desde la capacidad insignia hasta trabajos más sensibles al costo. xAI, por su parte, está fijando el precio de Grok 4.5 de manera tan agresiva que hay que tomarlo en serio en cualquier discusión sobre costo-rendimiento.
Y sin embargo, lo más importante que aprendí en esas semanas tuvo muy poco que ver con páginas de lanzamiento o diapositivas de benchmarks.
El verdadero avance en mi entorno fue la preparación.
Teníamos historias listas. Teníamos el trabajo dividido en piezas que los sistemas de codificación agéntica podían ejecutar realmente. Una vez que existió esa cola, el rendimiento se volvió absurdo. Entre Codex, Claude, Cursor, Grok y otras herramientas en el flujo de trabajo, se escribieron más de 2 millones de líneas de código en aproximadamente diez días. Ese número suena a exageración hasta que ves lo que lo hizo posible: no magia, ni autonomía en abstracto, sino un flujo constante de trabajo acotado con suficiente estructura para que los modelos siguieran avanzando.
Eso es lo primero que mucha gente todavía no entiende. La explosión de producción no ocurre porque los modelos de repente se conviertan en ingenieros autodirigidos. Ocurre porque los humanos prepararon el terreno de batalla.
Lo segundo que aprendí es que los errores aparecen más rápido a escala de lo que el marketing admite.
Codex es un buen ejemplo. El material de OpenAI sobre trabajos de larga duración deja claro que los hilos duraderos conllevan una compensación: la continuidad es útil, pero los hilos largos también pueden volverse más costosos y difíciles de manejar que empezar de cero. La función Goals está diseñada precisamente para mantener un hilo ligado a un objetivo acotado, en lugar de convertir cada tarea difícil en un prompt cada vez más grande. En la práctica, eso coincide con lo que he visto. Si un proceso se alarga demasiado, el mejor patrón suele ser detenerlo, pedir una transferencia limpia, reiniciar la sesión y continuar con un objetivo nuevo. Eso no es solo una conveniencia. A menudo es higiene operativa.
También hay un problema más concreto de Codex que ahora tiene un rastro público visible: las explosiones de subagentes y estado local.
El problema abierto #34061 documenta un caso en el que un hilo padre reanudado produjo miles de archivos JSONL hijos y cientos de gigabytes de historial de sesión persistido. Otro problema advierte explícitamente que fork_context=true puede hacer que los historiales grandes del padre se copien en los agentes hijos, amplificando tanto el riesgo de corrección como el consumo de tokens. Otro informe público muestra que los arranques en frío de Codex degeneran en esperas de 1 a 5 minutos una vez que ~/.codex acumula grandes registros SQLite y estado de sesión. En conjunto, esos informes describen un modo de fallo que muchos usuarios avanzados reconocerán de inmediato: una vez que la capa de metadatos local se vuelve lo suficientemente grande, la persistencia de sesión se convierte en una parte seria de la experiencia del producto.
Esto importa porque la codificación multiagente siempre se ve mejor en demostraciones que en una máquina de desarrollo estresada.
La promesa es clara. Los documentos de OpenAI sobre multiagente describen por qué los subagentes paralelos pueden acelerar flujos de trabajo independientes, y esa promesa es real. Pero los mismos documentos también advierten que los subagentes aumentan el uso de tokens y pueden no ser adecuados para tareas que implican escrituras frecuentes en estado mutable compartido. La guía de agentes paralelos en ChatGPT Learn es aún más explícita: empezar con trabajo intensivo en lectura, como exploración, pruebas, triaje y resumen; ser más cauteloso con flujos intensivos en escritura porque los conflictos y la sobrecarga de coordinación aumentan rápidamente. Esa advertencia no es teórica. Cualquiera que haya visto a una flota de agentes lanzarse al mismo tiempo hacia un conjunto completo de pruebas sabe exactamente lo que significa.
En mi propio entorno, este es ahora uno de los problemas operativos definitorios de toda la categoría.
El problema no es si los modelos son lo suficientemente inteligentes para paralelizar. Claramente lo son. El problema es que todavía necesitan límites de orquestación mucho mejores, porque "ser lo suficientemente inteligente para delegar" no es lo mismo que "ser lo suficientemente inteligente para preservar la salud de la máquina, la prioridad local y la disciplina de costos bajo contención".
Esa misma discrepancia aparece en los precios.
Cursor ilustra el problema claramente. Su precio actual es transparente: hay dos grupos de uso mensual, uno para los modelos propios de Cursor y otro para los "Otros Modelos" de terceros. También muestra que Auto no es una sola cosa. Auto Cost usa tarifa plana por tokens, pero Balance e Intelligence facturan a la tasa del modelo enrutado, y el enrutador puede elegir entre modelos como Composer, GPT‑5.6, Claude o Grok. Para personas que hacen trabajo interactivo ocasional, esa flexibilidad es atractiva. Para cargas de trabajo industriales y ráfagas, puede convertirse en una trampa. El presupuesto premium de un mes puede desaparecer en unos pocos días muy productivos.
Probé exactamente ese modo de fallo en un escenario con mucha revisión.
Un proyecto incorporó aproximadamente 500 mil nuevas líneas de código. Nuestro sistema de revisión señaló alrededor de 1,500 problemas en ese delta, incluyendo duplicados y falsos positivos. A Cursor CLI se le encargó procesarlos. Los volúmenes brutos de tokens fueron enormes. El resultado fue útil. Pero la economía no era la adecuada para mi caso de uso. Cuando el trabajo intensivo de revisión y corrección puede consumir un presupuesto mensual en una semana, la herramienta puede seguir siendo buena, pero la suscripción deja de tener sentido.
Esa tensión ahora está en todas partes.
Claude sigue siendo el sistema con el que más disfruto trabajar. Pero también es el que más me hace consciente del costo. Codex, especialmente en el ecosistema más amplio de GPT‑5.6, a menudo puede soportar mucho más rendimiento de lo que sus críticos admiten. Grok 4.5 no es una broma; su precio público y posicionamiento lo convierten en un contendiente legítimo. El propio precio de Anthropic hace que la compensación entre Fable y Opus sea tan obvia que casi escribe el editorial por ti: la capacidad frontera está ahí, pero también la factura.
Y luego está el problema más difícil de todos, ese que ningún evento de lanzamiento resuelve realmente.
En casi todos los modelos de codificación frontera que uso, todavía hay una brecha frustrante entre infrautilizado y sobreingenierizado.
La elección es demasiado a menudo entre un modelo que no está pensando lo suficiente y uno que está pensando demasiado para la tarea en cuestión. La propia guía de Anthropic para Fable 5 lo reconoce efectivamente. Dice que un esfuerzo mayor puede sobreplanificar, que el trabajo rutinario puede beneficiarse de un esfuerzo menor, y que las instrucciones breves a menudo superan a un andamiaje inflado. OpenAI dice algo similar en su guía de GPT‑5.6: al migrar desde modelos anteriores, comienza con el mismo nivel de razonamiento y luego prueba un nivel inferior, porque los modelos más nuevos a menudo pueden preservar o mejorar la calidad con menos tokens. Esa es una forma técnica de decir lo mismo que muchos de nosotros estamos descubriendo empíricamente: el dial de esfuerzo sigue siendo demasiado fácil de sobrepasar.
Quizás parte de eso todavía es culpa nuestra.
Quizás los archivos de instrucciones son demasiado largos. Quizás parte del andamiaje ahora está peleando con los modelos en lugar de ayudarlos. Esa teoría es al menos consistente con la propia guía de ingeniería de contexto de Anthropic, que dice que el contexto debe ser informativo pero ajustado. Existe la posibilidad real de que algunas de las complicaciones excesivas que atribuimos a los modelos estén siendo amplificadas por una infraestructura de prompts demasiado crecida.
Pero incluso después de tener en cuenta eso, la conclusión más amplia permanece sin cambios.
Los modelos están cometiendo menos errores obvios que antes. Pero los errores que aún cometen a menudo son más peligrosos precisamente porque son más difíciles de detectar. Se esconden dentro de código que por lo demás se ve pulido, deliberado y profesional. Cuanto mejor se ve la implementación desde lejos, más sospechoso he aprendido a ser.
Por eso sigo siendo escéptico ante la actual ola de triunfalismo en la codificación con IA.
Entiendo de dónde viene el hype. Si no has vivido dentro de estos sistemas todos los días, el rendimiento por sí solo puede parecer milagroso. Y algo de eso realmente lo es. Pero el uso diario y práctico también expone el otro lado: incertidumbre en la facturación, fallos de orquestación, fragilidad en sesiones largas, una tendencia hacia la simplificación superficial o el diseño excesivamente elaborado, y la persistente necesidad de empaquetado, revisión y juicio humano.
Todavía estamos muy lejos de un mundo ideal de codificación con LLM.
El hype no está completamente equivocado. Pero sigue siendo mucho menos honesto que la realidad operativa.
