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 escena y, en el mismo período, OpenAI lanzó GPT‑5.6 con Sol, Terra y Luna. La señal del mercado fue obvia: los laboratorios frontera ya no lanzan avances aislados, sino que comprimen 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 capacidades insignia hasta trabajos más sensibles al costo. Por su parte, xAI está fijando el precio de Grok 4.5 de forma 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 esa cola existió, 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 abstracta, 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 resultados no ocurre porque los modelos se convirtieron repentinamente 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 trabajo de larga duración deja claro que los hilos duraderos conllevan una compensación: la continuidad es útil, pero los hilos de larga duración también pueden volverse más caros y difíciles de gestionar que empezar de nuevo. La función Goals está diseñada precisamente para mantener un hilo vinculado 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 documental público visible: explosiones de subagentes y estado local.
El issue 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 issue advierte explícitamente que fork_context=true puede causar que grandes historiales padre se capturen en agentes hijos, amplificando tanto el riesgo de corrección como el consumo de tokens. Otro informe público más muestra que los arranques en frío de Codex se degradan a esperas de 1 a 5 minutos una vez que ~/.codex acumula grandes bases de datos SQLite y estado de sesión. En conjunto, esos informes describen un modo de fallo que muchos usuarios avanzados reconocerán de inmediato: en el momento en 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 multi-agente siempre se ve mejor en los demos que en una máquina de desarrollo estresada.
La promesa es clara. Los documentos de multi-agente de OpenAI 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: comienza con trabajo pesado en lectura, como exploración, pruebas, triaje y resumen; sé más cauteloso con flujos pesados 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 abalanzarse sobre un conjunto de pruebas completo al mismo tiempo sabe exactamente lo que significa.
En mi propia configuración, esto 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 desconexión se manifiesta 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 "Otros Modelos" de terceros. También muestra que Auto no es una sola cosa. Auto Cost usa precios planos por token, pero Balance e Intelligence facturan a la tarifa 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 intensivo en revisión.
Un proyecto asumió aproximadamente 500 mil nuevas líneas de código. Nuestro sistema de revisión marcó alrededor de 1500 problemas en ese delta, incluyendo duplicados y falsos positivos. Cursor CLI tenía la tarea de procesarlos. Los volúmenes de tokens en bruto eran enormes. El resultado fue útil. Pero la economía no funcionaba 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 está ahora 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 manejar 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 lo está 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 existe una brecha frustrante entre insuficiente y sobrediseñado.
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 reconoce esto 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 del esfuerzo sigue siendo demasiado fácil de sobrepasar.
Quizás parte de eso sigue siendo 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 coherente con la propia guía de ingeniería de contexto de Anthropic, que dice que el contexto debe ser informativo pero ajustado. Existe una posibilidad real de que algunas de las sobrecomplicaciones que atribuimos a los modelos estén siendo amplificadas por una infraestructura de prompts demasiado grande.
Pero incluso después de considerar eso, la conclusión general sigue siendo la misma.
Los modelos están cometiendo menos errores obvios que antes. Pero los errores que aún cometen son a menudo más peligrosos precisamente porque son más difíciles de detectar. Se esconden dentro de un código que por lo demás parece pulido, deliberado y profesional. Cuanto mejor se ve la implementación desde la distancia, 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 lo es genuinamente. Pero el uso diario práctico también expone la otra cara: 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 necesidad persistente de empaquetado, revisión y juicio humanos.
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.
