Hay una tentación muy humana cuando tienes acceso a un agente que genera código: empezar cuanto antes. Describir la idea a grandes rasgos, darle al enter y ver qué sale. A veces funciona. Para un script sencillo, para un prototipo desechable, para explorar una idea. Pero para construir algo real, esa prisa tiene un precio.
El precio se llama retrabajo. Y con agentes, el retrabajo escala.
El agente no adivina, interpreta
Cuando un agente recibe una descripción vaga, no se detiene a pedir aclaraciones indefinidamente. Toma decisiones. Elige una arquitectura, un patrón, una estructura de datos. Lo hace con coherencia interna y con confianza. Y el resultado puede parecer razonable aunque esté completamente desalineado con lo que necesitabas.
El problema no es que el agente sea malo. Es que interpreta el silencio como libertad. Y donde no hay especificación, hay suposición.
Un PRD bien construido no es un trámite. Es el único mapa que tiene el agente para no perderse. Sin él, cada decisión que toma es una apuesta. Y las apuestas se acumulan.
Sin una fuente de verdad, el agente no alucina por error. Alucina por necesidad. Algo tiene que rellenar el hueco que dejaste.
Lo que pasa cuando no hay fuente de verdad
La ausencia de especificación no produce un error visible. Produce algo más peligroso: un resultado que parece correcto.
El agente genera pantallas que funcionan pero no siguen el sistema de diseño. Crea endpoints que responden pero no encajan con el contrato de la API existente. Implementa una lógica de negocio plausible que ignora una restricción corporativa que nadie le explicó. Todo compila. Todo tiene sentido interno. Y nada encaja con lo que el equipo necesitaba.
Esto ocurre igual con un Figma incompleto que con un PRD a medias. Si el prototipo no especifica los estados vacíos, los errores, los permisos por rol o los flujos alternativos, el agente los inventa. Si el documento de requisitos omite las restricciones técnicas, el contexto de negocio o las decisiones ya tomadas, el agente parte de cero en cada una de ellas.
La fuente de verdad no tiene que ser perfecta. Tiene que ser suficientemente completa para que las decisiones importantes no queden en manos del modelo.
Qué debe responder un PRD antes de que el agente empiece
No hace falta un documento de cien páginas. Hace falta que alguien se haya sentado a responder las preguntas que el agente no puede resolver solo:
¿Qué hay que construir y qué queda explícitamente fuera? ¿Qué restricciones técnicas aplican? ¿Qué decisiones de arquitectura ya están tomadas? ¿Cuáles son los flujos principales y los alternativos? ¿Qué reglas de negocio no son negociables? ¿Cómo se verifica que lo construido es correcto?
Cada pregunta sin respuesta en el PRD es una decisión que tomará el agente. A veces acertará. Muchas veces no. Y el coste de corregirlo después de que el código exista siempre es mayor que el de haberlo especificado antes.
El problema que nadie menciona
Hay un riesgo adicional que merece nombrarse, aunque incomode.
Cuando el agente genera el código y el desarrollador no tiene la formación suficiente para evaluarlo, el PRD deja de ser solo una guía para el agente: se convierte en la única red de seguridad del proceso. Si las especificaciones son concretas y los criterios de aceptación están bien definidos, al menos es posible verificar que el resultado hace lo que debía hacer. Si no lo están, no hay forma de saber si lo que se ha entregado es correcto, seguro o mantenible.
Tener una IA que genera código no equivale a saber evaluarlo. Y un resultado que parece funcionar no es lo mismo que un resultado que funciona bien. La diferencia entre ambos la ve quien tiene el conocimiento. El PRD es lo que permite que esa diferencia sea visible aunque quien revise no sea un experto.
Especificar es desarrollar
Hay una mentalidad extendida que trata la especificación como el paso previo al trabajo real. Como si escribir el PRD fuera el trámite que hay que completar antes de empezar a desarrollar de verdad.
Es exactamente al revés. Especificar es desarrollar. Es el momento en que se toman las decisiones más importantes: qué se construye, cómo se organiza, qué restricciones aplican, cómo se verifica. Todo lo que viene después —el código, los tests, la documentación— es la consecuencia de esas decisiones.
Con agentes, esto es más cierto que nunca. La calidad del output depende directamente de la calidad del input. Y el input más valioso no es el prompt: es el contexto que hay detrás de él.
El agente ejecuta. Tú decides. Pero para decidir bien, primero hay que pensar bien. Y pensar bien, en desarrollo, se llama especificar.
