Bueno, publiqué el mensaje anterior y ahora he probado mi aplicación en modo operativo: ¡funciona completamente! Casi sin ajustes. El agente lo hizo todo solo.

¡Estoy realmente impresionado!

El chat GPT me convenció de que, dado que los agentes escriben código, las especificaciones de desarrollo deben cambiarse para que el código sea cómodo de escribir para los agentes, no para las personas. Es una idea sencilla, pero poco común.

Por eso decidí sacar esta solución a discusión. Ayer publiqué tres artículos:

- reddit: https://www.reddit.com/r/javascript/comments/1re4blt/askjs_is_declaring_dependencies_via_deps_in_esm_a/
- dev.to: https://dev.to/flancer64/static-imports-are-undermining-javascripts-isomorphism-25nm
- habr: https://habr.com/ru/articles/1003708/

La recepción más favorable fue en dev.to. La gente puso 3 corazones, 1 unicornio, aplaudió 2 veces y dibujaron una llama una vez. No está claro qué significa todo esto. Hubo un comentario en el que me indicaron amablemente que "existen los imports map". En total, hubo unas 280 lecturas en un día.

Lo más habitual fue en Habr. Pusieron 2 votos negativos, 2 personas añadieron a favoritos, y en total hubo alrededor de 410 lectores. En los comentarios apareció Karlitsky (autor de $mol), quien dijo que mi enfoque es incorrecto. Pero él dice eso a todos, esa es su función.

Lo más interesante fue en reddit. Lo vieron unas 10 000 personas, hubo 39 comentarios (la mitad fueron mis respuestas), y la valoración del post fue 0 (al publicarse empieza con +1, así que al final fue negativa). En general, la gente en reddit recibió la idea de reemplazar las importaciones estáticas por declaraciones de dependencias para pasar del enlace temprano al enlace tardío con bastante frialdad. Pero no de forma abiertamente negativa, como suele pasar en Habr. Así que al final también fue positivo :)

Probablemente haya que seguir impulsando esta idea: sobre el enlace tardío en JS.

He dividido en dos ramas mi paquete base @teqfw/di, sobre el cual construyo todas mis aplicaciones web.

- versión 1.x: es "código hecho a mano" siguiendo los preceptos de los fundadores;
- versión 2.x: es un desorden neuronal generado por un agente Codex;

El primero, hecho por personas para personas; el segundo, por agentes para agentes.

https://www.npmjs.com/package/@teqfw/di

Por cierto, la traducción automática de los mensajes de este canal al inglés y al español para los canales en en & es la realiza la aplicación cambiada por los agentes a la segunda versión de @teqfw/di. Ellos lo hacen muy bien.

Después de dividir mi paquete base `@teqfw/di` en dos ramas (humana y de agente), probé la versión v2 (la de agente) en mi aplicación para traducir publicaciones en canales de Telegram a otros idiomas. El agente Codex manejó esta aplicación de consola con la misma destreza que el propio paquete DI.

Luego le propuse a Codex un desafío más complejo: construir una plataforma web al nivel de `express` o `fastify`. Ya tenía el paquete `@flancer32/teq-web`, que creé manualmente. Es una plataforma web hecha según las reglas del Tequila Framework (código isomórfico sin importaciones estáticas y con enlace tardío).

Durante tres días, el chat GPT y Codex corrigieron la documentación en un contexto cognitivo, siguiendo mi excelente metodología ADSM. Ayer, Codex, basándose en esa documentación, convirtió el código del paquete al modo de generación. Ahora tengo dos paquetes, creados por el agente Codex, que deben comunicarse de alguna manera entre sí.

El problema que encontré es: ¿cómo explicarle al agente que trabaja con `@flancer32/teq-web` cómo usar correctamente el paquete `@teqfw/di`? La documentación del contexto cognitivo del paquete es demasiado extensa y detallada, por lo que no tiene sentido incluirla tal cual en el paquete con el código fuente.

De aquí se desprende una conclusión lógica: es necesario hacer una documentación especial para agentes y entregarla en el paquete npm junto con el código fuente. En esta dirección es en la que estoy trabajando ahora...

Entre la publicación del mensaje anterior en el canal en ruso y la publicación de sus traducciones en los canales en inglés y español pasaron un poco más de 45 minutos, aunque normalmente es sólo un par de minutos. Esto se debe a que Telegram dejó de responder al bot sobre cuáles mensajes ya se habían publicado en el canal. Tuve que pedir al agente Codex que modificara la documentación y el código del proyecto de traducción de publicaciones en Telegram para que fuera posible proporcionar manualmente el mensaje original para hacer repost. El agente realizó todo de la mejor manera.

Aquí está ese commit, por si a alguien le interesa — https://github.com/flancer64/tg-wa-blog-post/commit/6cc7d8c56094c031a58134b2c7127cc5f7304667

He reiniciado el bot en Telegram. Ahora verificaré si se ha restaurado el funcionamiento habitual.

¡Recuperado! (y)

Pregunté en Reddit si existen prácticas establecidas para explicar a los agentes cómo usar ciertos paquetes (maven, composer, npm, ...) - https://www.reddit.com/r/codex/comments/1rmdaxp/agentfriendly_documentation_for_npm_packages_how/

Nadie respondió. Parece que aún no hay prácticas definidas en este sentido. Tuvimos que inventar algo junto con el chat GPT. El resultado está aquí - https://github.com/teqfw/di/blob/2.0.3/ai/AGENTS.md

En total, la documentación del paquete di consta de 6 archivos y 4,164 K tokens en total. Incluye el archivo índice AGENTS.md. Podría haberse hecho en un solo documento, pero el chat sugirió dividirlo por temas, para que sea más fácil para los agentes. Bueno, ya veremos.

La idea de usar chats GPT personalizados me encantó. En su momento intenté escribir una "documentación clara" para mis primeras versiones de bibliotecas públicas. El problema es que los lectores tienen distintos niveles de experiencia. Hacer una documentación del producto que sea igual de comprensible para principiantes y usuarios avanzados es una tarea difícil. Hay que presentar el material de maneras diferentes.

En la personalización del chat GPT, tú simplemente describes la especificación del producto, y el chat adapta esa información al nivel del usuario. Da más detalles o, por el contrario, se enfoca en abstracciones. Además, el chat hablará con el usuario en su idioma nativo, aunque la especificación esté en inglés.

En fin, actualicé la versión del paquete @teqfw/di e incluí directamente en el README.md un enlace a su chat de incorporación. Voy a intentar acompañar cada uno de mis paquetes públicos con un chat de onboarding así. Ah, y de paso cambié el enfoque de toda la plataforma TeqFW. Ahora el foco está en la facilidad para desarrollar aplicaciones web usando agentes de IA. Resulta que el isomorfismo de JS, el enlace tardío y los namespaces encajan muy bien con la arquitectura LLM.

Este es mi paquete en el registro de NPM con el README ya actualizado — https://www.npmjs.com/package/@teqfw/di

Hoy instalé un agente Codex en modo autónomo en uno de mis servidores virtuales (en EE. UU.). Lo conecté a OpenAI mediante una clave API. A la tercera intento logré que en modo autónomo creara en el directorio actual un archivo de texto con el saludo "Hello World!". Intentaba constantemente salirse al modo interactivo.

En total, crear el archivo le costó al agente 10,000 tokens en tres intentos, lo que equivale a 3 centavos. Tengo una sensación vaga de que Codex por suscripción es claramente más rentable. Por 20 euros al mes puede funcionar durante mucho tiempo. Al menos, en seis meses nunca he llegado a los límites. Pero tampoco he codificado nada grande con Codex.

En resumen, el agente Codex puede funcionar de forma autónoma en un servidor. Si se instala una aplicación web para recibir webhooks de GitHub (por ejemplo, al crear un issue en un repositorio), se puede usar esta app web para activar al agente, que analizará el contenido del issue y decidirá enviarlo a trabajo o rechazarlo. Con buena financiación se podría crear una pequeña agencia automática para el desarrollo de alguna aplicación. Seguro que manejaría las tareas igual o mejor que Magento. Por lo menos, más rápido. Pero consumiría una cantidad considerable de tokens.

Mi VSCode me pidió hoy actualizar el plugin de Codex. Como ayer instalé Codex CLI en el servidor, decidí comparar las versiones. Los desarrolladores de Codex lanzan nuevas versiones con mucha frecuencia, a veces varias veces al día. Por eso configuré una actualización automática diaria en el servidor mediante cron.

Entonces, en el servidor tengo la versión codex-cli 0.114.0, y en VSCode después de la actualización está codex-cli 0.115.0-alpha.11. Es decir, en uso independiente se emplean versiones más estables, y la estabilidad se prueba con usuarios reales. Las razones son evidentes: testers gratuitos con retroalimentación.

Así es hacia donde se dirige la industria: el código lo escriben los robots, y lo prueban las personas.

Esto ya lo vivimos con Magento. Solo que allí la gente escribía y probaba el código. ¡Qué adelantados estuvieron en el equipo de Magento! Pero ya sé lo que sentirán los agentes que corrijan código en ramas donde los humanos no pasan muy seguido. :)

Hoy mi agente codex me hizo un componente para la configuración en tiempo de ejecución de mi paquete npm @flancer32/teq-web (un servidor web para aplicaciones al estilo TeqFW). En la especificación le di un código con un ejemplo de cómo debía ser, pero él lo hizo a su manera. Le pedí que me explicara. El agente me aclaró que "como en el ejemplo" no podía hacerlo, porque fallaban las pruebas debido a mi otro paquete — @teqfw/di. Resulta que en ese paquete hay demasiadas verificaciones. Por cierto, ese código también lo hizo el agente codex.

Le pedí que creara la tarea para otro agente para corregir ese error. Y para no ser un eslabón extra entre los agentes, que pusiera directamente esa tarea en GitHub.

Y así lo hizo. Aquí está esa tarea: https://github.com/teqfw/di/issues/33

Solo queda idear cómo hacer para que el agente codex del servidor tome las tareas de GitHub, las arregle y entregue el resultado. O mejor dicho, esto ya está ideado desde antes. Solo falta implementarlo para que también lo tengamos nosotros.

He creado un puente entre GitHub Issues y un agente Codex. Por ahora es solo una prueba de concepto, pero funciona bastante bien. El puente se conecta a GitHub en nombre del usuario adsm-agent (adjunto captura de pantalla). Conecté tres de mis repositorios a este puente: el propio puente, el sitio teqfw.com y el traductor de publicaciones en Telegram al inglés/español.

Hice varias issues que el agente procesó. En algunos casos funcionó de maravilla, en otros no pudo resolverlas. En resumen, el concepto funciona, pero hay que mejorar para que esté listo para la venta.

He creado un puente entre GitHub Issues y el agente Codex. Por ahora es solo una prueba de concepto, pero funciona bastante bien. El puente se conecta a GitHub usando la cuenta del usuario adsm-agent (adjunté captura de pantalla). He vinculado tres de mis repositorios a este puente: el propio puente, el sitio teqfw.com y el traductor de posts a Telegram en inglés/español.

Creé varios issues que el agente procesó. En algunos casos funcionó de maravilla, en otros no tuvo éxito. En resumen, el concepto funciona, pero hay que mejorarlo para que esté listo para el mercado.

He duplicado el último mensaje en los canales en inglés y español. Le pedí al Agente que añadiera en "tg-wa-blog-post" la capacidad de procesar imágenes adjuntas a las publicaciones a través de este issue - https://github.com/flancer64/tg-wa-blog-post/issues/6. El Agente hizo algo e hizo este PR - https://github.com/flancer64/tg-wa-blog-post/pull/7. Lo integré en el código principal y fui a probarlo en la práctica. Como resultado, el bot de Telegram no envió ninguna notificación sobre el nuevo mensaje y pensé que el problema era el nuevo código. Envié el mensaje manualmente, usando un archivo de texto. Configuré la prueba del bot en otro canal y la prueba afectó al canal principal. Por lo tanto, ahora en los canales en inglés y español hay dos mensajes iguales: el primero con la imagen insertada manualmente (copiar y pegar), y el segundo, procesado por la aplicación.

Este mensaje también prueba el funcionamiento del retransmisor automático, por eso adjunto una captura de pantalla (no muy informativa).

Pues bien, esta vez la imagen se retransmitió sin problemas. Quiero destacar que el código para la retransmisión de imágenes fue completamente escrito por el agente a través de un issue en GitHub. Es decir, el esquema funciona perfectamente.

¡Ay! ¡Y todo había empezado tan bien! Parece que he estropeado GitHub :( No todo, claro. Solo mi repositorio. Pero, aun así...

Hoy creé, con ayuda de un agente Codex, mi primera habilidad para agente: la verificación del formato de código ESM para asegurar su compatibilidad con mi plataforma Tequila. Solo son tres comprobaciones, pero lo que más me interesaba era el principio de crear y conectar la habilidad. Desde la creación del primer issue hasta la publicación de la habilidad en el registro npm, pasaron 40 minutos.

https://www.npmjs.com/package/@flancer32/skill-teqfw-esm-validator

P.D.

Por cierto, ayer arreglé GitHub: simplemente cerré sesión y volví a iniciar. Espero que nadie haya notado que lo había roto.

Hoy hice la versión 4 del skill "@flancer32/skill-teqfw-esm-validator". Casi todo el trabajo lo hizo el agente a través del plugin de VSCode. En total, quedaron 12 validaciones:

- RequireDefaultExport — el módulo debe tener un export default.
- NoCommonjs — están prohibidos require(), module.exports y exports.*.
- NoStaticImports — están prohibidos los import estáticos y los re-export estáticos.
- DependencyPosition — __deps__ debe ser el último export de nivel superior.
- ValidateDepsExport — __deps__ debe ser un objeto descriptor congelado y coincidir con los parámetros del constructor.
- ConstructorClosureBehavior — la clase behavior exportada debe tener constructor.
- ExportedClassBehaviorScope — las validaciones de class-behavior se aplican solo a clases exportadas.
- NoClassFieldBehavior — las clases exportadas no deben tener campos de clase (class fields).
- NoPrototypeMethodBehavior — las clases exportadas no deben tener métodos en el prototipo.
- NoClassInheritanceBehavior — las clases behavior exportadas no deben heredar de otras clases.
- ModuleTopBlock — el módulo debe comenzar con exactamente un bloque JSDoc principal.
- ConstructorDepsParameterName — para el constructor DI, el parámetro estructurado debe llamarse deps.

Esto es suficiente para que los agentes puedan revisar la estructura general del código fuente en proyectos TeqFW. Los skills resultaron ser un complemento potente al contexto. A futuro, se podrían trasladar todas las especificaciones del contexto (las reglas universales “interproyecto”) a skills, crear una biblioteca de especificaciones accesible por la red y vincular los agentes a ella mediante skills. Esto sin duda ahorrará tokens a los agentes.

Ayer no pude resistirme y escribí un artículo en Habr sobre el costo del código generado por agentes de IA - https://habr.com/ru/articles/1023900/

Para nuestro próximo evento familiar necesitábamos una lista de reproducción en Spotify de unas 100 canciones aproximadamente. Surgió la idea de crear una aplicación mediante un agente Codex. Después de aproximadamente dos horas de trabajo efectivo por mi parte y unos 10-20 minutos de trabajo del agente, obtuve la aplicación necesaria. Me interesó comprobar qué tan bien se mantenía el comportamiento del contexto que creo según mi metodología ADSM (una variedad de Spec-Driven Development). Le pedí al agente que eliminara el código y las pruebas y, partiendo solo del contexto, generara el código de la aplicación desde cero. Dos veces: una para el modelo GPT-5.4 y otra para los niveles de razonamiento medium & low. El código original fue escrito a nivel GPT-5.4 high. En general, el agente lo hizo bastante bien. Confirmó mi tesis de que el contexto cognitivo (la documentación) sostiene el control durante el desarrollo de la aplicación. En resumen, una generación de código por el agente costó aproximadamente el 4% de la cuota semanal de la suscripción ChatGPT Plus (20 euros/mes). Es decir, unos 20 céntimos de euro.