Un buen prompt no garantiza una aplicación excelente por sí solo. La calidad depende de que las instrucciones describan qué problema resolver, para quién, cómo debe funcionar y cómo se comprobará el resultado. En proyectos grandes, conviene trabajar en etapas: primero definir y diseñar; luego implementar por partes; finalmente revisar y corregir.
1. Describe el producto antes que la tecnología
Empieza explicando el contexto y el objetivo:
- Qué es la aplicación: «Una plataforma para que pequeños restaurantes administren pedidos para llevar».
- Quién la usará: «Dueños y empleados con poca experiencia técnica».
- Qué problema resuelve: «Evitar pedidos perdidos en llamadas y mensajes».
- Qué acción principal debe facilitar: «Recibir, confirmar y actualizar pedidos».
- Qué queda fuera del alcance inicial: «No incluir entregas propias ni facturación electrónica».
Esto ayuda a que la IA tome decisiones coherentes en vez de añadir funciones por su cuenta.
2. Explica los flujos con ejemplos concretos
Las funciones vagas producen resultados vagos. En lugar de pedir «agrega inicio de sesión», especifica lo que debe ocurrir:
Un empleado ingresa su correo y contraseña. Si los datos son correctos, llega al panel de pedidos. Si son incorrectos, ve un mensaje claro sin que la aplicación revele si el correo existe. Debe poder solicitar un enlace para restablecer su contraseña.
Incluye, cuando corresponda:
- Qué inicia cada flujo.
- Qué datos ingresa la persona.
- Qué resultado espera.
- Qué pasa si hay errores, falta información o se pierde la conexión.
- Qué permisos necesita cada tipo de usuario.
3. Define cómo se reconocerá una entrega completa
Convierte expectativas en criterios observables. Por ejemplo:
- El usuario puede crear, editar y cancelar un pedido.
- Los pedidos se ordenan del más reciente al más antiguo.
- Un usuario no puede consultar pedidos de otro restaurante.
- El formulario explica qué campos faltan.
- La interfaz funciona con teclado y lector de pantalla.
Estos criterios sirven tanto para guiar la implementación como para revisar si quedó bien.
4. Da contexto técnico y límites
Si ya existen un proyecto o tecnologías elegidas, indícalos:
- Lenguaje, framework y versiones relevantes.
- Base de datos, proveedor de autenticación y servicios externos.
- Estructura actual del repositorio y convenciones del equipo.
- Dispositivos, navegadores o sistemas que se deben soportar.
- Límites de tiempo, presupuesto, rendimiento o compatibilidad.
Pide que la IA inspeccione el proyecto antes de proponer cambios y que respete sus patrones existentes. Si todavía no hay decisiones técnicas, pídele que proponga opciones y explique sus ventajas y costos antes de implementar.
5. Separa los requisitos comunes de los específicos de plataforma
Frontend web
Aclara:
- Qué páginas y rutas necesita la aplicación.
- Qué componentes se reutilizan.
- Cómo se adapta a móvil, tableta y escritorio.
- Qué estados debe mostrar cada pantalla: carga, vacío, error, éxito y acceso denegado.
- Cómo se manejan formularios, validación, navegación y permisos.
- Qué nivel de accesibilidad se espera.
Puedes pedir que siga WCAG 2.2 como referencia para accesibilidad web: teclado, foco visible, etiquetas, contraste, ampliación de texto y mensajes de estado. Referencia WCAG 2.2.
Backend y API
Especifica:
- Entidades y relaciones principales.
- Operaciones disponibles y quién puede ejecutarlas.
- Formato de entradas y respuestas, incluidos errores.
- Reglas de validación y consistencia de datos.
- Autenticación, autorización, auditoría y límites de solicitudes.
- Qué información es confidencial y cómo debe protegerse.
No basta con pedir «una API segura». Explica, por ejemplo, que cada operación debe comprobar que la persona tiene permiso sobre ese recurso específico, y no solo que inició sesión. OWASP destaca fallos de autorización, autenticación y consumo de recursos entre los riesgos importantes para APIs. OWASP API Security Top 10.
Aplicaciones móviles
Indica:
- Si será iOS, Android o ambas plataformas, y si usarás desarrollo nativo o multiplataforma.
- Versiones mínimas y tamaños de pantalla que hay que soportar.
- Qué debe funcionar sin conexión y qué datos se guardarán localmente.
- Cómo se manejan permisos, notificaciones y enlaces profundos.
- Qué pasa cuando el sistema suspende o cierra la aplicación.
- Reglas de diseño y accesibilidad propias de cada plataforma.
Para Android, la guía oficial recomienda separar responsabilidades, mantener los datos fuera de componentes de pantalla y adaptar la interfaz a distintos tamaños y cambios de configuración. Guía de arquitectura para Android. Para iOS, utiliza las Human Interface Guidelines de Apple como referencia de diseño y accesibilidad.
6. Pide una interfaz específica, no solo «moderna»
Describe la experiencia visual con referencias concretas:
- «Interfaz clara para uso frecuente en una cocina».
- «La lista de pedidos es la información principal».
- «Botones grandes y legibles en una tableta».
- «Usa colores para acompañar el texto, no como única señal del estado».
- «Incluye estados vacíos y mensajes de error útiles».
Si tienes diseños, capturas o una guía visual, adjúntalos y señala qué debe conservarse y qué puede cambiar. «Hazlo bonito» no define jerarquía, comportamiento ni identidad visual.
7. Pide arquitectura proporcional al problema
Indica el tamaño y la etapa del producto para evitar tanto una estructura improvisada como una complejidad innecesaria.
Para esta primera versión, mantén una arquitectura sencilla y modular. Separa la interfaz, las reglas del negocio y el acceso a datos. No introduzcas servicios distribuidos ni dependencias nuevas sin justificar por qué hacen falta.
Las guías oficiales de Android también aconsejan separar capas y responsabilidades para facilitar el mantenimiento y las pruebas. Ese principio es útil como orientación general, aunque la arquitectura adecuada depende de la plataforma y el producto. Arquitectura de apps Android.
8. Especifica cómo revisar el trabajo
Pide una entrega verificable:
- Qué comprobaciones ejecutar, como compilación, análisis estático o pruebas existentes.
- Qué recorridos principales revisar manualmente.
- Qué dispositivos, navegadores o tamaños de pantalla comprobar.
- Qué documentación actualizar.
- Qué resultado presentar: archivos modificados, decisiones tomadas, límites conocidos y pasos para ejecutar la aplicación.
Mejor pedir pruebas asociadas a criterios concretos que decir simplemente «asegúrate de que todo funcione». Si no quieres que se ejecuten pruebas o se modifiquen ciertos archivos, dilo explícitamente.
9. Trabaja en pasos pequeños
Para una aplicación completa, evita un único prompt del tipo «crea una app profesional». Divide el trabajo:
- Definir: resume el problema, usuarios, alcance y criterios de aceptación.
- Diseñar: propone pantallas, flujos, modelo de datos y arquitectura.
- Implementar: construye una función o recorrido completo cada vez.
- Revisar: compara lo hecho con los criterios, identifica fallos y corrígelos.
- Entregar: explica cómo ejecutar el proyecto y qué queda pendiente.
Si la IA tiene acceso al repositorio, puede empezar inspeccionando la estructura y los patrones existentes. Pide que informe cualquier incertidumbre que afecte decisiones importantes, en lugar de inventar requisitos.
Plantilla reutilizable
Actúa como [rol o especialidad]. Ayúdame a construir [tipo de aplicación].
## Producto
- Problema que resuelve:
- Usuarios principales:
- Objetivo de la primera versión:
- Fuera de alcance:
## Plataforma y contexto técnico
- Frontend:
- Backend/API:
- Móvil:
- Base de datos y servicios:
- Versiones, dispositivos y navegadores:
- Repositorio o convenciones existentes:
## Flujos y funciones
1. [Flujo descrito paso a paso]
2. [Flujo descrito paso a paso]
## Reglas del negocio y permisos
- [Regla]
- [Quién puede ver o cambiar cada dato]
- [Validaciones y errores esperados]
## Diseño y experiencia
- Prioridad de cada pantalla:
- Estilo o referencias:
- Requisitos responsive:
- Accesibilidad:
- Estados de carga, vacío, error y éxito:
## Requisitos de calidad
- Seguridad y privacidad:
- Rendimiento:
- Funcionamiento sin conexión:
- Arquitectura y límites de complejidad:
- Compatibilidad:
## Criterios de aceptación
- [Resultado comprobable]
- [Resultado comprobable]
## Forma de trabajo
Primero inspecciona el proyecto y resume el plan. Señala las decisiones importantes que falten.
Después implementa [función o etapa concreta], siguiendo los patrones existentes.
Al terminar, indica qué cambiaste, qué comprobaciones realizaste y qué limitaciones quedan.
No inventes requisitos ni añadas dependencias o funciones fuera del alcance sin explicarlo.La regla práctica
Escribe el prompt como una especificación breve: contexto, usuarios, flujos, restricciones y criterios de aceptación. Luego avanza función por función y revisa el resultado contra esos criterios.