Definir un proyecto: una IA que pregunta vale más que una IA que adivina

Un fundador resume el problema en una frase: cuando no da una especificación real, la herramienta diseña a su manera y él se pasa el tiempo corriendo detrás. Definir el proyecto mediante preguntas lo resuelve antes de la primera línea de código, siempre que alguien las haga.

La definición de un proyecto empieza por las preguntas que te hace la herramienta antes de suponer por ti. Un fundador lo cuenta en Reddit (r/vibecoding, junio de 2026): «Cuando no le doy una especificación real, diseña a su manera y me paso el tiempo corriendo detrás».

Lo que ocurre cuando la herramienta adivina

Una IA a la que describes «un software para gestionar mis clientes» no se queda bloqueada: elige. Decide que un cliente tiene nombre, correo y teléfono, que se elimina con un clic y que solo accede un usuario. Cada decisión es razonable por separado y ninguna viene de ti. Las descubres al usarlo, a menudo tres semanas después, cuando tu socia pregunta dónde fueron los clientes archivados. Las correcciones llegan entonces desordenadas, cada una sobre una base que nadie escribió, y la factura de rehacer supera la de construir. El mismo autor nombra su dificultad sin rodeos: su punto débil, escribe, es que no sabe escribir ese diseño inicial. El bloqueo está en ese documento, que la máquina produce encantada por sí sola cuando nadie se lo da.

Las preguntas que cambian el resultado

Una definición útil cabe en una docena de preguntas cortas, planteadas en un orden con sentido. «¿Quién usará este software, cuántas personas y con qué permisos?» «¿Qué ocurre cuando un expediente se cancela después del pago?» «¿Qué información debes poder encontrar dentro de dos años para una inspección?» «¿Qué te hará decir dentro de tres meses que el producto ha fracasado?» Te obligan a decidir mientras una decisión todavía cuesta una frase en lugar de una semana de rehacer trabajo. El vocabulario técnico queda fuera del asunto: respondes con las palabras de tu oficio, la herramienta traduce y la traducción se revisa. Una docena de respuestas escritas valen más que un documento de requisitos de treinta páginas copiado de una plantilla, porque cada una viene de ti. Desarrollamos este punto en otro artículo, cuando faltan las palabras exactas para describir tu idea.

Quién ya hace preguntas

El mercado empieza a hacerlo y algunos lo hacen bien. Replit abre sus proyectos con una definición seria, la mejor que hemos encontrado entre las herramientas que viven en un navegador, y lo escribimos sin reservas. Varios generadores ofrecen un modo donde el asistente presenta un plan antes de construir. El límite está en lo que ocurre después: el plan aparece en una conversación, se desplaza y nada garantiza que el código entregado se ajuste a él tres pantallas más adelante. Una pregunta hecha y después olvidada equivale a no haberla hecho.

El documento que te proponen, no el que te exigen

En Maestro, la primera agente se llama Margaux y su único trabajo consiste en definir el proyecto mediante preguntas. Ella pregunta, respondes en francés corriente y propone un brief que lees. Nada arranca hasta que digas «Me parece bien»: el documento es una propuesta, nunca un hecho asumido. Victor toma después el relevo para el documento de requisitos, con la misma puerta que cruzar. Esa inversión importa: la mayoría de los métodos te pide aportar un documento de requisitos que no sabes escribir, mientras un primer borrador propuesto se corrige en una hora. Cuidado con la trampa inversa, que le costó a un fundador nueve meses de proyecto (r/startups, julio de 2026): un documento validado no es un acuerdo si la gente asintió sin leerlo.

Hacer la prueba esta noche

Toma la herramienta que ya usas y, antes de describir tu idea, pídele que te haga diez preguntas sobre ella y espere tus respuestas. Anota las que no sabes responder: son tus verdaderas zonas de indefinición y se habrían rellenado por ti. Respóndelas fuera de la máquina, con tu socio o contable, y después vuelve. Si la herramienta continúa de todos modos con código sin esperar, sabes lo que te falta, y una hora de documento de requisitos te costará menos que tres semanas de correcciones. Guarda tus respuestas en un documento que releas en cada etapa: será el que decida el día en que dos personas de tu equipo recuerden la misma decisión de dos formas distintas.