Un autocompletado propone las siguientes líneas dentro de una tarea que ya está ejecutando una persona. Un chat puede producir un fragmento de código o explicar un error. Un agente de código recibe un objetivo, explora archivos, modifica el repositorio, ejecuta herramientas y utiliza los resultados para decidir los siguientes pasos.
La diferencia no es solo cuantitativa. Cambia la unidad de interacción: pasamos de aceptar texto generado a delegar una parte del trabajo.
Esa delegación puede terminar en un diff, una pull request o un diagnóstico. No significa que el sistema comprenda el producto como una persona ni que sea autónomo dentro de la organización. Significa que un modelo puede dirigir un conjunto de herramientas durante varios pasos, dentro de unos límites determinados.
Para un líder técnico, la pregunta importante no es si el agente escribe código impresionante en una demostración. La pregunta es qué parte del flujo puede delegarse con un coste razonable, un riesgo aceptable y evidencia suficiente para comprobar el resultado.
Cuatro niveles que no conviene mezclar
Autocompletado
Predice código dentro del archivo actual. La persona conserva la secuencia de trabajo y acepta o rechaza fragmentos pequeños.
Chat con contexto
Responde preguntas o genera cambios a partir de archivos seleccionados. Puede trabajar con bastante contexto, pero no necesariamente ejecuta el resultado ni observa sus consecuencias.
Agente interactivo
Explora, edita y ejecuta comandos mientras una persona supervisa el proceso. Por ejemplo, puede implementar un cambio, ejecutar los tests y corregir la implementación después de detectar un fallo.
Agente delegado
Recibe una unidad de trabajo y devuelve una propuesta posteriormente, muchas veces mediante una pull request. Su ejecución puede ser asíncrona y la persona no necesita observar cada paso.
Este modelo requiere confiar más en los límites de ejecución, los permisos, las trazas y los mecanismos de validación.
Una organización que afirma usar agentes puede encontrarse en cualquiera de estos niveles. Comparar productividad sin distinguirlos conduce fácilmente a conclusiones equivocadas.
El bucle cambia de escribir a especificar y evaluar
En el flujo tradicional, una persona investiga, decide, implementa y verifica. Con un agente, todas estas actividades continúan existiendo, pero pueden distribuirse de otra forma:
intención
-> contexto y criterios
-> exploración
-> propuesta
-> ejecución y feedback
-> revisión
-> integración
-> observación
La generación reduce el coste de producir una propuesta. No reduce automáticamente el coste de determinar si esa propuesta corresponde realmente a la intención.
Si el repositorio tiene contratos claros, pruebas fiables y feedback rápido, un agente puede recorrer buena parte de este bucle con bastante autonomía.
Si el proyecto depende de conocimiento tácito, pruebas frágiles y decisiones que nunca se documentaron, el agente puede generar cambios aparentemente razonables que después obliguen a reconstruir todo ese contexto durante la revisión.
La experiencia reciente con la adopción de IA apunta precisamente a este patrón: los equipos con buenos procesos suelen aprovechar mejor estas herramientas, mientras que las debilidades existentes también pueden amplificarse.
Producir cambios más deprisa no mejora por sí mismo el sistema que debe especificarlos, validarlos e integrarlos.
La productividad no es velocidad de tecleo
Medir líneas generadas, sugerencias aceptadas o pull requests abiertas mide actividad, no necesariamente resultados.
Una evaluación útil debería contemplar el ciclo completo:
- tiempo hasta que una capacidad útil llega a producción;
- tasa de retrabajo y regresiones;
- tiempo dedicado a revisión;
- estabilidad del cambio;
- interrupciones y carga cognitiva;
- coste de modelos e infraestructura;
- mantenimiento posterior;
- impacto sobre seguridad y operación.
Existe además una asimetría de contexto.
Generar otro diff puede tener un coste marginal pequeño para el agente. Revisarlo exige que una persona comprenda la intención, las restricciones y los posibles efectos laterales.
Quien vuelve sobre código propio puede conservar parte de ese contexto. Quien recibe una tarea delegada normalmente necesita reconstruirlo.
Esto no significa que el código generado por IA sea siempre más difícil de revisar que el código escrito por otra persona. Significa que el tiempo de revisión, las interrupciones y el retrabajo deben considerarse parte del coste de la solución.
Los estudios disponibles tampoco permiten una conclusión simple sobre productividad.
Algunas mediciones muestran mejoras importantes en determinadas tareas, mientras que otras han encontrado resultados neutros o incluso negativos en contextos concretos.
Uno de los experimentos controlados más citados, publicado en 2025, observó que un grupo reducido de desarrolladores experimentados tardó más en completar determinadas tareas cuando podía utilizar herramientas de IA.
El resultado era interesante porque medía tiempo real y no únicamente percepción, pero tenía un alcance muy concreto: desarrolladores expertos, repositorios que conocían bien y herramientas disponibles a principios de 2025.
Datos posteriores con herramientas más recientes apuntaron a una posible mejora, aunque los propios investigadores consideraron que no existía todavía evidencia suficiente para estimar con precisión la magnitud del efecto.
Por tanto, afirmar que la IA siempre acelera el desarrollo sería tan poco riguroso como afirmar que siempre lo ralentiza.
También aparece otra diferencia interesante: muchos desarrolladores perciben mejoras de productividad mientras mantienen cierta desconfianza hacia la precisión de los resultados generados.
Las dos cosas pueden ser ciertas.
La productividad depende de la tarea, la herramienta, la experiencia del desarrollador, la calidad del repositorio, el proceso de revisión y, sobre todo, de la calidad del mecanismo utilizado para decidir si el resultado es correcto.
Dónde aparece valor primero
Los agentes suelen ofrecer mejor encaje cuando el trabajo tiene un resultado observable y un espacio de decisión relativamente acotado:
- corregir un fallo que puede reproducirse y dispone de pruebas fiables;
- actualizar una API mecánica en consumidores conocidos;
- añadir cobertura siguiendo patrones existentes;
- investigar dependencias y producir un diagnóstico verificable;
- ejecutar una migración repetitiva mediante checkpoints;
- preparar documentación derivada del código actual;
- implementar una unidad pequeña con criterios explícitos.
El valor potencial disminuye cuando la tarea contiene decisiones de producto sin un responsable claro, exige negociar prioridades, depende de accesos humanos o carece de un buen criterio para determinar si el resultado es correcto.
A este último elemento se le suele llamar oráculo: el mecanismo que permite decidir si una solución es válida.
Pedir simplemente:
Diseña una arquitectura mejor.
deja al agente demasiada libertad para interpretar qué significa mejor.
En cambio:
Reduce estas dos dependencias manteniendo estos contratos
y demuéstralo ejecutando estos consumidores.
convierte el trabajo en una delegación mucho más evaluable.
La diferencia no está únicamente en escribir mejores prompts. Está en definir mejor el trabajo.
El cuello de botella puede desplazarse a la capacidad de aceptar
Un agente puede producir en minutos un diff que después necesita horas para comprenderse y validarse.
Si varias tareas trabajan simultáneamente, el equipo puede saturar revisión, integración continua y entornos compartidos mucho antes de saturar la capacidad de implementación.
La capacidad de generación y la capacidad de aceptación son diferentes:
generar -> revisar -> validar -> integrar -> desplegar -> observar
^
el cuello de botella puede desplazarse
Aumentar la tasa local de generación sin aumentar la salida total del sistema produce inventario: ramas envejecidas, pull requests grandes, feedback tardío y decisiones incompatibles.
Eso no es necesariamente más throughput. Puede ser simplemente más trabajo iniciado.
Este comportamiento ya es conocido en ingeniería y gestión de flujos de trabajo.
En un sistema estable, la cantidad de trabajo en curso, la velocidad con la que el sistema lo completa y el tiempo medio que permanece dentro del flujo están relacionados.
La conocida Ley de Little lo expresa así:
L = λW
La fórmula no identifica qué componente ha generado un cuello de botella ni explica por qué apareció. Su utilidad aquí es más sencilla: recuerda que acelerar una fase concreta no implica acelerar todo el sistema.
Por eso una adopción de agentes también debe controlar el trabajo en curso.
En determinadas situaciones puede aportar más valor un agente que cierre una tarea pequeña con evidencia suficiente que cinco agentes abriendo cambios simultáneos.
Las buenas prácticas sobre cambios pequeños ya eran importantes antes de la IA. Con agentes adquieren todavía más valor porque una unidad de trabajo pequeña resulta más fácil de comprender, revisar, rechazar y revertir.
La revisión humana cambia de objeto
Revisar código generado línea por línea sin comprender primero la intención es una revisión insuficiente, igual que lo sería con código escrito por una persona.
La revisión debería cubrir distintas capas:
- Intención: ¿resuelve realmente el problema autorizado?
- Arquitectura: ¿respeta los contratos, límites y fuentes de verdad?
- Comportamiento: ¿qué evidencia demuestra los caminos positivos y negativos?
- Seguridad: ¿amplía permisos, acceso a red, entradas o dependencias?
- Operación: ¿cómo falla, cómo se observa y cómo se revierte?
- Mantenibilidad: ¿el equipo podrá evolucionarlo sin depender del agente que lo creó?
La explicación proporcionada por el modelo puede orientar la inspección, pero no demuestra que el cambio haga lo que afirma.
La evidencia debe encontrarse en el código, los contratos, las pruebas y otros resultados reproducibles.
Tampoco es suficiente que el mismo agente escriba implementación y pruebas.
El agente puede incorporar el mismo supuesto equivocado en ambos elementos. El resultado puede quedar completamente en verde y seguir siendo incorrecto respecto al requisito real.
A veces este problema se describe como pruebas tautológicas o ilusión de cobertura.
El problema real es que implementación y prueba pueden compartir el mismo error de interpretación.
Cuando el riesgo aumenta conviene combinar mecanismos de verificación con procedencias diferentes:
- pruebas de contrato ya existentes;
- análisis estático;
- pruebas de integración o navegador;
- revisión de permisos;
- comparación con datos conocidos;
- evaluación humana del resultado.
Cuanto mayor sea el impacto de una acción, menos razonable resulta depender de una única fuente de validación.
Implantar IA es diseñar un sistema de trabajo
Comprar licencias y pedir al equipo que use IA no constituye por sí mismo una estrategia de adopción.
Una implantación profesional debería responder al menos a estas preguntas:
- qué problemas queremos resolver;
- qué casos de uso tienen realmente sentido;
- qué datos y repositorios pueden utilizarse;
- qué acciones puede ejecutar cada modalidad de agente;
- qué permisos necesita;
- qué tareas comienzan como piloto;
- qué instrucciones y políticas debe respetar;
- quién mantiene esas instrucciones;
- qué evidencia requiere cada nivel de riesgo;
- quién sigue siendo responsable del resultado;
- cómo se registran uso, coste, errores y retrabajo;
- qué métricas determinan si el piloto funciona;
- cuándo detener, limitar o revertir la adopción.
La clasificación por riesgo resulta especialmente importante.
No debería recibir el mismo nivel de autonomía un agente que actualiza documentación que otro capaz de modificar autenticación, migrar datos o desplegar en producción.
También conviene separar experimentación y producción.
Un entorno descartable permite probar comportamientos que no deberían ejecutarse directamente desde un equipo con credenciales de producción ni desde un runner con permisos elevados.
La política puede ser proporcional:
- documentación: revisión editorial;
- refactor interno: pruebas del módulo y revisión del diff;
- actualización de dependencias: análisis de consumidores y cadena de suministro;
- autenticación: revisión especializada, pruebas negativas e integración;
- migración de datos: ensayo, reconciliación y mecanismo de reversión;
- producción: autorización explícita y credenciales separadas.
El principio es sencillo: cuanto mayor es el impacto posible de una acción, mayores deben ser las restricciones y la evidencia necesaria para autorizarla.
No se trata de impedir el uso de la herramienta. Se trata de evitar que la propia herramienta determine implícitamente cuánto debemos confiar en ella.
Antes de escalar, hay que medir
Una implantación de IA debería comenzar con una línea base.
Sin ella resulta muy difícil saber si el nuevo flujo realmente mejora el anterior.
Antes de introducir agentes en una categoría de trabajo pueden medirse, por ejemplo:
tiempo de ciclo
+ tiempo de revisión
+ retrabajo
+ defectos posteriores
+ coste
+ satisfacción del equipo
Después puede compararse el mismo tipo de trabajo utilizando el nuevo flujo.
Esto no requiere diseñar un experimento científico perfecto. Requiere simplemente evitar que impresiones como parece mucho más rápido sustituyan completamente a los resultados.
También conviene medir por tipo de tarea.
Un agente puede generar una mejora importante en migraciones mecánicas y aportar mucho menos en decisiones arquitectónicas ambiguas.
Agrupar ambos escenarios en una única métrica de productividad con IA puede ocultar más información de la que aporta.
Por eso la unidad de adopción debería ser el caso de uso, no la herramienta.
No deberíamos empezar preguntando:
¿Cómo implantamos agentes de IA?
sino:
¿Qué parte de nuestro trabajo queremos mejorar
y cómo sabremos si realmente ha mejorado?
A partir de ahí se elige la herramienta y el nivel de autonomía adecuado.
Qué habilidades ganan valor
Cuando producir una implementación resulta más barato, aumentan de valor las capacidades que permiten decidir qué implementación merece aceptarse:
- modelar dominios y contratos;
- recuperar conocimiento de sistemas existentes;
- descomponer trabajo mediante fronteras verificables;
- diseñar pruebas y observabilidad;
- leer cambios y detectar efectos laterales;
- tomar decisiones de seguridad y operación;
- comunicar restricciones y compromisos.
Esto no convierte necesariamente al desarrollador en prompt engineer.
Continúa siendo ingeniería de software, pero aparece una nueva fuente capaz de generar propuestas y ejecutar parte del trabajo.
Saber proporcionar contexto es importante. Saber evaluar el sistema continúa siendo decisivo.
Existe además un riesgo formativo.
Si una persona delega desde el principio tareas que todavía no sabe inspeccionar, puede aumentar su capacidad de producir software sin desarrollar al mismo ritmo su capacidad para juzgarlo.
Una buena adopción debería conservar espacios para depurar, diseñar y explicar sin delegar automáticamente todo el proceso.
Un modelo operativo posible
Una organización puede avanzar progresivamente.
Nivel 1: asistencia local
Autocompletado y chat, sin acciones externas.
Se evalúan utilidad, calidad de las respuestas, exposición de información y posibles casos de uso.
Nivel 2: agente interactivo
Acceso de lectura y escritura al workspace, ejecución de comprobaciones acotadas y aprobación explícita para red, credenciales o comandos sensibles.
La persona continúa supervisando el trabajo.
Nivel 3: tareas delegadas
El agente trabaja en un entorno aislado y una rama propia.
Dispone de instrucciones versionadas, comprobaciones automáticas y criterios de aceptación. El resultado llega mediante una pull request para revisión humana.
La ejecución conserva una traza operativa suficiente para reconstruir qué ocurrió, por ejemplo:
- objetivo;
- versión de las instrucciones;
- commit de partida;
- herramientas utilizadas;
- comandos relevantes;
- aprobaciones;
- resultados de las comprobaciones;
- artefactos producidos;
- diff final.
Nivel 4: automatización operativa acotada
Tareas repetibles con entradas definidas, permisos mínimos, límites temporales, idempotencia, logs, mecanismos de reversión y políticas específicas de acceso y retención.
Publicar, desplegar o ejecutar acciones de alto impacto continúa siendo una capacidad separada salvo que exista una autorización explícita, controlada y auditable.
Esta trazabilidad forma parte de lo que habitualmente se denomina observabilidad de agentes.
Su objetivo es registrar hechos observables de la ejecución: qué se pidió, qué herramientas se utilizaron, qué acciones se realizaron y qué resultado produjeron.
No necesita almacenar el razonamiento interno del modelo ni debería tratar una explicación generada como evidencia de que una acción fue correcta.
Tampoco resulta aconsejable almacenar indiscriminadamente prompts y respuestas completas. Pueden contener código privado, credenciales, información empresarial o datos personales.
Las prácticas y estándares específicos para observar agentes continúan evolucionando.
Por ello, el contrato realmente importante para una organización es decidir qué evidencia necesita conservar, quién puede consultarla y durante cuánto tiempo.
No todos los equipos necesitan alcanzar el último nivel.
El grado adecuado de autonomía es aquel que mejora el sistema de trabajo sin superar la capacidad de la organización para comprenderlo, validarlo y controlarlo.
Conclusión
Los agentes de código cambian el desarrollo porque pueden recorrer varios pasos del proceso de ingeniería, no simplemente porque produzcan código más deprisa.
La oportunidad consiste en delegar exploración, implementación y tareas repetitivas allí donde existen límites y criterios suficientes para evaluar el resultado.
El riesgo aparece cuando una mayor capacidad de generar propuestas se convierte simplemente en una mayor cantidad de software que el equipo no tiene capacidad de revisar, entender o mantener.
Por eso la madurez de una implantación no debería medirse por el número de agentes utilizados.
Una organización madura debería poder explicar qué delega, por qué lo delega, qué información puede utilizar el agente, con qué permisos trabaja, cómo comprueba sus resultados y qué evidencia necesita antes de integrarlos.
La pregunta final no es cuánto código puede producir la IA.
Es cuánto trabajo podemos delegar sin perder la capacidad de entender, verificar y controlar el resultado.
