Patrones de prompts para crear mejores apps con Coderblock

Un buen prompt para Coderblock no tiene por qué parecer una especificación técnica. No necesitas hablar de frameworks, bases de datos, API ni arquitectura. Basta con describir lo que quieres crear y dejar que los agentes de IA conviertan la idea en una app full stack real con React, TypeScript, Tailwind CSS, autenticación y, cuando sea necesario, una base de datos Postgres.

Sin embargo, eso no significa que todos los prompts funcionen igual de bien.

Cuanto más claro sea el contexto que proporciones, más fácil será para el agente tomar decisiones útiles por ti. Un buen prompt no describe cada detalle de la implementación: aclara qué estás creando, para quién, cómo debería funcionar y qué reglas deben respetarse.

A partir de ahí, puedes dejar que Coderblock se encargue del resto. Estos son algunos patrones que puedes utilizar para obtener mejores resultados y hacer que las iteraciones sean más eficaces.

Empieza por el producto, el usuario y el resultado

Un prompt como «Crea un dashboard» o «Crea una app de reservas» puede bastar para empezar, pero deja muchas preguntas sin responder. ¿Quién utilizará la app? ¿Qué debe poder hacer? ¿Cuál es el resultado más importante que quieres conseguir?

Una forma sencilla de proporcionar al agente el contexto adecuado es empezar por tres elementos:

• Producto: ¿qué tipo de app estás creando?
• Usuario: ¿quién la utilizará?
• Resultado: ¿qué debe poder conseguir?

Por ejemplo:

Crea una plataforma de reservas para entrenadores personales independientes. Los entrenadores deben poder publicar sus sesiones disponibles, mientras que los clientes deben poder consultar los horarios, crear una cuenta y reservar una franja horaria. Incluye un dashboard para que los entrenadores gestionen las próximas reservas.

Con esta información, el agente ya dispone de un modelo concreto del producto. Puede deducir las pantallas principales, los roles, las entidades de la base de datos y la navegación sin que tengas que especificar rutas ni esquemas.

Si partes de una de las plantillas de Coderblock, puedes utilizar el mismo enfoque para explicar qué quieres cambiar o añadir. La plantilla es el punto de partida: tu idea se construye sobre esa estructura.

Describe flujos, no funcionalidades aisladas

Una lista de funcionalidades indica qué debe incluirse. Un flujo explica cómo debería funcionar todo en conjunto. En lugar de escribir «añade autenticación, perfiles, reservas y correos electrónicos», describe qué ocurre cuando una persona utiliza el producto.

Prueba así:

Un visitante nuevo debe poder consultar los perfiles de los entrenadores sin iniciar sesión. Cuando elija una sesión, pídele que se registre o inicie sesión, confirme la reserva y muéstrala después en la sección Mis reservas. Los entrenadores solo deben ver las reservas correspondientes a sus propias sesiones.

Ahora el agente conoce el recorrido del usuario: qué es público, cuándo es necesario autenticarse, qué ocurre después de reservar y qué datos puede ver cada rol.

A partir de estas indicaciones, puede configurar Supabase Auth, rutas protegidas, sesiones, tablas y Row Level Security según el comportamiento que hayas descrito. Por tanto, no necesitas solicitar una lógica JWT personalizada, el hash de las contraseñas ni una tabla independiente para guardarlas. Es más útil indicar quién debe poder acceder a qué y dejar que Coderblock elija la implementación necesaria.

Separa lo esencial de las preferencias

No todas las decisiones tienen la misma importancia. Un buen prompt puede distinguir claramente entre lo que la app debe hacer obligatoriamente y lo que el agente puede interpretar.

Por ejemplo:

Requisitos esenciales: acceso para clientes, perfiles de entrenadores, disponibilidad, reservas y vistas separadas para clientes y entrenadores. Preferencias visuales: diseño editorial y relajado, colores neutros y cálidos, espacios amplios y animaciones mínimas. El agente de UX puede decidir el diseño exacto de las tarjetas.

De este modo, las funcionalidades fundamentales siguen siendo obligatorias, mientras dejas que los agentes del Agent Team tomen decisiones sobre el diseño y la UX.

Las restricciones también pueden resultar muy útiles. Por ejemplo:

• Enfoque mobile-first o desktop-first
• Páginas públicas o accesibles solo después de autenticarse
• Roles de usuario necesarios
• Moneda e intervalo de facturación
• Datos que deben permanecer privados para cada usuario
• Acciones reservadas a los administradores

La regla es sencilla: especifica el comportamiento, no necesariamente cómo debe implementarse.

Describe los datos mediante relaciones

Al crear una app, no tienes por qué pensar en términos de tablas y migraciones.

Es mucho más natural describir las relaciones que existen en el mundo real.

Coderblock asigna a las apps web estándar un proyecto específico de Supabase, con Postgres y Row Level Security. Por tanto, puedes explicar cómo deben organizarse los datos sin escribir manualmente el esquema de la base de datos.

Por ejemplo:

Cada entrenador puede crear varios tipos de sesión. Un tipo de sesión incluye duración, precio y descripción. Las franjas horarias disponibles pertenecen a un entrenador y pueden tener como máximo una reserva confirmada. Los clientes solo deben ver sus propias reservas, mientras que los entrenadores deben ver las correspondientes a sus franjas horarias.

En comparación con un simple «añade una tabla de reservas», esta descripción proporciona al agente mucha más información: qué entidades existen, cómo están relacionadas, qué restricciones deben cumplir y quién puede acceder a los datos.

Si el producto evoluciona, sigue describiendo los cambios desde el punto de vista del comportamiento:

Añade a las reservas el motivo de la cancelación y la fecha y hora en que se produjo. Los clientes pueden cancelar hasta 24 horas antes de una sesión, pero solo los entrenadores pueden marcar una reserva como completada.

De este modo, el agente puede actualizar la estructura existente sin tener que reconstruir la app desde cero.

Un cambio cada vez. Y siempre verificable.

Una de las características más útiles de la vista previa en directo de Coderblock es la posibilidad de ver rápidamente el efecto de cada cambio. Por eso, después de la primera generación, conviene continuar con solicitudes específicas y concretas en lugar de reescribir todo el briefing cada vez.

Por ejemplo:

Fija la barra de navegación en la versión de escritorio, pero mantén el encabezado compacto en dispositivos móviles.

En el dashboard del entrenador, muestra las sesiones de hoy antes del calendario semanal.

Añade un estado vacío a la sección Mis reservas, con un botón para volver a la búsqueda de entrenadores.

Cada solicitud produce un resultado concreto que puedes comprobar inmediatamente en la vista previa. Así resulta más fácil entender qué ha funcionado, qué debe corregirse y cuál debería ser el siguiente paso.

Para cambios más amplios, también puedes pedir al agente que proceda por fases:

Primero añade los roles de entrenador y las rutas protegidas para entrenadores. Después crea el editor de disponibilidad. Por último, conecta las franjas horarias disponibles con el flujo de reservas de los clientes.

De este modo, incluso una funcionalidad compleja se convierte en una secuencia de pasos fáciles de verificar.

No olvides los estados ni los casos límite

Una app no solo existe en su happy path. ¿Qué ve un usuario que todavía no tiene reservas? ¿Qué ocurre si falla un pago? ¿Y si una franja horaria deja de estar disponible? ¿Qué ve un usuario que intenta acceder a una sección restringida?

Puedes describir estos escenarios directamente en los prompts:

• «Muestra un estado vacío útil cuando el usuario no tenga reservas».
• «Desactiva las franjas horarias no disponibles y explica por qué no pueden seleccionarse».
• «Muestra un indicador de carga mientras se envía la reserva».
• «Si un usuario que no es administrador abre la ruta de administración, redirígelo de forma segura».
• «Utiliza mensajes de validación específicos y colócalos junto a los campos correspondientes».

Son pequeños detalles, pero marcan una gran diferencia entre un prototipo que funciona y un producto que realmente parece listo para usarse. También puedes pedir a los agentes especializados en UX o seguridad que analicen un flujo existente y sugieran o apliquen mejoras.

Cuando añadas pagos, describe la regla comercial

Para integrar pagos, no necesitas explicar cómo funciona Stripe. Debes explicar qué estás vendiendo y qué ocurre después del pago. Indica al menos:

• producto o servicio
• precio
• moneda
• modelo de facturación
• funcionalidades disponibles después de la compra

Por ejemplo:

Permite que los clientes se suscriban por 9,99 € al mes. Los suscriptores pueden reservar sesiones prémium, gestionar la suscripción desde su cuenta y consultar el estado actual de la facturación. Empieza en el modo de prueba de Stripe.

En el modo gestionado predeterminado, el agente puede crear una cuenta gestionada de Stripe después de solicitarte algunos datos básicos, como el país y el nombre de la empresa. Después puede configurar productos, precios, el checkout y los webhooks, mientras que la configuración para recibir pagos puede completarse más adelante mediante el enlace de incorporación alojado por Stripe.

Si prefieres utilizar tu propia cuenta de Stripe, puedes solicitar el modo BYOK. El agente pedirá STRIPE_SECRET_KEY mediante un prompt seguro para variables de entorno y configurará automáticamente el webhook.

Los secretos permanecen en el servidor y no se incluyen ni en el chat ni en el código generado.

Termina con un prompt de revisión

Antes de publicar, puedes pedir a los agentes que hagan una última revisión de toda la experiencia. Por ejemplo:

Revisa la app desde la perspectiva de un cliente que la utiliza por primera vez, un entrenador y un administrador. Comprueba la navegación, la usabilidad en dispositivos móviles, los permisos, los estados vacíos y todo el flujo de reserva. Corrige los problemas evidentes sin cambiar la dirección visual.

Este tipo de prompt funciona porque define a quién debe simularse, qué debe comprobarse y qué límites deben respetarse. Después de revisar la vista previa, puedes utilizar Publicar para desplegar la app en su correspondiente dirección coderblock.app o conectar un dominio personalizado desde Configuración → Dominios.

El mejor prompt es el que deja espacio a la IA

No necesitas escribir prompts larguísimos para obtener buenos resultados con Coderblock. Debes proporcionar al agente la información que realmente importa: quién utilizará el producto, qué debe poder hacer, cómo deben funcionar los flujos, qué datos deben estar relacionados, qué reglas no pueden incumplirse y qué debe ocurrir en los distintos escenarios.

El resto puede construirse mediante iteraciones. Empieza con un briefing claro. Observa qué se genera. Prueba la app. Después continúa con solicitudes pequeñas, concretas y verificables.

Esa es la verdadera ventaja de trabajar con un agente de programación con IA: no necesitas saber de antemano cómo crear el producto. Necesitas saber qué quieres crear.