🧠 Cómo escribir prompts para desarrollar productos con ChatGPT sin desperdiciar tokens
Trabajar con un modelo de IA no consiste en hacer preguntas inteligentes, sino en darle el contexto correcto para que pueda tomar decisiones similares a las que tomaría un miembro experimentado del equipo.
Uno de los errores más frecuentes es tratar a ChatGPT como un buscador. Se envía una frase corta, se obtiene una respuesta genérica, luego aparecen nuevas preguntas y termina existiendo una conversación de decenas de mensajes que consume miles de tokens para llegar a algo que pudo resolverse desde el primer prompt.
La diferencia entre un resultado mediocre y uno realmente útil casi siempre está en la calidad de las instrucciones.
Cuando el objetivo es desarrollar un producto completo —una API, un panel administrativo, una aplicación móvil o una plataforma SaaS— el prompt debe funcionar como un documento técnico resumido.
Pensar como si estuvieras escribiendo una especificación
Un desarrollador no empieza escribiendo código.
Primero necesita entender:
- qué problema existe
- quién utilizará el sistema
- cuáles son las restricciones
- qué tecnologías están permitidas
- qué resultado se espera
Con ChatGPT ocurre exactamente lo mismo.
Este prompt produce respuestas muy pobres:
Hazme un sistema de inventario.
El modelo debe asumir demasiadas cosas:
- lenguaje
- framework
- base de datos
- autenticación
- arquitectura
- estructura del proyecto
- permisos
- despliegue
Cada decisión que inventa puede no coincidir con lo que realmente necesitas.
Un prompt mucho mejor sería:
Actúa como un arquitecto de software senior.
Quiero desarrollar un sistema de inventario para una cadena de tiendas.
Stack:
- Laravel 12
- PostgreSQL
- Redis
- Docker
- Vue 3
- TailwindCSS
Requisitos:
- autenticación con JWT
- múltiples sucursales
- movimientos de inventario
- historial completo
- auditoría
- exportación Excel
Quiero que toda la arquitectura siga principios SOLID y Clean Architecture.
No generes código todavía.
Primero define:
- módulos
- entidades
- relaciones
- estructura de carpetas
- flujo de negocio
El resultado cambia completamente.
En lugar de generar cientos de líneas de código improvisado, primero diseña el producto.
Eso reduce muchísimo las correcciones posteriores.
Divide el trabajo en etapas
Uno de los errores más costosos consiste en pedir todo en un único mensaje.
Ejemplo:
Haz una tienda online completa.
Eso obliga al modelo a condensar demasiada información.
La experiencia demuestra que funciona mejor dividir el desarrollo.
Por ejemplo:
Paso 1
Arquitectura
Diseña la arquitectura completa.
Paso 2
Modelo de datos
Genera únicamente las tablas y relaciones.
Paso 3
Backend
Genera únicamente el backend.
Paso 4
Frontend
Genera únicamente el frontend.
Paso 5
Docker
Genera docker-compose.
Paso 6
CI/CD
Genera pipeline de GitHub Actions.
Cada interacción consume menos tokens y mantiene un contexto mucho más limpio.
Indica siempre el rol que debe asumir
No es lo mismo pedir ayuda a un desarrollador junior que a un arquitecto DevOps.
Estos prompts generan enfoques distintos.
Actúa como un desarrollador Laravel senior.
Actúa como un especialista en Kubernetes.
Actúa como un experto en PostgreSQL.
Actúa como un CTO con experiencia en SaaS.
El rol ayuda al modelo a priorizar cierto tipo de decisiones.
Define restricciones desde el principio
Un error muy habitual es corregir continuamente al modelo.
Por ejemplo:
No uses Bootstrap.
Después:
No uses jQuery.
Luego:
No uses clases estáticas.
Cada corrección añade contexto innecesario.
Es mucho más eficiente comenzar indicando todas las restricciones.
Restricciones:
- No utilizar Bootstrap
- No utilizar jQuery
- No utilizar Singleton
- No utilizar Service Locator
- Aplicar SOLID
- Aplicar Clean Architecture
- Código desacoplado
- Tipado estricto
Especifica el formato de salida
Muchas veces el problema no es la respuesta.
Es el formato.
Por ejemplo:
Devuelve únicamente Markdown.
Devuelve únicamente JSON válido.
No agregues explicaciones.
Devuelve únicamente código.
No agregues comentarios.
Esto evita consumir tokens en texto que luego terminarás eliminando.
Evita preguntas abiertas
Los prompts ambiguos producen respuestas ambiguas.
Ejemplo:
¿Cómo hago una API?
Mucho mejor:
Necesito una API REST para un ecommerce.
Debe soportar:
- JWT
- paginación
- filtros
- búsqueda
- validaciones
- OpenAPI
- Docker
Laravel 12
Genera únicamente la estructura inicial.
Pide primero análisis y después implementación
Una práctica muy útil consiste en separar ambas fases.
Primero:
Analiza este problema.
Después:
Propón tres soluciones.
Luego:
Compara ventajas y desventajas.
Finalmente:
Implementa la opción dos.
Esto evita tener que rehacer código porque el diseño inicial era incorrecto.
Usa listas en lugar de párrafos largos
Los modelos interpretan mucho mejor información estructurada.
En vez de esto:
Quiero un sistema donde los usuarios puedan comprar productos, pagar con Stripe, recibir correos, administrar pedidos y controlar inventario.
Resulta más claro escribir:
Módulos:
- Usuarios
- Productos
- Inventario
- Pedidos
- Stripe
- Correos
- Dashboard
Requisitos:
- JWT
- Docker
- PostgreSQL
- Redis
- Cache
La diferencia en precisión suele ser notable.
Mantén el contexto estable
Uno de los mayores consumidores de tokens aparece cuando el proyecto cambia constantemente.
Por ejemplo:
Laravel
↓
Ahora Symfony
↓
Ahora Node
↓
Ahora Go
↓
Ahora Django
Cada cambio obliga al modelo a reinterpretar toda la conversación.
Cuando el proyecto ya tiene un stack definido, conviene mantenerlo durante toda la sesión.
Ejemplo de prompt para construir un producto completo
Actúa como un arquitecto de software senior.
Necesito desarrollar una plataforma SaaS para gestión de clínicas.
Tecnologías:
- Laravel 12
- PostgreSQL
- Redis
- Docker
- Vue 3
- TailwindCSS
- Nginx
Arquitectura:
- Clean Architecture
- SOLID
- Repository Pattern
- DTO
- Eventos de dominio
Requisitos:
- Multiempresa
- Roles
- Permisos
- Agenda médica
- Pacientes
- Facturación
- Reportes PDF
- Exportación Excel
Responde únicamente con:
1. Arquitectura
2. Módulos
3. Entidades
4. Relaciones
5. Flujo del negocio
No escribas código todavía.
Con un prompt de este tipo es habitual obtener una base mucho más consistente que empezando directamente por el código.
Cómo reducir el consumo de tokens
El consumo de tokens no depende únicamente del tamaño de la respuesta.
También influye la cantidad de contexto acumulado durante la conversación.
Algunas prácticas que ayudan:
- reutilizar el mismo contexto cuando el proyecto no cambia
- evitar repetir requisitos en cada mensaje
- solicitar una sola tarea por interacción
- pedir únicamente el formato necesario
- evitar explicaciones cuando solo se necesita código
- separar arquitectura, backend y frontend
- iniciar un chat nuevo cuando el contexto ya no es relevante
Una conversación de 80 mensajes suele consumir muchos más tokens que tres conversaciones independientes enfocadas en tareas concretas.
Ejemplo de flujo eficiente
En lugar de esto:
Haz una aplicación completa.
Es preferible seguir un flujo como este:
Paso 1
Diseña la arquitectura.
Paso 2
Genera el modelo relacional.
Paso 3
Genera migraciones.
Paso 4
Genera entidades.
Paso 5
Genera casos de uso.
Paso 6
Genera controladores.
Paso 7
Genera pruebas.
Cada respuesta mantiene un alcance claro y reduce la necesidad de rehacer trabajo.
Prompt reutilizable para proyectos
Actúa como un desarrollador senior especializado en arquitectura de software.
Objetivo:
[Describe el producto]
Stack:
- Backend:
- Frontend:
- Base de datos:
- Infraestructura:
Restricciones:
- SOLID
- Clean Architecture
- Código desacoplado
- Tipado estricto
- Docker
- Buenas prácticas
Formato de salida:
- Responde únicamente en Markdown.
- No inventes funcionalidades.
- Si falta información, indica qué dato es necesario antes de continuar.
- No generes código hasta que se solicite explícitamente.
Primera tarea:
[Describe únicamente la tarea actual]
Este tipo de plantilla reduce la ambigüedad y facilita reutilizar el mismo enfoque entre distintos proyectos.
Buenas prácticas
- Define el objetivo del producto antes de pedir una sola línea de código.
- Mantén el mismo stack durante toda la conversación para evitar respuestas inconsistentes.
- Divide el desarrollo en tareas pequeñas y con un único objetivo.
- Indica siempre el rol técnico que debe asumir el modelo.
- Declara restricciones desde el inicio en lugar de corregirlas sobre la marcha.
- Solicita primero análisis y diseño; implementa después.
- Especifica el formato exacto de la respuesta para evitar texto innecesario.
- Reutiliza plantillas de prompts para estandarizar la comunicación entre proyectos.
- Reinicia el contexto cuando cambie por completo el dominio del problema o la tecnología.
- Si la IA necesita asumir información crítica, detén la implementación y completa primero los requisitos faltantes.