Cuatro. Ahí es, aproximadamente, donde un build pasa por primera vez su propia verificación y produce algo que realmente funciona —una página funcional, un endpoint funcional, un flujo de inicio de sesión que efectivamente inicia sesión. Once es el número mediano de prompts que acumula un build para cuando alguien lo da por terminado y lo despliega. Sesenta y ocho por ciento es la proporción de todos los prompts enviados después de esa primera versión funcional que no cambia nada que un usuario notaría en la lógica subyacente. Y treinta es donde la mayoría de la gente se detiene en silencio, no porque el producto esté terminado, sino porque se les acabó lo que decir sobre él.
Esas cuatro cifras describen la misma forma una y otra vez: los builds se vuelven funcionales rápido, y luego pasan la mayor parte de su vida restante siendo comentados en lugar de reconstruidos.
El muro no está donde lo esperarías
Si me hubieras preguntado, antes de empezar a prestar atención, dónde se atascan los creadores, habría dicho que en las integraciones —proveedores de pago, callbacks de autenticación, la API de SMS que necesita un remitente verificado. Esos son puntos de fricción reales, pero no es ahí donde se dispara el número de prompts. Normalmente cuestan uno o dos turnos extra y luego se resuelven.
El muro aparece después, una vez que la cosa funciona. Un build llega a su primer pase de verificación limpio —las páginas se renderizan, el flujo principal corre de punta a punta, nada arroja errores— y en lugar de detenerse, los prompts siguen llegando. "Haz el encabezado más grande." "Prueba con otro color de acento." "¿Puede el botón ser un poco más redondeado?" "En realidad vuelve a la primera versión de eso." Ninguno de estos toca un modelo de datos, una ruta o un control de permisos. Todos son superficiales.
Por qué "terminado" no se siente como un punto de parada
Parte de esto es simplemente cómo se siente la iteración desde dentro. Cuando un build está roto, sabes exactamente qué pedir —arreglar el error, agregar el campo faltante, conectar lo que no está conectado. Cuando funciona, el objetivo desaparece. No hay ningún mensaje de error que te diga que el tono de azul está mal. Ahora estás tomando decisiones de gusto sin una verdad de referencia, y las decisiones de gusto son infinitamente revisables de una manera que los errores no lo son.
La otra parte es que enviar un prompt es barato e instantáneo, así que el costo de "probar una cosa más" se redondea a cero en el momento, aunque no sea cero en conjunto. Una docena de pases cosméticos de un par de minutos cada uno es una tarde entera de verdad, pero ningún prompt individual de esa docena se sintió lo suficientemente costoso como para omitirlo.
Qué cambian realmente los prompts tardíos
| Rango de prompts | Objetivo típico | ¿Diferencia funcional? |
|---|---|---|
| 1–4 | Páginas principales, modelo de datos, flujo primario | Sí —aquí es donde se construye el producto |
| 5–7 | Casos límite, estados de error, campos faltantes | Normalmente sí —brechas reales descubiertas durante el uso |
| 8–15 | Diseño, texto, color, espaciado, tono | Rara vez |
| 16+ | Revertir o volver a intentar elecciones estéticas anteriores | Casi nunca |
Esa tercera fila es la que vale la pena analizar. No es que el pulido estético sea una pérdida de tiempo — un build que se ve genérico rendirá peor que uno que no lo es, y la fase de diseño importa. Es que el pulido rara vez necesita de ocho a quince prompts separados para lograrse, y la razón por la que toma tantos suele ser la indecisión, no la iteración. No estás convergiendo hacia una mejor respuesta después del prompt once; estás oscilando entre dos respuestas que ya habías generado en el prompt nueve.
Vi a alguien pasar cuarenta minutos moviendo un botón de llamada a la acción entre tres posiciones en una landing page, decidir en el prompt catorce que la primera posición era la mejor, y pedirle al agente de build que lo devolviera. El agente no hizo nada mal en ninguno de esos turnos. Simplemente el botón nunca necesitó catorce opiniones.
Lo que realmente te dice la diferencia entre veinte y treinta
Aquí está la parte que más me sorprendió: los builds que se detienen alrededor del prompt once y los que superan los treinta no resultan significativamente distintos en calidad. Busqué el beneficio — seguramente más iteración significa un producto más pulido — y en su mayoría no lo encontré. Lo que encontré en cambio fue que quienes se detienen antes tienden a haber tomado sus decisiones de estilo una sola vez, desde el principio, en el propio prompt ("limpio, minimalista, un solo color de acento, sin fotos de stock") en lugar de descubrir su estilo a través de veinte rondas de prueba y error después del hecho.
Los builds que duraron más no eran más ambiciosos. Eran aquellos en los que el prompt original dejaba más cosas sin decidir — sin tono, sin punto de referencia, sin público declarado — así que cada vacío se llenaba de a un pequeño prompt a la vez en lugar de una sola vez, por escrito, antes de la primera ejecución.
La conclusión práctica
Si ya llevas cuatro o cinco prompts y las cosas funcionan, eso no es un punto de control — es la mayor parte del trabajo real hecho. Lo que queda es real pero pequeño: revisar los casos límite que nadie pensó en describir, verificar el texto y hacer una pasada deliberada sobre el tono visual en lugar de una docena exploratorias. Y si te das cuenta de que en el prompt veinte sigues ajustando un border-radius, eso no significa que el build esté inconcluso. Suele ser una señal de que el prompt anterior debería haber dicho lo que querías desde el principio, y la solución pertenece al mensaje inicial del próximo build, no al prompt cuarenta de este.
