Desarrollo agéntico: qué dice la evidencia real y qué debe cambiar en tu equipo antes de adoptarlo

En julio de 2025, METR publicó el estudio que se convirtió en el argumento favorito de todos los escépticos de la IA en programación: desarrolladores experimentados tardaban un 19% más en completar sus tareas cuando podían usar herramientas de IA, a pesar de que ellos mismos estimaban después haber ido un 20% más rápido.

En febrero de 2026, los propios autores publicaron algo mucho más interesante: van a cambiar el diseño del experimento porque ya no consigue medir nada fiable. ¿La razón principal? Un número significativo de desarrolladores invitados se negaba a participar si tenía que trabajar sin IA.

Ese arco —de "la IA te hace más lento" a "ya no podemos medirlo porque nadie quiere trabajar sin ella"— es la mejor introducción posible al desarrollo agéntico. Porque describe con precisión dónde estamos: la adopción es masiva, la evidencia sobre productividad es ambigua, y la variable que sí predice resultados no es el modelo que uses, sino el sistema de ingeniería en el que lo metes.

Este artículo trata de eso.

¿Qué es realmente el desarrollo agéntico?

El desarrollo agéntico es el uso de agentes de IA que ejecutan ciclos de planificar, actuar con herramientas, verificar el resultado e iterar, dentro de un presupuesto acotado y bajo revisión humana. La diferencia con un copiloto no es la calidad del código generado: es que el agente puede llamar a herramientas, leer el resultado de esa llamada y corregirse.

Un copiloto sugiere. Un agente ejecuta un ciclo cerrado. Esa distinción cambia dónde está el riesgo.

Con autocompletado, el peor caso es una sugerencia mala que tú descartas en dos segundos. Con un agente, el peor caso es una cadena de cuatro pasos donde el error del paso uno se propaga y el resultado final parece plausible. Por eso las dos piezas que realmente importan en un sistema agéntico no son el prompt ni el modelo, sino el validador de salida y el presupuesto de pasos.

En la práctica, un agente aparece en cuatro momentos del trabajo: descomponer una petición en tareas, escribir o modificar código, ejecutar tests o comprobaciones, y corregir tras el feedback. El único de esos cuatro que la mayoría de equipos no tiene resuelto es el tercero. Y sin el tercero, los otros tres son generación de texto con extra pasos.

¿Los agentes hacen más rápidos a los equipos?

La respuesta honesta es que nadie lo ha medido bien todavía, y conviene desconfiar de quien afirme lo contrario en cualquiera de las dos direcciones.

El estudio de METR de julio de 2025 fue el intento más riguroso hasta la fecha: un ensayo controlado aleatorizado con 16 desarrolladores experimentados sobre 246 tareas reales en sus propios repositorios, con una media de cinco años de experiencia en esos proyectos. El resultado fue que permitir el uso de IA aumentaba el tiempo de completado un 19%, cuando los propios desarrolladores habían pronosticado antes de empezar una reducción del 24%. El intervalo de confianza, eso sí, era amplio: entre +2% y +39%.

Lo que ocurrió después importa más que el titular. METR arrancó un nuevo experimento en agosto de 2025 con un grupo mayor de desarrolladores y herramientas más recientes, y concluyó que los datos ofrecían una señal poco fiable del efecto actual, principalmente porque un número creciente de participantes rechazaba entrar en el estudio al no querer trabajar sin IA. También bajaron la remuneración de 150 a 50 dólares por hora, lo que introdujo su propio sesgo de selección, y detectaron que el tiempo por tarea deja de ser medible cuando alguien opera varios agentes en paralelo.

Los números revisados apuntan en otra dirección, aunque con incertidumbre enorme: para el subconjunto de desarrolladores originales que repitieron, la estimación pasó a una aceleración del 18% con un intervalo entre -38% y +9%, mientras que entre los recién reclutados la estimación fue del 4%, con intervalo entre -15% y +9%. Intervalos que cruzan el cero no son evidencia de nada concluyente.

Hay un dato dentro de todo esto que sí es sólido y que casi nadie cita: la brecha entre percepción y medición. Los desarrolladores del estudio original creían haber acelerado un 20% mientras el cronómetro decía lo contrario. Eso significa que cualquier afirmación sobre productividad basada en encuestas internas —"el equipo dice que va más rápido"— no vale como evidencia. Si vas a justificar una inversión en herramientas agénticas, necesitas medir tiempo de ciclo y tasa de fallo en producción, no sensaciones.

¿Por qué los agentes amplifican los problemas del equipo en lugar de resolverlos?

Porque no cambian el sistema, lo aceleran. El informe DORA de 2025 sobre desarrollo asistido por IA, basado en casi 5.000 profesionales, resume su hallazgo central en una frase: la IA no arregla un equipo, amplifica lo que ya hay.

El detalle técnico es más útil que la metáfora. DORA encontró que una mayor adopción de IA se asocia simultáneamente con más throughput de entrega y más inestabilidad de entrega, y que el tiempo ahorrado en la creación de código se reasigna con frecuencia a auditoría y verificación. Es decir: el cuello de botella no desaparece, se desplaza aguas abajo. Pasa de "escribir" a "revisar".

Eso tiene una consecuencia operativa concreta que rara vez se planifica. Si tu equipo genera el triple de pull requests y mantiene la misma capacidad de revisión, no has multiplicado la velocidad: has creado una cola. Y una cola de revisión saturada es exactamente el entorno donde el código mediocre pasa por aprobado.

La conclusión de DORA es que el mayor retorno no viene de las herramientas, sino de la calidad de las plataformas internas, la claridad de los flujos de trabajo y la alineación de los equipos. Traducido a decisión de arquitectura: antes de preguntar qué agente adoptar, pregunta si tu repositorio tiene una suite de tests en la que confíes lo suficiente como para dejar que algo automático la use como criterio de verdad.

Si la respuesta es no, el agente no es tu siguiente inversión. Los tests lo son.

He visto este patrón en mi propio sitio, sin necesidad de un equipo grande. Publicar un artículo aquí implica tocar cuatro o cinco archivos: la página, el registro en articles.ts, el JSON-LD, llms.txt, el filtro de categorías. Delegar esa integración a un agente funciona bien y es cuestión de minutos. El problema es que el resultado siempre parece terminado: la página compila, el build pasa, el sitio renderiza. Los fallos que he encontrado revisando —un slug registrado en el array equivocado, un campo de schema copiado de otro artículo sin ajustar— no los detecta ningún test que yo tenga hoy. El generador me ahorra el trabajo mecánico. El verificador sigo siendo yo, y ahí es donde se va el tiempo real.

Es la misma restricción que aplico al construir agentes de IA para clientes: el techo no lo pone lo que el agente es capaz de generar, sino lo que se puede verificar antes de que llegue a producción.

¿Cómo se ve un ciclo agéntico controlado en Next.js?

Un ciclo agéntico mínimo pero real tiene tres elementos que un ejemplo de juguete no tiene: un contrato de salida validado, un registro de herramientas con argumentos tipados, y un presupuesto de pasos. Sin los tres, no es un agente: es una llamada a un modelo dentro de un bucle.

Primero, el contrato. El modelo no devuelve texto libre: devuelve una de tres formas posibles, y cualquier otra cosa se rechaza antes de ejecutar nada.

import { z } from "zod";

export const DecisionSchema = z.discriminatedUnion("tipo", [
  z.object({
    tipo: z.literal("usar_herramienta"),
    herramienta: z.enum(["consultar_inventario", "calcular_envio"]),
    argumentos: z.record(z.string(), z.unknown()),
    motivo: z.string().max(240),
  }),
  z.object({
    tipo: z.literal("responder"),
    respuesta: z.string().min(1),
    confianza: z.number().min(0).max(1),
  }),
  z.object({
    tipo: z.literal("rendirse"),
    motivo: z.string().min(1),
  }),
]);

export const HERRAMIENTAS = {
  consultar_inventario: {
    entrada: z.object({ sku: z.string().regex(/^[A-Z]{3}-\d{4}$/) }),
    ejecutar: async ({ sku }: { sku: string }) => {
      // Aquí iría la consulta real a la base de datos.
      return { sku, disponible: 12, almacen: "CCS-01" };
    },
  },
  calcular_envio: {
    entrada: z.object({ sku: z.string(), destino: z.string().min(2) }),
    ejecutar: async ({ destino }: { sku: string; destino: string }) => {
      return { destino, dias: 3, costo_usd: 8.5 };
    },
  },
} as const;

Fíjate en el detalle que se salta casi todo el mundo: los argumentos de la herramienta se validan por separado del contrato general. Que el modelo diga "quiero usar consultar_inventario" no significa que el SKU que propone sea válido. Esa segunda validación es la que evita que una alucinación llegue a tu base de datos.

Ahora el bucle. Nótese que no hay recursión infinita ni "el agente decide cuándo parar": hay un presupuesto explícito.

import { NextResponse } from "next/server";
import { DecisionSchema, HERRAMIENTAS } from "./_contrato";

const MAX_PASOS = 4;

export async function POST(request: Request) {
  const { tarea } = await request.json();
  if (typeof tarea !== "string" || tarea.length < 3) {
    return NextResponse.json({ error: "Tarea inválida" }, { status: 400 });
  }

  const traza: unknown[] = [];
  const observaciones: string[] = [];

  for (let paso = 0; paso < MAX_PASOS; paso++) {
    const bruto = await pedirDecision(tarea, observaciones);
    const decision = DecisionSchema.safeParse(bruto);

    // El contrato falla: no se ejecuta nada, se devuelve el error al modelo.
    if (!decision.success) {
      observaciones.push(`Salida fuera de esquema. Corrige y reintenta.`);
      traza.push({ paso, resultado: "esquema_invalido" });
      continue;
    }

    const d = decision.data;

    if (d.tipo === "responder") {
      traza.push({ paso, resultado: "respuesta", confianza: d.confianza });
      return NextResponse.json({ estado: "ok", respuesta: d.respuesta, traza });
    }

    if (d.tipo === "rendirse") {
      traza.push({ paso, resultado: "rendicion" });
      return NextResponse.json({ estado: "sin_solucion", motivo: d.motivo, traza });
    }

    // Segunda validación: los argumentos concretos de esta herramienta.
    const herramienta = HERRAMIENTAS[d.herramienta];
    const args = herramienta.entrada.safeParse(d.argumentos);

    if (!args.success) {
      observaciones.push(`Argumentos inválidos para ${d.herramienta}.`);
      traza.push({ paso, resultado: "argumentos_invalidos" });
      continue;
    }

    const salida = await herramienta.ejecutar(args.data as never);
    observaciones.push(`${d.herramienta} devolvió: ${JSON.stringify(salida)}`);
    traza.push({ paso, resultado: "herramienta", herramienta: d.herramienta });
  }

  // Se agotó el presupuesto sin conclusión: eso también es un resultado válido.
  return NextResponse.json({ estado: "presupuesto_agotado", traza }, { status: 200 });
}

Lo importante de este ejemplo no es el código en sí, sino tres decisiones de diseño:

1. El agente nunca ejecuta una acción que no haya pasado por dos validaciones. El esquema general y los argumentos específicos.
2. Agotar el presupuesto es un estado legítimo, no un error. Un agente que siempre devuelve algo es un agente que a veces inventa.
3. La traza se devuelve siempre. Sin traza no hay depuración posible, y un sistema agéntico sin observabilidad es una caja negra que escribe en tu producción.

¿Qué hace que un repositorio sea apto para agentes?

Hay un estándar concreto que responde a media pregunta. AGENTS.md es un formato abierto pensado como un README para agentes: un lugar predecible donde dejar el contexto, los pasos de compilación, los tests y las convenciones que un agente necesita y que ensuciarían un README para humanos. Desde su publicación en agosto de 2025 lo han adoptado más de 60.000 proyectos de código abierto y frameworks como Codex, Cursor, Gemini CLI, GitHub Copilot y Jules, y el formato fue donado a la Agentic AI Foundation bajo la Linux Foundation. Claude Code lee CLAUDE.md en su lugar, y la solución habitual es importar AGENTS.md desde ahí.

Que un formato tan simple se haya vuelto estándar dice algo: el problema real no era la capacidad del modelo, era que nadie le decía cómo se compila el proyecto.

La otra mitad de la respuesta no tiene estándar y depende de ti. Un repositorio apto para agentes necesita:

• Comandos deterministas. Un npm test que a veces falla por flakiness convierte al verificador en ruido.
• Tests rápidos. Si la suite tarda 20 minutos, el agente no puede iterar; solo puede adivinar.
• Tipado estricto. TypeScript en modo estricto es el detector de errores más barato que puedes darle a un agente.
• Datos de prueba sembrados. Un agente que no puede levantar el entorno no puede verificar nada.
• Presupuesto de revisión humana explícito. Si generas más PRs de los que puedes revisar, has empeorado el proceso, no mejorado.

Ninguno de esos cinco puntos es nuevo. Todos son buenas prácticas de ingeniería de hace quince años. Esa es exactamente la conclusión de DORA: la IA no premia a quien la adopta primero, premia a quien ya tenía la casa en orden.

¿Qué debería hacer un equipo antes de adoptar desarrollo agéntico?

Tres cosas, en este orden.

Primero, medir el estado actual de verdad. Tiempo de ciclo, tasa de fallos en producción, tiempo medio en revisión de PR. Si no tienes esa línea base antes de introducir agentes, nunca sabrás si funcionaron — y ya sabemos que la percepción del equipo no sirve como evidencia.

Segundo, arreglar el verificador antes que el generador. Tests, tipos, CI. Un agente sin un criterio de verdad fiable produce código que parece correcto, y "parece correcto" es la categoría de bug más cara que existe.

Tercero, acotar el alcance. Los agentes rinden donde el trabajo está estructurado: migraciones repetitivas, cobertura de tests, refactors mecánicos, andamiaje de CRUD — buena parte del trabajo mecánico de un sistema de gestión a medida cae justo ahí. Rinden mal donde el problema es ambiguo o el contexto vive en la cabeza de alguien. Empezar por lo segundo es la forma más rápida de concluir que "esto no funciona".

El desarrollo agéntico no sustituye ingenieros. Redistribuye el trabajo: menos escritura, más definición de límites y más revisión. Los equipos que salgan ganando no serán los que automaticen más, sino los que hayan construido el sistema de verificación que hace segura esa automatización.

Preguntas frecuentes

¿Qué es el desarrollo agéntico?

El desarrollo agéntico es el uso de agentes de IA que ejecutan ciclos de planificar, actuar con herramientas, verificar el resultado e iterar, dentro de un presupuesto de pasos acotado y bajo revisión humana. Se diferencia de la generación de código asistida en que el agente no solo produce texto: llama a herramientas reales — ejecutar los tests, leer archivos, consultar una API —, lee el resultado de esa llamada y se corrige con él. Sin esa fase de verificación no es desarrollo agéntico, es autocompletado dentro de un bucle.

¿Qué diferencia hay entre un agente de IA y un chatbot?

Un chatbot mantiene una conversación y devuelve texto: todo lo que produce lo tiene que ejecutar una persona. Un agente de IA tiene acceso a herramientas y actúa sobre sistemas reales — escribir un archivo, lanzar una consulta, ejecutar un comando —, encadenando varios de esos pasos y leyendo el resultado de cada uno. Por eso el riesgo es distinto: la peor salida de un chatbot es una respuesta equivocada que tú descartas; la de un agente es una acción equivocada ya ejecutada. Esa es la razón por la que un agente necesita validación automática de sus salidas y un límite explícito de iteraciones, y un chatbot no.

¿Los agentes de IA realmente aumentan la productividad de los desarrolladores?

Depende del contexto, y hoy no existe una medición limpia que permita afirmarlo de forma universal. El ensayo controlado de METR (julio de 2025) encontró una ralentización del 19% en un conjunto reducido de tareas, con desarrolladores muy experimentados trabajando en sus propios repositorios y con un intervalo de confianza amplio; en febrero de 2026 los propios investigadores rediseñaron el experimento al detectar limitaciones metodológicas. El informe DORA de 2025, sobre casi 5.000 profesionales, midió algo distinto y compatible: mayor adopción de IA se asocia a la vez con más throughput de entrega y más inestabilidad de entrega. El dato más sólido es el menos citado: los desarrolladores del estudio original creían haber acelerado un 20% mientras el cronómetro decía lo contrario, así que las encuestas internas de percepción no sirven como evidencia.

¿Qué es AGENTS.md y para qué sirve?

Es un archivo Markdown en la raíz del repositorio que funciona como un README para agentes de IA: comandos de build, cómo ejecutar los tests, convenciones de código y el contexto que un agente necesita y que ensuciaría un README para humanos. Sirve para que el agente conozca los comandos del proyecto en lugar de deducirlos, que es la causa más común de que rinda mal en un repositorio ajeno. Es un formato abierto adoptado por más de 60.000 proyectos de código abierto y donado a la Agentic AI Foundation bajo la Linux Foundation. Claude Code lee CLAUDE.md en su lugar, y la práctica habitual es importar AGENTS.md desde ahí para no mantener dos documentos.

¿Qué características debe tener un repositorio para aprovechar el desarrollo agéntico?

Comandos de build y test deterministas — una suite que falla de forma intermitente convierte al verificador en ruido —, tests rápidos para que el agente pueda iterar en lugar de adivinar, tipado estricto como detector de errores más barato, datos de prueba sembrados para que el entorno se pueda levantar, y capacidad real de revisión humana para el volumen adicional de cambios. Ninguna de esas cinco condiciones es específica de la IA: son buenas prácticas de ingeniería de hace quince años. Si la suite de tests no es confiable, el agente carece de criterio de verdad y su verificación no vale nada.

¿Cuándo no merece la pena utilizar agentes de IA en un proyecto?

Cuando falta el criterio de verdad o cuando el problema es ambiguo. En concreto: si la suite de tests no es fiable o no existe, si el entorno no se puede levantar de forma reproducible, si el equipo no tiene capacidad de revisar el volumen extra de cambios, o si el contexto necesario para resolver la tarea vive en la cabeza de alguien y no está escrito en ninguna parte. Los agentes rinden en trabajo estructurado — migraciones repetitivas, cobertura de tests, refactors mecánicos, andamiaje de CRUD — y rinden mal en decisiones de diseño ambiguas. Empezar por lo segundo es la forma más rápida de concluir que esto no funciona.