Anatomía de un Prompt para Desarrolladores
Los Cinco Componentes
Cada prompt efectivo de desarrollador contiene los mismos cinco componentes, ya sea que los incluyas explícitamente o no. Cuando dejas componentes fuera, la IA llena los vacíos con suposiciones -- y las suposiciones producen salida genérica. El framework COCFE te da una lista de verificación para asegurar que tus prompts contienen todo lo que la IA necesita para producir código preciso y utilizable.
C -- Context (Contexto): Qué proyecto, qué stack, qué archivo, qué estado. Esto ancla a la IA en tu situación específica.
O -- Objective (Objetivo): Lo que quieres lograr. No "arréglalo" sino el resultado específico que necesitas.
C -- Constraints (Restricciones): Lo que NO hacer. Límites, limitaciones, cosas a evitar.
F -- Format (Formato): Cómo quieres la salida estructurada. ¿Una sola función? ¿Un archivo completo? ¿Solo el diff? ¿Una explicación?
E -- Examples (Ejemplos): Muestra, no describas. Un ejemplo del patrón que quieres seguir, el estilo que esperas, el formato de salida que necesitas.
No todo prompt necesita los cinco componentes. Tareas simples podrían solo necesitar Contexto y Objetivo. Pero tareas complejas que consistentemente producen salida incorrecta casi siempre están careciendo de uno o más de estos componentes.
Context: Anclando a la IA
El contexto es el componente que más frecuentemente falta en los prompts de desarrolladores. Tú vives dentro de tu proyecto todos los días -- la IA no. Necesita saber dónde está trabajando y qué la rodea.
Malo -- Sin contexto:
Crea una funcion para validar direcciones de email
Bueno -- Con contexto:
En nuestra API Express (src/utils/validators.ts), crea una funcion de
validacion de email. Usamos Zod para validacion de esquemas en todo el
proyecto. La funcion debe seguir el patron de la funcion validateUsername()
existente en el mismo archivo.
El contexto incluye: la ruta del archivo, el stack tecnológico, las convenciones del proyecto, archivos relacionados, y cualquier estado relevante (esquema de base de datos, contrato de API, patrones existentes). Herramientas como Claude Code leen automáticamente los archivos de tu proyecto, pero declarar explícitamente el contexto relevante aún mejora la salida porque le dice a la IA qué partes de tu proyecto importan para esta tarea específica.
Objective: Siendo Específico Sobre los Resultados
El objetivo es lo que quieres que la IA produzca. El error más común es declarar el objetivo de forma demasiado amplia.
Malo -- Objetivo amplio:
Mejora el sistema de autenticacion
"Mejorar" no es un objetivo. Es una dirección. ¿Mejorar cómo? ¿Más rápido? ¿Más seguro? ¿Mejores mensajes de error? ¿Soporte para más proveedores?
Bueno -- Objetivo específico:
Agrega rate limiting al endpoint POST /api/auth/login. Despues de 5 intentos
fallidos desde la misma IP en 15 minutos, devolver un codigo de estado 429
con un header Retry-After. Almacenar los conteos de intentos en nuestra
instancia Redis existente.
Un buen objetivo pasa la "prueba de terminado": cuando lees la salida de la IA, puedes determinar claramente si el objetivo se cumplió o no. Si el objetivo es vago, no puedes saber si la salida es correcta.
Constraints: Dibujando los Límites
Las restricciones le dicen a la IA qué evitar. Previenen que la IA haga suposiciones que entren en conflicto con las necesidades de tu proyecto.
Sin restricciones:
Agrega caching a las respuestas de la API
La IA podría usar un cache en memoria, instalar una nueva librería, modificar tu middleware de respuestas globalmente, o agregar cache headers -- cualquiera de estos podría ser válido pero incorrecto para tu situación.
Con restricciones:
Agrega caching con Redis al endpoint GET /api/products. Restricciones:
- Usar la conexion Redis existente de src/lib/redis.ts
- NO instalar ningun paquete nuevo
- El TTL del cache debe ser configurable via variable de entorno
- No cachear respuestas para usuarios autenticados
- No modificar la cadena de middleware, agregar el caching dentro del handler
Las restricciones son especialmente importantes para tareas de refactorización donde quieres que la IA cambie cosas específicas sin tocar otras. Frases como "no modificar la API pública," "mantener los tests existentes pasando," y "no cambiar el esquema de la base de datos" previenen la expansión del alcance en la salida de la IA.
Format: Controlando la Salida
El formato especifica cómo quieres la respuesta estructurada. Sin guía de formato, la IA elige su propia estructura, que podría no coincidir con lo que necesitas.
Sin formato:
Explica como funciona nuestro flujo de autenticacion
Podrías recibir un ensayo de 500 palabras cuando querías una lista con puntos, o un recorrido por el código cuando querías una descripción de diagrama.
Con formato:
Explica como funciona nuestro flujo de autenticacion. Formato:
- Comenzar con un flujo paso a paso numerado (request entra -> ... -> respuesta enviada)
- Para cada paso, incluir la ruta del archivo relevante
- Terminar con una lista de puntos potenciales de falla en cada paso
- Mantenerlo en menos de 200 palabras
Especificaciones de formato comunes para prompts de desarrollador:
- "Devuelve solo la funcion modificada, no el archivo completo"
- "Devuelve un archivo completo que pueda copiar y pegar"
- "Muestra el diff, no el codigo completo"
- "Explica tu razonamiento antes de mostrar el codigo"
- "Dame 3 enfoques alternativos con sus tradeoffs"
Examples: Muestra, No Describas
Los ejemplos son el componente más poderoso y el menos utilizado. En lugar de describir lo que quieres, muéstrale a la IA una instancia de ello.
Sin ejemplo:
Crea una interfaz TypeScript para la respuesta de la API de User con
comentarios JSDoc apropiados
Con ejemplo:
Crea una interfaz TypeScript para la respuesta de la API de User. Sigue
exactamente este estilo de documentacion de nuestra interfaz ProductResponse
existente:
/**
* Respuesta de API para datos de producto.
* Devuelta por GET /api/products/:id
*
* @example
* const product: ProductResponse = await api.getProduct("abc-123");
*/
export interface ProductResponse {
/** Identificador unico del producto (UUID v4) */
id: string;
/** Nombre para mostrar, 1-255 caracteres */
name: string;
/** Marca de tiempo de creacion en ISO 8601 */
createdAt: string;
}
Con este ejemplo, la IA igualará tu estilo exacto de JSDoc, formato de comentarios y estructura de interfaz. Sin él, la IA inventa sus propias convenciones que podrían no coincidir con tu codebase.
La técnica de "patrón existente" es la forma más confiable de obtener salida consistente de las herramientas de IA. En lugar de describir el patrón que quieres, apunta a un archivo o bloque de código que lo demuestre y di "sigue este patrón."
El Experimento de 1 Oración
Aquí hay un ejercicio que demuestra el poder del contexto. Toma cualquier prompt que hayas usado recientemente y agrega exactamente una oración de contexto. Compara los resultados.
Original:
Escribe un componente React para una barra de busqueda
Más una oración:
Escribe un componente React para una barra de busqueda. Esto es para nuestra
app Next.js 14 que usa Tailwind CSS, y el componente debe seguir el mismo
patron que nuestro componente TextInput existente en
src/components/ui/TextInput.tsx.
Esa sola oración agregó: el framework (Next.js 14), el sistema de estilos (Tailwind), el patrón a seguir (TextInput), y la ubicación del archivo. La salida de la IA pasa de una barra de búsqueda genérica a una que encaja en tu proyecto.
Cuándo Funcionan los Prompts Cortos
No toda tarea necesita un prompt de cinco componentes. Los prompts cortos funcionan bien para:
- Tareas simples e inequívocas: "Agrega un type guard de TypeScript para la interfaz User"
- Tareas con contexto obvio: cuando estás en una sesión interactiva y la IA ya tiene tu proyecto cargado
- Tareas exploratorias: "¿Qué hace esta función?" o "Explica este mensaje de error"
- Patrones estándar: "Crea una ruta GET de Express para /api/users que devuelva todos los usuarios de la base de datos"
La regla general: si hay solo una interpretación razonable de tu prompt, mantenlo corto. Si hay múltiples interpretaciones posibles, agrega contexto, restricciones y ejemplos hasta que solo quede una interpretación.
Plantillas de Prompts para Tareas Comunes
Aquí tienes plantillas iniciales usando el framework COCFE que puedes adaptar:
[Plantilla de Generacion de Codigo]
Contexto: En [ruta_archivo], usando [stack_tecnologico].
Objetivo: Crear [que] que [comportamiento].
Restricciones: [que evitar, limites].
Formato: [archivo completo / solo funcion / diff].
Ejemplo: Seguir el patron en [archivo_referencia].
[Plantilla de Correccion de Bugs]
Contexto: En [ruta_archivo], [stack_tecnologico], [entorno].
Objetivo: Corregir [comportamiento actual] para que [comportamiento esperado].
Restricciones: No cambiar [areas protegidas].
Formato: Mostrar la correccion con una breve explicacion de la causa raiz.
[Plantilla de Revision]
Contexto: [ruta_archivo o diff], [contexto del proyecto].
Objetivo: Revisar por [preocupaciones especificas: seguridad / rendimiento / correctitud].
Restricciones: Enfocarse solo en [alcance], ignorar [elementos fuera de alcance].
Formato: Listar problemas como: severidad, ubicacion, descripcion, correccion sugerida.
A medida que trabajes en este curso, desarrollarás tus propias plantillas adaptadas a tus herramientas, proyectos y flujo de trabajo específicos.