En los artículos anteriores cerramos una idea: tu trabajo no es escribir más rápido, es decidir mejor. Aprendimos qué delegar y qué retener usando tres filtros —claridad, precisión y control— y repetimos el principio que sostiene toda la serie: conserva el pensamiento, delega la escritura.
Pero hay un problema práctico. Puedes tener clarísimo qué quieres delegar y aun así obtener basura, porque el prompt es el contrato entre tu pensamiento y el agente. Si el contrato es vago, el agente rellena los huecos con suposiciones, y esas suposiciones se convierten en bugs que tú vas a tener que cazar después.
Este artículo abre un nuevo bloque de la serie —técnicas, reglas y control— y empieza por lo más cercano al teclado: cómo pedir las cosas. No son trucos para "engañar" al modelo. Son hábitos para que el agente trabaje dentro de tus reglas y no contra ellas.
Por qué un buen prompt es prevención de bugs, no decoración
Un junior suele pensar en el prompt como una pregunta: "hazme un endpoint". Un desarrollador que trabaja en serio con agentes lo piensa como una especificación pequeña: contexto, restricciones y forma de salida.
La diferencia se nota en el coste. Un prompt vago genera código que compila pero que asume la versión equivocada del framework, mete una dependencia que no querías o rompe una convención de tu proyecto. Tú no lo ves al instante: lo descubres en code review, en un test que falla o —peor— en producción. Cada suposición no controlada del agente es deuda que pagas con tu tiempo.
Las ocho técnicas que siguen atacan justo eso: reducir el espacio de suposiciones para que el agente acierte a la primera.
1. Contexto antes que instrucción
El error más común del junior es ir directo a la orden: "créame un repositorio para usuarios". El agente no sabe en qué versión de .NET estás, qué ORM usas ni cómo organizas las capas, así que adivina —y suele adivinar lo más popular en su entrenamiento, no lo que tú tienes.
Pon el contexto primero, en una o dos líneas:
Stack: .NET 10, ASP.NET Core, EF Core 9, arquitectura por capas
(Domain / Application / Infrastructure / Web).
Tarea: crea un repositorio para la entidad Experto.Qué bug evitas: código para una versión que no usas, APIs obsoletas (o aún no disponibles) y patrones que no encajan con tu arquitectura. El contexto recorta de golpe el 80% de las suposiciones malas.
2. Define qué significa "terminado"
"Hazme la búsqueda de expertos" no tiene un final claro. ¿Incluye paginación? ¿Filtra por categoría? ¿Devuelve un DTO o la entidad? El agente decidirá por ti, y rara vez como tú querías.
Dale criterios de aceptación, igual que harías en una historia de usuario:
Terminado cuando:
- Busca expertos por nombre o categoría (coincidencia parcial).
- Devuelve una lista de ExpertoDto, no la entidad de dominio.
- Soporta paginación (page, pageSize), con valores por defecto 1 y 20.
- Si no hay resultados, devuelve lista vacía, nunca null.Qué bug evitas: el clásico NullReferenceException por devolver null en vez de lista vacía, y rondas enteras de "no, en realidad necesitaba que también…". Definir el final por adelantado es la forma más barata de no iterar cinco veces.
3. Da un ejemplo de tu propio código (few-shot)
Los modelos imitan muy bien. Si le pegas un ejemplo de cómo ya escribes tú, el resultado se parecerá a tu código y no al de un tutorial random de internet.
Antes de pedir un repositorio nuevo, pega uno que ya tengas:
Sigue exactamente este estilo (nombres, async, manejo de IQueryable):
public class CategoriaRepository : ICategoriaRepository
{
private readonly AppDbContext _db;
public CategoriaRepository(AppDbContext db) => _db = db;
public async Task<Categoria?> GetByIdAsync(int id) =>
await _db.Categorias.FindAsync(id);
}
Ahora hazme el ExpertoRepository con los mismos criterios.Qué bug evitas: inconsistencias de estilo que ensucian el code review, mezcla de patrones (un método síncrono aquí, otro async allá) y convenciones de nombres que rompen con el resto del proyecto. Un ejemplo vale más que tres párrafos de instrucciones.
4. Restricciones explícitas: dile también qué NO hacer
Esta técnica es la que más sorprende a los juniors, porque parece contraintuitivo gastar tokens diciendo lo que no quieres. Pero los agentes tienden a "ayudar de más": meten una librería, refactorizan algo que no tocaba, cambian una firma pública.
Restricciones:
- No agregues paquetes NuGet nuevos.
- No uses AutoMapper; el mapeo a DTO va a mano.
- No cambies la firma de los métodos públicos existentes.
- No toques la configuración de DI.Qué bug evitas: dependencias sorpresa que tú no decidiste, cambios fuera de alcance que rompen otras partes y refactors no pedidos que disparan tu diff de 10 a 200 líneas. Las restricciones son tu primer mecanismo de control —y, no por casualidad, el tema del próximo artículo.
5. Pensar antes de escribir: primero el plan, luego el código
Para lógica no trivial, pedir el código directamente es arriesgado: el agente se compromete con un diseño en la primera línea y luego "defiende" ese diseño aunque esté mal. Sepáralo en dos pasos.
Antes de escribir nada, explícame en 4-5 puntos cómo vas a
resolver la validación de la solicitud de búsqueda
(orden de las validaciones, qué devuelves ante cada error).
No escribas código todavía.Lees el plan, lo corriges si hace falta, y recién entonces le dices "ok, impleméntalo". Aquí sigues siendo el navegante: el plan es donde está tu pensamiento, y revisarlo cuesta segundos frente a revisar 80 líneas de código equivocado.
Qué bug evitas: errores de diseño que se vuelven errores de implementación. Es mucho más barato corregir un plan en texto que un código ya escrito que parece correcto.
6. Descompón la tarea en pasos pequeños
"Hazme toda la funcionalidad de búsqueda de expertos, de la entidad al controlador" es pedir mucha superficie de una sola vez. Cuanto más grande el output, más difícil es revisarlo y más se esconden los bugs.
Ve capa por capa, en el mismo orden en que tú lo construirías:
- Entidad y configuración de EF Core.
- DTO de salida.
- Interfaz del repositorio.
- Implementación del repositorio.
- Servicio de aplicación.
- Controlador.
- Tests.
Revisas y das el visto bueno a cada paso antes de pasar al siguiente. Qué bug evitas: el efecto "muro de código" donde apruebas 300 líneas que no leíste de verdad. Pasos pequeños = revisión real = menos bugs colándose por cansancio.
7. Trata el test como especificación
Si ya trabajas con TDD o BDD, esta técnica encaja sola: pide el test primero (o junto con el código), porque el test es una forma ejecutable de decir qué significa "correcto".
Primero escribe los tests xUnit para BuscarExpertosAsync:
- Devuelve expertos que coinciden por nombre parcial.
- Devuelve lista vacía cuando no hay coincidencias.
- Respeta la paginación.
Luego implementa el método para que esos tests pasen.Qué bug evitas: el código que "parece" funcionar pero no cubre los casos borde. Cuando el test define el contrato, el agente no puede irse por las ramas: tiene un objetivo verificable, no una interpretación libre. Además te quedas con la red de seguridad puesta para el refactor.
8. Feedback específico en la iteración
Cuando algo sale mal, el reflejo del junior es escribir "no funciona" o "sigue mal". Eso obliga al agente a adivinar otra vez, y suele cambiar cosas al azar hasta que algo encaja —o hasta que rompe más.
Dale el error exacto, igual que se lo darías a un compañero:
Lanza NullReferenceException en BuscarExpertosAsync, línea 24,
cuando _db.Expertos no tiene registros. El Where devuelve un
IQueryable vacío, pero luego haces .First() en vez de
.FirstOrDefault(). Corrige solo eso.Qué bug evitas: las "correcciones" que generan tres bugs nuevos. Un error concreto produce un arreglo concreto; un "no anda" produce una ruleta. Y fíjate en el detalle final —"corrige solo eso"— que es otra vez una restricción para que no aproveche para refactorizar de más.
El hilo que conecta las ocho
Si las relees, todas hacen lo mismo: reducen lo que el agente tiene que suponer. Contexto, criterios de "terminado", ejemplos, restricciones, plan previo, pasos pequeños, tests y feedback exacto son ocho maneras de cerrar huecos antes de que se conviertan en bugs.
Y todas son coherentes con el principio de la serie. No estás escribiendo menos para pensar menos; estás escribiendo prompts precisos porque ahí es donde vive tu pensamiento. El agente teclea; tú decides qué teclear.
Estas técnicas funcionan a nivel de cada interacción. Pero cuando trabajas con agentes de forma seria —varios pasos, varias sesiones, un proyecto real como una API en ASP.NET Core— necesitas algo más que buenos prompts sueltos: necesitas límites y estructura que el agente respete siempre, sin que tengas que repetirlos cada vez. De eso trata el próximo artículo.
