Cada Generación Eligió el Stack Equivocado. Los Vibe Coders No Son Diferentes.

7 min read

Ahora puedes crear una app sin entender lo que funciona por debajo.

Mira, mientras funcione, funciona... Pero si tienes más ambición que una simple herramienta casera, si quieres hacerla evolucionar, escalarla, eventualmente venderla, vas a tener que ensuciarte las manos en algún momento. La ola del no-code decía que no necesitabas programar. La ola del vibe coding dice que no necesitas entender la arquitectura. Ambas son ciertas, hasta que no lo son. Y cuando dejan de serlo, reescribes.

Los LLMs no eliminan este patrón. Lo aceleran.

Espacio de trabajo de oficina dividido mostrando dos desarrolladores con enfoques tecnológicos contrastantes: uno abrumado por arquitectura compleja y dependencias, el otro relajado con configuración mínima, separados por una langosta robótica montando un cable USB.
Tu stack tecnológico no está mal. Simplemente no es tan genial como el de ellos.

El Mismo Guión, 3 Veces

En algún momento de los 80, BASIC llegó con una propuesta directa: no necesitas entender punteros ni gestionar memoria, solo escribe la lógica. Y durante un tiempo esto fue completamente real. Podías construir programas reales sin tocar jamás los detalles de bajo nivel, lo cual fue genuinamente liberador para mucha gente que solo quería algo que funcionara. El problema no era la promesa. El problema era lo que la promesa mantenía invisible. Cuando tu programa en BASIC se volvía lo suficientemente complejo, el acoplamiento llegaba puntual como un reloj. La lógica de UI y la lógica de negocio se enredaban sin separaciones limpias y sin forma de probar nada sin tocar todo. La reescritura no era un fallo de BASIC. Estaba incluida en el trato desde el principio.

En algún cajón todavía tengo un disquete de 1993 con un programa en BASIC que automatizaba la lista de tarjetas de cumpleaños de mi hermana pequeña. Sobres con direcciones, 47 de ellos, impresos en una matriz de puntos a la velocidad aproximada de la deriva continental. No tengo ni idea de por qué estoy pensando en esto ahora mismo.

Visual Basic extendió el mismo trato hasta mediados de los 2000, solo que con formularios y manejadores de eventos en lugar de números de línea. Entonces apareció el no-code con una versión aún más limpia de la propuesta: no necesitas programar en absoluto. De nuevo, cierto, hasta que necesitas una funcionalidad que la plataforma no soporta, o alcanzas el techo de precios, o necesitas mover datos a algún lugar al que la plataforma no puede llegar. El techo del no-code es simplemente el borde de la plataforma. Lo encuentras en el peor momento posible, cuando hay más en juego.

El vibe coding es el acto 3. La propuesta está mejorada pero es casi palabra por palabra idéntica por debajo: no necesitas entender la arquitectura. Solo describe lo que quieres, el agente se encarga del resto. Cierto, para muchos casos, durante un tiempo. Lo que es consistente en las 3 olas no es la herramienta. Es la nota al pie que la propuesta omite: "no necesitas entender X, excepto cuando tu problema tiene la forma de X." Y esa condición, la persona que empieza no puede verla en el momento de elegir. Eso es lo que hace que la promesa se sienta real hasta que comienza la reescritura.

Tu Agente Conoce el Problema Popular

He estado leyendo hilos esta semana sobre qué orquestar alrededor del código generado por IA. Gestión de estado, lógica de reintentos, rollback, toda la fontanería que rodea lo que producen los agentes. Las herramientas en esos hilos son técnicamente correctas. Resuelven problemas reales. Pero los problemas reales que resuelven fueron creados aguas arriba, por decisiones anteriores: un SPA completo en React, un cliente pesado, estado complejo distribuido entre múltiples servicios. Si no tienes esos problemas, no necesitas esas soluciones.

Y cada vez que alguien pregunta cómo manejar la complejidad de orquestación, al menos 1 comentario en cada hilo dice: "simplemente dile a tus agentes que se encarguen de eso." Lo cual es completamente cierto. Y también esquiva la pregunta más útil, que es por qué esos agentes produjeron la complejidad en primer lugar. (Funciona en mi máquina. La máquina simplemente necesita 14 servicios corriendo en Docker para funcionar.)

Cuando le pides a un agente que construya una app, produce la respuesta estadísticamente probable para el tipo de problema en el que fue entrenado más a menudo: no la respuesta que se ajusta a tus restricciones reales, sino la respuesta más probable de ser correcta en todas las veces que se hizo este tipo de pregunta. El agente optimiza para la respuesta modal, lo que en la práctica significa el patrón dominante en el ecosistema. Así que pides una app y obtienes el stack por defecto: React con un bundler, una capa de gestión de estado, toda la configuración. El agente está haciendo exactamente lo que se supone que debe hacer, creo. Simplemente no puede saber que tu problema específico no necesita nada de eso.

Pasé por el mismo ejercicio para herramientas, no código: si CLI o MCP realmente se ajusta a agentes de producción. La opción popular tiene el mismo problema.

Antes de Abrir el Prompt

Tengo 2 proyectos funcionando ahora mismo, construidos aproximadamente en el mismo período, mismo desarrollador, mismo flujo de trabajo asistido por IA.

El primero es una herramienta ligera. Renderizado en servidor, Hono JSX, cero bundler de front-end. El primer pase de mi agente volvió con 23 dependencias de runtime. Necesitaba 1. Los extras no estaban mal en ningún sentido absoluto. Cada uno resuelve un problema real en un contexto real, pero ninguno de esos contextos era el mío. (Claude Code siguió proponiendo React Query para una app renderizada en servidor con cero estado de cliente. Rechacé 3 veces. En el 4º prompt finalmente abandonó la sugerencia.) No hay complejidad de estado que valga la pena mencionar y ningún flujo lo suficientemente complejo para justificar una máquina de estados aquí. XState habría sido ingeniería para un problema que no existe.

Has Muerto.

El segundo proyecto es un SaaS con clientes pagando y un flujo de importación de múltiples pasos donde los modos de fallo realmente importan. Si el paso 2 falla, el paso 3 no se ejecuta. Si la importación muere a medias, el usuario ve el estado de fallo exacto, no un error genérico. Ese proyecto usa React 18 y XState v5, pero solo 1 máquina, para exactamente ese 1 flujo. El resto de la app no toca XState. No lo necesita. Un producto usualmente tiene muchas superficies que son simples y 1 superficie que tiene complejidad de estado real, y el error es tratar todo el producto como si tuviera la complejidad de la parte más difícil.

Antes de escribir un solo prompt para cualquiera de los proyectos, me hice 1 pregunta: ¿tiene este problema estados nombrados distintos con transiciones explícitas y modos de fallo separados? Para la herramienta, no. Para el flujo de importación del SaaS, sí, pero solo para ese flujo específico.

El agente no puede responder esa pregunta. No conoce tu problema lo suficientemente bien para hacerla.

Tu agente optimiza para el problema popular. Asegúrate de que el tuyo realmente sea uno.

La Restricción Que No Se Delega

La habilidad que ha sobrevivido intacta a cada ola es saber qué complejidad requiere realmente tu problema.

Ninguna de las 3 olas la construyó, porque ninguna tuvo que hacerlo. Cada ola convenció a suficiente gente durante suficiente tiempo de que la habilidad no era necesaria. BASIC lo hizo primero, luego no-code empaquetó la misma promesa en arrastrar y soltar, y ahora vibe coding está ejecutando la misma jugada en lenguaje natural. El techo es el mismo cada vez.

El vibe coding acelera ambos lados de la ecuación: la construcción y la deuda. La primera reescritura llega más rápido, no nunca. La pregunta de arquitectura no desaparece. Se aplaza a un momento cuando hay más código que desenredar y más decisiones ya horneadas que ahora cuestan algo cambiar.

Lo que no se delega no es la programación. Es el diagnóstico. Antes de abrir el prompt, antes de describir la app al agente: ¿puedes explicar, en lenguaje simple, por qué NO necesitas X en este proyecto? El agente ya sabe que X es útil en general. La pregunta es por qué tu proyecto específico, con sus restricciones reales, no lo necesita ahora mismo. Si puedes responder eso, puedes restringir al agente al stack adecuado en lugar del modal. Si no puedes, el agente por defecto va a lo popular, y no será técnicamente incorrecto, solo no correcto para ti.

Expliqué el mecanismo exacto en cómo los contratos de prompt realmente restringen a un agente. La restricción es el 1 paso que el agente no puede hacer por ti. Todo lo demás, el agente lo maneja bastante bien.

También es la habilidad que BASIC, Visual Basic y no-code dijeron que no necesitabas aprender. Vale la pena notarlo.

Cuando llevas tu coche al taller sin saber nada sobre lo que hay bajo el capó, la factura siempre es una sorpresa. El mecánico conoce su trabajo. Tú simplemente no sabes qué cuestionar o a qué oponerte. Lo mismo con tu app. Descubrirás lo que funciona por debajo en el momento en que quieras cambiar algo, o pasársela a otra persona. La factura tiende a coincidir.

Fuentes

Este post puede contener enlaces de afiliados. Si haces clic en ellos, podría ganar una pequeña comisión, no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura.