Es 19 de enero de 2026, lunes por la tarde.
Hoy me levanté muy tarde porque anoche estaba bastante emocionado trasteando con CZONE y OpenCode. Aunque el resultado no fue satisfactorio. Pero si no lo hubiera intentado, quizás el resultado de ayer habría sido aún más fallido.
Quedarse despierto hasta tarde es negarse a admitir el fracaso del día. —— de PH
Anoche, usé OpenCode + MiniMax M2.1 para construir CZONE (la versión en línea de CZON) desde cero, como se describe en esta entrada del diario.
La IA empezó a preguntar y preguntar, desde la selección tecnológica hasta la configuración del scaffolding, pasando por el diseño de funcionalidades y finalmente el flujo de CI/CD. Todo el proceso fue muy rápido.
Honestamente, fue un poco demasiado rápido, me sentí un poco mareado (risas).
Pero, y este es un gran pero, pronto surgieron problemas.
Descubrí que, al resolver el problema de permisos de la API REST de GitHub, su comprensión de los detalles no era suficiente.
¿Erudición y memoria fuerte? No tanto.
Por ejemplo, después de inicializar el repositorio, necesitábamos modificar el archivo .github/workflows/pages.yml para agregar los pasos de construcción de CZON. Esto requiere permisos de alcance (scope) workflow, pero el código proporcionado por OpenCode no incluía este permiso. Esto se puede ver fácilmente revisando la documentación de la API de GitHub. Sin embargo, ignoró repetidamente este detalle. Además, GitHub también es un idiota, el mensaje de error era solo un 404, sin ninguna indicación de permisos insuficientes. Y la IA tampoco se dio cuenta de este problema.
Durante este proceso, demostramos que escribir en index.md tuvo éxito, escribir en .github/index.md tuvo éxito, escribir en github/workflows/pages.yml también tuvo éxito, pero solo .github/workflows/pages.yml falló. Aunque la conversación tuvo varias rondas (porque cada vez tenía que modificar un poco el código), algo tan obvio como no darse cuenta de que .github/workflows/ podría ser un directorio con permisos especiales, muestra que su atención es dispersa y su capacidad de razonamiento (Reasoning) en modo de depuración no es lo suficientemente fuerte.
Recomiendo encarecidamente que el propio LLM o un marco de control externo (Agent) tenga un modo laboratorio (Lab Mode). En este modo, el Agent debe diseñar repetidamente experimentos controlados, verificar los resultados y así encontrar la verdad. A veces siento que un LLM es un cerebro inconsciente; donde apuntas, allí se ilumina. Lo que dice el prompt es en lo que se enfoca.
A veces queremos que tenga un conocimiento enciclopédico, otras veces queremos que sea ignorante hasta la claridad. En cierto sentido, la energía consumida por un LLM es limitada. Esperamos que, al enfrentar diferentes tareas, pueda asignar esa energía donde más se necesita, no distribuirla equitativamente. Algunos avances recientes en el campo de los LLM a menudo adoptan este enfoque.
Un cerebro en una cubeta, con capacidad de acción limitada
Otra razón importante y molesta es la insuficiente capacidad de autodepuración de OpenCode. Carece por completo de la capacidad de abrir y controlar un navegador (Browser), por lo que solo puede adivinar con frecuencia, registrar logs y pedirme que los revise. A veces juego con él, pero otras veces, mirándolo, es como mirar a mi Mentee, sin tener idea de lo que está pensando, solo impotencia. Puedo aceptar tener un Mentee un poco torpe, pero probablemente no pueda aceptar que sea un "cerebro en una cubeta sin manos": aún debemos encontrar la manera de completar el ciclo de su pensamiento. El Antigravity de Google, al lado, lo hace bastante bien, probablemente también por la cercanía con Chrome.
En cuanto a soluciones comunitarias, usar algunos frameworks de pruebas de extremo a extremo (como Cypress, Playwright) para controlar el navegador debería ser una buena opción. Después de todo, muchas operaciones actuales requieren interacción del lado del navegador; depender solo de APIs no es suficiente.
Progreso demasiado rápido, fundamentos inestables
La última razón también es mi atribución. Esta vez, la IA, desde cero, en menos de 10 minutos, me escribió docenas de archivos. La veía como si estuviera imprimiendo, sin ninguna sensación de pausa o descanso. Sin embargo, cualquier sistema complejo necesita arquitectura, necesita capas, necesita garantizar la calidad básica de cada módulo. Terminas la capa inferior, haces buenas pruebas, y luego puedes construir la capa superior con confianza. La IA actualmente carece por completo de este sentido del ritmo; simplemente imprime código. Aunque si tuviera capacidad de depuración integrada, quizás podría modificar flexiblemente arriba y abajo, pero lo que realmente evita problemas son conceptos correctos, abstracciones correctas, implementaciones correctas; depende de la coherencia lógica, de que tenga sentido. En cuanto al tiempo que la IA dedicaría a esto, creo que actualmente está muy lejos. Quizás esto es algo que solo puede resolver una capa de coordinación, no algo que el LLM pueda hacer por sí mismo. El LLM solo allana el camino, como el agua de una inundación, vertiéndose hacia el punto de menor energía potencial.
Pero muchos humanos también son así. El clásico chiste de antes: un fontanero arreglando una fuga, tapa aquí y explota allá. Tratar el dolor de cabeza cuando duele la cabeza, tratar el dolor de pie cuando duele el pie. Al final, no se puede resolver fundamentalmente, solo queda remar en el agua.
