El prompt engineering para programadores es el conjunto de técnicas para instruir a modelos de lenguaje (ChatGPT, Claude, Gemini, GitHub Copilot) de forma precisa para tareas de desarrollo: generación de código, debugging, revisión, testing, documentación y arquitectura. Va más allá de "escribir el prompt correcto" — incluye diseño de system prompts para agentes de código, uso de function calling para conectar LLMs con APIs, y patrones como Chain-of-Thought (CoT) para resolver problemas complejos paso a paso.
Según el Stack Overflow Developer Survey 2024, el 78% de los desarrolladores profesionales ya usa IA en su flujo de trabajo. Los que dominan prompt engineering avanzado reportan 40-60% de mejora en productividad para tareas de boilerplate, debugging y documentación. La clave no está en que la IA "sepa programar" — sino en que el desarrollador sepa comunicarle exactamente qué necesita.
El system prompt es la instrucción que define el rol, restricciones y formato de respuesta del modelo antes de que el usuario interactúe. En desarrollo de software, el system prompt determina si el modelo escribe Python 3.11 o 3.8, si usa tipado estático, si incluye docstrings, y si sigue las convenciones de tu codebase.
SYSTEM: Eres un senior Python developer especializado en FastAPI y PostgreSQL. Reglas: - Usa Python 3.11+ con type hints en todas las funciones - Maneja errores con try/except específicos (nunca `except Exception`) - Escribe docstrings en formato Google Style - Para DB queries, usa SQLAlchemy Core (no ORM) - Sigue PEP 8; líneas máximo 88 chars (Black formatter) - Si no tienes suficiente contexto, pregunta antes de asumir - Incluye tests unitarios cuando generes funciones
Prueba de Anthropic Internal Benchmarks 2024: el mismo user prompt "escribe una función para conectar a la base de datos" con diferentes system prompts produce código que varía en 60-80% en calidad, seguridad (SQL injection, secrets hardcodeados) y adherencia a las convenciones del equipo.
El error más frecuente: pedir código sin contexto. Los 5 elementos que debe tener un buen prompt de generación:
USER: Escribe una función Python que valide emails en una lista. - Usa regex RFC 5322 simplificado (solo formato name@domain.tld) - Input: list[str] — puede contener None y duplicados - Output: dict con "valid": list[str] y "invalid": list[str] (sin duplicados) - Incluye docstring y 3 test cases con pytest # El modelo genera código limpio, tipado, con tests — vs el prompt vago # "escribe una función para validar emails" que da código sin tipos ni tests
El prompt de debugging más efectivo incluye el stacktrace completo, el contexto relevante del código y lo que ya intentaste. Sin estos tres elementos, el modelo hace suposiciones.
USER: Tengo este error en producción. Analiza la causa raíz y proporciona el fix. Error: ``` AttributeError: 'NoneType' object has no attribute 'split' File "services/parser.py", line 47, in parse_address parts = address.split(',') ``` Código relevante (líneas 40-55 de parser.py): [pegar el código] Contexto: - address viene de una request HTTP externa (Mercado Libre API) - Falla solo con ~0.3% de los pedidos - Los pedidos afectados tienen provincia vacía en la API de ML Lo que ya intenté: - Añadir `if address:` pero el error persiste porque el campo existe pero tiene None Proporciona: (1) causa raíz, (2) fix inmediato, (3) mejora defensiva a largo plazo
El function calling (también llamado tool use) permite que el LLM llame funciones de tu código cuando necesita información externa. Transforma el LLM de un chatbot a un agente que puede consultar tu base de datos, llamar APIs externas o ejecutar cálculos.
import openai tools = [ { "type": "function", "function": { "name": "get_product_inventory", "description": "Returns the current stock level for a product by SKU", "parameters": { "type": "object", "properties": { "sku": {"type": "string", "description": "Product SKU code"}, "warehouse": {"type": "string", "enum": ["BA", "MX", "BOG"]} }, "required": ["sku"] } } } ] response = openai.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "¿Cuántas unidades de SKU-4821 hay en Buenos Aires?"}], tools=tools, tool_choice="auto" ) # El modelo detecta que necesita llamar get_product_inventory y lo indica en la respuesta
USER: Genera tests pytest para esta función. Incluye: - Happy path (al menos 3 casos) - Edge cases: input vacío, None, tipos incorrectos - Caso de error esperado (que lanza ValueError) - Usa pytest.parametrize para los happy path cases - Mockea la dependencia `requests.get` usando pytest-mock [pegar la función a testear]
USER: Revisa este PR diff desde una perspectiva de: 1. Seguridad (inyección, secrets, permisos) 2. Rendimiento (N+1 queries, memory leaks, I/O bloqueante) 3. Mantenibilidad (naming, complejidad, DRY) 4. Tests faltantes o insuficientes Para cada issue: indica severidad (CRITICAL/HIGH/MEDIUM/LOW), la línea exacta y el fix sugerido. [pegar el diff del PR]
# Añadir "piensa paso a paso" antes de pedir código complejo USER: Diseña el algoritmo para detectar ciclos en un grafo dirigido. Piensa paso a paso antes de escribir el código: 1. ¿Qué estructura de datos es más eficiente para este problema? 2. ¿Cuál es la complejidad temporal y espacial de cada enfoque? 3. ¿Qué casos edge hay que manejar? Luego escribe la implementación en Python con los análisis anteriores en comentarios.
USER: Escribe una función siguiendo el mismo patrón de estos ejemplos de nuestro codebase: EJEMPLO 1: [pegar función existente de tu repo] EJEMPLO 2: [pegar otra función del mismo estilo] TAREA: Escribe una función para [nueva funcionalidad] siguiendo exactamente el mismo patrón de naming, error handling, logging y docstrings.
¿Quieres dominar la IA generativa y el prompt engineering con certificado?
No. El prompt engineering para programadores amplifica las habilidades existentes — no las reemplaza. Para detectar errores en el código generado por la IA, evaluar la arquitectura propuesta y escribir prompts técnicamente precisos, necesitas conocimientos sólidos de programación. Los modelos de IA cometen errores sutiles que solo un programador con criterio puede identificar.
El system prompt configura el comportamiento global del modelo (lenguaje, versión, convenciones del codebase, restricciones de seguridad). El user prompt contiene la tarea específica. En producción, el system prompt va en el servidor y no cambia por usuario; el user prompt varía por solicitud. Para agentes de código, el system prompt es el "contrato" con el modelo.
Function calling permite que el LLM decida cuándo necesita llamar una función de tu código para obtener información real (datos de tu BD, APIs externas, cálculos específicos). Es la base de los agentes de IA: el modelo no alucina datos — los pide a tu sistema. Disponible en OpenAI GPT-4o, Anthropic Claude y Google Gemini.