> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-nocode, iteración rápida y nuevas restricciones de ingeniería

La semana pasada, Recursos Humanos lanzó una actividad de vlogs por los diez años de servicios financieros. Luo Huayu, uno de nuestros practicantes, hizo todo el proyecto con nocode. Revisé su código la semana pasada y encontré varias cosas interesantes.

Primero, no me sorprendería que no-code multiplicara la productividad varias veces, o incluso decenas de veces, en proyectos así. Lo que sí me sorprendió fue que el proceso completo hubiera generado 268 versiones. Sabemos que la IA seguirá acelerando la entrega de software y que los proyectos en producción probablemente avanzarán varias veces más rápido que hoy. Pero ¿qué ocurre cuando aumenta la velocidad? Creo que este proyecto lo ilustra bien.

Hace unos años, para una actividad similar con sorteos, lo habitual era asignar un desarrollador de frontend y otro de backend y darles algo más de medio mes. Tras trabajar intensamente durante más de una semana, entregaban un MVP. El cliente lo veía y proponía cambios; desarrollo iteraba y se lo volvía a mostrar dos días después. A menudo seguía sin quedar satisfecho y había que hacer otra ronda. Al final, el tiempo solía agotarse y el cliente decía: «Dejémoslo así por ahora». En todo el proceso, quizá solo llegaba a ver tres o cuatro versiones. El margen para iterar se terminaba enseguida.

nocode, en cambio, acorta mucho la distancia entre necesidad e implementación. El cliente recibe resultados antes y también genera nuevas ideas más rápido. En el mismo medio mes, la iteración avanzó más de 200 versiones. Muchas iteraciones que antes nunca habrían ocurrido ahora se vuelven posibles. Por eso hay algo importante: una mayor productividad no implica necesariamente una reducción clara del tiempo y los recursos. Es más probable que se cumpla la paradoja de Jevons. Al bajar la barrera de implementación, aumentan las ideas y las iteraciones. La demanda puede tender al infinito. No tiene por qué desaparecer la carga de trabajo; más bien se liberan iteraciones que antes no podían hacerse.

Segundo, al leer el código tuve una impresión fuerte: rara vez una persona escribiría por iniciativa propia un código así. Este servicio web completo no tiene un servidor independiente. El frontend accede directamente a la base de datos y utiliza un total de 16 procedimientos almacenados. En conjunto, es una arquitectura típica de frontend sin backend propio más BaaS. El frontend construye una SPA con React y Vite. No hay un servicio de backend separado: todas las operaciones de datos usan supabase-js desde el navegador para llamar directamente a la instalación privada de Supabase de Meituan, cuya base de datos es PostgreSQL.

La lógica de negocio está dividida en dos partes. Las validaciones sencillas y los límites de frecuencia se gestionan en worksApi.js, en el frontend. La lógica central que exige seguridad ante la concurrencia y consistencia de los datos, como votar, dar «me gusta» o eliminar, está encapsulada en funciones almacenadas de PostgreSQL, invocadas mediante supabase.rpc(). El control de permisos descansa principalmente en las políticas RLS de la base de datos. Esta solución es muy eficiente para desarrollar y elimina el costo de mantener un servidor independiente, pero sus problemas también son claros. La lógica de negocio está dispersa entre JavaScript en el frontend y PL/pgSQL en la base de datos, lo que ofrece una mantenibilidad bastante limitada. Algunos datos sensibles, como la lista de administradores, incluso tienen que quedar codificados directamente en el cliente.

El valor de este proyecto no consiste solo en mostrar que nocode permite hacer más rápido una página para una actividad. Expone de forma muy concreta una nueva normalidad de la entrega de software en la era de la IA: más versiones, comentarios más rápidos y arquitecturas cada vez más inclinadas a tomar primero el camino más corto hacia la implementación. Para los equipos, esto ofrece oportunidades reales de productividad y nuevas restricciones de ingeniería. En el futuro, lo verdaderamente escaso quizá no sea escribir primero una función, sino conservar los límites arquitectónicos, la mantenibilidad y la capacidad de evolución a largo plazo en medio de iteraciones extremadamente rápidas.