Método PRP:instruye a Claude para que construya bien

Un Product Requirement Prompt —un PRP— es un documento corto que escribes antes de pedirle a Claude que construya una funcionalidad. El método PRP: cuatro secciones, unas trescientas palabras, veinte minutos para escribirlo, y convierte dos días de depuración en entre una y tres horas de implementación limpia. Es el hábito de mayor impacto en la construcción asistida por IA, y casi nadie que empieza lo usa.

«Claude, hazme un flujo de registro» parece progreso. No lo es. Este artículo te da el método, las cuatro secciones y un PRP real de mi propio producto, palabra por palabra, para que puedas copiar la estructura esta noche.

¿Qué es el método PRP?

La IA no sustituye el pensamiento. La IA sustituye el tecleo. El tecleo nunca fue la limitación: lo fue el diseño de lo que estás tecleando. Cuando le das a Claude una instrucción vaga, rellena cada hueco con suposiciones: qué tabla de la base de datos usar, cómo está estructurada tu app, qué significa «terminado». Algunas de esas suposiciones serán erróneas, y las pagarás en horas de depuración que no te puedes permitir en tardes y fines de semana.

Un PRP cierra los huecos antes de empezar a construir. No es opcional. La diferencia entre «Claude, hazme un flujo de registro» y un PRP bien estructurado es la diferencia entre dos días depurando basura y veinte minutos de implementación limpia.

Las cuatro secciones de un PRP

Objetivo. Qué estás construyendo, en una frase. «Construir un flujo de registro que cree un usuario, cree una empresa, los vincule y envíe un correo de bienvenida.»

Contexto. Todo lo que Claude necesita saber y no puede deducir: el esquema de tu base de datos, tu proveedor de autenticación, tu servicio de correo, tu framework de frontend, los patrones existentes en tu código, enlaces a la documentación relevante. Cuanto más contexto aportes, menos alucina Claude y más se acerca el resultado a calidad de producción.

Plan de implementación. Un esquema paso a paso de lo que debe hacer la funcionalidad. No código real —eso es trabajo de Claude—, pero sí estructura suficiente para que Claude no se pierda. Te obliga a pensar la funcionalidad antes de delegarla y le da a Claude raíles sobre los que construir.

Bucle de validación. Cómo sabrás que la funcionalidad funciona: los casos de prueba que ejecutarás, los casos límite que hay que contemplar. Claude también puede escribir las pruebas, pero tú tienes que especificar qué probar antes de que Claude las escriba, o probará las cosas equivocadas.

Un PRP real, palabra por palabra

Así era uno de una funcionalidad que construí en FIKR Space: una sencilla página de preferencias de notificaciones por correo:

Objetivo: Construir una página de preferencias de notificaciones donde los usuarios con sesión iniciada puedan elegir qué tipos de notificaciones por correo reciben: resumen semanal, novedades del producto, alertas de seguridad. Guardar las preferencias en el registro del usuario. Por defecto, todo activado.

Contexto:

• Stack: React, TypeScript, Supabase, Tailwind.
• La tabla users existente tiene las columnas id, email, created_at. Hay que añadir una columna JSON notification_preferences con la forma { digest: bool, updates: bool, security: bool }.
• El contexto de autenticación ya proporciona el usuario actual mediante el hook useAuth() en /hooks/useAuth.ts.
• La página vive en /settings/notifications. El enrutamiento ya está configurado.
• Seguir el patrón de la página de ajustes existente en /pages/settings/profile.tsx para el diseño y el estilo del formulario.

Plan de implementación:

1. Añadir la columna JSON notification_preferences a la tabla users mediante una migración de Supabase. Valor por defecto: los tres en true.
2. Crear el componente de página en /pages/settings/notifications.tsx.
3. Al montarse, cargar desde Supabase las preferencias del usuario actual.
4. Renderizar tres interruptores con el componente existente <Switch>.
5. Al cambiar un interruptor, aplicar un debounce de 500 ms y luego guardar en Supabase.
6. Mostrar una notificación toast si el guardado funciona o falla.
7. Gestionar el estado de carga mientras la consulta inicial está en curso.

Bucle de validación:

• Iniciar sesión. Ir a /settings/notifications. Los tres interruptores deben aparecer activados.
• Desactivar uno. Refrescar la página. El interruptor debe seguir desactivado.
• Desconectar la red. Cambiar un interruptor. Debe verse el toast de error.
• Reconectar. Volver a cambiarlo. Debe guardarse y mostrar el toast de éxito.

Son unas trescientas palabras. Claude genera la implementación en menos de diez minutos. Tiempo total desde «quiero esta funcionalidad» hasta «está en producción»: quizá noventa minutos, incluyendo escribir el PRP, generar el código, probar a mano y desplegar.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Qué pasa sin un PRP

Compáralo con la misma funcionalidad sin él. Escribes «hazme una página de preferencias de notificaciones» en Claude. Produce algo. Ese algo no sabe qué tabla de la base de datos usar, así que se inventa una. No conoce tu biblioteca de componentes, así que genera componentes nuevos que no se parecen al resto de la app. No conoce tus convenciones de guardado, así que guarda con cada pulsación de tecla. Pasas dos horas reescribiendo casi todo lo que te dio para adaptarlo a tu código. La funcionalidad sale en medio día en lugar de en hora y media, y el código que te queda es un cincuenta por ciento tuyo y un cincuenta por ciento de las conjeturas de Claude, cosidas entre sí.

Por qué el PRP parece pesado, y por qué lo escribes igualmente

El método PRP parece pesado al empezar. Parece más trabajo que teclear en Claude y esperar lo mejor. La primera vez que te saltes uno y Claude genere mil quinientas líneas que tengas que tirar, lo entenderás. Veinte minutos de escritura te ahorran entre cuatro y ocho horas de limpieza por funcionalidad, y a lo largo de una construcción completa eso se acumula hasta marcar la diferencia entre lanzar en ocho semanas y lanzar en veinte.

Teclear en Claude y esperar lo mejor tiene nombre y un final predecible; ya he escrito aparte sobre la trampa del vibe coding. La versión corta: la velocidad sin estructura parece progreso justo hasta que deja de serlo. El PRP es cómo conservas la velocidad y te saltas el colapso.

Y fíjate en lo que el PRP te impone sin hacer ruido: pensar. Escribir el plan de implementación significa recorrer la funcionalidad paso a paso antes de que exista código. Escribir el bucle de validación significa decidir qué significa «funciona» antes de ver algo que lo parezca. Ese pensamiento es tu trabajo: es la parte que la IA no puede hacer, y la que el marco BUILD entrena de forma deliberada.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Qué es un Product Requirement Prompt (PRP)?

Un PRP es un documento corto que escribes antes de pedirle a la IA que construya una funcionalidad. Tiene cuatro secciones —objetivo, contexto, plan de implementación y bucle de validación— y su función es eliminar las suposiciones que Claude haría de otro modo sobre tu base de datos, tus convenciones y qué significa «terminado».

¿Cuánto debe durar un PRP?

Unas trescientas palabras para una funcionalidad mediana, que se escriben en unos veinte minutos. Con eso obtienes una funcionalidad operativa en una a tres horas de construcción, en lugar de esas mismas horas más dos días de depuración encima.

¿Necesito ser técnico para escribir un PRP?

No. El plan es un paso a paso en lenguaje llano, no código: «comprobar si el correo ya existe, crear el usuario, enviar el correo de bienvenida». Describes qué debe ocurrir y cómo lo verificarás; Claude se ocupa de la implementación. Conocer a fondo tu producto importa mucho más que conocer la sintaxis.

¿Cuánto tiempo ahorra realmente el método PRP?

Entre cuatro y ocho horas de limpieza por funcionalidad. En una construcción de ocho semanas con una funcionalidad importante por semana, eso se acumula hasta lanzar en ocho semanas en lugar de veinte: las mismas herramientas, la misma IA, otra disciplina.