Un año construyendo una Pomelo AI-Native: infraestructura, procesos y equipos

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 y escalarla en Pomelo. Haciendo ese análisis, empecé a identificar patrones que se repetían una y otra vez porque . Equipos pequeños, agentes participando activamente del trabajo cotidiano, especificaciones como eje de coordinación y una velocidad de ejecución difícil de explicar desde las estructuras tradicionales.

La pregunta dejó de ser tecnológica y pasó a ser organizacional. ¿Era posible llevar esos principios a Pomelo, una empresa que opera cientos de clientes, millones de transacciones y emisión a escala global?  La respuesta es sí:

• 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. Conoce los detalles a continuación.

¿Por dónde empecé?

La primera observación en compañías AI-Native fue casi incómoda: lo que tradicionalmente se resuelve con equipos de diez o quince personas empezó a resolverse con tres o cuatro personas trabajando junto a agentes. No porque trabajaran más, ni porque fueran mejores, sino porque estaban operando bajo una lógica completamente distinta.

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

El contexto es la materia prima

Para que un agente funcione, su principal materia prima es el contexto. Sin contexto no sabe qué hacer ni qué responder; con el contexto indicado, amplifica la performance de cualquier persona o equipo.

En una organización AI-Native, la documentación deja de ser un entregable que se escribe una vez y se desactualiza, y pasa a ser el lugar donde una idea evoluciona: de una conversación sobre un problema de negocio a una definición de producto, a las decisiones técnicas, hasta convertirse en el contexto que consumen los agentes que construyen y validan. Deja de llamarse "documentación" y pasa a ser "especificaciones": el lenguaje común que conecta negocio, producto, ingeniería y agentes. Cuando eso ocurre, la calidad de las conversaciones mejora y buena parte de las pérdidas de contexto entre equipos empieza a desaparecer.

De ahí que Spec Driven Development (SDD) haya empezado a tener sentido para nosotros, no como metodología sino como consecuencia lógica de trabajar junto a la AI. Hoy, cuando definís algo, Claude te pregunta si querés crear una especificación. En una startup de tres a diez personas eso fluye casi solo. Nuestro desafío era otro: que cientos de personas generen especificaciones con un nivel de calidad consistente, que negocio, producto e ingeniería compartan un único framework de trabajo, y que los agentes reciban contexto estructurado sin que la velocidad destruya la calidad.

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

Primero, lo primero: la infraestructura

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

Sobre esa base 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 distinta. Hoy el 100% de nuestro uso de AI pasa por ese gateway y los productos nuevos ya nacen MCP-first. Nada de esto es necesario para una AI-Native chica, pero es fundamental para una empresa de escala.

Con estos cambios pudimos darles a los agentes contexto de productos que ya existían, y validamos algo clave: a mejor calidad de contexto, mejor calidad de los agentes. Eso nos empujó al siguiente paso: convertirlo en una práctica continua, simple y automática, como pasa en una AI-Native. Y para lograrlo tuvimos que repensar todos nuestros procesos.

Los procesos determinan cómo fluye la información: cómo una necesidad de negocio se transforma en definición de producto, luego en especificación funcional y, finalmente, en definición técnica. Una de las sorpresas más interesantes del recorrido fue que las especificaciones funcionales que hoy construimos junto a la AI alcanzan un nivel de profundidad, precisión y contexto que difícilmente una persona hubiera podido producir sola. Y ese resultado se convierte en el mejor input posible para producto, arquitectura, ingeniería y agentes.

La iteración constante entre negocio, producto y tecnología, amplificada por la AI, termina produciendo algo más importante que una mejora de productividad: es el riel para convertirte en una organización superior a la que tenías antes. Ese es el concepto que realmente permite evolucionar. No se trata de evolucionar las herramientas, sino de evolucionar los procesos para evolucionar la organización.

Una nueva generación de builders

Cuando se habla del futuro del desarrollo de software, la conversación suele reducirse a una pregunta bastante limitada: ¿la AI va a reemplazar a los desarrolladores? Creo que miramos el problema desde el lugar equivocado. La transformación real no tiene que ver con cuánto código escribe un developer, sino con qué significa construir software.

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 y controles de calidad, garantiza seguridad, escalabilidad y observabilidad, y 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: acceso a información, contexto, conocimiento organizacional y personas capaces de diseñarlos, construirlos, orquestarlos y mantenerlos funcionando a escala.

Las especificaciones se vuelven una pieza central porque son el mecanismo que permite transferir intención a escala: no solo ayudan a una persona a entender qué construir, sino que 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.

Menos capas, más equipos: los micro-squads

Se escucha cada vez más seguido que la inteligencia artificial está eliminando el middle management, y casi siempre la explicación es la misma: eficiencia, reducción de costos, menos capas. Después de este año de aprendizaje creo que la eficiencia es una consecuencia, no la causa. Lo que realmente pasa es que la AI amplifica al mismo tiempo los dos extremos de la 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 crecen a la vez, buena parte del trabajo que históricamente ocurría en el medio se redistribuye de forma natural. No porque alguien lo elimine, sino 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 nos permitió expandir horizontalmente y multiplicar nuestros micro-squads, generando más capacidad de producción y aumentando el throughput de ingeniería. 

La distancia entre una idea y su ejecución se acorta, y buena parte de la energía que antes se consumía coordinando queda disponible para construir. Ahí aparecieron los micro-squads: equipos más chicos, más autónomos, en una organización más horizontal. El objetivo dejó de ser optimizar una estructura por mandato y pasó a ser multiplicar la cantidad de equipos capaces de generar delivery real.

Para mí, esa es una de las diferencias más importantes entre adoptar herramientas de AI y construir una organización AI-Native: la primera busca eficiencia; la segunda busca transformar la organización en una versión realmente superior a la 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.