Por qué escalar rompe las apps hechas con vibe coding

Qué es y por qué importa

Una app hecha con Claude Code funciona de maravilla contigo y tres amigos. Luego llegan cien personas a la vez y las páginas tardan una eternidad, o directamente no se abren.

El motivo no suele ser el servidor pequeño. Es la forma en que la app habla con la base de datos. Con pocos datos y pocos usuarios, cada despilfarro cuesta milisegundos. Con muchos datos y mucha gente a la vez, se va sumando.

La prueba de carga sirve para verlo antes: simulas mucha gente a la vez, mides cuánto tarda cada página y descubres qué se rompe. Tú antes que tus usuarios.

Regla número uno, sin excepciones: la prueba se hace en una copia del proyecto o en el entorno de pruebas (staging), con datos falsos. Nunca en la base de datos con los datos reales, nunca en la web en producción. Una prueba de carga es un pequeño ataque: en la web real ralentizas o tumbas la app para quien la está usando.

1. Prepara el sitio adecuado

Antes de escribir el prompt, me aseguro de tres cosas.

1. Tengo una copia separada: un entorno de pruebas, o el proyecto en mi ordenador con su propia base de datos.
2. He hecho un commit con git, para poder volver atrás.
3. Sé qué servicios externos usa la app (pagos, email, notificaciones, API de otros). En la prueba no se deben llamar de verdad.

Sobre el último punto: una prueba de carga contra una web o una API que no son tuyas puede incumplir sus condiciones de uso. Prueba solo tu propio entorno de pruebas. Para empezar, le pido a Claude que lo compruebe:

Antes de nada, comprueba a qué base de datos y a qué servicios externos está conectado el proyecto ahora mismo. Si algo apunta a los datos reales o a producción, para y dímelo. Quiero hacer la prueba solo en una copia, con datos falsos, y con los servicios externos sustituidos por versiones falsas.

2. La prueba con mil usuarios falsos

Luego, en Claude Code, escribo esto:

Haz una prueba con mil usuarios falsos y dime qué se rompe. Llena la base de datos de pruebas con datos falsos realistas, escribe un script que simule mil personas en las páginas principales al mismo tiempo (usa una herramienta gratuita y open source, por ejemplo k6, Locust o Artillery) y mide cuánto tarda cada página. Dame las tres páginas más lentas, el motivo y la corrección que propones. No toques el código hasta que te diga ok.

Qué pasa, en la práctica. Claude llena la base de datos de pruebas con muchas filas falsas pero creíbles: usuarios, pedidos, productos. Esto importa más de lo que parece: con diez filas todo va rápido, los problemas solo salen con volúmenes realistas.

Luego escribe un script que manda peticiones a las páginas principales como si fueran muchas personas a la vez. k6, Locust y Artillery son tres herramientas gratuitas y open source que hacen justo esto: deja que Claude elija según el proyecto.

La última frase es la más importante: primero quiero entender, luego decido. El script de la prueba y los datos falsos sí tiene que crearlos, el código de la app no.

Para tener una garantía extra mientras te propone las correcciones, usa el plan mode: Shift+Tab hasta que veas «plan mode on» abajo, o /plan al principio del mensaje. Ahí Claude lee y propone, pero no modifica archivos hasta que apruebas el plan. Para la prueba en sí, quédate fuera: tiene que crear el script y los datos falsos.

Mil de golpe o por escalones

Mil personas a la vez son muchas, también para el ordenador que genera la prueba. Mejor subir por escalones y ver en qué punto las páginas van lentas. Y el entorno de pruebas suele ser más pequeño que el real: lo que cuenta es el antes y el después, no el número absoluto.

Haz la prueba por escalones: primero 50 usuarios, luego 200, luego mil. Para cada escalón dime el tiempo medio, el tiempo de las peticiones más lentas y a partir de qué punto empiezan los errores.

Una corrección cada vez

Cuando te dé la lista de las tres páginas más lentas, no le pidas que lo arregle todo a la vez. Escribe:

Corrige la primera, repite la prueba y dime los tiempos de antes y después.

Y así con la segunda y la tercera. Si lo corriges todo de golpe y luego algo mejora, o empeora, no sabes qué ha sido.

3. Las tres cosas que arregla casi siempre

Cuando una página va lenta, el motivo casi siempre es uno de estos tres.

Cien preguntas en lugar de una

Una página muestra 100 productos. El código primero le pide a la base de datos la lista de productos y luego, para cada uno, le pide el precio. Total: 101 preguntas a la base de datos para una sola página. Se llama «problema N+1»: una pregunta para la lista, más una por cada elemento.

Tú solo no lo notas. Con mil personas se convierten en cien mil preguntas, y la base de datos se atasca. Y a menudo el código parece limpio: el problema está por detrás.

La corrección es pedirlo todo junto: una sola pregunta que traiga productos y precios, o dos como mucho (la lista y luego todos los precios de golpe). Pide:

Encuentra las consultas dentro de un bucle y conviértelas en una sola.

Tablas sin índices

Piensa en el índice al final de un libro. Sin él, para encontrar una palabra hojeas todas las páginas. La base de datos hace lo mismo: sin índice, para encontrar los pedidos de un usuario los lee todos, uno a uno. Con el índice va directa.

Normalmente el id principal de cada tabla ya tiene su índice. Las columnas que usas para buscar, filtrar y relacionar tablas, a menudo no. Pide:

Añade índices en las columnas que usas para buscar, filtrar y ordenar (id del usuario, email, fecha).

Pero los índices no salen gratis: ocupan espacio y hacen las escrituras un poco más lentas, porque con cada dato nuevo la base de datos actualiza también el índice. Solo van donde hacen falta. Yo siempre pido la prueba:

Para cada índice que añadas, dime qué página o consulta lo usa y enséñame el tiempo antes y después. Si un índice no sirve para nada, no lo añadas.

Datos que se recargan cada vez

La lista de precios o el menú que cambian una vez al día no hay que pedírselos a la base de datos en cada visita. Se guardan en memoria unos minutos: eso es la caché.

Pon en caché los datos que cambian poco y dime cada cuánto se actualizan.

La caché también tiene un precio: los datos pueden estar desfasados. Si cambias un precio y la caché dura diez minutos, durante diez minutos alguien ve el de antes. Por eso tienes que saber cada cuánto se actualizan. Y los datos personales de un usuario no deben acabar en una caché compartida, o algún otro podría verlos.

Comprueba que en la caché no haya datos personales de un usuario que otro usuario pueda ver.

Cuidado si la app está en un hosting serverless: ahí el código se ejecuta en muchas instancias que se encienden y se apagan solas. La memoria de una instancia no se comparte con las demás y se vacía a menudo, así que una caché guardada ahí sirve de poco. Hace falta una caché compartida, por ejemplo Redis. Pregúntale a Claude cuál ofrece tu hosting:

¿La app está en un hosting serverless? Si es así, dime qué caché compartida ofrece mi hosting y usa esa en lugar de la memoria del servidor.

Errores comunes

• Hacer la prueba en la web real o en la base de datos con los datos reales. Se hace siempre en una copia o en el entorno de pruebas, con datos falsos.
• Probar con la base de datos casi vacía. Llénala de datos falsos en cantidades realistas.
• Corregirlo todo de golpe. Una corrección cada vez, con los tiempos de antes y después.
• Poner índices en todas las columnas. Solo en las que usas para buscar, filtrar y ordenar.
• Una caché sin una caducidad clara. Decide cada cuánto se actualiza y deja fuera los datos personales.

Lista de comprobación

• Trabajo en una copia o en el entorno de pruebas, no en producción
• La base de datos de pruebas tiene datos falsos en cantidades realistas
• En la prueba, los servicios externos son falsos
• Tengo la lista de las tres páginas más lentas, con motivo y corrección
• He corregido una cosa cada vez, con los tiempos de antes y después
• Sé cada cuánto se actualiza cada caché

Preguntas frecuentes