El enfoque con OpenAPI y prism es sólido, pero el pipeline extra que mencionas es precisamente donde muchas empresas se quedan: montan la validación, ven que falla constantemente por alucinaciones, y acaban desactivándola. La clave no es solo detectar el error, sino cerrar el bucle: que la IA reciba el feedback del fallo y regenere. Yo he usado un script que captura el error de prism y se lo pasa a un modelo con un prompt del tipo "Corrige este fragmento de spec para que pase la validación, sin inventar endpoints nuevos". Reduce mucho el ruido, aunque no lo elimina.
Sobre la comparación ASM/C, tienes razón en que es tramposa, pero por otra razón: el compilador no tiene incentivo en que confíes en él. La IA sí, porque está entrenada para sonar segura. Eso es lo que rompe el sesgo de automatización. No es que revises menos por vago, es que el output está diseñado para parecer correcto. La solución no es solo disciplina individual, es fricción deliberada: que el merge requiera un comentario explicando qué parte del código generado has validado y cómo. Si eso se convierte en un checkbox más, vuelves al mismo problema.
¿Habéis medido el coste real de ese esfuerzo extra? En mi equipo hicimos un experimento informal: con revisión línea a línea, la velocidad de entrega bajó un 15% en tareas pequeñas, pero los bugs en producción relacionados con APIs bajaron un 40%. El ROI está ahí, pero tarda en verse y los managers suelen mirar solo el primer número.
