Hace unos seis meses escribí sobre los agentes de IA con un título que ahora me resulta casi tímido: “cuando la IA deja de responder y empieza a hacer cosas”. En aquel momento, los agentes eran sobre todo una posibilidad. Algo que se intuía, que se mostraba en demos impactantes, que prometía. Yo los describía con cierta cautela, como una dirección hacia la que íbamos, no como una realidad instalada. Y escribí, entre otras cosas, que los agentes necesitaban barandas. Vuelvo al tema ahora, medio año después, porque algo cambió, y no es menor: los agentes empezaron a trabajar de verdad. Ya no es una demo de laboratorio ni una promesa de roadmap. Hoy hay agentes que toman una tarea, la dividen en pasos, tocan archivos en un repositorio real, corren pruebas, iteran sobre los errores y trabajan durante horas con poca intervención humana. La posibilidad se volvió práctica. Y eso me obliga a revisar lo que dije, no para desdecirme, sino para afinarlo: porque lo que era cierto cuando los agentes solo prometían se volvió mucho más urgente ahora que cumplen.
Lo que cambió en estos meses#
No quiero quedarme en el anuncio puntual, porque eso envejece rápido y no es lo que me importa. Pero conviene dar contexto. En estos meses, los principales laboratorios de IA empujaron fuerte en una misma dirección: modelos pensados específicamente para tareas agénticas, capaces de razonar durante más tiempo, de usar herramientas, de sostener un trabajo largo sin perder el hilo. Lo que se anuncia ahora ya no se vende por lo bien que conversa, sino por lo bien que ejecuta tareas complejas de varios pasos, sobre todo en desarrollo de software. Y, de manera reveladora, varias de estas herramientas dejaron de ser experimentos en vista previa para volverse productos disponibles, listos para que cualquier equipo los use en su flujo de trabajo diario.
Ese detalle, que parece administrativo, es en realidad el más importante. Una cosa es que exista una capacidad en un laboratorio; otra muy distinta es que esté disponible, integrada, lista para meter en producción. El paso de “vista previa de investigación” a “producto general” es el paso de la curiosidad a la responsabilidad. Cuando algo está en preview, lo prueba un puñado de entusiastas que saben que están jugando con fuego. Cuando algo es un producto general, lo usa todo el mundo, incluido el que no leyó la letra chica, el que no entiende los riesgos, el que asume que si está disponible es porque es seguro usarlo sin pensar. Y ahí es donde la conversación sobre agentes deja de ser teórica.
De la posibilidad a la práctica: qué significa “trabajar de verdad”#
Vale la pena detenerse en qué quiere decir, concretamente, que un agente “trabaja de verdad”, porque la frase puede sonar a marketing y no lo es. Hablo de algo bastante específico. Le damos una tarea descrita en lenguaje natural —arreglá este bug, implementá esta funcionalidad, migrá este módulo— y el agente no nos devuelve una sugerencia para que copiemos y peguemos, como hacía hace un año. En cambio, explora el repositorio para entender el contexto, identifica qué archivos hay que tocar, hace los cambios, corre las pruebas, ve qué falla, corrige, vuelve a probar, y sigue así durante un rato largo, a veces horas, hasta llegar a algo que se le parece a una solución terminada. Después nos deja el resultado para revisar.
Ese ciclo —explorar, decidir, actuar, verificar, corregir— es exactamente lo que distingue a un agente de un asistente. El asistente responde a un pedido puntual y se detiene. El agente persigue un objetivo a lo largo de muchos pasos, tomando decisiones intermedias por su cuenta. Y cuando esos pasos son muchos y se extienden en el tiempo, pasa algo que en noviembre solo podía anticipar: la cantidad de decisiones que el agente toma sin que las veamos crece muchísimo. No es una decisión la que se nos escapa, son docenas, encadenadas, cada una construida sobre la anterior. El resultado puede ser excelente. Pero el camino para llegar a él, esa secuencia de pequeñas elecciones autónomas, se vuelve cada vez más difícil de seguir.
El entusiasmo, otra vez, está justificado#
Quiero ser claro, porque sería fácil leer todo esto como una advertencia temerosa y no lo es: lo que está pasando es genuinamente bueno y emocionante. Un agente que puede tomar una tarea bien delimitada y trabajarla de punta a punta es una herramienta poderosísima. Libera tiempo humano para los problemas que de verdad lo necesitan. Acelera el trabajo repetitivo y mecánico. Permite que equipos chicos hagan cosas que antes requerían muchas más manos. Destraba tareas que se postergaban por falta de tiempo, esas que todos sabemos que hay que hacer y que nunca llegan a la cima de la lista.
Lo viví en carne propia en estas semanas, probando estas herramientas. Hay un momento, parecido al que sentí con el vibe coding, en que la cosa simplemente funciona, y uno se queda mirando la pantalla con una mezcla de asombro y vértigo. El agente entendió el problema, navegó un código que no había visto nunca, hizo cambios sensatos, corrió las pruebas, se dio cuenta de que algo fallaba y lo corrigió solo. Es difícil no maravillarse. Y descartar esa maravilla por prudencia excesiva sería tan ingenuo como rendirse a ella sin pensar. La capacidad es real, el valor es real. Justamente por eso el resto de la reflexión importa: porque cuando algo es tan útil, la tentación de soltarle las riendas del todo es enorme.
El caballo se volvió más fuerte; el arnés importa más#
Acá quiero traer una imagen que me ayuda a pensar todo esto. Un agente potente es como un caballo de tiro fuerte. Cuanto más fuerte es el caballo, más trabajo puede hacer, más carga puede mover, más lejos puede llevarnos. Pero también, cuanto más fuerte es, más importa el arnés con que lo conducimos. Un caballo manso y débil se controla con cualquier cosa; si se desvía, no pasa gran cosa. Un caballo poderoso, sin arnés o con un arnés flojo, no es una bendición, es un peligro. Toda su fuerza, que es justamente lo que lo hace valioso, se vuelve la razón por la que necesitamos conducirlo bien.
En noviembre escribí que los agentes necesitaban barandas, y lo sostengo. Pero ahora veo que esa metáfora se queda corta, porque una baranda es pasiva: está ahí para que uno no se caiga si se acerca al borde. El arnés es activo: es cómo se dirige la fuerza hacia donde queremos que vaya. Y eso es lo que cambió. Cuando los agentes solo respondían, alcanzaba con contener los desastres. Ahora que ejecutan tareas largas y potentes, necesitamos algo más: conducir esa fuerza, no solo limitarla. El arnés de un agente son los permisos que le damos y los que no, las acciones que puede tomar solo y las que requieren que un humano apruebe, los entornos donde lo dejamos trabajar libremente y los que protegemos, el registro de todo lo que hizo para poder entenderlo después, los puntos donde lo obligamos a detenerse y mostrar antes de seguir. Cuanto más capaz es el agente, más fino tiene que ser ese arnés. La intuición fácil es la contraria —“ya es tan bueno que puedo confiar más”— y es exactamente al revés. Más capacidad pide más conducción, no menos.
Las tres piezas del arnés que no cambian: permisos, revisión, trazabilidad#
Si tuviera que reducir el arnés a sus piezas esenciales, me quedaría con tres, las mismas que ya importaban antes y que ahora se vuelven críticas. La primera son los permisos: qué puede tocar el agente y qué no. Un agente que trabaja en una rama aislada de un repositorio es una cosa; uno con permiso para hacer merge directo a la rama principal, o para tocar producción, o para ejecutar comandos sin límite, es otra muy distinta. La pregunta no es solo qué queremos que el agente pueda hacer, sino qué no debería poder hacer nunca, por más capaz que sea. La capacidad no debería confundirse con la autorización. Que un agente pueda borrar una base de datos no significa que deba tener permiso para hacerlo.
La segunda es la revisión. Y acá hay una trampa sutil que conviene nombrar. Cuando un agente produce poco, revisar es fácil. Cuando un agente produce mucho, rápido, durante horas, revisar se vuelve agotador, y aparece la tentación de aprobar sin mirar de verdad, confiando en que “seguro está bien”. Ese es el momento peligroso. Un agente que genera más de lo que podemos revisar con atención no nos hace más productivos: nos hace acumular, a gran velocidad, cambios que nadie entendió del todo. La revisión humana no es un trámite que estorba la velocidad; es lo único que separa “el agente hizo un montón de cosas” de “el agente hizo las cosas correctas”. Y si el volumen que genera supera nuestra capacidad de revisarlo, el problema no es la revisión: es que le estamos pidiendo al agente más de lo que podemos gobernar.
La tercera es la trazabilidad, y es quizás la que más se vuelve a valorar con los agentes que trabajan solos por horas. Si el agente tomó docenas de decisiones que no vimos, lo mínimo que necesitamos es poder reconstruir qué hizo y por qué. Un registro de sus pasos, de sus decisiones, de los comandos que ejecutó. Porque el día que algo salga mal —y va a salir, todo sale mal alguna vez— la diferencia entre un incidente manejable y una pesadilla va a estar en si podemos entender qué hizo el agente o si tenemos que adivinar. Un agente sin trazabilidad es una caja negra que toma decisiones por nosotros, y poner una caja negra en el camino crítico de algo importante es, históricamente, una de las peores ideas de la ingeniería.
El riesgo no es que el agente se rebele, es que confiemos de más#
Cuando se habla de los riesgos de los agentes, la imaginación tiende a irse a la ciencia ficción: la máquina que se rebela, que toma decisiones malignas, que se sale de control por voluntad propia. Es una distracción. El riesgo real, el que veo todos los días en cómo se usan estas herramientas, es mucho más mundano y mucho más probable: que confiemos de más. Que, deslumbrados por lo bien que funciona el agente la mayoría de las veces, bajemos la guardia justo cuando más la necesitamos.
El problema no es que el agente sea malo. Es que es bueno casi siempre, y ese “casi” es traicionero. Un agente que acierta el noventa y cinco por ciento de las veces nos entrena, sin que nos demos cuenta, a confiar en el cien por ciento. Empezamos revisando todo con cuidado, vemos que casi siempre está bien, y poco a poco aflojamos. Revisamos menos. Aprobamos más rápido. Le damos más permisos. Hasta que llega ese cinco por ciento —o ese uno por ciento— en un momento crítico, y nos encuentra desprevenidos, porque nos habíamos acostumbrado a que todo saliera bien. La confiabilidad alta no elimina la necesidad de vigilancia; paradójicamente, la vuelve más difícil de sostener, porque erosiona nuestra disciplina sin que lo notemos. Es el mismo fenómeno de las dependencias que funcionan tan bien que dejamos de mirarlas, solo que ahora aplicado a algo que toma decisiones por nosotros.
El agente sigue sin entender nuestra empresa#
Hay algo que dije en noviembre y que el aumento de capacidad no cambió en absoluto: un agente puede ser extraordinariamente bueno ejecutando tareas técnicas y seguir sin entender el contexto de nuestra organización. No sabe qué cliente es crítico, qué decisión de arquitectura responde a una restricción del negocio y no a una preferencia técnica, qué parte del sistema está en medio de una migración delicada, qué deuda técnica decidimos tolerar a propósito y cuál hay que atacar. Puede saberlo si se lo damos, puede respetarlo si se lo explicitamos, pero no lo adivina. Y un agente más capaz, que actúa más y más rápido, puede equivocarse en esa dimensión contextual con mucho más alcance que antes.
Esto refuerza algo que vengo repitiendo y que cada nueva capacidad vuelve más cierto: cuanto más queremos delegar en una IA, más importa el contexto que le damos. Las reglas, la documentación, las restricciones, los límites explícitos. Si dejamos que un agente potente trabaje sobre un sistema mal documentado, sin reglas claras, con un objetivo vago, va a llenar todos esos huecos con supuestos, y los va a llenar rápido y con seguridad, que es la peor combinación. El agente no es el sustituto de entender nuestro propio sistema; es, si acaso, una razón más para entenderlo bien, porque ahora ese entendimiento es lo que le da al agente las riendas para no perderse.
Empezar por lo acotado, no por lo crítico#
Si una organización quiere incorporar agentes en serio ahora que de verdad funcionan, sigo creyendo lo mismo que en noviembre, con más convicción todavía: conviene empezar por lo acotado y de bajo riesgo, no por lo crítico. Un agente trabajando en una rama aislada, generando una primera versión que un humano revisa antes de integrar, sobre tareas bien delimitadas y reversibles, es un lugar excelente para aprender. Permite ganar experiencia, descubrir cómo se equivoca, calibrar cuánto revisar, ajustar los permisos, todo sin poner en juego lo que no nos podemos permitir perder.
Lo que no haría —y lo veo como una tentación creciente justamente porque las herramientas se ven tan capaces— es soltar un agente potente directo sobre lo crítico solo porque la demo impresiona. La madurez no está en automatizar lo más posible lo más rápido posible; está en saber qué conviene delegar, con qué arnés, y en qué momento. Un equipo que aprendió a trabajar con agentes en territorio seguro va a estar muchísimo mejor preparado para, eventualmente, darles más responsabilidad, que uno que los puso a correr en producción el primer día y descubrió los límites a fuerza de incidentes. La velocidad de adopción no es una virtud en sí misma. La velocidad con la que aprendemos a gobernar lo que adoptamos, sí.
El rol del que lidera, todavía más en el centro#
Cada vez que la capacidad de estas herramientas da un salto, el rol de quien conduce equipos de tecnología se vuelve más importante, no menos, y los agentes que trabajan de verdad lo confirman. Porque alguien tiene que tomar las decisiones que el entusiasmo, solo, no toma: qué le permitimos a un agente y qué no, qué requiere aprobación humana, dónde lo dejamos trabajar libre y dónde no, cómo registramos lo que hace, cómo medimos si de verdad mejora el trabajo o solo genera más cosas para revisar. Son decisiones de criterio, y el criterio no viene incluido en la herramienta.
Hay además una responsabilidad más sutil, que tiene que ver con la cultura del equipo. Cuando aparece una herramienta tan seductora, la tendencia natural es que cada uno la use a su manera, soltándole cada vez más las riendas a medida que le toma confianza. El trabajo de liderar, en parte, es sostener la disciplina colectiva justo cuando la herramienta invita a relajarla: mantener la revisión seria aunque el agente casi siempre acierte, mantener la pregunta por los permisos aunque sea más cómodo dar acceso total, mantener viva la trazabilidad aunque parezca que nunca la vamos a necesitar. No por desconfianza hacia la tecnología, sino por respeto a cómo fallan los sistemas complejos. La diferencia entre un equipo que usa agentes con criterio y uno que es arrastrado por ellos se va a notar, y se va a notar en producción.
Lo que me queda, medio año después#
Vuelvo al principio, a ese post de noviembre que ahora me parece tímido. No me arrepiento de lo que escribí; al contrario, me sorprende cuánto se sostiene. Lo que dije entonces sobre permisos, revisión, trazabilidad, contexto y humanos en el circuito no solo sigue siendo cierto: se volvió más urgente, porque la distancia entre “el agente podría hacer cosas” y “el agente está haciendo cosas” se cerró. Aquello era una advertencia sobre un futuro probable. Esto es una descripción de un presente real.
Y la lección de fondo, esa que quiero que perdure más allá de qué modelo salió este mes o cuál saldrá el que viene, es esta: la capacidad y la responsabilidad de gobernarla tienen que crecer juntas, y nuestra tendencia natural es dejar que crezca solo la primera. Nos entusiasma lo que el agente puede hacer y nos cuesta acompañar ese entusiasmo con la disciplina de conducirlo bien. Cada salto de capacidad nos tienta a soltar un poco más las riendas, justo cuando el caballo se volvió más fuerte y las riendas importan más. Resistir esa tentación, sin caer tampoco en el miedo paralizante, es probablemente la habilidad técnica y de liderazgo más valiosa de este momento.
Les dejo, para terminar, una pregunta para llevarse al propio equipo. La próxima vez que un agente nos resuelva una tarea de manera impecable y sintamos esa tentación tan humana de darle un poco más de libertad, un permiso más, una revisión menos, ¿vamos a estar afinando el arnés a la altura de su nueva fuerza, o simplemente vamos a estar soltando las riendas porque por ahora, casi siempre, sale bien? Porque ese “casi siempre” es cómodo hasta el día que deja de serlo, y para ese día, lo único que nos va a proteger es el arnés que hayamos tenido la disciplina de mantener.
Fuentes consultadas#
- Anthropic, “Introducing Claude 4”, 22 de mayo de 2025.
- Anthropic, “Claude Code: Deep coding at terminal velocity”, disponibilidad general anunciada el 22 de mayo de 2025.
- Anthropic, “Claude 3.7 Sonnet and Claude Code”, 24 de febrero de 2025 (Claude Code como research preview).