En una empresa, un equipo armó un taller interno para mostrar agentes. Uno de los ejemplos era la “skill” de un agente para crear un entorno de trabajo. Una skill es un paquete de instrucciones para el agente.
Cuando la abrieron, era una lista de comandos de gh y bash. Puestos uno detrás del otro, formaban un script.
Un participante lo contó en un foro de DevOps (la prueba 106). El hilo juntó 517 puntos y su comentario, 454.
La conclusión fue que un proceso que se repite anda mejor si es determinista. Determinista quiere decir que, con la misma entrada, da siempre la misma salida.
La tesis que se juzga dice lo contrario. Para automatizar un proceso, lo moderno es un agente, y el flujo programado quedó viejo.
Primero, los términos. Un post técnico de Fly.io (la prueba 16), con 1.070 puntos en Hacker News, define al agente así: una llamada al modelo dentro de un bucle con herramientas. El modelo mira lo que devuelve cada herramienta y decide el paso siguiente.
En un flujo fijo, en cambio, una persona escribió en código el orden de los pasos. El flujo puede llamar a un modelo en algunos pasos, por ejemplo para clasificar un texto. Pero el modelo no elige el camino.
Entre los dos extremos hay de todo. La decisión real es cuánto de cada proceso dejás en manos del modelo.
El agente rinde mejor donde el camino cambia según el caso, como en un diagnóstico. Ahí, un modelo que lee, cruza datos y propone una causa aporta algo que un script no da.
Un equipo de plataforma con unos 20 servicios probó agentes durante un año (la prueba 120). Contó en un foro que se quedó con la correlación de alertas.
60 % contra 0 %
Veces que la correlación de alertas acierta la causa probable, contra el sistema anterior. Prueba 120
Según el equipo, acierta la causa probable 60 % de las veces, contra 0 % del sistema anterior. Un comentarista sospecha que el post es publicidad de una herramienta que menciona.
En un hilo de responsables de TI (la prueba 117), uno armó un triage de tickets. Triage es la primera clasificación de un caso para saber qué es y a quién va.
Su flujo tiene acceso de solo lectura: puede leer, pero no cambiar. Lee la gestión de equipos, el directorio, el doble factor, la red y el historial de tickets. Dice que en los tickets complejos ahorra 30 minutos por ticket.
Un ingeniero con 11 años de experiencia contó otro caso en un foro (la prueba 79). Dice que automatizó cerca del 80 % de su trabajo con un agente de código. El agente toma los pedidos y abre los cambios.
Él dedica 2 a 3 horas por día a revisar y probar lo que entrega el agente. Un comentarista contó que, sin la revisión, la calidad se degradó en una semana.
Los tres casos comparten un rasgo: cada caso pide una investigación distinta, y una persona revisa o hace el cambio.
El hilo del triage lo confirma desde el otro lado. Preguntaba qué tareas repetitivas se automatizaron de verdad con IA. La respuesta más votada fue “ninguna”.
En otro hilo de responsables de TI (la prueba 144), uno contó que casi ninguno de sus pares despliega agentes. Los que sí describieron casos angostos: agentes separados para seguridad, diagnóstico y rendimiento, con acceso de solo lectura a logs y APIs. El agente analiza y recomienda, y la persona hace el cambio.
El mejor lugar para un agente son las tareas repetitivas que hoy se hacen a mano.
Veredicto: Lo que se hace siempre igual sale mejor como script. El agente rinde donde cada caso pide investigar distinto. Un hilo preguntó qué tareas de TI se automatizaron de verdad con IA. La respuesta más votada fue que ninguna. El caso a favor fue un triage de tickets complejos, con acceso de solo lectura a varios sistemas. Según quien lo armó, ahorra 30 minutos por ticket. Otros equipos usan agentes que analizan logs y recomiendan, y la persona hace el cambio.
Criterio
Elegí el primer caso de agente entre las tareas donde cada caso pide investigar distinto. Algunos ejemplos son el triage, que ordena y deriva pedidos, o el diagnóstico. No lo elijas entre las tareas que más se repiten.
Por qué confianza baja. Todo viene de hilos de Reddit, con ahorros autoinformados y sin medición. El caso a favor es el relato de una persona con una semana de uso, en un trabajo que los comentarios describen como simple.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 3 en contra, 0 matizan
Un ingeniero con 11 años de experiencia cuenta que automatizó cerca del 80 % de su trabajo con un agente de código. El agente toma los issues y abre pull requests. Dice que la calidad se mantiene porque revisa todos los cambios. Le dedica 2 a 3 horas por día a revisar y probar. Un comentarista cuenta que, al sacar la revisión, la calidad se degradó en una semana. Otros discuten la ética de hacerlo a escondidas del empleador.
Números
cerca del 80 %Parte del trabajo que el autor dice haber automatizado.
2 a 3 horas por díaTiempo que dedica a revisar y probar.
1.200 puntos y 276 comentariosTamaño del hilo según el archivo.
Limitación Relato de una persona, con una semana de uso al momento del post. Los comentarios señalan que funciona porque el trabajo es simple. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
En un taller interno, la “skill” de un agente para crear un entorno resultó ser una lista de comandos de gh y bash. Juntos, esos comandos son un script. El hilo concluye que un proceso que se repite anda mejor si es determinista, es decir, si siempre hace lo mismo. Un contrapunto dice que el agente lleva a la máquina local el ciclo de integración continua (las pruebas automáticas de cada cambio). Así, deja la CI como último control.
Números
517 puntos y 115 comentariosTamaño del hilo según el archivo. El comentario del taller tiene 454 puntos.
Limitación Experiencia de practicantes, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Turns out that recurring processes work way better when they are deterministic.”
Un hilo pregunta qué tareas de TI se automatizaron de verdad con IA, y el comentario más votado responde “ninguna”. A favor, un responsable armó un flujo de triage (clasificación de pedidos) con acceso de solo lectura. El flujo lee la gestión de equipos, el directorio, el doble factor, la red y el historial de tickets. El paso siguiente es automatizar con una persona que aprueba desde un chat. Él dice que el objetivo es crecer, no sacar gente.
Números
30 minutos por ticketAhorro en tickets complejos, según quien construyó el triage.
67 puntos y 146 comentariosTamaño del hilo según el archivo. El comentario citado tiene 47 puntos y el de “ninguna”, 134.
Limitación Ahorro autoinformado, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“On more complicated stuff this is saving EASILY 30 minutes per ticket.”
Un responsable de TI de pymes dice que casi ninguno de sus pares despliega agentes, y muchos le responden que no. Los que sí cuentan casos angostos: agentes separados para seguridad, diagnóstico y rendimiento, con acceso de solo lectura a logs y APIs. Esos agentes analizan y recomiendan, y la persona hace el cambio. Otro usa un agente sobre su propia telemetría de red para armar resúmenes operativos.
Números
133 puntos y 174 comentariosTamaño del hilo según el archivo.
Limitación Relatos de practicantes, sin medición. El comentario citado tiene 26 puntos. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“The agents only have read-only access, so they can analyze and recommend actions”
En los procesos que se repiten, el código fijo anda mejor que un agente suelto.
Un hilo de Hacker News de 590 puntos trae otro caso (la prueba 97). Es un agente de QA, es decir, de control de calidad.
El agente tenía que recorrer unos 200 archivos de requisitos, guiado solo por un prompt. Un prompt es la instrucción escrita que recibe el modelo. Cerca del archivo 30, el agente se rompía.
Lo resolvió un arnés determinista. Un arnés es el código que rodea al modelo y controla el recorrido. Otro comentarista agregó que, con piezas chicas, modelos más baratos rinden como los de frontera (los más avanzados).
Ese argumento le deja trabajo al modelo, pero pone el flujo de control en código. El flujo de control es el orden de los pasos, qué se repite y cuándo se termina.
Dex Horthy escribió la guía 12-factor agents. Un año después, sostiene lo mismo (la prueba 131): un bucle grande de agente no aguanta trabajo serio sin estructura y verificación.
Su empresa dejó correr tres o cuatro meses una “fábrica de software” poco supervisada. El código llegó a tener de 30.000 a 40.000 líneas, y terminaron archivándolo entero. Es la anécdota de una persona, no un estudio.
Un proveedor de modelos llega a lo mismo. Anthropic comparó un agente solo contra un arnés de tres agentes para construir aplicaciones completas (la prueba 70).
Un juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).Prueba 70
Tiempo de trabajo
Agente solo20 minutos
Arnés completo6 horas
0
Costo, en dólares
Agente solo9 dólares
Arnés completo200 dólares
0
Para un juego retro, el agente solo tardó 20 minutos y gastó 9 dólares. El juego no respondía a los controles. El arnés tardó 6 horas y gastó 200 dólares, y el juego se podía jugar.
El proveedor dice que cada pieza del arnés supone algo que el modelo no puede hacer solo. En otro post (la prueba 77) repite que esos supuestos vencen con cada modelo nuevo. Entonces la parte fija no se escribe una vez y listo: se revisa.
Ninguna fuente de la base defiende con datos que el agente sea la opción por defecto. El equipo que probó agentes un año se quedó con los que leen y resumen: changelogs automáticos (registros de cambios), revisión de cambios y correlación de alertas.
Descartó el Terraform generado por IA, porque había que leer cada línea. Terraform es una herramienta que describe infraestructura en código. Su regla quedó así: los agentes leen todo, pero no tocan la infraestructura.
Para automatizar un proceso, lo moderno es un agente: el flujo programado quedó viejo.
Veredicto: Al revés: el flujo fijo es el punto de partida, y el agente se tiene que ganar su lugar. Un comentarista cuenta que un agente guiado solo por prompts se rompía cerca del archivo 30 de unos 200. Un arnés determinista lo resolvió: código fijo que guía cada paso. Una empresa dejó correr meses una fábrica de software poco supervisada. Terminó archivando todo el código. El agente suma donde el camino cambia según el caso, como al cruzar alertas.
Criterio
Escribí primero el proceso como flujo fijo. Dejá que el modelo decida solo en los pasos donde el camino cambia según el caso, y justificá cada uno con una prueba.
Por qué confianza media. Varios equipos coinciden, pero no hay un experimento controlado. Los casos de Hacker News y Reddit son relatos sin medición. La fábrica archivada es la anécdota de una persona. Los posts sobre arneses son de un proveedor de modelos. Nadie defiende la afirmación con datos.
Ver el detalle de las 6 pruebasOcultar el detalle0 a favor, 4 en contra, 2 matizan
Hilo sobre un artículo que pide escribir el flujo de control en código y no en prompts. Un comentarista cuenta que un agente de QA debía recorrer unos 200 archivos de requisitos y se rompía cerca del archivo 30. Un arnés determinista (código que fija cada paso) lo resolvió. Otro dice que, con el trabajo partido en piezas chicas, modelos más baratos rinden como los de frontera. Algunos se quejan de que las plataformas prefieren flujos solo con prompts.
Números
unos 200 archivos, falla cerca del 30Caso de un agente de QA guiado solo por prompt, según un comentarista.
590 puntos y 296 comentariosTamaño del hilo.
Limitación Relatos de usuarios, sin datos medidos. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra y por eso no se usan.
En un taller interno, la “skill” de un agente para crear un entorno resultó ser una lista de comandos de gh y bash. Juntos, esos comandos son un script. El hilo concluye que un proceso que se repite anda mejor si es determinista, es decir, si siempre hace lo mismo. Un contrapunto dice que el agente lleva a la máquina local el ciclo de integración continua (las pruebas automáticas de cada cambio). Así, deja la CI como último control.
Números
517 puntos y 115 comentariosTamaño del hilo según el archivo. El comentario del taller tiene 454 puntos.
Limitación Experiencia de practicantes, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Turns out that recurring processes work way better when they are deterministic.”
Nota sobre Dex Horthy, autor de la guía 12-factor agents. Un año después sostiene la misma idea: un bucle grande de agente no aguanta trabajo serio sin estructura y verificación. Su empresa dejó correr tres o cuatro meses una "fábrica de software" con poca supervisión y después archivó todo el código. Según él, faltan mejores verificadores de la calidad del código.
Números
30.000 a 40.000 líneasTamaño que llegó a tener el código de la fábrica antes de archivarlo.
10 de 30 (33,3 %)Checkpoints que pasaron los mejores modelos en el subconjunto de SlopCodeBench que cita; las diferencias entre proveedores están dentro del margen de error.
Limitación Es una nota sobre una persona, con una anécdota propia; no es un estudio.
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Un equipo de plataforma con unos 20 servicios cuenta qué quedó después de un año de probar agentes. Descartó Terraform generado por IA, porque había que leer cada línea. También descartó un asistente que respondía mal con seguridad: alguien casi corre en producción un comando que sugirió. Se quedó con lo que lee y resume: changelogs automáticos, revisión de PR y correlación de alertas. La regla es que los agentes leen todo, pero no tocan la infraestructura.
Números
60 % contra 0 %Veces que la correlación de alertas acierta la causa probable, contra el sistema anterior.
289 puntos y 43 comentariosTamaño del hilo según el archivo.
Limitación Relato de un equipo, sin medición independiente. Un comentarista sospecha que el post es publicidad de una herramienta de revisión que menciona. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“agents can read and summarize anything but they dont get to touch infra”
Separa tres piezas con interfaces estables: la sesión, el arnés y el sandbox. La sesión es un registro de eventos fuera del contexto. El arnés es el bucle que llama al modelo y el sandbox corre el código. Así cualquier pieza puede fallar o cambiarse sin perder la sesión, y las credenciales quedan fuera del sandbox. Repite que el arnés codifica supuestos que vencen con cada modelo nuevo.
Números
cerca de 60 % y más de 90 %Baja del tiempo hasta el primer token en la mediana (p50) y en el percentil 95.
Limitación Post de producto del proveedor. No compara flujo fijo contra agente.
La discusión tiene un costado comercial. Según una encuesta de Menlo Ventures a decisores de EE. UU. (la prueba 32), solo 16 % de lo que despliegan las empresas grandes califica como agente real. En las startups, 27 %.
Menlo es un fondo que invierte en empresas de IA.
El hilo del capítulo 1 (la prueba 73) muestra el otro lado del rótulo. El agente se vendía como un “empleado virtual”, y los comentarios lo describieron como un modelo en un bucle.
Separá dos quejas. Un producto que es sobre todo código determinista, con pasos de modelo en los puntos justos, no es una estafa.
Si un bucle grande sin estructura no aguanta trabajo serio, esa forma es una virtud. La estafa aparece cuando te cobran la palabra y no el resultado.
Si lo que te venden como agente es, en el fondo, un script con algunos pasos de modelo, te estafaron.
Veredicto: Depende de qué te cobran. Un producto que es sobre todo código determinista, con pasos de modelo en los puntos justos, suele ser una virtud. Un bucle grande de agente no aguanta trabajo serio sin estructura y verificación. El problema es el rótulo. Un fondo de inversión encuestó a empresas grandes: solo 16 % de sus despliegues califica como agente real.
Criterio
Preguntale al proveedor qué decide el modelo y qué está escrito en código. Pagá por el resultado y por los controles, no por la palabra agente.
Por qué confianza baja. La cifra de agentes reales sale de una encuesta de un fondo que invierte en empresas de IA. Lo de la estructura viene de la experiencia de una persona que construye agentes y de hilos de Reddit, sin datos medidos.
Ver el detalle de las 5 pruebasOcultar el detalle1 a favor, 2 en contra, 2 matizan
Tully, T., Redfern, J., Das, D., Xiao, D. Menlo Ventures
De lo que las empresas despliegan como IA, solo una parte chica califica como agente de verdad. Las empresas compran más de lo que construyen (76 %). Menlo dice, sin dar una cifra, que lo comprado llega antes a producción. Cerca de la mitad de los acuerdos de IA llega a producción, bastante más que en el software tradicional.
Números
16 % y 27 %Despliegues de empresas grandes y de startups que califican como agentes reales.
76 % compradoParte de la IA que se compró en 2025 en lugar de construirla (53 % en 2024).
47 % contra 25 %Acuerdos de IA que llegan a producción, contra el software tradicional.
37.000 millones de dólaresGasto empresarial en IA generativa en 2025 (11.500 millones en 2024).
Limitación Encuesta a 495 decisores de empresas de EE. UU. (7 al 25 de noviembre de 2025) más datos de mercado. Menlo es un fondo que invierte en empresas de IA. No dice que comprar funcione mejor. Dice que se compra más y que lo comprado llega antes a producción.
“companies spent $37 billion on generative AI in 2025”
Nota sobre Dex Horthy, autor de la guía 12-factor agents. Un año después sostiene la misma idea: un bucle grande de agente no aguanta trabajo serio sin estructura y verificación. Su empresa dejó correr tres o cuatro meses una "fábrica de software" con poca supervisión y después archivó todo el código. Según él, faltan mejores verificadores de la calidad del código.
Números
30.000 a 40.000 líneasTamaño que llegó a tener el código de la fábrica antes de archivarlo.
10 de 30 (33,3 %)Checkpoints que pasaron los mejores modelos en el subconjunto de SlopCodeBench que cita; las diferencias entre proveedores están dentro del margen de error.
Limitación Es una nota sobre una persona, con una anécdota propia; no es un estudio.
En un taller interno, la “skill” de un agente para crear un entorno resultó ser una lista de comandos de gh y bash. Juntos, esos comandos son un script. El hilo concluye que un proceso que se repite anda mejor si es determinista, es decir, si siempre hace lo mismo. Un contrapunto dice que el agente lleva a la máquina local el ciclo de integración continua (las pruebas automáticas de cada cambio). Así, deja la CI como último control.
Números
517 puntos y 115 comentariosTamaño del hilo según el archivo. El comentario del taller tiene 454 puntos.
Limitación Experiencia de practicantes, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Turns out that recurring processes work way better when they are deterministic.”
Desde una conferencia de seguridad, el autor cuenta que allí se vende el agente como un “empleado virtual”. Los comentarios lo bajan a tierra. Un agente es una llamada a un modelo en un bucle con herramientas, y su “memoria” son archivos o una base de datos. Otro advierte que después no se puede analizar por qué decidió algo. Un tercero describe la proliferación de agentes que quedan huérfanos cuando se va quien los creó.
Números
356 puntos y 261 comentariosTamaño del hilo según el archivo. El comentario citado tiene 86 puntos.
Limitación Opiniones de quienes operan TI, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
Un agente es una llamada al modelo dentro de un bucle con herramientas, y escribir uno es simple. Lo difícil es manejar el contexto: pasado un umbral, el sistema empeora sin aviso. Conectar el agente con la realidad, para que no crea que resolvió algo que no resolvió, queda como problema abierto.
Números
1.070 puntos y 395 comentariosTamaño de la discusión en Hacker News (item 45840088).
Limitación El post no muestra autor ni fecha; la fecha es la de la discusión en Hacker News. Opinión, sin datos.
“Past a threshold, the whole system begins getting nondeterministically stupider.”
El flujo fijo es el punto de partida, y el agente se tiene que ganar su lugar.Se lo gana donde el camino cambia según el caso, como al cruzar alertas o clasificar un ticket complejo. Lo que se hace siempre igual queda en código.
Los equipos con agentes funcionando llegan a una forma parecida. Un estudio se basa en 20 casos y 86 practicantes con agentes en producción (la prueba 29). Encontró que 68 % deja como máximo 10 pasos al agente antes de que intervenga una persona.
68 %
Corre como máximo 10 pasos antes de que intervenga una persona. Prueba 29
También encontró que 70 % usa modelos comerciales con prompts, sin reentrenarlos. La muestra es chica y la eligieron los autores.
Aun así, coincide con los relatos. En un foro, alguien que dice haber construido más de 150 agentes para negocios hizo un balance (la prueba 57). Según su relato, los que funcionaron eran simples, de un solo propósito y con una persona para una parte chica.
Dentro de Anthropic se ve la misma tensión (la prueba 28). En 2025, su agente de código pasó de 9,8 a 21,2 llamadas a herramientas seguidas sin intervención.
de 9,8 a 21,2 llamadas
Llamadas a herramientas seguidas del agente de código entre febrero y agosto de 2025; los turnos humanos bajaron de 6,2 a 4,1. Prueba 28
Pero la mayoría de los empleados dice delegar del todo solo entre 0 % y 20 % de su trabajo. Es autorreporte de empleados del proveedor.
La contracara existe. En un experimento del mismo proveedor (la prueba 52), dieciséis agentes trabajaron en paralelo. Se coordinaron solo con un repositorio compartido.
En casi 2.000 sesiones y por poco menos de 20.000 dólares, escribieron un compilador de C de unas 100.000 líneas. Funcionó mientras el trabajo se pudo partir en piezas independientes con un verificador externo.
El verificador era un compilador de referencia y suites de tests (conjuntos de pruebas automáticas). Pocos procesos de una empresa tienen un verificador así. Sigue en el capítulo 4.
Los agentes que andan en producción son chicos, hacen una sola cosa y tienen una persona cerca.
Veredicto: Es un patrón que se repite en los equipos que tienen agentes funcionando. En un estudio con 86 practicantes con agentes en producción, 68 % deja como máximo 10 pasos al agente. Después interviene una persona. Los sistemas grandes rinden cuando el trabajo se parte en piezas con un verificador externo. Así, 16 agentes hicieron un compilador de C por poco menos de 20.000 dólares.
Criterio
Dale a cada agente un solo trabajo, con entrada y salida claras, y un tope de pasos antes de que mire una persona. Agrandalo solo cuando la versión chica ya anda y se queda corta.
Por qué confianza media. El estudio de producción es primario, pero con una muestra chica elegida por los autores. El resto son hilos de Reddit con cifras autoinformadas, una encuesta a empleados de un proveedor y un experimento del mismo proveedor.
Ver el detalle de las 6 pruebasOcultar el detalle4 a favor, 1 en contra, 1 matiza
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
Una persona dice que construyó más de 150 agentes para negocios. Cuenta que los que funcionaron eran simples, de un solo propósito y con una persona para una parte chica de la tarea. En los comentarios, otro equipo cuenta que dos agentes se consultaron entre sí 60 rondas sin resultado. El costo subía hasta que agregaron una capa que corta las llamadas repetidas.
Números
más de 150 agentesAgentes que el autor dice haber construido en un año (autoinformado).
60 rondasBucle entre dos agentes sin resultado útil, según un comentario.
Limitación Hilo chico (9 puntos y 12 comentarios en el archivo). Cifras autoinformadas. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“simple, single-purpose, and had a human-in-the-loop for 5% of the task”
Un responsable de TI de pymes dice que casi ninguno de sus pares despliega agentes, y muchos le responden que no. Los que sí cuentan casos angostos: agentes separados para seguridad, diagnóstico y rendimiento, con acceso de solo lectura a logs y APIs. Esos agentes analizan y recomiendan, y la persona hace el cambio. Otro usa un agente sobre su propia telemetría de red para armar resúmenes operativos.
Números
133 puntos y 174 comentariosTamaño del hilo según el archivo.
Limitación Relatos de practicantes, sin medición. El comentario citado tiene 26 puntos. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“The agents only have read-only access, so they can analyze and recommend actions”
Huang, S., Seethor, B., Durmus, E., Handa, K., McCain, M., Stern, M., Ganguli, D. Anthropic
Dentro del propio laboratorio, la gente usa Claude en más trabajo y dice ser más productiva. Pero solo puede delegar del todo una parte chica. Los agentes encadenan más acciones con menos intervención humana. Preocupa perder justamente las habilidades que hacen falta para supervisar a la IA, y cómo van a aprender los perfiles junior.
Números
de 0 % a 20 %Parte del trabajo que la mayoría puede delegar del todo.
59 % y +50 %Trabajo en el que usan Claude (28 % un año antes) y productividad autorreportada (+20 % un año antes), en 132 encuestados.
de 9,8 a 21,2 llamadasLlamadas a herramientas seguidas del agente de código entre febrero y agosto de 2025; los turnos humanos bajaron de 6,2 a 4,1.
Limitación Autorreporte de empleados del proveedor, con datos de 2025 (encuesta de agosto de 2025, 53 entrevistas y 200.000 transcripciones).
“I am for sure atrophying in my skills as a software engineer”
Dieciséis instancias de Claude trabajaron en paralelo, sin un orquestador que repartiera el trabajo. Se coordinaron solo con un repositorio git compartido y archivos de bloqueo para reclamar tareas. Funcionó mientras el trabajo se podía partir en piezas independientes con un verificador externo (GCC y suites de tests). Encararon el kernel de Linux como una sola tarea grande. Ahí todos los agentes encontraban el mismo error, lo arreglaban y se pisaban los cambios.
Números
casi 2.000 sesiones y poco menos de 20.000 dólaresSesiones de Claude Code en dos semanas y costo en API (2.000 millones de tokens de entrada y 140 millones de salida, Opus 4.6).
unas 100.000 líneasTamaño del compilador de C en Rust. Compila Linux 6.9 en x86, ARM y RISC-V con 99 % de aprobación en la mayoría de las suites.
Limitación Un experimento del proveedor. El código generado es menos eficiente que GCC sin optimizaciones. La tarea tenía un verificador externo muy bueno, algo que pocos procesos de empresa tienen.
El autor desaconsejó los sistemas multiagente y diez meses después revisa su postura. Para él, varios agentes que escriben en paralelo todavía toman decisiones incompatibles, pero tres patrones sí funcionan. Son un revisor con contexto limpio, un modelo chico que consulta lo difícil a uno más fuerte y un agente gerente que reparte trabajo. En los tres, un solo hilo escribe.
Números
2 errores por pull requestPromedio que encuentra el agente revisor; cerca de 58 % son graves.
unas 8 vecesCrecimiento del uso de su agente en el segmento de empresas más grande, en 6 meses.
Limitación Lo publica una empresa que vende un agente de código; los números son internos.
“clean context leads to a notable improvement in capabilities”