Por Lucas Yoris · Performate
Alucinaciones y APIs: por qué los scripts de carga redactados con IA aún necesitan validación
Alucinaciones de API en scripts k6 redactados con IA: modos de fallo comunes, cómo revisar paths y checks, y por qué los smoke tests ganan a ajustar prompts.
El script k6 generado por IA se ve perfecto—imports limpios, URLs plausibles, checks con nombres confiados. Escalas a cincuenta usuarios virtuales y descubres que el 40 % de requests golpea /v1/checkout cuando producción migró a /v2 hace tres sprints. Las alucinaciones en scripts de carga con IA rara vez son dramáticas; son drift de rutas mundano, checks silenciosos y suposiciones JSONPath que nunca fallan porque la aserción estaba mal.
Los modelos optimizan coherencia, no tu tabla de rutas. En esta guía verás las clases principales de alucinación en borradores k6, un flujo de validación estricto antes de escalar y cómo la coreografía smoke detecta endpoints bogus más rápido que solo afinar prompts.
Por qué fallan los borradores de IA aunque «se vean bien»
Si el modelo nunca vio tu spec privada, inventa. Si vio un export OpenAPI obsoleto, publica obsoleto con confianza.
- Drift de rutas:
/v1vs/v2, prefijos de microservicio omitidos, barras finales distintas. - Fantasía de auth: flujos de refresh que omiten cookies o headers que exige tu gateway.
- Suposiciones de correlación: extraer IDs de nombres de campo que no existen en JSON vivo.
- Checks silenciosos: aserciones que no pueden fallar—equivalentes a
check(true)disfrazados de validación.
Empareja estructura con tipos de escenarios k6 explicados; tasas de llegada incorrectas duelen tanto como URLs erróneas al escalar. Las funciones de modelo opcionales no verifican tu API—reformulan lo que les mostraste.
Cuándo prompts más largos no arreglan inputs malos
Actualiza extractos OpenAPI, exports de colección o k6 previo por release. Haz diff del output de IA contra la spec aprobada línea a línea en paths críticos—el enfoque de pruebas de contrato vs rendimiento evita que alucinaciones pasen como «probablemente bien».
Si rutas alucinadas golpean hosts admin internos o regiones inesperadas, trata la revisión como lección potencial de SSRF—allowlists de URL pertenecen a revisión humana, no solo a prompts.
Implementación práctica en k6: smoke adversarial antes de escalar
Trata cada llamada http generada por IA como culpable hasta que un smoke de 1 VU contra un entorno conocido demuestre inocencia.
Script de ejemplo (ilustrativo—no es una prueba lista para producción). Muestra helpers de validación y checks negativos que borradores de IA suelen omitir.
Qué demuestra este ejemplo:
- Paths alineados a spec: constantes desde variables de entorno que verificas contra OpenAPI antes del merge.
- Checks adversariales: campos de body requeridos por producto—no solo status 2xx.
- Sonda negativa en setup: auth inválida intencional una vez para probar que los checks fallan cuando deben.
- Coreografía smoke ordenada: auth → lectura → escritura antes de cualquier escenario con rampa.
import http from 'k6/http';
import { check, fail } from 'k6';
const BASE = __ENV.API_BASE || 'https://staging.example.com';
const CHECKOUT_PATH = __ENV.CHECKOUT_PATH || '/v2/checkout';
export const options = {
scenarios: {
smoke_validation: {
executor: 'shared-iterations',
vus: 1,
iterations: 3,
maxDuration: '2m',
tags: { phase: 'smoke' },
},
},
thresholds: {
http_req_failed: ['rate==0'],
checks: ['rate>0.99'],
},
};
export function setup() {
const bad = http.post(
`${BASE}${CHECKOUT_PATH}`,
JSON.stringify({ sku: 'SKU-100', qty: 1 }),
{
headers: { 'Content-Type': 'application/json', Authorization: 'Bearer invalid' },
tags: { phase: 'negative_probe' },
},
);
const negativeOk = check(bad, { 'bad auth not 2xx': (r) => r.status === 401 || r.status === 403 });
if (!negativeOk) {
fail('Checks may be silent—fix before scaling load');
}
return { token: __ENV.TOKEN };
}
export default function (data) {
const catalog = http.get(`${BASE}/catalog?page=1`, {
headers: { Authorization: `Bearer ${data.token}` },
tags: { route: 'catalog' },
});
check(catalog, {
'catalog 2xx': (r) => r.status >= 200 && r.status < 300,
'catalog has items array': (r) => Array.isArray(r.json('items')),
});
const checkout = http.post(
`${BASE}${CHECKOUT_PATH}`,
JSON.stringify({ sku: 'SKU-100', qty: 1 }),
{
headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${data.token}` },
tags: { route: 'checkout' },
},
);
check(checkout, {
'checkout 2xx': (r) => r.status >= 200 && r.status < 300,
'checkout orderId present': (r) => typeof r.json('orderId') === 'string',
});
}
Patrones que funcionan
- Diff línea a línea contra OpenAPI o export Postman para cada URL
httpdel borrador. - Orden smoke: solo auth → lectura → escrituras al final—detente pronto si fallan pasos (runbook depurar prueba de carga fallida).
- Rompe mock data una vez: elimina un campo requerido; los checks deben fallar.
- Baseline humana: compara output de IA con plantilla script k6 mínimo para APIs.
Antipatrones a evitar
- Saltarse smoke porque «el script se veía bien».
- Escalar antes de que sondas negativas prueben que los checks disparan.
- Dejar que modelos infieran paginación, claves de idempotencia o hostnames internos.
Pro tip (comando de ejemplo): logging verbose en smoke de 1 VU.
k6 run smoke-validate.js -e CHECKOUT_PATH=/v2/checkout --http-debug=full -e TOKEN=$STAGING_TOKEN
Qué demuestra este comando: trazas completas request/response exponen paths y headers erróneos antes de que la concurrencia los oculte en agregados.
Marco de decisión: cuándo rechazar vs corregir borradores de IA
| Situación | Acción recomendada |
|---|---|
| URL no está en spec/colección aprobada | Rechaza borrador; corrige doc fuente o re-prompt con export adjunto |
| Check pasa con data mala intencional | Bloquea merge; smoke adversarial falló |
| Flujo auth sin cookie/header del gateway | Parche humano; no escales hasta que cookie jar coincida con staging |
| ID dinámico desde campo JSON incorrecto | Corrige extracción; re-ejecuta 1 VU con bodies logueados |
| IA inventó URL admin o interna | Revisión seguridad; añade allowlist antes de cualquier corrida |
| Paths válidos, umbrales desconocidos | Pasa a smoke; calibra umbrales aparte (ejemplos umbrales k6) |
Rechaza el borrador si ninguna URL de journey crítico se traza al artefacto de release actual.
Corrige y re-smoke si los paths alinean pero checks o helpers de auth están incompletos.
Escala a seguridad si aparecen hosts, regiones o patrones SSRF inesperados—independiente de la calidad del prompt.
Observabilidad, documentación y próximos pasos
La validación solo perdura si es repetible entre releases.
- Adjunta SHA de OpenAPI/colección a cada PR de borrador IA—mismo identificador en smoke CI.
- Registra
CHECKOUT_PATHy base URL en metadata de corrida para auditoría. - Guarda logs de smoke 1 VU en revisiones fallidas para que el siguiente diff sea explícito.
- Añade ítem «validación pasada» antes de que escenarios de escala corran en Performate o CI.
- Empareja revisión de script con generación scripts k6 asistida IA seguridad upstream.
Cómo Performate simplifica la validación de scripts con IA
Abajo hay un ejemplo de flujo concreto para el path smoke checkout de este artículo.
Ejemplo: detectar alucinaciones antes de escalar
- Importa la colección Postman u OpenAPI actual como fuente de verdad—no snippets pegados del chat. Problema resuelto: borradores IA parten de rutas que el equipo ya aprobó.
- Genera o pega borrador IA en el editor solo tras sincronizar el import. Problema resuelto: menos paths inventados porque nombres de carpeta coinciden con requests reales.
- Ejecuta smoke 1 VU con logging verbose desde el runner de escritorio. Problema resuelto: URLs erróneas aparecen en el reporte integrado antes de tocar arrival rate.
- Añade checks adversariales en orderId y arrays de catálogo—como el ejemplo k6 arriba. Problema resuelto: checks silenciosos fallan en setup, no a 50 VUs.
- Diff k6 exportado contra la colección antes de promover a escenarios de carga. Problema resuelto: el drift es visible en control de versiones, no en conocimiento tribal.
- Promueve a escenario de carga solo tras smoke OK—mismos requests, executors más altos (Postman a k6 paso a paso si ese es tu camino de import).
Ese flujo corresponde al cta de este post: imports estilo Postman, corridas k6 y asistencia IA siguen siendo prácticos cuando la validación es obligatoria—no opcional.
Cierre
Las alucinaciones en scripts de carga con IA bajan cuando adjuntas specs, los smokes son obligatorios y los checks son adversariales—la ingeniería de prompts no sustituye eso. Haz diff de cada URL contra el artefacto del release, demuestra que los checks fallan con data mala, luego escala.
Pasa tu próximo borrador IA por smoke 1 VU con sonda negativa de auth antes de subir VUs—y rechaza cualquier path que no esté en el export aprobado de esta semana.
¿Listo para optimizar el rendimiento de tu API?
Descubre cómo Performate conecta flujos estilo Postman, k6 e insights asistidos por IA para que las pruebas de rendimiento sigan siendo prácticas para equipos reales.