# Prototipar con IA: cuándo acelera el trabajo y cuándo engaña > Prototipar con IA es rápido, pero una demo que funciona no prueba que la idea sea buena. Qué prototipos conviene hacer con IA y cómo evitar el engaño. *Tags: ia, prototipos, ux-para-ia, vibe-coding* --- > [!info] Definición Rápida > **Prototipar con IA** es crear un prototipo funcional describiendo lo que quieres a una herramienta de generación de código o de diseño, en lugar de construir cada pantalla a mano. Acelera la exploración, pero no reemplaza la prueba con personas. ## ¿Qué cambia cuando el prototipo lo genera la IA? Antes, un prototipo navegable requería semanas de trabajo con una herramienta de diseño y, a menudo, ayuda de un desarrollador. Hoy, una persona puede describir un flujo y tener una versión clicable en una tarde. Lo que cambia no es solo la velocidad: cambia quién puede explorar. Un diseñador puede probar cinco variantes de un flujo antes de pedir una revisión. El riesgo también cambia. Un prototipo a mano suele verse como borrador, y el equipo lo trata como tal. Un prototipo generado puede verse pulido desde el primer día, y eso le da más peso del que merece. ## ¿Cuánto ahorra realmente? La evidencia es todavía escasa, así que conviene leerla con cuidado: - **Una encuesta de UX Tools (informe de primavera de 2026)**, con 1.478 respuestas de 18 regiones, encontró que 43,8% de los diseñadores pasa más de la mitad de su tiempo haciendo vibe coding. Mide uso, no ahorro de tiempo ni calidad ([UX Tools, estado del prototipado en 2026](https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026)). - **Una lección de desarrollo de software.** Un ensayo de METR publicado en julio de 2025, con 16 desarrolladores experimentados y 246 issues reales, encontró que con las herramientas de IA de principios de 2025 tardaban 19% más, aunque creían haber ido 20% más rápido. No es un estudio de diseñadores, y METR marca esos resultados como desactualizados: en febrero de 2026 publicó datos nuevos, pero los considera poco fiables porque muchos desarrolladores se negaron a trabajar sin IA ([METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/); [METR, actualización de febrero de 2026](https://metr.org/blog/2026-02-24-uplift-update/)). Lo que sigue en pie es la advertencia: la sensación de velocidad no es una medición. Como la evidencia es escasa y cambia rápido, no le prometas a nadie un porcentaje de ahorro. La calidad de la interacción sigue necesitando revisión humana. Mide tu propio proceso: cuánto tardas en un prototipo y cuánto en corregirlo. ## ¿Qué prototipos conviene hacer con IA? | Tipo de prototipo | ¿Conviene con IA? | Por qué | |---|---|---| | Probar si un flujo tiene sentido | Sí | Se descarta fácil y se itera rápido | | Mostrar una idea a stakeholders | Sí | Basta con que se entienda | | Probar microinteracciones o timing | Con cuidado | Requiere ajuste fino a mano | | Validar accesibilidad o contraste | No solo con IA | Necesita revisión con herramientas y personas | | Base de un producto real | No sin ingeniería | Ver [[que-es-vibe-coding\|qué es vibe coding]] | ## ¿Qué hace que el prototipo sea útil? La calidad del prototipo depende mucho de la descripción. Una guía de Kasava muestra prompts con valores concretos (colores, tipografías, espaciados), estados de interacción y puntos de quiebre para cada pantalla, y con el generador usando los componentes que ya existen en el proyecto. Advierte que un prompt vago "funciona técnicamente", pero produce un prototipo genérico, y que cada iteración gasta tiempo y puede romper cosas que ya funcionaban ([Kasava, sobre prompts para prototipos](https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt)). ## ¿Cómo evitar que la demo engañe? Tres prácticas simples: 1. **Define la pregunta antes de construir.** "¿Entienden cómo cancelar una cita en menos de tres pasos?" es una pregunta que el prototipo puede responder. "Ver si gusta" no lo es. 2. **Prueba con personas, no con el equipo.** Quien no conoce el producto encuentra problemas que el equipo ya no ve. Según Jakob Nielsen, cinco participantes detectan cerca de 85% de los problemas de usabilidad en una primera ronda, y recomienda varias rondas pequeñas en vez de una grande ([Nielsen Norman Group](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/)). 3. **Etiqueta lo que es prototipo.** Un banner que diga "Prototipo, datos de prueba" evita que alguien confunda la demo con un producto. Si el prototipo pasa a ser la base de un producto, el paso siguiente es una especificación y revisión de código, como describe [[spec-driven-development|spec-driven development]]. ## Ejemplo Ejemplo ilustrativo: un equipo quiere saber si los clientes de una clínica entienden un flujo de pago en tres pasos. Un diseñador genera un prototipo con IA en una tarde: tres pantallas con datos ficticios. Se prueba con seis personas. Cuatro se pierden en el paso de confirmación porque el botón dice "Procesar" en vez de "Pagar". El equipo cambia el texto, prueba de nuevo con otras cuatro personas y lo mantiene. El prototipo costó una tarde; la prueba dio la respuesta. ## ¿Cómo aplicarlo mañana? 1. Escribe la pregunta que quieres responder con el prototipo en una frase. Si no cabe en una frase, divide el prototipo en dos. 2. Describe la pantalla con valores concretos (colores, espaciados, estados) y apunta a los componentes que ya existen en el proyecto. 3. Consigue cinco personas que nunca hayan visto el producto y prueba el flujo en menos de media hora por persona. 4. Anota el tiempo total del prototipo, incluidas las correcciones. Con dos o tres prototipos tendrás tu propia medida, más confiable que cualquier promedio de la industria. Después de la prueba, decide en una frase qué cambia en el producto. Si nada cambia, el prototipo cumplió su trabajo de todos modos. Guarda cada prototipo con su pregunta y su resultado en una línea, aunque lo descartes. Pasados unos meses, ese registro te dice qué tipo de preguntas respondieron bien los prototipos y cuáles no. Si el prototipo se convierte en producto, el paso siguiente está en [[de-idea-a-app-en-un-dia|de idea a app en un día]], con sus límites. ## Errores comunes - Mostrar un prototipo generado como si fuera un producto final. - Medir el ahorro de tiempo solo por la sensación de rapidez. - Probar solo con el equipo que construyó el prototipo. - Dejar datos reales o credenciales en una demo pública. - No definir qué pregunta responde el prototipo. - Usar la IA para validar detalles de accesibilidad sin revisión humana. ## Fuentes - UX Tools, "This is the state of prototyping in 2026": [https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026](https://www.uxtools.co/blog/this-is-the-state-of-prototyping-in-2026) - Kasava, "Your AI prototype is only as good as your prompt": [https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt](https://www.kasava.dev/blog/your-ai-prototype-is-only-as-good-as-your-prompt) - METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (julio de 2025): [https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) - METR, actualización de la productividad con IA de finales de 2025 (24 de febrero de 2026): [https://metr.org/blog/2026-02-24-uplift-update/](https://metr.org/blog/2026-02-24-uplift-update/) - Nielsen Norman Group, "Why You Only Need to Test with 5 Users" (2000): [https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) --- Source: https://www.fernandoux.com/es/wiki/ia/prototipar-con-ia/