Anatomia de un Prompt para Desarrolladores

Los Cinco Componentes

Cada prompt efectivo de desarrollador contiene los mismos cinco componentes, ya sea que los incluyas explicitamente o no. Cuando dejas componentes fuera, la IA llena los vacios con suposiciones -- y las suposiciones producen salida generica. El framework COCFE te da una lista de verificacion para asegurar que tus prompts contienen todo lo que la IA necesita para producir codigo preciso y utilizable.

C -- Context (Contexto): Que proyecto, que stack, que archivo, que estado. Esto ancla a la IA en tu situacion especifica.

O -- Objective (Objetivo): Lo que quieres lograr. No "arreglalo" sino el resultado especifico que necesitas.

C -- Constraints (Restricciones): Lo que NO hacer. Limites, limitaciones, cosas a evitar.

F -- Format (Formato): Como quieres la salida estructurada. Una sola funcion? Un archivo completo? Solo el diff? Una explicacion?

E -- Examples (Ejemplos): Muestra, no describas. Un ejemplo del patron que quieres seguir, el estilo que esperas, el formato de salida que necesitas.

No todo prompt necesita los cinco componentes. Tareas simples podrian solo necesitar Contexto y Objetivo. Pero tareas complejas que consistentemente producen salida incorrecta casi siempre estan careciendo de uno o mas de estos componentes.

Context: Anclando a la IA

El contexto es el componente que mas frecuentemente falta en los prompts de desarrolladores. Tu vives dentro de tu proyecto todos los dias -- la IA no. Necesita saber donde esta trabajando y que 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 tecnologico, 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 automaticamente los archivos de tu proyecto, pero declarar explicitamente el contexto relevante aun mejora la salida porque le dice a la IA que partes de tu proyecto importan para esta tarea especifica.

Objective: Siendo Especifico Sobre los Resultados

El objetivo es lo que quieres que la IA produzca. El error mas comun es declarar el objetivo de forma demasiado amplia.

Malo -- Objetivo amplio:

Mejora el sistema de autenticacion

"Mejorar" no es un objetivo. Es una direccion. Mejorar como? Mas rapido? Mas seguro? Mejores mensajes de error? Soporte para mas proveedores?

Bueno -- Objetivo especifico:

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 cumplio o no. Si el objetivo es vago, no puedes saber si la salida es correcta.

Constraints: Dibujando los Limites

Las restricciones le dicen a la IA que 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 podria usar un cache en memoria, instalar una nueva libreria, modificar tu middleware de respuestas globalmente, o agregar cache headers -- cualquiera de estos podria ser valido pero incorrecto para tu situacion.

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 refactorizacion donde quieres que la IA cambie cosas especificas sin tocar otras. Frases como "no modificar la API publica," "mantener los tests existentes pasando," y "no cambiar el esquema de la base de datos" previenen la expansion del alcance en la salida de la IA.

Format: Controlando la Salida

El formato especifica como quieres la respuesta estructurada. Sin guia de formato, la IA elige su propia estructura, que podria no coincidir con lo que necesitas.

Sin formato:

Explica como funciona nuestro flujo de autenticacion

Podrias recibir un ensayo de 500 palabras cuando querias una lista con puntos, o un recorrido por el codigo cuando querias una descripcion 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 mas poderoso y el menos utilizado. En lugar de describir lo que quieres, muestrale 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 igualara tu estilo exacto de JSDoc, formato de comentarios y estructura de interfaz. Sin el, la IA inventa sus propias convenciones que podrian no coincidir con tu codebase.

La tecnica de "patron existente" es la forma mas confiable de obtener salida consistente de las herramientas de IA. En lugar de describir el patron que quieres, apunta a un archivo o bloque de codigo que lo demuestre y di "sigue este patron."

El Experimento de 1 Oracion

Aqui hay un ejercicio que demuestra el poder del contexto. Toma cualquier prompt que hayas usado recientemente y agrega exactamente una oracion de contexto. Compara los resultados.

Original:

Escribe un componente React para una barra de busqueda

Mas una oracion:

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 oracion agrego: el framework (Next.js 14), el sistema de estilos (Tailwind), el patron a seguir (TextInput), y la ubicacion del archivo. La salida de la IA pasa de una barra de busqueda generica a una que encaja en tu proyecto.

Cuando Funcionan los Prompts Cortos

No toda tarea necesita un prompt de cinco componentes. Los prompts cortos funcionan bien para:

• Tareas simples e inequivocas: "Agrega un type guard de TypeScript para la interfaz User"
• Tareas con contexto obvio: cuando estas en una sesion interactiva y la IA ya tiene tu proyecto cargado
• Tareas exploratorias: "Que hace esta funcion?" o "Explica este mensaje de error"
• Patrones estandar: "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 interpretacion razonable de tu prompt, mantenlo corto. Si hay multiples interpretaciones posibles, agrega contexto, restricciones y ejemplos hasta que solo quede una interpretacion.

Plantillas de Prompts para Tareas Comunes

Aqui 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, desarrollaras tus propias plantillas adaptadas a tus herramientas, proyectos y flujo de trabajo especificos.