Stress test agéntico: el bucle no se detiene en plan y execute
Mike Codeur
📺 Este artículo se basa en el vídeo completo. Míralo aquí: https://mkc.sh/stress-test
La semana pasada publiqué un vídeo de más de dos horas sobre el método Killer SaaS: cómo reemplazar cualquier SaaS, incluso complejo, con código de calidad. La idea no es vibe codear una pequeña aplicación, sino producir código limpio y seguro.
Muchos lo visteis. Y en ese vídeo ya decía algo importante: la mayoría os quedáis en las fases plan y execute. Planificáis, ejecutáis, avanzáis, y pensáis que ya está.
No está. El desarrollo agéntico abarca más que eso.
Aunque llegues hasta el final del método y publiques un SaaS en producción, no has terminado. Que tu aplicación funcione para ti no significa que vaya a funcionar para varios usuarios.
Una petición atraviesa cinco capas
El principio es el de la cadena: su resistencia es la del eslabón más débil.
Una petición atraviesa varias capas, y basta con que una sola falle para que todo el tiempo de respuesta se vea afectado. Da igual que las otras cuatro sean rápidas. Si el pool de conexiones tarda cinco segundos, tu petición tarda cinco segundos.
Los puntos de saturación que hay que conocer:
- el pool de conexiones
- las consultas lentas
- las API externas
- el arranque en frío
Cualquiera de ellos puede convertirse en el cuello de botella.
La curva que todo desarrollador debería tener en mente
Esto es lo que suele pasar. Pruebas tu aplicación. Te conectas, estás solo, miras la latencia y concluyes que todo va bien. Responde, funciona.
Funciona con 10 usuarios. Con 20. Con 30.
Y de golpe, quizá a los 50, tienes una degradación fuerte y un pico de respuestas muy lentas.
Eso es exactamente lo que un desarrollador debe detectar antes que sus usuarios.
k6, y las tres cifras que hay que saber leer
Los escenarios de prueba de carga se escriben en JavaScript. Es fácil de generar con una IA, y permite lanzar varios cientos de usuarios virtuales en paralelo.
Para leer los resultados, bastan tres conceptos.
VU, por usuario virtual. 200 VU corresponden a 200 personas navegando simultáneamente. k6 produce esas simulaciones de usuarios.
p95. Es la métrica importante: 95 visitantes de cada 100 fueron atendidos más rápido que ese valor. Si tu p95 está en 1,5 segundos, 95 de cada 100 visitantes tienen tiempos de respuesta aceptables. Si tu p95 está en 4 segundos, 95 de cada 100 visitantes esperan entre 3 y 4 segundos. Eso no es bueno.
El umbral. Es el límite que declaras antes de disparar. Sin umbral, produces un gráfico, no una prueba.
Los dos skills
El flujo se apoya en dos skills que comparto en el kit: el que redacta y ejecuta las pruebas de carga, y el que explota los errores de producción.
El primero tiene un comportamiento útil: si nunca has implementado un escenario de prueba, te ayuda a implementarlo. Si el escenario ya existe, te dice qué se ejecutó y te pregunta si quieres lanzar la prueba de carga.
Estos skills tienen reglas fijas, y son ellas las que importan:
- se incluye siempre una página testigo sin base de datos;
- el agente nunca fija los umbrales por su cuenta;
- el agente nunca cierra una issue por su cuenta.
En la práctica, la petición se parece a esto:
Lanza una prueba de carga en producción con 200 usuarios virtuales.
Y el agente se encarga del resto.
Lo que encontró la prueba
En mi plataforma de formaciones, la ejecución sacó a la luz un error de conexión con la base de datos: se había alcanzado el número máximo de conexiones de sesión.
El detalle que importa: ese error no se dispara con 200 usuarios. Aparece a partir de una veintena.
No es el tipo de problema que ves a la primera. Pero si hubiera anunciado este SaaS a mi comunidad sin hacer esa prueba, mucha gente se habría encontrado con ese error. Y su conclusión habría sido simple: este SaaS no funciona.
En producción, en concreto, el usuario llega al sitio y recibe un error 500.
Cruzar la prueba con los logs de producción
Esta es la segunda parte, y es lo que hace fiable el veredicto.
Lanzas la prueba de carga y luego comparas con lo que el rastreador de errores registró realmente durante ese mismo periodo. Sin ese cruce, solo mides tiempos de respuesta.
Un ejemplo de lo que evita. Entre los errores vi pasar una URL en .php. Le pregunté a mi agente si estaba relacionada con el stress test. La respuesta: no son mis peticiones. Y tiene sentido, porque el sitio usa next-intl y todas las URLs pasan por el idioma, del tipo /fr/.... Así que era alguien escaneando el sitio, no mi prueba.
Sin el agente para zanjarlo, podría haber perdido tiempo buscando un bug inexistente.
El veredicto
Tras la corrección, nueva ejecución. Cero errores, esta vez realmente verificado.
Ahí está la diferencia con la prueba anterior. La primera no tenía rastreador conectado: miraba los tiempos de respuesta sin comprobar de verdad qué pasaba en el servidor. La segunda tiene ambas mediciones, y solo entonces el «cero errores» significa algo.
Lo que hay que retener
El bucle agéntico no se detiene en plan y execute. Después del despliegue quedan al menos tres frentes: la auditoría de seguridad, la explotación de los logs de producción y el stress test.
Este último ya no es un proyecto en sí mismo. Con un skill bien escrito, es una frase que escribes, y un agente que construye el escenario, dispara, procesa la salida y te entrega un veredicto.
Siempre que no le dejes elegir sus propios umbrales.
Para profundizar
📺 El vídeo completo: https://mkc.sh/stress-test
🎁 Los 2 skills y las 3 guías se pueden descargar gratis: https://mkc.sh/the-agentic-dev?lead=charge-sentry