Qué delegar a los agentes y qué no (y cómo decidirlo sin equivocarte)

En el artículo anterior quedó establecido algo incómodo: tú eres el navegante permanente y el agente es el conductor rápido. El agente teclea más rápido que tú, no se cansa y no se distrae. Pero el rumbo lo pones tú, siempre. Lo que no resolvimos ahí es la pregunta que aparece a los cinco minutos de trabajar así: vale, soy el navegante… pero entonces, ¿qué le doy exactamente al conductor y qué hago yo?

Este artículo va de eso. Y empieza desmontando la intuición con la que casi todos los juniors arrancan.

La pregunta equivocada: "¿qué es lo fácil?"

Cuando alguien empieza a delegar en un agente, casi siempre delega por dificultad. La lógica parece sensata: "lo aburrido y mecánico se lo doy a la IA, lo difícil me lo quedo yo". El problema es que esa regla te lleva justo al peor sitio.

Porque "difícil" suele significar dos cosas distintas que no tienen nada que ver entre sí. A veces "difícil" es tedioso pero perfectamente definido (escribir veinte DTOs casi idénticos). Y a veces "difícil" es que aún no sabes qué quieres (decidir cómo modelar un agregado del dominio). El primero es el candidato perfecto para delegar. El segundo es exactamente lo que jamás deberías soltar. Y la palabra "difícil" no te ayuda a distinguirlos.

La pregunta correcta no es qué es fácil. Es: ¿puedo especificar esto con precisión y verificar el resultado de forma barata? Eso cambia todo el criterio.

El reparto que de verdad importa: pensar vs. teclear

Hay una forma muy simple de ver el reparto correcto, y es la que distingue al que de verdad programa con IA del que solo pega código:

Quédate con el pensamiento. Delega el tecleo.

La trampa del junior es hacer justo lo contrario: deja que el agente decida el diseño ("hazme la API de usuarios") y luego se pone él a teclear correcciones encima de lo que el agente decidió. Ha delegado el pensamiento y se ha quedado con el tecleo. Es el peor reparto posible, porque el pensamiento es donde está tu valor y el tecleo es donde está el del agente.

El profesional invierte el reparto. Piensa el modelo, el contrato, el orden de las cosas y qué significa "terminado". Y entonces deja que el agente convierta esa decisión en código. El agente no decide nada importante: ejecuta decisiones que tú ya tomaste.

Tres criterios para decidir en el momento: claridad, precisión y control

"Quédate con el pensamiento" es la idea; los tres criterios son la herramienta para aplicarla tarea a tarea. Antes de delegar algo, pásalo por estos tres filtros. Tienen que pasar los tres. Si falla uno, no delegues todavía.

1. Claridad: ¿puedes decir qué es "terminado"?

Si no eres capaz de describir con palabras qué quieres y cómo sabrás que está bien, el agente tampoco lo sabrá. Va a rellenar los huecos por su cuenta —siempre rellena— y vas a recibir algo plausible que no es lo que necesitabas.

Aquí hay un matiz clave: cuando una tarea no es clara, eso no significa "no se puede delegar". Significa "tu trabajo ahora mismo es hacerla clara". Convertir un deseo difuso en una especificación precisa es trabajo de navegante, y es de lo más valioso que haces. La especificación no es el paso previo a programar; es la parte de programar que no puedes delegar.

2. Precisión: ¿puedes verificar el resultado de forma barata y objetiva?

La pregunta es si existe un juez automático y barato que diga "esto está bien" o "esto está mal" sin que tengas que leerlo línea a línea: una prueba que pasa o falla, el compilador, el sistema de tipos, un esquema, un linter, un endpoint que devuelve la forma esperada.

Cuando la corrección es objetiva y verificable, delegar es seguro: aunque el agente se equivoque, el juez lo caza. Cuando la corrección es subjetiva o contextual —si un nombre refleja bien el dominio, si una responsabilidad vive en la capa correcta, si una abstracción merece la pena— no hay juez automático. Ahí el único verificador eres tú, y por tanto la decisión también.

Esto explica por qué los agentes encajan tan bien con TDD y BDD. Una prueba escrita primero es el juez. El ciclo rojo-verde-refactor convierte "implementa esto" en una tarea con corrección verificable, y por eso se delega tan limpiamente.

3. Control: ¿qué pasa si se equivoca y cuánto cuesta deshacerlo?

Este es el criterio que la gente olvida, y el que más caro sale. Una tarea puede ser clarísima y perfectamente verificable y aun así no debes delegarla, porque el radio de explosión de un error es enorme o difícil de revertir.

Una migración que toca datos de producción es clara. Un cambio en el contrato público de tu API es claro. Una decisión de seguridad o de autenticación puede ser clara. Y aun así te quedas con la mano en el volante, porque equivocarte ahí no es un test en rojo: es datos corruptos, clientes rotos o un agujero. El control manda sobre los otros dos criterios. Cuando el coste del error es alto e irreversible, la claridad y la verificabilidad no bastan.

Al revés también funciona: trabajo de bajo radio, fácilmente reversible y fácilmente verificable es donde puedes delegar con los ojos casi cerrados.

Aterrizándolo en .NET

Con esos tres filtros, el reparto en un proyecto real (una API en ASP.NET Core, por ejemplo) se ordena solo.

Buenos candidatos para delegar —alta claridad, verificación barata, radio contenido—:

• DTOs, records de request/response y código de mapeo entre capas.
• Scaffolding repetitivo de repositorios o CRUD una vez decidido el contrato.
• Implementar un método cuya firma y contrato ya diseñaste tú.
• Escribir el código que hace pasar un escenario o una prueba que tú ya definiste.
• Refactors mecánicos y transformaciones repetidas en muchos ficheros.
• La migración de EF Core una vez que el modelo está decidido.
• Borradores de documentación, de mensajes de commit, búsqueda de sintaxis o de uso de una API.

Lo que te quedas tú —baja claridad de entrada, corrección subjetiva o radio de explosión grande—:

• El modelo de dominio y las fronteras de los agregados: ahí vive tu comprensión del negocio.
• El contrato público de la API: qué significan los endpoints y qué prometen.
• Las decisiones de arquitectura y sus trade-offs (dónde vive cada responsabilidad, qué capa depende de qué).
• Qué construir y en qué orden: el alcance y los criterios de aceptación.
• Las fronteras de seguridad y autenticación.
• Los nombres que cargan significado de dominio.
• La elección de dependencias e infraestructura.
• La revisión final: ¿esto hace de verdad lo que el negocio necesita?

Fíjate en que la lista de la izquierda no es "lo fácil" y la de la derecha no es "lo difícil". Escribir veinte mappers es tedioso; decidir una frontera de agregado puede hacerse en una frase. El eje no es la dificultad: es si puedes especificar y verificar sin riesgo.

Cómo se ve esto en un ciclo real con agentes

Si trabajas con un flujo de varios agentes —un especificador, un arquitecto, un programador, un revisor—, este reparto deja de ser una intuición y se convierte en la propia estructura del ciclo. No es casualidad: ese montaje es exactamente "quédate con el pensamiento, delega el tecleo" hecho proceso.

El humano sujeta dos puertas: la de entrada (la especificación: qué se construye y cómo sabremos que está bien) y la de salida (la revisión: ¿pasa lo que tenía que pasar y dice lo que tenía que decir?). Entre esas dos puertas, los agentes hacen el trabajo mecánico. Tú no tecleas la implementación; tú garantizas que la tarea entró clara y que salió correcta.

Por eso los baby steps de XP no son un detalle estético: el incremento pequeño y bien especificado es, literalmente, la unidad mínima que pasa los tres criterios a la vez. Un trozo grande y difuso falla en claridad, falla en verificación barata y tiene un radio de explosión grande. Trocearlo en pasos pequeños es lo que lo vuelve delegable. Delegar bien y avanzar en pasos pequeños son la misma disciplina vista desde dos ángulos.

Señales de que delegaste de más

Sabrás que cruzaste la línea cuando notes alguno de estos síntomas:

• Estás corrigiendo a mano, una y otra vez, decisiones de diseño que el agente tomó por ti. (Delegaste el pensamiento.)
• No sabrías explicar por qué el código está estructurado así. (No revisaste de verdad; aceptaste.)
• Para verificar si está bien tienes que leerlo entero con lupa. (No había juez automático: faltaba precisión.)
• Te da miedo tocar lo que produjo porque no entiendes el radio de explosión. (Perdiste el control.)

Ninguno de esos problemas se arregla pidiéndole al agente que lo haga mejor. Se arreglan subiendo un nivel: especificar más claro, poner un juez antes de delegar, o sencillamente recuperar esa decisión y tomarla tú.

El objetivo no es delegar lo máximo posible

Es tentador medir tu progreso por cuánto le pasas al agente, como si delegar más fuera ser mejor. No lo es. El objetivo es mantener tu juicio donde de verdad importa y soltar todo lo demás. Un buen navegante no demuestra su valía conduciendo menos; lo demuestra eligiendo bien el rumbo y sabiendo, en cada curva, qué puede ceder al volante y qué no.

Claridad, precisión y control son los tres instrumentos del navegante. Mientras los uses antes de cada tarea, da igual lo rápido que teclee el conductor: el coche va a donde tú decides.