nokode - Si un LLM puede hacerlo todo, ¿por qué escribir código? (experimento de app web)

• Un experimento que construye un servidor web sin ninguna lógica de aplicación, haciendo que el LLM procese todas las solicitudes
  • El servidor simplemente recibe solicitudes HTTP y le pregunta al LLM “¿qué se debe hacer?”, y el LLM se encarga de todo lo demás
• El servidor usa solo tres herramientas: database, webResponse y updateMemory para realizar funciones CRUD
• El LLM realiza por sí mismo el diseño del esquema SQL, la generación de HTML y JSON, y la incorporación de retroalimentación, implementando una app básica de gestión de contactos
• La velocidad de respuesta es de 30 a 60 segundos, el costo es 100 a 1000 veces mayor que el de una app web tradicional, y existen problemas de consistencia de UI y memoria
• Aun así, demuestra la posibilidad de implementar una app CRUD completa que funciona sin código, sugiriendo que el código en sí podría ser un concepto transitorio

---

Contexto

• Todo comenzó con la idea medio fantasiosa (Shower Thought) de que “algún día ya no tendremos que escribir código”
  • En el futuro, los LLM podrían procesar entradas en tiempo real y generar video a 120 fps, haciendo posible una computación puramente basada en intención, sin apps ni código
• En la realidad, esto sigue estando en el terreno de la ciencia ficción, pero durante un fin de semana decidió probar como experimento hasta dónde se puede llegar con la tecnología actual
• La hipótesis del experimento partía esperando un fracaso
  • Mientras la mayoría de la IA se enfoca en generar código (por ejemplo, Claude Code, Cursor, Copilot, etc.),
    se creó este proyecto para validar otra perspectiva: “¿y si omitimos por completo la generación de código?”
• Como resultado, se creó un servidor HTTP sin rutas, controladores ni lógica de negocio, que funciona preguntándole al LLM en cada solicitud: “¿qué se debe hacer?”
• El objetivo del experimento es demostrar qué tan lejos está realmente ese futuro

Resumen del proyecto

• nokode es un experimento que pone a prueba una arquitectura en la que se construye un “servidor web sin lógica de aplicación” y el LLM procesa todas las solicitudes
  • El servidor simplemente recibe solicitudes HTTP y le pregunta al LLM “¿qué se debe hacer?”, y el LLM hace todo lo demás
• El objetivo es validar si un LLM puede ejecutar directamente la lógica de la aplicación sin generar código
• El caso de prueba es una app de gestión de contactos (contact manager), con funciones CRUD básicas (crear, consultar, editar y eliminar)

Arquitectura del sistema

• El backend está compuesto por solo 3 herramientas
  • database: ejecuta SQL en SQLite, y el LLM diseña directamente el esquema
  • webResponse: genera respuestas en el formato adecuado, como HTML, JavaScript o JSON
  • updateMemory: guarda la retroalimentación del usuario en Markdown para consultarla en solicitudes futuras
• Por ejemplo, ante una solicitud a /contacts genera una página HTML, y ante /api/contacts genera una respuesta JSON
• Cada página incluye un widget de retroalimentación, que aplica de inmediato solicitudes como “haz los botones más grandes” o “cámbialo a tema oscuro”

Resultados del experimento

• Funcionalmente sí logró funcionar
  • El envío de formularios, el guardado de datos, la visualización de la UI y las respuestas de la API funcionaron correctamente
  • Incluso sin ejemplos, el LLM generó un esquema de base de datos adecuado, SQL seguro, una API de estilo REST, diseño responsivo, validación de formularios y manejo de errores
• Problemas de rendimiento
  • Cada solicitud tarda entre 30 y 60 segundos, lo que lo hace 300 a 6000 veces más lento que una app web convencional (10 a 100 ms)
  • El costo por solicitud es de $0.01 a 0.05, por lo que resulta 100 a 1000 veces más caro
  • Hay inconsistencias en colores y layout de la UI, imposibilidad de recordar el estado previo, y si genera SQL incorrecto ocurre un error inmediato
  • Intentos de optimización del prompt como “⚡ THINK QUICKLY” incluso empeoraron la velocidad

Conclusión e implicaciones

• Los LLM sí tienen la capacidad de ejecutar directamente la lógica de una aplicación
• El problema está en las limitaciones de rendimiento, como velocidad, costo, consistencia y confiabilidad
• Sin embargo, estas limitaciones parecen pertenecer más al terreno de las mejoras cuantitativas que de problemas cualitativos
  • La velocidad de inferencia mejora aproximadamente 10 veces por año
  • Los costos vienen bajando
  • La expansión de la longitud de contexto podría mejorar la memoria
  • La tasa de errores muestra una tendencia a la baja
• En consecuencia, podría estar más cerca la “era en la que la IA ejecuta directamente” que la “era en la que la IA escribe código”
• Lo único que queda hoy es código a nivel de infraestructura, como configuración HTTP, definición de herramientas y conexión a la base de datos,
  lo que sugiere a largo plazo una transición hacia una “computación donde solo existan la intención y la ejecución”

Cómo ejecutarlo

• Después de npm install, configura el proveedor de LLM y la API key en el archivo .env
• Ejecuta npm start y entra a http://localhost:3001 (la primera solicitud tarda entre 30 y 60 segundos)
• Puedes modificar prompt.md para cambiar el tipo de app o sus funciones
  • También puedes probar varias rutas como /game, /dashboard, /api/stats
  • La retroalimentación como “make this purple” o “add a search box” se aplica de inmediato
• El costo por solicitud ronda entre $0.001 y 0.05 según el modelo
• Publicado bajo licencia MIT

[aer0700]

La cuestión será hasta qué punto la computación se volverá más rápida y barata.
Si en el futuro un servidor promedio llega a ser 100 mil veces más rápido que ahora, y aun así los costos de operación o de instalación se mantienen iguales, eso también podría ser una forma válida de hacerlo.
Así como, a medida que la computación se abarató, pasamos del lenguaje de máquina a C, y de C a Node.js o Python, quizá en el futuro pasemos a los LLM.
Muchas cosas van a cambiar, y a su manera parece que será interesante. También surgirán muchas oportunidades.

[GN⁺]

Opiniones en Hacker News

• Yo también he estado pensando algo parecido

  1. Si la generación de código se automatiza por completo y cada búsqueda en Google produce una página personalizada en tiempo real, ¿ya no haría falta que los humanos construyan sitios web? En ese punto, el “desarrollo web” se parecería menos a programar y más a dar forma a la intención (intent-shaping)
  2. Tampoco estoy de acuerdo con la idea de que el chat sea la interfaz de usuario ideal. El lenguaje natural es flexible, pero lento, ambiguo y con alta carga cognitiva. Probablemente los sistemas basados en LLM necesiten un nuevo modelo de UI que combine conversación e interacción estructurada

• Empecé a pensar esto cuando apareció ChatGPT 3.5
  Puede que algún día la IA reemplace por completo a los programas, pero el verdadero punto clave es encontrar la abstracción correcta
  Por ejemplo, así como la transición de CVS a Git abrió la era de los microservicios, una buena abstracción tiene el poder de cambiar el problema de raíz
  Para que un LLM descubra este tipo de abstracciones por sí mismo, tendría que aprender interactuando con el mundo real durante mucho tiempo

• Si se agregaran herramientas para que el LLM pudiera modificar archivos de código directamente, creo que mejorarían mucho la velocidad de respuesta y la consistencia
  El código terminaría funcionando como una especie de memoria (memory)
  Enviarle solicitudes HTTP directamente al LLM sería algo parecido a un fallo de caché, y también se podría mantener un mecanismo de retroalimentación que dispare actualizaciones de código

  • Esto era solo un experimento, y la intención era mostrar que todavía hay muchos cuellos de botella
    Hay mucho margen de optimización, pero en términos prácticos, el enfoque tradicional de programación probablemente siga siendo más eficiente
  • Esta arquitectura se parece a plantar una semilla (seed): definir la dirección de crecimiento y sus límites
  • Estaría bueno construirlo

• Suena como preguntar: “Si es posible un comportamiento no determinista, ¿por qué insistir en que sea determinista?”
  Pero no creo que la mayoría de la gente quiera una webapp que funcione distinto cada vez

  • En realidad, la gente no quiere una “webapp” en sí, sino una solución a su problema
    El código determinista tiene límites para abordar problemas complejos, y un enfoque más flexible, parecido al humano, podría ser más adecuado
  • Los LLM actuales están limitados sobre todo a la salida de texto y casi no tienen memoria de largo plazo
    Pero en el futuro tendrán capacidades de salida y almacenamiento mucho más ricas
    Por ejemplo, un LLM podría generar enlaces que, al hacer clic, lancen nuevas consultas internamente, o podría gestionar una base de datos temporal
  • Mi intención no es decir que el comportamiento no determinista sea mejor, sino mostrar la brecha entre el presente y una era post-code
  • De hecho, el software actual tampoco es completamente determinista
    La experiencia del usuario cambia constantemente por actualizaciones automáticas, pruebas A/B, cambios de UX, etc.
  • Si pones la temperatura en 0 y haces que el LLM guarde la configuración en archivos locales, también podrías crear una app determinista

• Curiosamente, este enfoque puede funcionar solo con la ventana de contexto, sin herramientas aparte
  En julio de 2025 hice una PoC

• Este experimento muestra muy bien cómo podría cambiar el concepto de código boilerplate
  Si ejecutas varias instancias en paralelo dentro de un sandbox y entregas el mejor resultado según una evaluación interna, eso se convierte en una especie de meta reinforcement learning
  Aun así, es difícil traducir la intención del usuario a una salida determinista y, por otro lado, las apps tradicionales carecen de flexibilidad
  Al final, la clave es cómo implementar de forma estable la evaluación de intención (intent evaluation)

  • Pero existe el riesgo de que el modelo termine sobreajustándose al método de evaluación interna
    Crear un buen método de evaluación es casi tan complejo como crear un modelo de IA

• Procesar solicitudes de la manera tradicional es mucho más rentable que usar un LLM directamente
  Aproximadamente, generar 10 tokens con un modelo de 7 mil millones de parámetros requiere más de 100 GFLOPs
  Es un desperdicio enorme de energía

  • Pero creo que también habría que incluir en el cálculo el costo energético del trabajo humano
    Si trabajas en IT empresarial, la ineficiencia humana tampoco es nada menor
  • La dirección de una industria no siempre coincide con la optimización
    Incluso la ineficiencia puede volverse tendencia
  • Aun así, el enfoque de usar un LLM para crear rápidamente un prototipo (V1), validar el product-market fit y luego optimizar con código tradicional, sí tiene sentido

• Tal vez bastaría con poner un LLM en el puerto 443 y decirle: “eres un servidor HTTPS y también un servidor de aplicaciones” ;)

• ¿De verdad hace falta una webapp? ¿No bastaría con hablar con la computadora por voz?
  “Muéstrame las fotos que tomé en las vacaciones del año pasado, quítales las nubes y mándaselas a mi amigo”
  “Pon un temporizador para ejercicio, pero saca los jumping jacks”
  “Créame un beat techno estilo Detroit”
  “Búscame una cita para esta noche, prefiero cabello negro”
  Me imagino un mundo donde todo se resuelva hablando así

  • Pero este tipo de automatización podría debilitar la autonomía (agency) humana
    Al final, la humanidad podría dividirse entre quienes lo acepten y quienes lo rechacen
    Ya se ven señales de eso en fenómenos como el regreso del vinilo
  • La interfaz por voz no es la respuesta para toda comunicación
    Incluso entre humanos muchas veces se prefiere el texto
  • Yo también hice esta semana una app personal de gestión del conocimiento con WebSpeech que recibe entrada por voz y lee/modifica archivos de org-mode y logseq
    Sirve para tareas, compras y agenda, y está completamente personalizada a mis necesidades
  • Este futuro se ha tratado muchas veces en la ciencia ficción
    Las tareas complejas pueden expresarse bastante bien por voz, pero para las tareas simples y repetitivas una UI sigue siendo más eficiente
    Por ejemplo, si dices “cómprame pantalones” y hay que elegir uno entre 30 resultados, al final necesitas una interfaz visual

• Yo también subí una PoC parecida a GitHub
  Al principio uso un “modelo de diseño” lento para crear el tema de la app y el esquema de la base de datos, y después un modelo rápido para manejar las respuestas
  Probé usar PostREST para meter la lógica en la base de datos, pero fallaba seguido al generar el esquema o producía consultas incorrectas
  Usé una librería de CSS para mantener la consistencia de la UI, e hice que recordara la página anterior
  Creo que este enfoque podría servir como un App Bench para evaluar si un LLM puede crear una app completa de una sola vez