La brecha de delegación: usas IA al 60%, delegas solo el 20%

Usas IA en más de la mitad de tu trabajo y aun así no te atreves a soltarle una tarea entera. La escribes, la revisas, la corriges, y el criterio de si está bien o mal sigue siendo tuyo. No es falta de confianza: Anthropic lo ha medido. Los desarrolladores usan IA en torno al 60% de su trabajo, pero solo pueden delegar por completo entre el 0% y el 20% de sus tareas ^[1]. A esa distancia la llamo la brecha de delegación. Y no se está cerrando sola: hace un año el uso rondaba el 28% ^[2]. El uso se ha duplicado. La delegación no se ha movido.

¿Qué es la brecha de delegación y quién le puso el nombre?

La brecha de delegación es la distancia entre cuánto usas la IA y cuánto trabajo puedes soltarle de verdad, sin volver a pasar por encima. El 2026 Agentic Coding Trends Report de Anthropic lo deja negro sobre blanco en su prólogo: los desarrolladores usan IA en “roughly 60%” de su trabajo pero reportan poder “fully delegate” solo el 0-20% de las tareas ^[1]. Más adelante el informe la bautiza como the collaboration paradox: uso masivo y ganancias reales de productividad conviviendo con una delegación mínima.

El “60%” tiene letra pequeña que conviene leer. El número real es 59%, y sale de una encuesta interna de Anthropic a 132 de sus propios ingenieros e investigadores, más 53 entrevistas cualitativas en agosto de 2025 ^[2]. Esos mismos 132 reportaron una subida de productividad autopercibida del +50%, y más de la mitad solo delegaba por completo entre el 0% y el 20% de su trabajo. Es gente que trabaja en la frontera de estas herramientas y las usa a diario. Si a ellos les pasa, al resto del sector le pasa más.

Una aclaración de atribución, porque circula mal: el término “delegation gap” no aparece en el informe de Anthropic. Lo acuñan los análisis posteriores, en concreto Janne Lammi en Pathmode ^[3]. Anthropic mide el fenómeno y lo llama collaboration paradox. Yo uso “brecha de delegación” como etiqueta de trabajo porque describe mejor lo que ves cada día: el hueco entre lo que la herramienta toca y lo que de verdad se le suelta.

¿Por qué existe la brecha: el modelo o la verificación?

Lo que limita la delegación es la verificabilidad de la tarea. La capacidad del modelo casi nunca es el cuello de botella. Y no lo digo yo: lo dice el propio informe. En el Trend 4 explica que los ingenieros tienden a delegar tareas fácilmente verificables, aquellas donde pueden “relatively easily sniff-check on correctness”, o de bajo riesgo, como un script rápido para cazar un bug. Cuanto más conceptualmente difícil o dependiente de diseño es una tarea, más probable es que se la queden o la trabajen a medias con la IA en vez de entregarla del todo ^[1].

Hay una cita de un ingeniero de Anthropic en esa misma página que lo resume mejor que cualquier gráfico: “I’m primarily using AI in cases where I know what the answer should be or should look like”. Traducido a decisión de diseño: solo delego cuando ya tengo el oráculo de corrección en la cabeza. Delegar de verdad significa transferir ese oráculo junto con el trabajo, no quedártelo tú.

Esa es la línea que separa asistir de delegar. No es el modelo que uses, es la infraestructura de verificación que has construido alrededor.

Dimensión	Asistencia (≈60% del trabajo)	Delegación completa (el 0-20%)
Quién verifica	Un humano en cada paso	Un gate computable
Criterio de corrección	Implícito, en la cabeza del senior	Explícito y ejecutable antes de lanzar la tarea
Coste marginal por tarea	Atención humana constante	Amortizado en la infraestructura de evals
Riesgo tolerable	Alto, porque hay revisión detrás	Acotado por guardarrailes que paran el bucle
Ejemplo	Refactor guiado desde el editor	El caso Rakuten (detallado más abajo): 7 h autónomas con verificación numérica

¿Cuánto cuesta verificar lo “casi bien”?

Verificar salidas casi correctas es el coste que hace que delegar no compense sin infraestructura. La Stack Overflow Developer Survey 2025 lo mide con crudeza: la mayor frustración de los desarrolladores, citada por el 66%, son las “AI solutions that are almost right, but not quite” ^[4]. En la misma encuesta un 84% ya usa o planea usar IA (frente al 76% de 2024), pero un 46% desconfía activamente de su precisión frente a un 33% que confía, y un 45,2% dice que depurar código generado por IA le consume más tiempo. La adopción sube y la confianza baja a la vez.

Ese coste engaña porque no aparece en la factura de tokens. Se paga en tu atención, que es mucho más difícil de contabilizar. El experimento de METR lo dejó medido en julio de 2025: en un ensayo controlado, desarrolladores open-source expertos que usaban IA tardaron un 19% más en cerrar sus issues ^[5]. Lo demoledor es la percepción. Antes del estudio esperaban ir un 24% más rápidos y, tras sufrir el frenazo, seguían creyendo haber ido un 20% más rápidos. Casi 40 puntos entre lo que sentían y lo que pasaba. Conviene leerlo con su contexto: 16 desarrolladores muy expertos en sus propios repos maduros, 246 issues, modelos de principios de 2025 (Cursor Pro con Claude 3.5 y 3.7 Sonnet). No dice que la IA te frene siempre. Dice que la sensación de velocidad no es una métrica.

¿Qué hace delegable una tarea? El techo lo marca Rakuten

Una tarea es delegable por completo cuando su corrección se puede comprobar de forma barata y automática. El mejor contraejemplo de la brecha está en el propio informe. Rakuten puso a Claude Code a implementar un método concreto de extracción de vectores de activación sobre vLLM, una librería open-source que el informe cifra en 12,5 millones de líneas en varios lenguajes. Claude Code terminó el trabajo en siete horas de ejecución autónoma, en una sola tirada, y la implementación alcanzó un 99,9% de precisión numérica frente al método de referencia ^[1].

Esas siete horas sin humano encima no funcionaron por potencia bruta del modelo. Funcionaron porque la tarea traía puesto su propio oráculo de corrección: comparar la salida contra un método de referencia y exigir coincidencia numérica. Había una condición de verificación computable y barata de ejecutar. Ahí está la regla que uso para decidir qué suelto y qué me quedo: delegación total si y solo si existe un criterio de aceptación computable. Sin ese oráculo, lo que llamas “delegación” es asistencia con la revisión manual aplazada.

¿Cómo se cierra la brecha? Ingeniería del bucle, no el próximo modelo

La brecha se cierra construyendo la infraestructura de verificación. El próximo modelo no la va a construir por ti: el uso se duplicó en doce meses y la delegación completa siguió clavada en el 0-20% ^[2]. Son cuatro movimientos los que convierten asistencia en delegación, y ninguno depende de esperar.

Criterios de aceptación ejecutables antes de lanzar la tarea. Tests, invariantes, umbrales numéricos, checks de esquema. Si defines qué significa “correcto” solo cuando ya ves la salida, estás verificando a ojo. El criterio tiene que existir antes, como en Rakuten. Para usar la suite de tests como contrato del agente, ahí está la estrategia de tests cuando la IA programa rápido pero rompe cosas.

Evals y jueces para lo que no cabe en un test. No todo se reduce a un assert. Para las salidas subjetivas o semánticas necesitas evals con puntuación y, cuando hace falta, un modelo que actúe de juez de las respuestas del agente. Montarlo en serio, con métricas y observabilidad, es el tema de cómo evaluar agentes de IA en producción.

Gates de verificación y guardarrailes que paran el bucle. La supervisión humana continua no escala: si tienes que mirar cada paso, no has delegado nada. Un gate computable decide si el resultado pasa o se escala, y un guardarraíl corta la ejecución cuando se sale del carril. El paso a paso con código está en cómo implementar guardarrailes en agentes de IA.

Bucles con condición de parada y mejora medida. Un agente que reintenta sin límite ni criterio de éxito es un generador de coste. La condición de parada (máximo de iteraciones, gate que autoriza el merge o escala al humano) es lo que hace el bucle seguro, y es la idea central de cómo diseñar bucles agénticos con condición de parada. Que además el bucle mejore con el tiempo es el terreno de la skill que hace que mis agentes se mejoren a sí mismos.

El esqueleto de una tarea delegable no tiene misterio. Lo que importa es dónde vive el criterio de aceptación:

Diagrama de flujo del bucle de verificación: una tarea con su criterio de aceptación entra al agente, que ejecuta y produce una salida; la salida pasa por un gate de verificación (tests, evals, guardarrailes); si aprueba, se fusiona el resultado verificado; si rechaza, el feedback vuelve al agente para un nuevo intento; al agotar los intentos, el flujo escala a un humano en lugar de fusionar — El bucle que convierte asistencia en delegación: un gate computable decide, no un humano en cada paso

// El criterio de aceptación existe antes de lanzar al agente:
// una función que solo devuelve ok si la salida es correcta.
type Verificacion = { ok: boolean; detalle: string }

async function delegar(
  tarea: string,
  aceptar: (salida: string) => Promise<Verificacion>,
  maxIntentos = 3,
): Promise<{ estado: 'merge' | 'escalar'; salida: string; motivo?: string }> {
  let feedback = ''
  let salida = ''
  for (let intento = 1; intento <= maxIntentos; intento++) {
    // agente: tu SDK de agente (Claude Agent SDK, LangGraph, etc.)
    salida = await agente.ejecutar(tarea, feedback)
    const v = await aceptar(salida)             // tests, invariantes, juez, umbral
    if (v.ok) return { estado: 'merge', salida } // el gate autoriza el merge
    feedback = v.detalle                         // reintento informado, no a ciegas
  }
  // preserva la última salida y el motivo para quien recibe la escalada
  return { estado: 'escalar', salida, motivo: feedback } // condición de parada → humano
}

// aceptar() para el caso Rakuten: ejecutar el método nuevo,
// compararlo con el de referencia y exigir coincidencia >= 0.999.

El modelo aparece en una sola línea. Todo lo demás es infraestructura de verificación, y es lo único sobre lo que tienes control real. Estos patrones (criterios de aceptación, evals, guardarrailes, bucles con condición de parada) son los que trabajamos en el curso Patrones de Diseño para Agentes de IA, porque son lo que distingue a un equipo que delega de uno que solo asiste.

Errores comunes al pasar de asistir a delegar

Delegar sin un criterio de aceptación ejecutable

Es el error raíz del que salen casi todos los demás. Si lanzas al agente sin haber definido antes qué significa que el resultado esté bien, acabas verificando cada iteración a mano y pagas el impuesto del “casi bien” (ese 66% de frustración de Stack Overflow ^[4]) una y otra vez. El oráculo primero, el agente después.

Medir la productividad por sensación

METR dejó el aviso claro: la percepción de velocidad puede desviarse casi 40 puntos de la realidad (creían +20%, era -19% ^[5]). Si tu única prueba de que “la IA nos hace más rápidos” es que el equipo lo siente así, no tienes una métrica. Tienes una encuesta de estado de ánimo.

Confundir uso con delegación cuando reportas a negocio

“Usamos IA en el 60% del trabajo” y “delegamos tareas de punta a punta” son dos frases distintas, y en la mayoría de equipos solo la primera es cierta. Reportar uso como si fuera delegación infla las expectativas y luego te explota en la cara cuando alguien pregunta qué se ha soltado de verdad. La respuesta honesta suele ser: el 0-20%.

Supervisar en continuo en lugar de por gates

Si el humano tiene que mirar cada paso del agente, no ha delegado la tarea. Ha duplicado el trabajo de revisión, y encima lo ha hecho más lento. La buena supervisión es discreta: un gate que decide y un guardarraíl que corta, con tu atención reservada para lo que de verdad escala.

¿Y si cierras la brecha, qué ganas?

No ganas “lo mismo pero más rápido”. Amplías qué es viable construir. El informe estima que cerca del 27% del trabajo asistido por IA son tareas que no se habrían hecho de otra forma: dashboards interactivos, herramientas “nice-to-have”, proyectos que escalan, exploración que a mano no salía a cuenta ^[1]. Cerrar la brecha no solo acelera el backlog existente, lo expande.

A escala organizacional el patrón se repite, y lo cito como referencia, no como promesa. Zapier alcanzó un 89% de adopción de IA en toda la organización, con más de 800 agentes internos desplegados ^[1]. TELUS construyó más de 13.000 soluciones de IA a medida, entregando código de ingeniería un 30% más rápido, con más de 500.000 horas ahorradas ^[1]. Ninguna de esas cifras sale de comprar el modelo más grande. Salen del andamiaje que hace que soltar una tarea sea seguro.

El informe cierra con el giro de rol que a mí me parece el corazón del asunto. Trend 1: “From implementer to orchestrator”. El trabajo deja de estar centrado en escribir código y pasa a orquestar agentes que lo escriben, evaluar su salida y marcar la dirección ^[1]. Y una frase que resume la postura mejor que ninguna mía: “It’s not ‘fully delegated’ but highly collaborative”. El objetivo, en sus palabras, no es sacar al humano del bucle, sino hacer que su criterio cuente donde más importa.

Ahí está lo que separa a los equipos que delegan de los que solo asisten. El juicio humano es la capa permanente del protocolo, no una fase transitoria que un modelo mejor vaya a eliminar. La brecha se cierra el día que decides construirle una infraestructura de verificación alrededor.

Fuentes

2026 Agentic Coding Trends Report (Anthropic). Cifra “roughly 60%” y “fully delegate” 0-20% y collaboration paradox; mecanismo “sniff-check on correctness” y cita del ingeniero (Trend 4); caso Rakuten 7 h / 12,5 M líneas / 99,9% (Trend 3); 27% de trabajo que no se habría hecho, TELUS y Zapier (Trends 6 y 7); “From implementer to orchestrator” e “It’s not ‘fully delegated’ but highly collaborative” (Trend 1).
How AI Is Transforming Work at Anthropic (Anthropic, Societal Impacts). Estudio del que sale el 60%: 59% del trabajo con Claude (28% doce meses antes), encuesta a 132 ingenieros más 53 entrevistas (agosto 2025), “more than half” delega solo 0-20%, productividad autopercibida +50%.
The orchestration era needs intent (Janne Lammi, Pathmode). Origen del término “delegation gap”; se cita solo para atribuir el nombre, las cifras vienen de Anthropic.
Stack Overflow Developer Survey 2025, sección AI. El 84% usa o planea usar IA (76% en 2024); 46% desconfía frente a 33% que confía; 66% de frustración con soluciones “almost right, but not quite”; 45,2% dice que depurar código de IA consume más tiempo.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR). RCT: 19% más lentos con IA; esperaban +24% y tras el estudio aún creían +20%; 16 desarrolladores, 246 issues, Cursor Pro con Claude 3.5/3.7 Sonnet.

Preguntas Frecuentes

¿Qué es la brecha de delegación en IA?

La brecha de delegación es la diferencia entre cuánto usan los desarrolladores la IA (en torno al 60% de su trabajo) y qué fracción de tareas pueden soltarle por completo sin revisarlas después (solo el 0-20%). El nombre lo popularizaron análisis del 2026 Agentic Coding Trends Report de Anthropic; el informe llama a este fenómeno the collaboration paradox.

¿De dónde salen los datos del 60% y el 0-20%?

De un estudio del equipo de Societal Impacts de Anthropic: una encuesta interna a 132 de sus ingenieros e investigadores, más 53 entrevistas cualitativas, hecha en agosto de 2025. Esos ingenieros reportaron usar Claude en el 59% de su trabajo, el doble que el 28% de un año antes, y más de la mitad dijo poder delegar por completo solo entre el 0% y el 20% de sus tareas. El “roughly 60%” del informe redondea ese 59%.

¿Se cerrará la brecha de delegación con modelos más capaces?

No por sí sola. En doce meses el uso se duplicó (del 28% al 59%) y la delegación completa no se movió del 0-20%. Lo que la limita es la verificabilidad de la tarea, y esa la construyes tú con criterios de aceptación ejecutables, evals, guardarrailes y bucles con condición de parada. Un modelo mejor genera salidas mejores, pero no te dice si son correctas.

¿Qué tareas conviene delegar por completo a un agente de IA hoy?

Las que tienen un criterio de aceptación computable y barato de ejecutar: comprobables con tests, invariantes, umbrales numéricos o un juez automático. El caso Rakuten (7 horas de trabajo autónomo verificadas al 99,9% contra un método de referencia) funcionó por eso. Si no puedes comprobar la corrección de forma automática, no la estás delegando: solo aplazas su revisión.