Escalando hacia AI-Native

Hace aproximadamente un año me obsesioné con una idea: entender si era posible tomar la forma en la que operan las compañías AI-native (reales) y escalarla en Pomelo.

Todo el tiempo aparecen frases célebres, definiciones simplificadas e incluso discusiones bastante superficiales sobre inteligencia artificial. Muchas veces terminan empañando el verdadero impacto que esta tecnología puede generar en una organización, y va mucho más allá de la tecnología.

Después de más de un año acompañando startups AI-Native, fui identificando patrones que aparecían naturalmente en este tipo de empresas. Gran parte del último año me enfoqué en entender cómo llevar esos mismos principios a Pomelo, preservando la esencia de una AI-Native, pero operando a una escala +10X mayor tanto en clientes, tráfico y equipos. ah! Y en una industria con regulaciones en cada uno de los 8 países en los que operamos.

Una buena forma de percibir el resultado de lo que solo representa el comienzo, es:

• En 12 meses multiplicamos 6X el throughput de ingeniería.
• Mejoramos 3.2X el time to delivery.
• Mejoramos prácticamente todos los indicadores de salud de nuestra plataforma, incluyendo uptime, capacidad de procesamiento y resiliencia operativa.
• Y, quizás más importante todavía, comenzamos a transformar la forma en la que construimos nuestro producto, cómo nos organizamos y cómo opera nuestra plataforma y nuestro equipo.

La primera observación fuerte, fue incómoda

Lo que tradicionalmente resolvemos con equipos de 10 o 15 personas empezaba a resolverse con 3 o 4 personas trabajando junto a agentes. No porque esas personas trabajaran más, ni porque fueran mejores, sino porque estaban operando bajo una lógica completamente diferente.

Por eso puedo asegurar algo: pensar que la inteligencia artificial se limita a automatizar flujos o generar código es una mirada con bastante miopía. El verdadero cambio ocurre cuando dejás de pensar en transformar una organización existente y empezás a rediseñarla desde cero. Luego, el desafío es transformarlo en realidad cuando tenés un negocio vivo, cientos de personas operando cientos de clientes y casi una decena de países.

Y esto fue exactamente lo que nos ocurrió: comenzamos por tecnología y rápidamente apareció un efecto dominó que terminó impactando en toda la empresa. Procesos, flujos de trabajo, estructuras organizacionales, roles e incluso la forma en la que evaluamos equipos y personas... y cuando llegás a ese punto aparecen cambios culturales que son necesarios para que actúen como enabler de decisiones. De hecho, si no lo vivís de esa manera, el riesgo es terminar atrapado en una nueva generación de transformaciones digitales que nunca terminan de transformar nada.

Empresas nacidas en esta nueva era

Durante este tiempo tuve la oportunidad de acompañar startups verdaderamente AI-Native. Empresas completas de 10 a 15 personas con impacto comparable al de equipos de 50. Otras con más de veinte personas produciendo a una velocidad que históricamente asociamos con organizaciones de cientos. Y cuanto más las observaba, más me llamaba la atención un detalle.

Ambas operaban de manera iguales! No utilizaban exactamente las mismas herramientas. No tenían los mismos productos, ni siquiera resolvían los mismos problemas, pero compartían patrones muy similares.

Tal vez el primero y el eslabón más oculto de la cadena: las especificaciones ocupaban un lugar central, los agentes participaban activamente del trabajo cotidiano, la coordinación ocurría alrededor del contexto compartido mucho más que alrededor de estructuras formales, y los equipos eran pequeños, de 2 o 3 personas, extremadamente autónomos y capaces de avanzar a una velocidad poco habitual para organizaciones tradicionales.

Lo interesante es que estas compañías no estaban intentando transformarse. Simplemente habían nacido así, y eso le gana a cualquier consejo porque es nativo de verdad. Ahí fue donde apareció una pregunta que terminó ocupando gran parte de mi tiempo durante el último año.

¿Cómo escalar estos patrones?

¿Cómo llevás dinámicas que aparecen naturalmente en compañías de 20 o 30 personas a organizaciones que operan múltiples productos, distintos países, regulaciones complejas y cientos de personas trabajando en paralelo?

Lo que me obsesionó no fue la tecnología, fue entender qué había detrás de esa forma de operar. Por qué equipos tan pequeños podían avanzar con semejante nivel de autonomía, alineación e impacto, y por qué compañías que no se conocían entre sí terminaban llegando a conclusiones tan parecidas.

¡Estamos frente a un cambio increíble! Mi desafío pasó a ser cómo capturar esos principios y escalarlos dentro de una organización mucho más compleja sin perder velocidad, calidad ni autonomía. Tan simple y tan complejo.

El rol de la documentación y el contexto para los agentes

Partimos de la base de que, para que un agente de AI funcione, su principal materia prima es la información o, mejor dicho, "el contexto". Sin contexto no sabría qué hacer o qué responder, pero con el contexto indicado, un agente tiene una capacidad que amplifica la performance de cualquier miembro o de cualquier equipo.

Una de las primeras cosas que observé es que la documentación ocupa un rol completamente distinto al que históricamente le asignamos. Durante años, una documentación de negocio o producto era algo que se escribía para alinear personas antes de empezar a construir. E incluso circulan versiones desactualizadas respecto de la realidad de lo que se construye.

En una organización AI-Native ocurre algo diferente: la documentación se convierte en el lugar donde una idea evoluciona y juega un papel fundamental. Una conversación inicial sobre un problema de negocio puede transformarse en una definición profunda utilizando inteligencia artificial para explorar alternativas, comparar soluciones, incorporar conocimiento interno, analizar riesgos, validar supuestos y enriquecer continuamente el entendimiento del problema.

La documentación se transforma en "especificaciones" y deja de ser un entregable: ahora son el contexto clave que las personas, el equipo y los agentes necesitan para saber exactamente qué hacer. Acompaña todo el recorrido, ayuda a entender un problema de negocio y evoluciona hacia una definición de producto. La documentación es la materia prima para las decisiones técnicas y finalmente se convierte en el contexto que consumen los agentes que participan en la construcción y la validación de entregables. Por tanto, existe desde la idea y vive hasta después de la implementación.

Entonces, las especificaciones terminan convirtiéndose en el lenguaje común que conecta negocio, producto, tecnología y agentes. Cuando eso ocurre, la calidad de las conversaciones mejora y gran parte de las pérdidas de contexto que históricamente existían entre equipos comienzan a desaparecer.

Spec Driven Development (SDD)

Ahí fue donde SDD empezó a tener sentido para mí. No como una metodología, sino como una consecuencia lógica de trabajar junto a inteligencia artificial.

El desafío no era adoptar SDD, sino escalarlo. En una startup AI-Native muchas de estas dinámicas aparecen casi solas. Hoy, cuando estás definiendo algo, Claude te pregunta si querés crear una especificación, es decir, un documento de texto plano llamado markdown, el cual contiene algunos caracteres que le sirven a los agentes como indicadores para entender mejor el contexto, pero que para nosotros es simplemente un documento lleno de información que deberá expresar con extrema profundidad lo que tenemos que hacer. Y, en una AI-Native company, estos documentos fluyen muy fácilmente entre 3 o 10 personas… Pero, ¿cómo llevamos esto a otra escala? Necesitás que:

• cientos de personas generen especificaciones con un nivel consistente de calidad;
• negocio, producto e ingeniería compartan un único framework de trabajo;
• los agentes reciban contexto estructurado, mientras te asegurás de que la velocidad no destruya la calidad.

Para lograrlo terminás rediseñando mucho más que el desarrollo de software. Terminás replanteando la forma en que una organización entiende problemas, transforma ideas en decisiones y convierte esas decisiones en ejecución. Durante años intentamos optimizar distintas partes del proceso, pero AI te obliga a replantear el proceso completo.

Primero, lo primero

Uno de los aprendizajes más importantes fue entender que SDD no escala solamente porque las personas escriban mejores especificaciones. Escala cuando la organización es capaz de convertir su conocimiento en algo accesible y utilizable por agentes.

Por eso, antes de transformar la forma de trabajar, transformamos nuestra infraestructura. Incorporamos una capa de MCPs como fuente principal de contexto para agentes y mecanismo que permite conectar sistemas, conocimiento y skills como layer de capacidades distribuidas dentro de la organización. En otras palabras, preparar la infraestructura para un mundo donde el trabajo es mixto: personas y agentes trabajando en simultáneo.

A partir de ahí construimos una capa de agentes conectados a ese contexto y un AI-Gateway que nos permitió gobernar modelos, costos, ambientes y responsabilidades a una escala completamente diferente. Hoy el 100% de nuestro uso de AI pasa por ese gateway y los productos nuevos ya nacen MCP-first. Por supuesto, nada de esto es necesario para una AI-Native, pero es fundamental para empresas de escala.

Con estos cambios, pudimos darle contexto de productos preexistentes a los agentes y validamos que, a mejor calidad de contexto, mayor calidad de agentes. Y esto nos llevó al siguiente nivel: necesitábamos hacer de esto una práctica continua, simple y automática como sucede en una AI-Native, así que tuvimos que repensar todos nuestros procesos. Los procesos determinan cómo fluye la información dentro de una compañía y cómo una necesidad de negocio termina transformándose en una definición de producto, una especificación funcional y finalmente una definición técnica.

Esta fue probablemente una de las sorpresas más interesantes del recorrido.

Las especificaciones funcionales que hoy podemos construir junto a inteligencia artificial alcanzan niveles de profundidad, precisión y contexto que difícilmente una persona hubiera podido producir por sí sola, y ese resultado termina convirtiéndose en el mejor input posible para producto, arquitectura, ingeniería y agentes.

La iteración constante entre definiciones de negocio, producto y tecnología, amplificadas por inteligencia artificial, termina produciendo algo mucho más importante que una mejora de productividad: es definitivamente el riel para convertirse en una organización superior a la que tenías antes. Acá es donde aparece el verdadero concepto que te permite evolucionar. No evolucionar las herramientas. Evolucionar procesos para evolucionar la organización y favorecer estas nuevas capacidades.

La nueva generación de builders

Quizás una de las transformaciones más profundas que observé durante este último año tiene que ver con la aparición de una nueva generación de builders. Cuando escucho hablar sobre el futuro del desarrollo de software, muchas veces la conversación termina reducida a una pregunta bastante limitada: ¿la AI va a reemplazar a los desarrolladores?

Mi sensación es que estamos mirando el problema desde el lugar equivocado. La verdadera transformación no tiene que ver con cuánto código escribe un developer. Tiene que ver con qué significa construir software. Las compañías AI-Native más avanzadas ya están mostrando una nueva generación de profesionales. Personas que entienden profundamente el negocio y el producto, pero que al mismo tiempo son capaces de diseñar los sistemas que permiten construirlos.

En este modelo el ingeniero deja de ser principalmente un implementador y se convierte en el diseñador de una fábrica de generación de software:

• Define especificaciones.
• Diseña agentes.
• Decide qué contexto reciben.
• Establece mecanismos de validación.
• Define controles de calidad.
• Garantiza seguridad, escalabilidad y observabilidad.
• Y finalmente valida que el resultado generado por el sistema sea consistente con la intención original.

Los agentes requieren una enorme cantidad de ingeniería detrás. Necesitan acceso a información. Necesitan contexto, conocimiento organizacional y personas capaces de diseñarlos, construirlos, orquestarlos y mantenerlos funcionando a escala.

Las especificaciones se transforman en una pieza central porque son el mecanismo que permite transferir intención a escala. No solamente ayudan a una persona a entender qué debe construirse. También permiten coordinar un conjunto completo de agentes trabajando sobre una misma necesidad.

El cuello de botella dejó de ser construir y pasó a ser revisar: hoy producimos más de lo que alcanzamos a revisar. Y ese es exactamente el problema que querés tener. Cuando la velocidad de construcción deja de ser el factor limitante, la calidad de las decisiones pasa a ocupar el centro de la escena.

Una observación sobre el middle management

Cada vez escucho más líderes, referentes de la industria, speakers o divulgadores repetir la misma frase: "La inteligencia artificial está eliminando el middle management". Y casi siempre la explicación es la misma. Eficiencia. Reducción de costos. Menos capas. Más productividad.

Después de pasar el último año observando y aprendiendo de compañías AI-Native e intentando escalar muchos de los patrones que comenté antes, creo que la explicación real es bastante más interesante y se ve con mucha claridad: la eficiencia es una consecuencia y no la causa. Lo que realmente sucede es que la inteligencia artificial amplifica simultáneamente dos extremos de una organización.

Por un lado, las personas con más contexto aumentan enormemente su capacidad para analizar, diseñar, decidir y liderar. Por el otro, quienes están más cerca de la ejecución empiezan a trabajar acompañados por agentes que construyen, validan, documentan, revisan y operan junto a ellos.

Cuando ambos extremos aumentan su capacidad al mismo tiempo, gran parte del trabajo que históricamente ocurría en el medio empieza a re-distribuirse de forma natural. No porque alguien lo elimine. Simplemente porque deja de ser necesario. En lo que va del año eso se tradujo en quitar entre una y dos capas de management por área; no por recorte, sino porque el propio cambio las volvió innecesarias, y esto nos permitió crecer horizontalmente generando más micro-squads y multiplicar nuestro throughput.

Y la distancia entre una idea y su ejecución se acorta. Una parte importante de la energía que antes se consumía coordinando termina disponible para construir nuevos equipos, para producir más pero en equipos mucho más chicos y con mayor autonomía. Esto es exactamente lo que te permite redefinir tu organización a base de micro-squads.

Micro-Squads

Una consecuencia natural de todo esto fue la evolución hacia estructuras basadas en micro-squads. La energía que antes consumíamos coordinando empieza a quedar disponible para construir nuevos equipos en una organización más horizontal. Y el efecto multiplicador te empieza a mostrar todos los cambios reales que necesitás producir, ya no por "mandato" o porque así dicen que hay que hacer en la AI-Native, sino porque el propio cambio te exige cambios para que todo fluya más rápido.

Se empiezan a ver procesos que quitan velocidad sin sentido: el impacto en la forma de medirnos, dónde romper procesos o implementar automatizaciones, dónde dejar de perder tiempo y dónde poner el foco en esta nueva forma de operar. Y esto cambia algo clave. El objetivo deja de ser "optimizar una estructura, por mandato" y pasa a ser multiplicar la cantidad de equipos capaces de generar más y más delivery real.

Mirándolo en perspectiva, creo que esa es una de las diferencias más importantes entre adoptar herramientas de AI y construir una organización AI-Native.

La primera idea busca eficiencia; la segunda busca transformar la organización en una realmente superior a la versión anterior.

No es solo software

Si tuviera que resumir todo este recorrido en una sola idea, sería esta: la inteligencia artificial no está cambiando únicamente la forma en que construimos software. Es un salto generacional en la forma en que se construyen los negocios digitales.

Aparece una nueva generación de ingenieros con capacidades amplificadas por la AI, en línea con un concepto sobre el que vengo escribiendo hace años y que hoy está más vigente que nunca: el product engineer. Un rol de tecnología mucho más amplio que el tradicional, inmerso no solo en la tecnología que construye software, sino en el entendimiento profundo del producto, el negocio y la operación punta a punta de la empresa.

Lo tomo como lo que es: un compromiso con la evolución. No con una idea abstracta de transformación, sino con la evolución hacia una Pomelo superior a la que teníamos hace un año. Y esto recién empieza.