IA generativa vs IA agéntica: la diferencia que decide tu stack
DominicodeHace unas semanas un CTO me escribió para que le ayudara a "medir el retorno de la IA" en su equipo. Doce developers, doce licencias, una factura mensual que ya se notaba en la hoja de gastos.
Le pregunté qué hacían exactamente con ellas.
"Autocompletar. Y a veces le preguntan cosas al chat."
Ahí estaba todo. Ese equipo no tenía un problema de retorno: tenía un problema de categoría. Estaban pagando IA generativa y esperando resultados de IA agéntica.
Y la diferencia entre IA generativa vs IA agéntica no es una discusión de nomenclatura para ponentes de conferencia. Es la decisión que determina qué compras, cuánto pagas cada mes y qué trabajo puedes delegar de verdad.
En 2026, seguir describiendo el trabajo de un programador con IA como "IA generativa" es señal de llevar dos años de retraso.
Resumen rápido
- IA generativa es un sistema que produce un artefacto (texto, código, JSON) a partir de un prompt y termina ahí: no ejecuta nada, no verifica nada, no conserva estado.
- IA agéntica es un sistema que recibe un objetivo en lugar de un prompt, tiene acceso a herramientas y repite el ciclo observar → decidir → actuar → verificar hasta cumplir un criterio de parada.
- El modelo puede ser el mismo. Lo que cambia es la capa que lo envuelve: herramientas, permisos y criterio de parada.
- Regla de decisión: si existe una señal automática de verdad (tests, typecheck, build, lint) que diga si el trabajo está bien hecho, es territorio de agente. Si el único verificador eres tú leyendo, es territorio de prompt.
- Coste: un agente consume unas 4 veces más tokens que un chat; un sistema multi-agente, unas 15 (Anthropic, junio 2025).
Lo que compraste no era generativa: era autocompletado caro
El equipo de ese CTO usaba la IA exactamente igual que en 2023. Escribir media línea, aceptar la sugerencia gris. Abrir un chat, pegar un stack trace, copiar la respuesta de vuelta al editor.
Eso funciona. Ahorra minutos. Pero el trabajo sigue siendo tuyo: tú lees el repo, tú decides, tú ejecutas, tú verificas si la respuesta era correcta, tú vuelves a preguntar cuando no lo era.
La IA hace la parte fácil —escribir texto plausible— y tú te quedas con el bucle completo. Con doce licencias, lo que compras es doce veces la parte fácil.
El salto de productividad real no está en generar mejor código. Está en dejar de ser tú quien cierra el bucle.
¿Qué es la IA generativa? Tú pides, ella escupe
La IA generativa es un sistema que produce un artefacto a partir de un prompt y termina ahí. Entra un prompt, sale texto, código, un JSON, un diagrama. Se acabó.
No tiene estado. No sabe qué hay en tu repositorio salvo lo que le pegas. No sabe si su respuesta compiló. No sabe si el test pasó. No puede saberlo, porque no ejecuta nada.
Eso no es un defecto. Es el diseño. Y para tareas de un solo salto es imbatible: latencia de segundos, coste de céntimos, resultado inmediato.
Un regex complejo. El mensaje de un commit a partir de un diff. Explicar qué demonios hace esa función de 2019 que nadie toca. Convertir un objeto de ejemplo en una interfaz de TypeScript.
En todos esos casos, montar un agente es como contratar una mudanza para llevar una caja de zapatos al piso de arriba.
¿Qué es la IA agéntica? Lee, decide, ejecuta y vuelve
La IA agéntica es un sistema que recibe un objetivo en lugar de un prompt, tiene acceso a herramientas y permiso para usarlas. Aquí el contrato cambia por completo.
El agente lee ficheros. Ejecuta comandos. Mira la salida. Decide el siguiente paso a partir de lo que ha visto, no de lo que tú le contaste. Y repite hasta que se cumple un criterio de parada.
Ese mecanismo tiene nombre y lo desmonté pieza a pieza en Agentic loop: el mecanismo detrás de los agentes de IA.
Ese ciclo —observar, decidir, actuar, verificar, repetir— es todo el asunto. Lo he desarrollado a fondo en Loop Engineering: la evolución definitiva del desarrollo con IA, porque diseñar bien ese bucle es hoy más determinante que elegir modelo.
Fíjate en que el modelo puede ser exactamente el mismo. Claude generando texto en una web y Claude arreglando un test en tu CI son el mismo peso de red neuronal. Lo que cambia es lo que hay alrededor: las herramientas que le das, los permisos que aceptas, la señal que le dice si ha terminado.
Un LLM solo no es un agente, igual que un motor no es un coche. Esa capa que lo envuelve —el harness— es la que hace el trabajo, y lo expliqué en detalle en El Agentic Harness: por qué un LLM por sí solo no es un producto.
La prueba práctica para distinguirlas: pídele algo cuyo resultado no puedas predecir sin ejecutar código. "Arregla el test que falla en CI" no lo resuelve un chat, por bueno que sea el modelo. Requiere leer el log, formular una hipótesis, tocar el código y volver a ejecutar. Eso es un agente o no es nada.
Si vienes de cero con esto, la guía definitiva de Agentes de IA cubre los fundamentos y lo dejas para después de este.
IA generativa o IA agéntica: cuál usar en cada tarea
Esta es la asignación que uso a diario: a la izquierda la tarea, a la derecha la categoría que la resuelve con el menor coste y la menor latencia.
| Tarea | Generativa o agéntica | Por qué |
|---|---|---|
| Escribir un regex o una query SQL puntual | Generativa | Salida única, la verificas tú en cinco segundos |
| Redactar el mensaje de un commit | Generativa | El contexto está en el diff, no hay bucle que cerrar |
| Explicar una función o un fichero legacy que no entiendes | Generativa | Necesitas comprensión, no cambios en disco |
| Renombrar un concepto de dominio en 40 archivos | Agéntica | Hay que leer el repo, decidir caso a caso y comprobar que compila — no es el rename del IDE: cambian nombres, strings, rutas y documentación |
| Arreglar un test en rojo que puedes reproducir en local | Agéntica | Requiere hipótesis, ejecución y reintento con la salida real |
| Migrar un módulo de RxJS a Signals | Agéntica | Cambios encadenados con verificación continua vía tests |
| Generar mocks o datos de ejemplo | Generativa | Un salto, coste mínimo, no toca disco |
| Subir una dependencia mayor con breaking changes | Agéntica | El error aparece al ejecutar, no al leer |
| Escribir la primera versión de un componente aislado | Generativa | Lo revisas tú de un vistazo; el bucle no aporta |
El patrón se ve solo: si existe una señal automática de verdad —tests, typecheck, build, lint— que diga si el trabajo está bien hecho, es territorio de agente. Si el único verificador eres tú leyendo, es territorio de prompt.
El error caro: meter un agente donde bastaba un prompt
Este es el fallo que más veo desde que los agentes se pusieron de moda. Y sale caro en cuatro dimensiones.
Coste. Un agente no hace una llamada al modelo: hace decenas. Anthropic publicó las cifras de su sistema de investigación multi-agente en junio de 2025: los agentes consumen unas 4 veces más tokens que una interacción de chat, y los sistemas multi-agente unas 15 veces más. Está medido en tareas de investigación, pero el orden de magnitud se traslada. Cuando delegas a un agente algo que resolvía un prompt, estás multiplicando la factura por un trabajo idéntico.
Latencia. El chat te responde en segundos. El agente tarda minutos porque lee, ejecuta, falla, reintenta. Para una tarea de treinta segundos, esa espera es una pérdida neta de tiempo, no una ganancia.
No determinismo. Con un prompt, si la respuesta no te gusta, la descartas y ya está. Con un agente, cada ejecución toma un camino distinto: puede tocar archivos que no esperabas, reescribir un test en lugar de arreglar el código o "resolver" el fallo borrando la aserción que molestaba. Dos ejecuciones del mismo objetivo rara vez producen el mismo diff.
Superficie de fallo. Un chat solo puede equivocarse en el texto. Un agente con permisos de escritura y shell puede equivocarse en tu disco, en tu historial de git y en tu base de datos de desarrollo. Cada herramienta que le das es potencia y es riesgo, en la misma proporción.
Resumido en una tabla:
| Dimensión | Prompt (generativa) | Agente (agéntica) |
|---|---|---|
| Coste | Una llamada al modelo | Decenas de llamadas: ~4x tokens, ~15x si es multi-agente |
| Latencia | Segundos | Minutos: lee, ejecuta, falla, reintenta |
| Determinismo | Descartas la respuesta y repites | Cada ejecución toma un camino distinto |
| Superficie de fallo | El texto que devuelve | Tu disco, tu historial de git, tu base de datos de desarrollo |
Mi regla, sin matices: si puedes verificar el resultado leyéndolo en menos de un minuto, no necesitas un agente.
Cómo migrar tu flujo de una a otra en 3 pasos
Si hoy vives en el chat y quieres pasar al bucle, no empieces instalando frameworks. Empieza por aquí.
1. Cierra el bucle de verificación antes de dar un solo permiso
Un agente sin forma de comprobar su propio trabajo es un generador de texto con acceso a tu disco. Es la peor combinación posible.
Antes de delegar nada, asegúrate de que existe un comando que responde sí o no:
# El criterio de parada del agente: un comando que responde sí o no
npm test && npx tsc --noEmit && npm run lint
Ese comando es el criterio de parada. Si tu proyecto no tiene tests que corran rápido y en verde, tu primer trabajo agéntico es conseguirlos —y si trabajas con Angular y andas flojo ahí, el curso de Testing en Angular con Jest y Testing Library resuelve justo esa base.
Sin señal de verdad no hay agente. Hay ruleta.
2. Escribe la especificación, no el prompt
Un prompt describe una petición. Una especificación describe un resultado esperado, sus límites y qué queda fuera del alcance.
La diferencia importa porque el agente va a tomar cientos de microdecisiones que tú no vas a supervisar. Todo lo que no esté escrito lo va a inventar.
Es la metodología que uso a diario y la que documenté entera en el libro de Spec-Driven Development: especificar primero, delegar después. Cambia el resultado más que cambiar de modelo.
3. Empieza por una tarea aburrida, acotada y reversible
Nada de "refactoriza la arquitectura". Elige algo que te lleve entre veinte y cuarenta minutos a mano, con criterio de éxito objetivo y sobre una rama nueva.
Migrar un módulo. Añadir tests a un servicio. Actualizar una dependencia. Ejecuta, revisa el diff completo, mide cuánto ha tardado y cuánto has tenido que corregir.
Si quieres ver ese primer trabajo delegado en la terminal, lo hago paso a paso con Claude Code.
Sube el listón solo cuando esa tarea salga limpia dos veces seguidas. Y cuando llegue el momento de elegir herramientas de verdad, tengo mi criterio completo en Stack IA agéntica en 2026: qué usar, qué ignorar y cuál elijo.
La pregunta que resuelve el 90% de las decisiones
No memorices la tabla. Quédate con una sola pregunta antes de abrir cualquier herramienta:
¿Existe una señal automática que diga si el trabajo está bien hecho?
Si existe, delega el bucle: es trabajo de agente. Si no existe, el bucle eres tú, y lo que necesitas es un buen prompt y tus ojos encima.
Esa pregunta te ahorra factura y sustos.
Si quieres ver el bucle completo montado de principio a fin —del objetivo a un producto funcionando, con especificaciones, herramientas y verificación— es exactamente lo que construimos en el curso Construye con IA. Y si prefieres hacerlo acompañado, con proyectos reales y gente que ya está en esto, te espero en Dominicode Labs.
Preguntas frecuentes
¿Cuál es la diferencia entre IA generativa e IA agéntica?
La IA generativa produce un artefacto a partir de un prompt y ahí termina: no ejecuta código, no verifica su propia salida y no conserva estado entre peticiones. La IA agéntica recibe un objetivo, dispone de herramientas para leer ficheros y ejecutar comandos, y repite el ciclo observar, decidir, actuar y verificar hasta cumplir un criterio de parada. El modelo subyacente puede ser el mismo en ambos casos; lo que cambia es la capa que lo envuelve. La prueba práctica para distinguirlas es pedir algo cuyo resultado no puedas predecir sin ejecutar código: eso solo lo resuelve un agente.
¿La IA agéntica sustituye a la IA generativa?
No. La agéntica se construye encima de la generativa: el modelo que razona dentro del agente es el mismo tipo de modelo que responde en un chat. Lo que cambia es la capa que lo envuelve, con herramientas, permisos y un criterio de parada. En un flujo de trabajo real conviven las dos, y la mayoría de tus interacciones diarias seguirán siendo generativas porque son más rápidas y más baratas.
¿Cuánto más caro sale usar un agente en vez de un chat?
Entre 4 y 15 veces más en consumo de tokens. Según los datos publicados por Anthropic en junio de 2025, un agente consume alrededor de 4 veces más tokens que una interacción de chat, y un sistema multi-agente unas 15 veces más. La cifra exacta depende del modelo y de la tarea, pero el orden de magnitud es ese: el agente solo compensa cuando la tarea es suficientemente valiosa como para justificar el gasto.
¿Un chat con acceso a herramientas ya es un agente?
Solo si cierra el bucle. Ejecutar una búsqueda web y devolverte el resultado sigue siendo un salto único. Un agente encadena decisiones: usa la salida de una herramienta para elegir la siguiente acción, evalúa si ha cumplido el objetivo y reintenta cuando no. Si el sistema no puede reintentar por su cuenta a partir de lo que ha observado, es un chat con extras.
¿Necesito un framework de agentes para empezar?
No al principio. Los asistentes de terminal actuales — Claude Code, Codex CLI, Gemini CLI — ya traen el bucle implementado, y con eso cubres la mayoría de tareas de desarrollo diario. El framework empieza a tener sentido cuando construyes un agente propio para un producto: cuando necesitas orquestar varios pasos, persistir estado entre ejecuciones o exponer herramientas específicas de tu dominio.
¿Qué tareas no delegaría hoy a un agente?
Tres tipos. Las que no tienen verificación automática, porque no hay forma de saber si acertó sin revisarlo todo a mano. Las irreversibles: migraciones sobre datos de producción, borrados, despliegues sin rollback. Y las decisiones de arquitectura, porque un agente optimiza para que el criterio de parada se cumpla, no para que el sistema siga siendo mantenible dentro de dos años. Esa parte todavía es tuya.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.