Cuando la IA acelera el desarrollo, el mayor peligro es creer que “ya está”
Con IA, una app multijugador puede pasar de idea a prototipo funcional a una velocidad absurda. Se crea la sala, entra gente, se publica, se vota. El cerebro declara:
Terminado.
El servidor contesta:
Has probado con una persona.
Las preguntas importantes vienen después: ¿qué pasa si 100 personas actúan a la vez? ¿Y si la base de datos guarda el cambio pero la respuesta de éxito se pierde? ¿Y si el último voto coincide con el cierre? ¿Y si llega dos veces una notificación de pago? ¿Y si todos se reconectan justo cuando vuelve el servicio?
La revisión de código de una pequeña app multijugador acabó en 324 casos de prueba. Eso no significa 324 fallos encontrados. Los 324 seguían sin ejecutar. Era un plan de pruebas, no un certificado de calidad.
1. DDoS no es el único riesgo de carga
Cloudflare ofrece mitigación automática de DDoS en todos sus planes, pero también recomienda controles de aplicación como límites de frecuencia porque un ataque grande todavía puede afectar a la aplicación.[1]
En un proyecto pequeño, el tráfico legítimo puede ser el primer problema.
Si cada cliente consulta el estado cada tres segundos:
| Clientes simultáneos | Consultas de estado por hora |
|---|---|
| 10 | 12.000 |
| 30 | 36.000 |
| 100 | 120.000 |
| 1.000 | 1.200.000 |
No es una predicción de capacidad real. El backoff y la caché pueden reducirla; publicaciones, imágenes, bandejas, varias pestañas y tareas programadas pueden aumentarla.
A 5 de octubre de 2026, Workers Free indica 100.000 solicitudes al día. D1 Free indica 5 millones de filas leídas al día, 100.000 escritas, 500 MB por base de datos y 50 consultas por invocación de Worker.[2][3] Una base D1 procesa las consultas de una en una; demasiada concurrencia forma cola y puede acabar en errores de sobrecarga.[3]
A veces el escenario peligroso no son “un millón de atacantes”.
Son 100 usuarios normales divirtiéndose al mismo tiempo.
2. Por qué la lista llegó a 324 pruebas
Se cubrieron 16 áreas: entradas y abuso, capacidad, concurrencia y recuperación, tareas programadas, salas y permisos, imágenes, texto, votación, plazos, desbloqueo de resultados, salas públicas, conexiones persistentes, dispositivos y reconexión, integraciones, pagos y despliegue/monitorización.
No todo tiene la misma prioridad.
3. Las 23 comprobaciones que atacaría primero
- ¿Incluso las solicitudes rechazadas llegan a trabajo caro de base de datos?
- ¿El contador interno mide realmente todas las rutas costosas?
- ¿El límite de frecuencia sobrevive reinicios y múltiples instancias?
- ¿Un “sin cambios” sigue leyendo mucho de la base?
- ¿Un solo asiento puede abrir conexiones persistentes ilimitadas?
- ¿HTTP y conexión persistente aplican los mismos límites?
- ¿Un apagado de emergencia detiene también a clientes ya conectados?
- ¿Una tarea programada tardía permite acciones después del plazo?
- ¿Puede fallar una escritura secundaria y aun así avanzar la sala?
- ¿Una reparación repetida duplica estadísticas?
- ¿Puede gastarse una reserva de inicio antes de crear la partida?
- ¿Un reintento puede convertir una respuesta en dos?
- ¿Variantes visuales del mismo nombre saltan la unicidad?
- ¿Dos personas pueden ocupar a la vez la última plaza?
- ¿Las tareas periódicas pueden acumular más trabajo del que procesan?
- ¿Se mide toda la base e índices, no solo imágenes?
- ¿Otra persona puede apropiarse de una identidad de dispositivo perdida?
- ¿Se validan formato, dimensiones, metadatos y ubicación de imágenes?
- ¿Un historial largo encarece cada carga de pantalla?
- ¿La reconexión sincronizada puede provocar un segundo fallo?
- ¿Se han probado pagos duplicados, tardíos, fallidos, cancelados y restaurados?
- ¿Se confunde pasar pruebas locales con pasar producción?
- ¿Si cae la base de datos también cae el sistema que avisa?
4. Los bugs adoran las combinaciones
Un buen escenario:
100 personas votan → 20 recargan → 10 pierden conexión → algunas escrituras sí se guardan pero la respuesta se pierde → reintentan.
Entonces se comprueba si se duplican votos, entran votos tardíos, la pantalla vuelve a datos antiguos o una acción correcta se ejecuta dos veces.
OWASP trata sesiones concurrentes, entradas anómalas y manejo de errores como áreas distintas de prueba.[4]
5. Guardar y recibir el “OK” son dos eventos
La escritura puede haber terminado y la respuesta de red desaparecer.
El usuario ve un error y vuelve a pulsar.
Sin un identificador de operación o deduplicación, pueden aparecer dos respuestas, dos salas, dos votos, dos avisos o dos cobros.
Los reintentos se diseñan.
6. La carga se prueba por etapas
En un entorno controlado: 10 → 30 → 100 clientes.
Después cambia la forma del tráfico: una sala llena, muchas salas, altas simultáneas, voto final simultáneo, reconexión masiva, tareas programadas y fallos de almacenamiento simulados.
No se envía tráfico masivo deliberado a sistemas ajenos o sin permiso. Se fijan antes presupuesto y condiciones de parada.
7. “No se cayó” no basta
Se puede empezar con metas como 95% de solicitudes normales por debajo de un segundo, 99% por debajo de tres y menos de 0,1% de errores 5xx inesperados.
Pero estos resultados deben ser cero:
- exposición de datos ajenos;
- acciones sin permiso;
- puntuación duplicada;
- pérdida de datos confirmados;
- doble cobro.
8. Diseño 9/10, evidencia ejecutada 0/10
Una lista de 324 casos y 23 riesgos prioritarios puede ser un diseño excelente.
Antes de ejecutarlos, la evidencia sigue siendo cero.
No es una mala situación: ya no estás en “no sé qué probar”, sino en “sé exactamente dónde intentar romperlo”.
9. Y entonces se agota otra cosa: el límite semanal de la IA
Un día entero haciendo que una IA lea un repositorio grande, implemente, corrija, revise y vuelva a implementar puede agotar antes la cuota de IA que el servidor.
A 5 de octubre de 2026, Claude Max 20x cuesta 200 dólares al mes en web. El “20x” se refiere a capacidad por sesión frente a Pro. La sesión se reinicia cada cinco horas, pero además existe un límite semanal compartido por todos los modelos.[5]
20x no significa infinito.
El consumo exacto depende del modelo, el contexto y la tarea. Settings > Usage es la referencia práctica.
10. “Fable es caro” también cuadra con los números
En Max, Fable 5 y 5.1 están incluidos, pero Fable puede ocupar hasta el 50% del límite semanal y Anthropic indica que consume esa cuota más rápido que otros modelos.[6]
Precios por uso:
| Modelo | Entrada / 1M tokens | Salida / 1M tokens |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Fable 5.1 cuesta 2,5 veces más por token de entrada y salida que Opus 5.5. El caché más barato reduce el coste frente a Fable 5, pero el precio absoluto sigue siendo alto.[6][7][8]
Los precios API no se convierten directamente en minutos de cuota Max, pero la idea se mantiene: usar el modelo más pesado durante muchas horas sale caro de una forma u otra.
11. No hace falta una grúa para cada tornillo
Sonnet 5.5: arreglos rutinarios, bugs entendidos, cambios repetitivos, tareas bien delimitadas.
Opus 5.5: causas desconocidas, arquitectura, revisión entre muchos archivos, decisiones críticas antes de publicar.
Fable 5.1: trabajos especialmente difíciles donde la capacidad extra justifique el mayor coste o consumo de cuota.
No es un ranking. Es ingeniería de coste por tarea.
12. La IA no elimina el cuello de botella: lo mueve
Antes: idea → semanas de desarrollo → pruebas.
Ahora: idea → implementación rápida → pruebas, operaciones, límites del servidor y límites de IA aparecen juntos.
“I hice la app en un día” puede ser verdad.
Una frase más exacta sería:
“En un día llegué al punto en que ya puedo intentar romperla en serio.”
Ahí empieza la preparación real para publicar.
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
