La IA puede escribir mucho código. Eso no significa necesariamente que pueda escribir buen código Total.js. Y esto es algo que hemos observado repetidamente al utilizar agentes de programación con IA para crear aplicaciones Total.js reales. Si le das a un modelo de IA una funcionalidad y le pides que la implemente en Node.js, normalmente encontrará la forma de hacerlo. Pídele al mismo modelo que implemente algo específicamente en Total.js y la cosa se vuelve más interesante. El modelo conoce JavaScript. Conoce Node.js. Probablemente conoce Express extremadamente bien.
Total.js tiene su propia filosofía. Tiene su propia estructura de aplicaciones, globals, schemas, routing system, QueryBuilder, definitions, modules, plugins, helpers para el sistema de archivos, RESTBuilder, mecanismos de autenticación y muchas otras convenciones.
Un agente de IA que no entienda esas convenciones puede seguir generando código que funcione. El problema es que el resultado a menudo no parece realmente "Total.js".
Así empiezan a aparecer imports innecesarios, capas de servicios inspiradas en Express, clases repository, abstracciones de middleware personalizadas, librerías de acceso directo a bases de datos y dependencias que resuelven problemas que Total.js ya resuelve.
En Total.js empezamos a tratar esto como un problema de contexto en lugar de un problema del modelo.
La pregunta pasó a ser:
¿Cómo hacemos que un agente de programación con IA piense en Total.js antes de empezar a escribir código Total.js?
Hay varias formas de abordar este problema.
Enfoque 1: Fine-tuning de un modelo
El enfoque más ambicioso sería hacer fine-tuning de un modelo de programación open source utilizando aplicaciones Total.js de alta calidad.
En teoría, esto podría enseñar al modelo patrones específicos del framework.
En la práctica, requiere un dataset cuidadosamente seleccionado, una separación clara entre patrones modernos y legacy, una capacidad de cómputo considerable y, aun así, deja abierta la pregunta de si el modelo ha aprendido realmente los principios o simplemente está imitando código.
Para la mayoría de los equipos, este enfoque es simplemente demasiado pesado.
Enfoque 2: RAG
Otra opción es Retrieval-Augmented Generation (RAG).
Podemos indexar la documentación de Total.js, ejemplos y repositorios públicos, e introducir fragmentos relevantes en el contexto del modelo cuando sean necesarios.
Esto ya resulta útil.
Pero sigue teniendo una limitación: la documentación explica las APIs, pero no siempre explica cómo pensar con ellas.
Responde: ¿Qué hace ROUTE()?
Pero no siempre: ¿Cuándo deberíamos utilizarlo y qué deberíamos evitar construir a su alrededor?
Ese vacío nos llevó a un tercer enfoque.
Enfoque 3: Dar al agente un contexto de IA
En lugar de entrenar un nuevo modelo o depender únicamente de retrieval, empezamos a mantener un repositorio que proporciona contexto práctico de ingeniería para agentes de IA que trabajan con Total.js.
El repositorio es:
La idea es sencilla: no nos limitamos a decirle a la IA que construya esta aplicación utilizando Total.js. Colocamos un conjunto estructurado de conocimientos de ingeniería sobre Total.js directamente dentro del workspace del proyecto y hacemos que forme parte del contexto de trabajo del agente.
El repositorio describe cómo debería estructurarse una aplicación Total.js y cómo deberían abordar los agentes la arquitectura, schemas, actions, controllers, routing, bases de datos, autenticación, operaciones con el sistema de archivos, plugins, funcionalidades en tiempo real, jobs, integración con el frontend y mucho más.
Y, lo que es más importante, incluye explícitamente anti-patterns.
Porque un agente de IA no solo necesita saber qué puede hacer. También necesita saber qué no debería hacer.
Por ejemplo, antes de introducir capas de servicios, abstracciones repository, contenedores de inyección de dependencias, frameworks de middleware, librerías WebSocket o sistemas internos personalizados de require(), el agente debería preguntarse primero:
¿Total.js ya proporciona un mecanismo nativo para esto?
En la mayoría de los casos, la respuesta es sí.
Y esa única restricción mejora significativamente la calidad del código generado.
De dónde surgió todo esto
El repositorio actual aicontext no apareció de la noche a la mañana.
Durante aproximadamente seis meses lo utilizamos directamente en aplicaciones reales.
Cada vez que un agente interpretaba mal una convención de Total.js, introducía un patrón genérico de Node.js donde Total.js ya disponía de una solución nativa o generaba una arquitectura que resultaba ajena al framework, teníamos una oportunidad para mejorar el contexto.
Algunas mejoras fueron manuales. Otras surgieron directamente de problemas encontrados en producción. Algunas se perfeccionaron mediante la colaboración iterativa con la propia IA: analizando su comportamiento, comparando resultados y afinando las instrucciones.
Con el tiempo, se convirtió en una guía de ingeniería viva.
Utilizarlo en un proyecto real
Una configuración práctica sería esta.
Supongamos que estamos desarrollando una aplicación llamada myapp:
myapp/
├── backend/
├── frontend/
├── aicontext/
├── README.md
└── ...
La parte importante es el límite del workspace. Todo el proyecto se encuentra aquí, backend/ contiene la aplicación Total.js, frontend/ puede ser cualquier cosa ---React, React Native, Flutter u otro cliente--- y después añadimos el contexto de IA:
git clone https://github.com/totaljs/aicontext.git
Ahora el agente tiene acceso directo a las directrices de ingeniería de Total.js dentro del workspace.
Antes de iniciar el agente, también recomendamos mantener un README.md claro o un documento de especificaciones de la aplicación en un archivo *.md situado en la raíz del proyecto.
Solo necesita describir:
- qué hace la aplicación
- funcionalidades principales
- expectativas arquitectónicas
- restricciones
- contexto de la lógica de negocio
Ahora el agente trabaja con tres capas de contexto: especificación de la aplicación, contexto de ingeniería de Total.js, código fuente existente y el agente de programación con IA.
Esto es considerablemente más eficaz que empezar simplemente con:
Construye un marketplace utilizando Total.js.
Utilizarlo con Codex
Esto se vuelve todavía más potente con agentes capaces de inspeccionar todo el workspace. Con Codex, por ejemplo:
codex
Después:
/init
Codex genera sus propias instrucciones para el agente en AGENTS.md basándose en el workspace. Como aicontext/ forma parte de ese workspace, podemos definir explícitamente cuál es su función. No es código de la aplicación. Es la capa de referencia de ingeniería de Total.js.
Un proyecto en evolución
totaljs/aicontext no es un producto terminado.
No debería considerarse definitivo. Total.js evolucionará. Los agentes de IA evolucionarán. Y seguiremos descubriendo mejores formas de expresar el contexto de ingeniería. Animamos a los desarrolladores a clonarlo, utilizarlo con Codex, Claude Code, Grok CLI u otros agentes, aplicarlo en proyectos reales, observar dónde falla o qué partes están incompletas y mejorarlo mediante contribuciones.
Conclusión
Los modelos de IA seguirán mejorando. Pero mejores modelos no significan automáticamente mejor código Total.js. Ahí es donde el contexto importa.
Prueba totaljs/aicontext en un proyecto real. Y cuando tu agente haga algo mal, no te limites a corregir el código: mejora también el contexto.
Publicado originalmente en Total.js Blog.
Enlaces:
Top comments (0)