Claude Code escribe las pruebas de carga y destapa tres cuellos de botella
Un desarrollador encarga a Claude Code una suite de k6 para su API en Node.js y encuentra tres cuellos de botella antes del lanzamiento.
Dos semanas antes de lanzar una API de cara al cliente, un desarrollador se dio cuenta de que tenía 340 tests unitarios, pruebas de integración y un pipeline de CI que tardaba menos de diez minutos en pasar, pero ninguna prueba de carga. Ni una. Dejó que Claude Code montara una suite de k6 en una tarde, y el primer run se cayó a 140 usuarios virtuales, no a los 300 que esperaba. Por el camino aparecieron tres cuellos de botella.
El stack no tiene nada de exótico: Node.js 22.x sobre Fastify, Postgres 16 y Redis 7. La API tenía 38 endpoints, muchos con autenticación y payloads que debían parecerse a los de producción. Y una restricción que condiciona todo el experimento: un solo día de trabajo, porque estirarlo más se comía el margen del lanzamiento.
El prompt y la estructura que salió
El primer intento fue el vago: apuntar a openapi.yaml y pedir pruebas para cada endpoint. Salió un fichero por ruta, cada uno machacando un único endpoint con un payload fijo. Correcto sobre el papel, inservible en la práctica: nadie llama a GET /orders/{id} en el vacío.
Lo que funcionó fue describir tres recorridos de usuario con su reparto de tráfico real (60% navegar, añadir al carrito y pagar; 30% login, historial y detalle de pedido; 10% admin paginado), pedir un token reutilizado por usuario virtual en lugar de un login por petición, y rampa de 0 a 300 VUs repartidos según ese mix. La suite resultante separa config.js, lib/auth.js, lib/factories.js, scenarios/ y un main.js que enlaza todo.
Dos decisiones que el autor admite que no habría tomado por su cuenta. La primera, thresholds por escenario con tags: p95 por debajo de 500 ms en los recorridos de compra y cliente recurrente, 800 ms en admin, de forma que un endpoint lento no enmascare uno rápido. La segunda, los generadores de payload: factories.js importa los mismos esquemas Zod que usa la API para validar, así que cuando más tarde añadió un campo obligatorio al checkout, la prueba lo recogió sin tocar nada.
El primer run y el cuello de botella
k6 v1.1 contra un staging dimensionado igual que producción: dos réplicas de API, una instancia de Postgres, un Redis. Falló a 140 VUs. En lugar de adivinar la causa, pegó el resumen de k6 y los logs de la API del mismo intervalo en la herramienta y le pidió que correlacionara.
El primer hallazgo fue el pool de conexiones. El cliente de Postgres seguía con las 10 conexiones por defecto por réplica, así que con dos réplicas el techo eran 20 consultas concurrentes; a partir de ahí, todo lo demás hacía cola. La p95 pasó de 80 ms con 100 VUs a 2.400 ms. El texto detalla ese cuello de botella y deja los otros dos enunciados, sin desarrollo.
Lo aprovechable no es que un agente escriba el test, sino qué contexto se le da: quién usa la API y en qué orden, no solo la forma del esquema. El trabajo humano se desplaza a revisar, ejecutar e interpretar. Queda por ver si el patrón aguanta cuando el sistema que se prueba no cabe entero en la ventana de contexto del modelo.
