Dominio 4 — Aplicar prompt engineering y creación de contexto

Peso en el examen: 10-15%

¡Holi! 🌸 Llegamos al dominio del "arte de pedir bien las cosas". El prompt engineering es lo que separa a quien le saca un 30% a Copilot de quien le saca un 90%: la herramienta es la misma, pero cómo le hablas cambia radicalmente el resultado. Y para el examen, este dominio es muy agradecido porque tiene conceptos muy nítidos y memorizables que caen casi tal cual: las 4 Ss y la familia zero/one/few-shot. Domina esos dos bloques y llevas medio dominio en el bolsillo.

En este capítulo vamos a ir más allá de las definiciones: verás ejemplos concretos de prompts (buenos y malos) para que interiorices por qué uno funciona mejor que otro, no solo que funciona. ¡Vamos! 💛

La explicación en profundidad

El prompt engineering es el proceso de diseñar instrucciones claras y con el contexto adecuado para guiar a Copilot hacia el código que realmente necesitas. No es "hablarle bonito": es una disciplina con principios y técnicas concretas. El objetivo último es conseguir código que sea correcto en tres dimensiones a la vez: sintáctica (que compile), funcional (que haga lo que debe) y contextual (que encaje con tu proyecto, sus convenciones y sus dependencias).

¿Por qué es tan determinante? Porque, como vimos en el Dominio 3, Copilot genera a partir del contexto que recibe. Un prompt pobre le da poco contexto y le obliga a "adivinar", lo que dispara las probabilidades de que alucine o de que produzca algo genérico que no encaja. Un buen prompt le da exactamente lo que necesita para acertar a la primera.

📝 Mini-repaso

1. ¿Qué tres dimensiones de corrección busca un buen prompt?
2. ¿Por qué un prompt pobre aumenta el riesgo de alucinaciones?

La explicación en profundidad

Los cuatro principios fundamentales de un buen prompt se resumen en las "4 Ss" (en inglés, que es como caen en el examen). Vamos a verlos con lo que significa cada uno de verdad:

1. Single (Único). Enfoca el prompt en una sola tarea bien definida. Si intentas que Copilot haga cinco cosas a la vez en un mismo prompt, el resultado se difumina. Mejor descomponer: una tarea, un prompt.

2. Specific (Específico). Da instrucciones explícitas y detalladas. No dejes espacio a la interpretación: indica el lenguaje, el formato de salida, las restricciones. Cuanto más concreta seas, menos "adivina" Copilot.

3. Short (Corto). Sé conciso y ve al grano. Ojo, esto no contradice a "specific": ser específica no es ser prolija. Se trata de dar toda la información necesaria sin paja. Un prompt puede ser corto y específico a la vez — de hecho, ese es el ideal.

4. Surround (Rodear). Aprovecha el contexto del entorno: usa nombres de archivo descriptivos y mantén abiertos los archivos relacionados, porque (recuerda el Dominio 3) Copilot usa las pestañas abiertas como contexto. "Surround" no va de escribir más en el prompt, sino de rodear a Copilot de pistas útiles en tu espacio de trabajo.

Veamos las 4 Ss en acción con un ejemplo. Un prompt flojo sería:

// haz una función

Y uno que aplica las 4 Ss:

// Write a Python function `filter_even(numbers)` that takes a list of
// integers and returns a new list with only the even numbers, preserving order.

El segundo es single (una tarea: filtrar pares), specific (nombra la función, el lenguaje, el tipo de entrada y salida, y que preserve el orden) y short (una sola frase clara). El surround lo aportas tú teniendo abierto el archivo con nombre descriptivo (number_utils.py, por ejemplo).

⚠️ Trampas típicas

• Que te cuelen una quinta "S" inventada ("Structured", "Sequential", "Secure") → solo son cuatro.
• Confundir Surround con "escribir prompts largos" → Surround es contexto del entorno (archivos abiertos, nombres), no longitud del prompt. De hecho, "Short" empuja justo en la dirección contraria.

📝 Mini-repaso

1. Enumera las 4 Ss y explica "Surround" con tus palabras.
2. ¿"Short" y "Specific" se contradicen? ¿Por qué no?

La explicación en profundidad

Más allá de las 4 Ss, hay una serie de buenas prácticas que el examen recoge y que conviene entender con ejemplos:

Sé clara con el resultado esperado. Indica el formato o el tipo de retorno. Compara:

// dame los clientes

frente a:

// Using SQLAlchemy, write a parameterized query that retrieves all customers
// from the `Customer` table where `last_name` matches a provided parameter.
// Return the query result as a list of Customer objects.

El segundo especifica la tecnología (SQLAlchemy), la seguridad (parametrizada, no concatenada), la tabla, la condición y el formato de salida. Copilot casi no tiene que adivinar nada.

Aporta contexto con comentarios. Un comentario descriptivo justo encima de donde vas a escribir orienta muchísimo. Y mantén abiertas las pestañas relacionadas (Surround).

Da ejemplos cuando el patrón importe. Si quieres que siga un estilo concreto, enséñaselo (esto nos lleva directos al few-shot de la siguiente sección).

Assert and iterate (afirma e itera). Esta es una de las prácticas más importantes y más preguntadas. Si la primera sugerencia no es perfecta, no empieces de cero ni te pongas a editarla a mano línea por línea. En su lugar: descarta la sugerencia, enriquece tu comentario o prompt con los detalles que faltaban (o añade un ejemplo), y vuelve a pedir. Es un diálogo iterativo: cada vuelta refina el resultado.

Un par de técnicas finas que también aparecen: darle un "out" al modelo (indicarle qué hacer si no puede completar la tarea, p. ej. "si no encuentras el dato, responde 'no encontrado'", lo que reduce alucinaciones) y tener en cuenta que el orden importa (dónde colocas las instrucciones respecto al contenido influye en el resultado).

⚠️ Trampa típica

• Presentar "refinar el output a mano" como la mejor práctica → lo recomendado es iterar el prompt, no editar manualmente. (Editar a mano ocasionalmente está bien, pero la práctica de prompt engineering que el examen premia es enriquecer y volver a pedir.)

🎯 Lo que cae en los tests reales: las 4 opciones casi iguales

En muchas preguntas las cuatro opciones ya son específicas. La correcta es la que reúne todas las restricciones y no cuela ninguna práctica insegura:

• SQL: versión del motor (PostgreSQL 14) + esquema + qué devolver + función de ventana para el ranking + columnas exactas de salida.
• Explicar un archivo a alguien nuevo: audiencia (new backend hire) + qué cubrir (propósito, flujos de datos, dependencias, riesgos) + límite (5 bullets max).
• Rendimiento: restricciones medibles (O(1) extra space, entradas de 10MB+, backpressure) frente a un vago "rápido y eficiente".
• Plan antes que código: "plan de 5 pasos para migrar Flask → FastAPI con riesgos, rollback y rutas compatibles hacia atrás".
• HTTP seguro: HTTPS + validar certificados TLS + timeouts y reintentos + ocultar secretos en los logs + backoff ante 429/5xx.
• Librerías: versión exacta (Python 3.11; redis-py v5 only), método concreto y "sin APIs deprecadas".
• Migración de BD segura: valor por defecto + backfill + online (sin downtime) + SQL de rollback.
• Logging con privacidad: JSON estructurado con requestId, sin PII, tokens ocultos y una línea por evento.

⚠️ Las opciones trampa suelen esconder un solo detalle inseguro: loguear cuerpos completos o tokens, saltarse la validación de certificados, una API key "de prueba" como respaldo, subir secretos al repo o aceptar downtime. Con uno basta para descartarla. Y si Copilot da sugerencias irrelevantes o el prompt es ambiguo → reformula añadiendo contexto y detalles (no lo acortes ni repitas lo mismo).

📝 Mini-repaso

1. Explica "assert and iterate" y por qué es mejor que editar a mano.
2. ¿Cómo puede ayudar darle un "out" al modelo a reducir alucinaciones?

La explicación en profundidad

Esta es la otra joya del dominio. Se refiere a cuántos ejemplos incluyes en el prompt para guiar a Copilot. La clave nemotécnica es sencilla: el número del nombre = el número de ejemplos.

Zero-shot: cero ejemplos. Le pides algo directamente, confiando en el conocimiento que el modelo ya tiene de su entrenamiento. Funciona muy bien para tareas comunes y estándar. Ventaja: es lo más económico (menos tokens). Ejemplo:

# Convert Celsius to Fahrenheit
def celsius_to_fahrenheit(c):

No le has dado ningún ejemplo; confías en que "sabe" la fórmula. Para algo tan estándar, sobra.

One-shot: un ejemplo. Le das un ejemplo de entrada→salida para que capte tu patrón o convención concreta. Útil cuando quieres consistencia con un estilo particular. Ejemplo:

# Format phone numbers like this example:
# Input: "1234567890" -> Output: "(123) 456-7890"
def format_phone(number):

Ese único ejemplo le dice exactamente el formato que esperas.

Few-shot: varios ejemplos. Le das varios pares entrada→salida para que infiera un patrón más sofisticado, o para cubrir varios escenarios y casos límite. Es el equilibrio entre la imprevisibilidad del zero-shot y el coste de reentrenar el modelo. Ejemplo clásico (clasificación por patrón):

# Classify the topic of each headline:
# "Twins' Correa to test free agency" -> Baseball
# "Qatar World Cup zones for sobering up" -> Soccer
# "Fantasy football intel for Week 6" -> Football
# "Coach confident injury won't derail Warriors" ->

Con esos tres ejemplos, el modelo infiere que debe responder "Basketball" — ¡aunque no le hayas dado ningún ejemplo con esa etiqueta! Ese es el poder del few-shot: los ejemplos "condicionan" al modelo para la tarea actual.

La confusión estrella: few-shot vs. fine-tuning

Esta distinción cae seguro, así que vamos a dejarla clavada. Few-shot consiste en dar ejemplos dentro del prompt, en el momento: no cambia el modelo, solo lo "condiciona" para esa consulta concreta. Fine-tuning es reentrenar el modelo con un conjunto de datos: modifica el modelo de forma permanente. Son cosas totalmente distintas.

Regla para el examen: si el enunciado habla de "ejemplos en el prompt" → few-shot. Si habla de "reentrenar / ajustar el modelo con datos" → fine-tuning.

⚠️ Trampas típicas

• Llamar "few-shot" a un prompt con un solo ejemplo → eso es one-shot.
• Confundir few-shot (ejemplos en el prompt, temporal) con fine-tuning (reentrenar, permanente).

📝 Mini-repaso

1. ¿Cuántos ejemplos lleva cada técnica: zero, one, few?
2. ¿En qué se diferencian few-shot y fine-tuning?
3. ¿Para qué tipo de tarea es ideal el zero-shot?

La explicación en profundidad

El role prompting consiste en pedirle a Copilot que actúe como un experto de un dominio concreto, para orientar la respuesta hacia ese enfoque y elevar su calidad. Al asignarle un "rol", el modelo activa los patrones asociados a ese perfil.

Ejemplos:

Act as a cybersecurity expert. Review this login function and harden it
against common OWASP vulnerabilities.

Act as a performance optimization expert. Refactor this loop for better
time complexity on large datasets.

El beneficio: obtienes código más alineado con las buenas prácticas de ese dominio, más rápido y con menos ciclos de revisión, porque el modelo "se pone las gafas" de esa especialidad.

📝 Mini-repaso

1. ¿Qué es el role prompting y qué beneficio aporta?
2. ¿Es lo mismo asignar un rol que pedir un tono?

La explicación en profundidad

En tareas complejas rara vez basta un solo prompt. El chain prompting consiste en encadenar prompts donde cada turno construye sobre el anterior: primero la implementación, luego el manejo de errores, luego los tests, luego la documentación, luego la optimización… Vas guiando a Copilot paso a paso hacia una solución completa.

El problema es que, según se alarga la conversación, el historial se vuelve pesado, costoso e incluso contraproducente (recuerda del Dominio 3 que los LLM pierden coherencia en charlas muy largas). Por eso hay que gestionar el historial con cabeza:

• Resumir el contexto cuando la conversación se alarga (en vez de arrastrarlo todo).
• Resetear y dar contexto enfocado cuando empiezas una feature nueva.
• Usar referencias concisas en lugar de repetir implementaciones completas en cada turno.

Un dato de eficiencia que a veces aparece: arrastrar un historial completo muy largo puede consumir del orden de 2-3 unidades de petición premium (PRU) por turno, mientras que resumir o resetear lo acerca a ~1 PRU por petición. O sea: gestionar el historial no solo mejora la calidad, también el coste.

⚠️ Trampa típica

• "Mantener siempre todo el historial completo es lo mejor para la calidad" → falso: es costoso y puede degradar la relevancia. Lo recomendado es resumir/resetear.

📝 Mini-repaso

1. ¿Qué es el chain prompting?
2. Da dos formas de gestionar eficientemente un historial largo.

La explicación en profundidad

Cerramos entendiendo de dónde saca Copilot el contexto, porque el examen lo pregunta explícitamente. Copilot no lee tu mente: reúne pistas de varias fuentes.

Para las sugerencias inline, usa: el código alrededor del cursor, las pestañas abiertas, el nombre y tipo del archivo, y la estructura del proyecto.

Para el chat, además entra en juego:

• La indexación del código: remota si tu repo está en GitHub o Azure DevOps, local si no.
• La búsqueda semántica: y aquí un concepto que cae. La búsqueda semántica busca por significado, usando embeddings (representaciones vectoriales del código), no por coincidencia exacta de palabras. Esto le permite encontrar código relacionado conceptualmente aunque no compartan las mismas palabras.
• El historial del chat, los archivos abiertos y el contexto explícito que tú añadas con referencias (a archivos, símbolos, cambios de Git…).

⚠️ Trampa típica

• Confundir la búsqueda semántica (por significado, con embeddings) con la búsqueda tradicional por palabras clave exactas.

📝 Mini-repaso

1. ¿En qué se basa la búsqueda semántica y cómo difiere de la búsqueda por palabras exactas?
2. Nombra tres fuentes de contexto que usa Copilot Chat.

• Fundamentos y buenas prácticas de prompt engineering — Microsoft Learn
• Introducción a la ingeniería de prompts con GitHub Copilot
• Prompt engineering para Copilot Chat (GitHub Docs)