# Agentes de IA: 7 ingenieros, 8 meses, ni el 5 %. No era falta de equipo

**La Startup que funciona con Agentes · Episodio 2 · AI4Managers**

| dato | valor |
|---|---|
| duración | 12:50,3 |
| formato | 1920x1080 a 30 fps |
| palabras | 1867 |
| segmentos | 170 (Whisper large-v3 sobre el audio del v18, idéntico en el v22) |
| video | https://playgrounds.digitalhubassist.ai/ai4m-ep2-v22.mp4 |
| guion v5 | https://playgrounds.digitalhubassist.ai/ai4m-ep2-guion.md |

Transcripción agrupada en bloques, con el minuto de entrada de cada uno.

---

**0:00** Hay un número de la historia de Frank que todavía cuesta creer. Siete personas trabajando durante ocho meses en el mismo sistema. Y entre esas personas había ingenieros y un líder técnico. No estamos hablando de alguien intentando construir un producto solo durante los fines de semana.

**0:19** Lo sorprendente es el resultado. Porque con un equipo así y ocho meses de trabajo, uno esperaría encontrar un producto bastante avanzado. Eso sería lo razonable. Pero según Frank, después de esos ocho meses, no habían llegado ni al 5% de lo que tiene construido hoy.

**0:39** Y aquí quiero evitar una conclusión demasiado fácil. ¿Estamos diciendo que esos ingenieros eran malos? No. Y reducir la historia a eso nos haría perder precisamente lo interesante. Puedes tener buenos profesionales y aún así obtener un mal resultado si existe una brecha entre lo que el negocio...

**1:00** necesita y lo que el equipo entiende que debe construir. Pero después de ocho meses, esa brecha debería haberse cerrado. En teoría. El problema es cómo intentamos cerrarla. Más reuniones, más documentos, más requerimientos, más explicaciones.

**1:18** Y cada paso agrega una nueva interpretación. La idea sale de la cabeza de Frank, pasa por varias personas y finalmente termina convertida en software. Y recién... cuando vuelve a Frank, puedes comprobar si todos estaban construyendo lo mismo que él tenía en mente. Entonces, el cuello de botella no necesariamente estaba en escribir código.

**1:39** Esa es la pregunta que quiero que mantengamos abierta. Porque antes de sacar conclusiones, vale la pena escuchar cómo describe Frank lo que ocurrió con ese equipo. Si, yo vengo, digamos, de un contexto el año pasado bastante interesante. Yo el año pasado tenía un socio inversionista que tenía un equipo de siete,

**1:59** siete personas, ingenieros, CTO. Pues para serles sinceros, estuvimos trabajando por cerca de ocho meses, tal vez. Y no alcanzamos a lograr ni el 5% de lo que yo tengo actualmente, que se ha desarrollado este año con estos agentes de inteligencia artificial.

**2:22** Ahora la historia cambia. Frank no está diciendo que necesitaba mejores programadores. Está describiendo un problema de entendimiento. Y es más común de lo que parece. Quien conoce el negocio a fondo, tiene una cantidad enorme de contexto que nunca llega completo al equipo que construye.

**2:43** Porque hay cosas que, para esa persona, son obvias. Reglas, excepciones, prioridades, cómo se relaciona un proceso con otro. Y muchas veces ni siquiera sabes que hay que explicarlas, hasta que alguien entiende algo distinto. Y entonces, ¿cómo se relaciona un proceso con otro?  Entonces, aparece otra reunión.

**3:02** Otra explicación, otro documento, otro ajuste. El equipo puede estar trabajando muchísimo. Y aún así, una parte del esfuerzo se va en reconstruir el contexto original. Y el que dirige eso, lo vive de otra manera. Es esa sensación de llevar tres reuniones, explicando lo mismo, y seguir sin ver nada funcionando.

**3:24** Ahí está la frustración. Y lo peor es que no sabes a quién señalar. Porque todos pueden estar haciendo bien su trabajo. Lo cual explica por qué más documentación no cerraba la brecha. Ahí está lo importante. El problema no era que Frank documentara poco. Es que un documento se interpreta.

**3:42** Cada persona que lo lee, construye su propia versión. Y esa versión es la que termina convertida en software. Entonces, la pregunta no es cómo explicarlo mejor. La pregunta es dónde queda guardado lo que ya se decidió. Y en la mayoría de las empresas, la respuesta es incómoda.

**4:02** Queda en la cabeza de alguien, en una conversación, o en un documento que ya nadie vuelve a abrir. ¿Y con un agente, eso desaparece? No. Esa es otra conclusión que hay que evitar. El agente también necesita contexto. Y también puede interpretar mal. Entonces, ¿dónde está la ventaja?

**4:22** En dos cosas. La primera es el tiempo. Entre que algo se interpreta mal, y tú lo detectas, o que no lo detectas. Pueden pasar minutos, en lugar de semanas. ¿Y la segunda? Que la decisión no se pierde. Cuando la corriges, queda registrada. El siguiente que trabaja sobre eso no tiene que volver a preguntar, lo consulta.

**4:41** Eso ya suena a algo más que una herramienta. Lo es. Y tiene nombre. No lo inventamos nosotros. Hasta aquí hemos hablado mucho de contexto, decisiones, y de cómo evitar que lo que una empresa aprende se pierda cada vez que alguien nuevo entra al proceso.

**5:02** Y justo ahí aparece una idea que ayuda a entender qué tendría que cambiar cuando empiezas a trabajar con agentes de inteligencia artificial. ¿De dónde viene esta idea de la que estás hablando? De una charla en Stanford de Chamath Palliapitiya. El título es cómo se gana en la era de la inteligencia artificial.

**5:22** ¿Y qué plantea? Dice algo que a un gerente le puede sonar extraño, pero que cambia completamente la forma de pensar cómo construimos con inteligencia artificial. Son apenas 30 segundos y prefiero que se lo escuches directamente a él. La verdadera verdadera base de todo esto en el mundo siempre será esta representación de hardware independiente, de datos independientes, de idiomas independientes, de lo que quieras hacer.

**6:05** Habló de construir el sistema operativo, en vez de la aplicación que corre encima. Esa es la primera parte, pero la segunda es la que importa para la historia de Frank. Dice que la fuente de verdad para todos esos agentes tiene que ser una representación de lo que quieres hacer, independiente de la herramienta con la que lo hagas.

**6:26** Tradúcelo para alguien que dirige una empresa y no escribe código. Es una capa donde vive lo que quieres lograr, separada del programa con el que lo construyes. No depende del lenguaje, ni de la base de datos, ni del modelo que esté de moda este año. ¿Y qué se guarda ahí? La intención, la decisión que se tomó, el resultado que produjo y de dónde salió cada cosa.

**6:50** No es un documento que describas.  Es el registro de lo que el sistema decidió y por qué. O sea que la diferencia con el documento de las 150 páginas es que ese registro no se interpreta. Se consulta. Y ahí está la diferencia con la cadena que describía Frank.

**7:10** En esa cadena, cada persona agregaba una interpretación. Acá la decisión queda en un solo lugar y cualquiera puede consultar la misma fuente. Incluyendo un agente. Incluyendo uno que empieza mañana y no estuvo en ninguna de las reuniones. ¿Y ustedes? ¿Llegaron a eso desde el principio?

**7:31** No. Y prefiero contarlo porque yo también cometí ese error. Al principio documentaba todo antes de construir. Escribía la especificación completa, la revisaba y recién ahí empezaba. Y me pasaba lo mismo que a Frank. A mitad del proceso, el documento ya no describía lo que realmente estábamos construyendo.

**7:51** ¿Y qué cambiaste? Dejé de intentar escribir todo el documento antes y empecé a registrar cada decisión cuando se tomaba, junto con el motivo. Parece un cambio pequeño, pero fue lo que más cambió el resultado. Porque el documento envejece y el registro no.

**8:10** El registro no tiene que predecir el futuro. Tiene que reflejar lo que era cierto cuando se tomó la decisión y quedar disponible para lo que venga después. ¿Y eso es lo que ustedes construyeron? Ese es el substrato sobre el que trabajamos. La aplicación es lo que se ve. El substrato es lo que hace que el trabajo de hoy le sirva al de la semana que viene.

**8:33** Las herramientas cambian. Esta capa acumula conocimiento. Aunque alguien podría decir que estamos comparando cosas distintas. Y tendría razón en preguntarlo. Porque quizá estamos comparando 8 meses de un equipo de trabajo.  ¿Qué es el tipo de ingeniería contra algo relativamente sencillo construido con inteligencia artificial?

**8:55** Después de todo lo que hemos visto con Frank, creo que queda una pregunta importante. ¿Por qué es fácil escuchar una historia así y pensar que funcionó por las características particulares de su negocio? Y esa es una distinción importante. No se trata de decir que ahora cualquier empresa puede reemplazar su forma de operar por agentes.

**9:16** Hay que entender primero dónde está la distinción.  Y dónde está realmente el cuello de botella. Entonces te hago la pregunta que probablemente se está haciendo el que nos está viendo. El caso de Frank es un negocio específico. ¿Esto sirve en cualquier operación? No necesariamente. Sirve especialmente cuando el cuello de botella está en la distancia entre quien decide y quien ejecuta.

**9:41** Si tu principal problema está en máquinas, logística física o trabajo que necesariamente ocurre en la calle, lo sacas de la calle. Y los agentes no van a hacer desaparecer esa limitación. Pero si el problema está entre la idea y la ejecución. Ahí cambia la historia. Si sabes lo que necesitas, pero convertirlo en algo que funcione tarda semanas

**10:02** porque tiene que atravesar reuniones, documentos, interpretaciones y varias personas, entonces sí tienes una oportunidad enorme de reducir esa distancia. ¿Y hay que ser técnico para hacerlo? El caso de Frank es interesante precisamente por eso. Frank no es programador.

**10:21** Lo que sí tiene es una claridad enorme sobre su negocio y la disposición a tomar decisiones rápido. Entonces el conocimiento importante no era necesariamente saber escribir el código. Era saber qué debía hacer el sistema, reconocer cuándo el resultado estaba mal y tomar la siguiente decisión.

**10:41** La inteligencia artificial puede ayudarte con la ejecución, pero no puede sustituir esa claridad. Eso cambia bastante el perfil de la persona que puede construir. Y probablemente sea una de las consecuencias más interesantes de todo esto. Estamos reduciendo la distancia entre conocer profundamente un problema

**11:03** y poder convertir ese conocimiento en algo que realmente funciona. Porque el problema no era simplemente cuántas personas estaban construyendo. Era cuánto de lo que Frank sabía sobre su negocio lograba convertirse en decisiones ejecutables sin perderse por el camino. Ocho meses acumulando documentos frente a un sistema que empieza a acumular decisiones.

**11:27** Y ahí está la diferencia. Pero quiero ser claro con algo. Esta forma de trabajar no es para cualquiera. ¿A qué te refieres? Si lo que buscas es que alguien te entregue un sistema terminado para no volver a pensar en él, esto probablemente no te va a servir. Esto es para quien quiere entender cómo funciona lo que está operando su negocio

**11:50** y seguir tomando las decisiones importantes. Aunque hay algo que todavía no hemos contado. Por lo que me dijiste, esos ocho meses ni siquiera fueron el costo más grande que Frank estuvo a punto de pagar. No. Y esa parte de la historia cambia completamente la conversación. Porque ya no estamos hablando solamente de tiempo perdido.

**12:11** Entonces. Entonces. ¿Qué estuvo en juego? Frank llegó a considerar entregar una parte de su empresa para conseguir la capacidad que necesitaba para construirla. Después de todo lo que acabamos de ver, eso pudo terminar costándole muchísimo más que ocho meses. Muchísimo más. Y en el próximo episodio vamos a ver qué estuvo a punto de entregar,

**12:32** por qué llegó hasta ese punto y qué cambió después. Entonces el siguiente capítulo ya no es solamente una historia sobre tecnología. No. Es una historia sobre cuánto puede terminar costándote no encontrar una forma de ejecutar lo que tienes en la cabeza.