Metodología

De ejecutor a director: lo que aprendí construyendo en dos días y medio lo que un equipo hace en un trimestre

Estimé un mes con una persona, el cliente urgido me pidió el mínimo real, le respondí dos semanas siendo irresponsablemente optimista. Tardó dos días y medio. La explicación no es la herramienta. Es un cambio de rol que aplica a casi cualquier profesional con criterio acumulado.

Felipe Catalán
9 min de lectura

Hice algo que no me esperaba

Voy a contar una historia corta, pero antes una advertencia: la moraleja no es la que parece al principio.

Me pidieron construir un sistema. Desde que esta nueva generación de agentes de IA se volvió capaz, me cuesta mucho estimar cuánto tiempo me va a tomar un proyecto. Los tiempos se comprimieron y todavía no tengo una intuición estable de cuánto.

Entonces hago lo único que sé hacer bien: parto desde la estimación que conozco. Cuánto tardaría un equipo tradicional en hacer lo mismo. En este caso eran tres a cuatro meses de un equipo de tres personas: un frontend, un backend y un analista funcional. Sobre eso, estimé que yo solo lo terminaba en un mes. Eso ya implicaba ser diez veces más productivo que un equipo competente. Era exigente.

El cliente, urgido, me preguntó cuál era el mínimo real que me podía tomar. Le dije, siendo irresponsablemente optimista, dos semanas. Me contestó: “Dale, lo que te demores.”

En dos días y medio estaba prácticamente terminado.

Qué quedó construido

Quiero detenerme acá porque la objeción inmediata —y razonable— es: “claro, armaste un prototipo en un editor de prototipos y le llamas sistema”. No es eso.

Lo que quedó construido en esos dos días y medio es una plataforma de aprendizaje empresarial con:

  • Arquitectura moderna: frontend reactivo, backend vía API, base de datos versionada con migraciones.
  • Capacidad multi-empresa: cada cliente ve su propio espacio con aislamiento real de datos a nivel del motor de la base de datos. No es separación por configuración. Es separación de motor.
  • Coach de IA embebido, que adopta la identidad y el lenguaje de cada empresa que contrata el producto. Para el cliente del piloto, el coach se llama Andrea y habla en lenguaje de transmisión eléctrica: “colaborador”, “Líder”, “subestación”, “anillo AT”. No es un chatbot genérico.
  • Autenticación de doble factor, ingreso por enlace mágico sin contraseña, envío de correos desde un dominio propio.
  • Videos protegidos contra descarga, con miniaturas y storyboards firmados.
  • Editor de contenido en vivo para los administradores, con vista previa.
  • Auditoría granular: cada cambio relevante queda registrado con autor, dirección de origen y momento exacto.
  • Pruebas automatizadas, despliegue continuo y monitoreo desde el primer día. Cada cambio pasa por verificación antes de quedar en producción.

No es trivial. Es lo que cualquier empresa con un equipo de tres personas tardaría un trimestre en armar.

La objeción razonable

Una objeción válida acá es si mi estimación inicial estaba inflada. Si dije “tres a cuatro meses con un equipo de tres” para que el resultado luciera más espectacular de lo que era.

Cuando terminé, le pedí al mismo agente que mirara el código construido y estimara desde cero cuánto le tomaría a un equipo tradicional —un frontend, un backend, un analista— reconstruir exactamente lo mismo, sin verme a mí trabajar.

Llegó al mismo número. Tres a cuatro meses.

El cálculo es directo: tres personas trabajando 160 horas al mes cada una, durante tres a cuatro meses, suman entre 1.440 y 1.920 horas de equipo. El punto medio queda en torno a 1.680 horas.

Lo que efectivamente me tomó a mí: dos días y medio de trabajo concentrado, alrededor de 20 horas.

El factor de multiplicación queda entre 72x y 96x, dependiendo de dónde caes en el rango. Yo uso 90x cuando lo cuento — está dentro del rango y es el orden de magnitud que importa.

La misma semana

La misma semana que esto pasó, Microsoft anunció que había consumido su presupuesto anual completo en consumo de IA. La conversación pública se concentró en si eso era buena o mala señal para la industria, si los modelos eran demasiado caros, si Anthropic iba a quedar bien o mal parada.

Mientras esa conversación ocurría en silla pública, en otro lado, profesionales con una suscripción de veinte dólares mensuales estaban haciendo en días lo que sus equipos hacían en trimestres.

Esa segunda historia, que es la importante, todavía no llega a las portadas. Pero está pasando.

La capacidad que tiene hoy un agente moderno, comparada con la de hace dieciocho meses, no es una mejora marginal. Es un salto de categoría. Pasamos del autocompletado al sistema que lee una especificación de mil novecientas líneas, escribe el código necesario, ejecuta sus propias pruebas, lee sus errores y se corrige solo. La mayoría de los profesionales todavía está operando con la imagen mental de capacidades de 2023.

Por qué pasó (bajemos una capa)

La lectura fácil de esta historia es errónea. La lectura fácil dice: “Felipe pagó veinte dólares al mes y se volvió noventa veces más productivo.” Eso es lo que parece. Pero no es lo que pasó.

Conviene bajar una capa.

Lo que pasó no fue el modelo. El modelo existe hace dieciocho meses. Cualquiera puede acceder a él.

Lo que pasó no fue la suscripción. La paga cualquiera.

Lo que pasó no fue el lenguaje de programación, ni la base de datos, ni el editor.

Lo que pasó fue una combinación de tres cosas que tuvieron que estar presentes simultáneamente:

  1. Una especificación disciplinada como contrato. Antes de empezar a construir, había un documento de mil novecientas líneas con requisitos numerados, modelo de datos diseñado, decisiones técnicas registradas (R1, R64c, R91…). Cada vez que el agente intentaba apartarse, la especificación lo devolvía al carril. Sin ese documento, el agente diverge y se gasta tiempo en deshacer.
  2. Conocimiento dual del negocio y de la técnica. Saber qué tiene que hacer Andrea en una conversación con un Líder de transmisión eléctrica y, en el mismo minuto, saber qué significa una política de aislamiento de datos a nivel del motor de la base de datos. Eso permite dirigir al agente sin perder tiempo en explicaciones intermedias.
  3. Un agente capaz, no un autocompletado. Un sistema que puede leer la especificación, navegar el código, escribir migraciones, ejecutar las pruebas, leer el error, corregir y reintentar. El operador humano dirige; el agente ejecuta.

Si falta cualquiera de las tres, la velocidad cae rápido.

Con un operador sin base técnica, las decisiones de plataforma y los ciclos de corrección son imposibles de dirigir. Con un operador técnico pero sin contexto del negocio, el código funciona pero no resuelve el problema correcto del cliente. Con ambos pero sin especificación disciplinada, el proyecto deriva en círculos.

La multiplicación no estaba en el modelo. Estaba en la combinación.

El cambio que importa: de ejecutor a director

Por eso vale la pena ser preciso con lo que efectivamente pasó.

Yo no me volví noventa veces más productivo. No soy noventa veces mejor que el Felipe de hace dos años. La diferencia no está en mí.

Lo que pasó es esto: dejé de ser quien ejecuta el trabajo y pasé a ser quien dirige a quien lo ejecuta.

La multiplicación está en ese cambio de rol, no en la herramienta.

Cuando ejecutas, estás limitado por la velocidad de tus manos, por el tamaño de tu memoria de trabajo, por la cantidad de horas seguidas que puedes mantener foco. Cuando diriges, estás limitado por la claridad de tu criterio y por la calidad de las decisiones que tomas en los puntos de bifurcación. El criterio escala. Las manos no.

Para que ese cambio de rol funcione, tienes que tener algo que dirigir y algo desde donde dirigir.

Lo que tienes que dirigir es el agente —y los agentes actuales ya están en un punto en el que pueden recibir dirección compleja y ejecutarla.

Lo que necesitas para dirigir es criterio acumulado en tu vertical. Es decir, los quince o veinte años que llevas haciendo lo que haces. La capacidad de mirar una propuesta y saber dónde está el problema en treinta segundos. La intuición de cuándo una decisión es reversible y cuándo no. El vocabulario preciso para nombrar lo que está bien y lo que no.

Ese criterio no se compra con una suscripción. Se construye con años de hacer el trabajo.

Por eso esto no es solo para developers

Acá está la parte que más me importa.

Yo no puedo ser noventa veces más productivo que un abogado. No tengo el criterio acumulado para dirigir su trabajo. No sé en qué cláusulas mirar primero, no tengo internalizada la jurisprudencia relevante, no reconozco la diferencia entre un contrato bien redactado y uno con riesgo escondido.

Pero un abogado con criterio sí puede dirigir su propio trabajo a esa escala. Tiene exactamente la materia prima que el agente necesita: criterio profesional acumulado, capacidad de detectar errores rápido, claridad sobre el resultado esperado.

Lo mismo aplica a diseño, a estrategia, a marketing, a operaciones, a ventas, a atención al cliente, a auditoría, a control de gestión, a recursos humanos, a contabilidad, a inversión, a investigación de mercado.

El criterio que tu vertical te tomó quince años en construir es exactamente la palanca que necesitas para dirigir, en vez de ejecutar.

La pregunta que vale la pena hacerse no es “¿puedo aprender a usar esta herramienta?”. Es “¿en qué parte de mi trabajo hay criterio acumulado que todavía estoy aplicando a escala manual?”

Casi siempre la respuesta es: en casi todo.

Lo que todavía estoy procesando

Yo no me esperaba este resultado. Y todavía estoy procesando lo que significa. Para mí. Para mi profesión. Para el negocio. Para el mercado laboral. Para la sociedad.

Lo que sí tengo claro es que el profesional con criterio acumulado en su vertical que todavía no está operando así va a ver lo mismo que vi yo en los próximos meses. La diferencia va a estar en quién se encuentra con el dato dirigiendo, y quién se lo encuentra cuando ya alguien más lo está aplicando en su industria.

Cuando esto se masifique —y se va a masificar—, dirigir agentes desde criterio acumulado dejará de ser una ventaja diferencial y pasará a ser el piso del trabajo profesional. Como pasó con saber usar el correo electrónico en 1998, con saber buscar en Google en 2005, con saber operar en la nube en 2015.

El piso se va a mover. La pregunta es si llegas al nuevo piso antes o después que el resto de tu mercado.


Yo me dedico, entre otras cosas, a entrenar líderes de empresas latinoamericanas para que hagan precisamente esto en su propia vertical. No en abstracto: con su criterio acumulado, su contexto real, sus decisiones de la próxima semana. Si te interesa cómo se ve eso aplicado a tu rol, escríbeme por LinkedIn.

Recibe el newsletter de AIThinking

Artículos, casos y estrategias para colaborar con IA de forma estratégica. Directo a tu correo.

Sin spam. Puedes darte de baja cuando quieras.