Prompting para generación de código: guía práctica

Generar código con LLMs es una de las aplicaciones más populares y también una de las más frustrantes cuando los prompts no están bien diseñados. El modelo produce código que compila pero no hace lo que necesitas, o que funciona en el ejemplo pero no en tu contexto real.

Esta guía cubre los patrones que sí funcionan para las tareas de código más frecuentes.

Por qué los prompts de código fallan

Los LLMs generan código plausible estadísticamente, no código correcto. Sin el contexto adecuado, producen:

Código genérico que no sigue las convenciones de tu codebase
Dependencias que no usas o versiones incorrectas
Código que funciona en el caso simple pero no maneja los edge cases
Arquitectura inconsistente con el resto de tu proyecto

La solución es dar más contexto, no menos.

El contexto que siempre hay que incluir

Para cualquier tarea de código, el prompt mínimo incluye:

Lenguaje y versión: Python 3.11 / TypeScript 5.2 / etc.
Framework/librería principal: FastAPI / Next.js App Router / etc.
Estilo de código: guía de estilo del proyecto o ejemplo de código existente
Qué tiene que hacer: descripción precisa de la funcionalidad
Qué NO tiene que hacer: restricciones explícitas
Tests requeridos: sí/no, y si sí, qué tipo

Prompts para generación de código

Patrón básico efectivo

Lenguaje: TypeScript con Next.js 14 App Router
Contexto: Estoy añadiendo autenticación a una app existente que usa Prisma + PostgreSQL

Necesito una Server Action que:
1. Recibe email y password del formulario
2. Valida que ambos campos existen y tienen formato correcto
3. Busca el usuario en la base de datos por email
4. Compara el password con bcrypt
5. Si es correcto, crea una sesión con next-auth
6. Si falla, devuelve un error específico (usuario no encontrado vs password incorrecto)

Restricciones:
- No uses try/catch genéricos — maneja cada tipo de error específicamente
- Tipado estricto, sin any
- Sigue el patrón de Server Actions de Next.js 14 (use server, useActionState)

Devuelve solo el código de la función con sus imports.

Incluir código existente como referencia

Si tienes código similar en el proyecto, inclúyelo. Es la forma más efectiva de que el modelo siga las convenciones correctas:

Aquí hay una Server Action existente en mi proyecto que sigue el patrón correcto:

[código de ejemplo de tu proyecto]

Ahora escribe una Server Action similar que haga [nueva funcionalidad].
Mantén exactamente el mismo estilo, estructura de errores y tipos.

Especificar el output esperado

La función debe tener esta firma:
async function calcularDescuento(
  precio: number,
  codigoDescuento: string,
  userId: string
): Promise<{ precioFinal: number; descuentoAplicado: number; error?: string }>

Implementa el cuerpo. Los códigos de descuento están en la tabla `discount_codes` de Prisma.

Dar la firma esperada reduce enormemente la variabilidad del output.

Prompts para code review

El LLM hace reviews útiles cuando le das criterios específicos, no cuando le pides "revisa esto":

Revisa este código Python como si fuera un senior engineer haciendo code review para producción.

Enfócate en:
1. Seguridad: inyección SQL, manejo de secretos, validación de inputs
2. Rendimiento: N+1 queries, operaciones innecesariamente síncronas
3. Manejo de errores: ¿qué pasa cuando [función X] falla?
4. Edge cases: inputs vacíos, None, tipos incorrectos

Para cada problema encontrado:
- Indica la línea específica
- Explica por qué es un problema
- Muestra el código corregido

Si no encuentras problemas en alguna categoría, indícalo explícitamente.

[código a revisar]

Prompts para debugging

El debugging es donde los LLMs brillan si les das el contexto correcto:

Tengo un bug en este código Python. Te doy:
1. El código
2. El error exacto con traceback completo
3. Los inputs con los que reproduce
4. Lo que debería hacer

CÓDIGO:
[código]

ERROR:
[traceback completo, copiado exactamente]

INPUTS QUE REPRODUCEN EL BUG:
[ejemplo específico]

COMPORTAMIENTO ESPERADO:
[qué debería hacer]

Analiza el problema, explica por qué ocurre y muestra la corrección mínima necesaria.

Crítico: No parafrasees el error. Copia el traceback completo. La información en el traceback que "parece irrelevante" a menudo es exactamente la clave.

Prompts para refactoring

Refactoriza este código para mejorar [objetivo específico].

Objetivo: reducir la duplicación (actualmente la validación se repite en 4 funciones)
Restricciones:
- No cambies el comportamiento externo (misma API pública)
- Mantén la compatibilidad con Python 3.9+
- No añadas nuevas dependencias
- Los tests existentes deben seguir pasando

Muestra primero los cambios propuestos en pseudocódigo, luego el código completo.

[código a refactorizar]

El "primero pseudocódigo, luego código" ayuda a verificar que el modelo entiende correctamente el objetivo antes de generar todo el código.

Prompts para tests

Escribe tests unitarios para esta función Python usando pytest.

Requisitos:
- Cubre el happy path
- Cubre los casos de error documentados en el docstring
- Incluye tests para inputs límite: lista vacía, None, string vacío
- Usa fixtures de pytest donde tenga sentido
- Los tests deben ser independientes entre sí (sin estado compartido)
- Nombra los tests descriptivamente (test_[función]_[escenario]_[resultado])

No mockees nada a menos que sea estrictamente necesario.

[función a testear]

Técnicas específicas para código

Pedir razonamiento antes del código (CoT)

Para problemas de arquitectura o diseño no triviales:

Antes de escribir el código, explica brevemente:
1. El enfoque que vas a usar y por qué
2. Las alternativas que descartaste y por qué
3. Los trade-offs principales

Luego escribe el código.

Generación incremental para código largo

En lugar de pedir una función larga de una sola vez:

Vamos a construir [sistema X] en partes.

Paso 1: Primero escribe solo las definiciones de tipos/interfaces (sin implementación)
[revisas y apruebas]

Paso 2: Implementa solo la función de validación
[revisas y apruebas]

Paso 3: Implementa la función principal usando los tipos del paso 1
[etc.]

El patrón "primero el test, luego el código"

Estoy usando TDD. Primero escribe el test que describe el comportamiento esperado,
luego escribe la implementación que hace pasar ese test.

Comportamiento a implementar: [descripción]

Errores frecuentes en prompts de código

Pedir "el mejor enfoque" sin restricciones: El modelo elegirá algún enfoque razonable, pero probablemente no el que se integra mejor con tu stack. Siempre da restricciones.

No dar el contexto del entorno: "Escribe una función que lea un CSV" produce código muy diferente si es para un script de línea de comandos, una Lambda, o una API FastAPI.

No especificar manejo de errores: Los LLMs tienden a generar el happy path. Pide explícitamente cómo manejar los casos de error.

Aceptar el primer output sin revisar: El código generado siempre debe revisarse. Los LLMs producen errores sutiles, especialmente en lógica de negocio compleja o en APIs que no estaban en su training data.

Recursos relacionados:

Guía de prompt engineering — fundamentos generales antes de especializarse en código
Técnicas de prompting avanzadas — Chain-of-Thought y otras técnicas aplicables a código
Evaluador de System Prompts — evalúa el system prompt de tu asistente de código
Generador de System Prompt — construye el system prompt para un asistente de código