En julio de 2025 firmamos la constitución de Orbitant.

En aquel momento recuerdo que la gran revolución de la que más se hablaba era el "autocomplete de Cursor", así que a medida que el equipo empezó a crecer en los siguientes meses, decidimos afianzar nuestro compromiso comprando las suscripciones anuales.

Hasta que probé Claude Code.

Lo importante en realidad no fue cambiar de herramienta, sino darme cuenta de que la empresa entera, no solo el flujo de desarrollo, estaba mal planteada para lo que venía.

Estábamos usando la IA como una mejora de productividad sobre procesos pensados para humanos. Y no ponerla en el centro me hacía sentir así:

Pin by Matthew Choi on Briefing inspo | Ferrari 458 Italia, Ferrari 458, Ferrari

Este artículo pretende transmitir nuestro camino hacia la transformación a una empresa AI-Native.

Disclaimer: si esperas un repo con diez ficheros .md prometiendo una legión de agentes que opera tu empresa mientras dedicas dos horas a la semana, este no es tu post. Esto va de lo otro: de trabajo, de fricciones, de dudas y de decisiones que cuestan dinero y tiempo.

Poniendo en contexto la que se viene

Es indudable que la humanidad está evolucionando a pasos agigantados. Por poner en perspectiva:

• De la Edad de Piedra a la Agricultura: 100.000 años.
• De la Agricultura al vapor: 12.000 años.
• Del vapor a la IA: 200 años.

Es decir: entre 2000 y 2014 se concentraron 100 años de progreso en solo 14.

La predicción de los años futuros pasa porque este crecimiento se acelere aún más gracias a los desarrollos de las últimas tecnologías.

La IA aprende y genera un efecto compuesto (la tecnología previa no tenía capacidad de mejorar por sí misma a esta velocidad), lo cual prácticamente asegura un crecimiento exponencial.

Saliendo del modo piloto

La mayoría de empresas están atascadas en un piloto eterno. Tienen Copilot en el IDE, un wrapper sobre GPT en algún script interno, una POC de un RAG en customer support que nunca llega a producción.

Las herramientas funcionan, pero a la compañía en realidad no le mueve demasiado la aguja.

El problema no es la IA. El problema es que el org chart, los KPIs, el SDLC, el ciclo comercial y todo el sistema operativo de la empresa está construido para que lo opere un humano.

Pegar IA encima de un proceso optimizado para humanos aporta, con suerte, un veinte por ciento de eficiencia extra. Atrapado en un máximo local que algún C-level llamaría "revolución histórica" en los consejos de administración.

Lo que sí cambia el orden de magnitud es rediseñar el sistema desde abajo.

Eso, para mí, es lo que significa ser "AI native".

Las bases de una empresa AI native

El reto es pensar diferente (y no es trivial). Tu cerebro y tu organización llevan décadas optimizándose para que un humano comprenda, navegue y ejecute. Pero ahora hay que diseñar también para que un agente pueda hacerlo.

Vercel publicó hace poco Zero, un lenguaje de sistemas en la liga de C o Rust. Lo distinto es que su compilador y su toolchain fueron pensados desde el día uno para ser consumidos por agentes, no solo por ingenieros.

Stripe lanzó recientemente Link's wallet for agents: con él, un agente puede pagar programáticamente con tarjetas de un solo uso y tokens compartidos, sin ver nunca las credenciales reales del cliente.

Estas features no son improvisadas, sino diseñadas con el agente como usuario primario.

Si no estás convencido aún de que los procesos para agentes y humanos pueden ser muy diferentes, mira en este vídeo cómo dos IAs optimizan su comunicación hablando en GibberLink, dejando el inglés de lado para empezar a enviarse paquetes de información estructurada (porque es mucho más eficiente).

Ahora, aplica ese mismo principio dos niveles más arriba. Una empresa AI native entonces, no es simplemente una empresa con agentes, sino una empresa donde cada workflow, cada decisión y cada artefacto fluyen a través de una capa inteligente.

La IA deja así de ser herramienta para pasar a ser el sistema operativo.

Y cuando lo piensas así, aparecen cuatro capas a diseñar en tu nueva arquitectura.

Capa 1: contexto

Las empresas pre-IA funcionan como ciclos abiertos. Decides, ejecutas, y el resultado se queda atrapado en cabezas, hilos de Slack, un comentario en GitHub o reuniones que nadie vuelve a leer.

Una empresa AI native es queryable: cada acción importante produce un artefacto que el sistema central puede leer y del que puede aprender.

En concreto: reuniones grabadas y resumidas, conversaciones unificadas, dashboards que cruzan revenue, sales, engineering, hiring y ops, y agentes con tanto contexto como darías a un empleado.

En Orbitant unificamos contexto vía documentación, APIs, MCPs y agentes. Los reports de compañía se generan mediante agentes y correlacionamos datos que antes vivían separados (CRM con ERP, por ejemplo).

Y, como somos remote first, los resúmenes cualitativos del estado de los proyectos nos llegan sin reuniones de seguimiento, leyendo las reuniones y los pipelines de desarrollo y producto.

Capa 2: procesos

Donde antes había ciclos abiertos, ahora hay ciclos cerrados que se autocorrigen. Además, cada proceso captura información, la realimenta y la mejora.

La forma más concreta de verlo es el siguiente paso del test-driven development. El humano escribe la spec y los tests que definen qué es tener éxito. Los agentes generan la implementación y la iteran hasta que los tests pasan.

Ya hay repos en producción que no contienen una sola línea de código escrito a mano, solo specs y test harnesses. El humano define qué construir y juzga el resultado, pero el cómo es trabajo del agente.

Nuestro equipo está internamente construyendo el know-how de la compañía paquetizado en plugins de Claude, que permite que tanto personas como agentes los activen - abstrayendo su implementación:

Capa 3: organización

El middleware humano deja de tener sentido en este nuevo universo (al menos cambia radicalmente). Si tu empresa es queryable, rica en artefactos y legible por AI, no necesitas capas de personas reenviando información.

Cada capa que eliminas es velocidad pura al liberar el contexto (y además acabas con gran parte del juego político, lo cual en empresas de gran tamaño supone un conflicto de interés importante).

Lo que queda (que parece que tenga algo de sentido) son tres arquetipos.

• IC / builder-operator: hace y opera, no solo perfiles ingenieros. Todos construyen y llegan a las reuniones con prototipos y producción final, no con slides.
• DRI, directly responsible individual: un nombre, un outcome. Estrategia y resultado de cliente, sin sitio donde esconderse. No es el manager clásico (para mí sería la evolución del Team Lead), sino que sería alguien con accountability directa sobre el resultado de negocio. Es el owner último del proyecto, con mucho foco no tanto en “terminar el proyecto a tiempo”, sino en generar impacto en negocio.
• AI founder: sigue construyendo, sigue siendo el primer power user. La convicción sobre estas herramientas no se delega.

Y en mi mente también aparece un departamento nuevo: AR (Agentic Resources). HR para empleados digitales: onboarding, asignación, feedback, evaluación, fine-tuning.

Cuando un agente lleva tareas reales y mide su impacto, la pregunta deja de ser técnica y pasa a ser organizativa.

Capa 4: producto y negocio

El modelo de time & materials no está muerto, pero se queda corto. Cuando un equipo entrega en una semana lo que antes tardaba seis, cobrar por horas penaliza al que va más rápido.

No tengo la respuesta cerrada al pricing, y sigo en muchas conversaciones, pero el principio sigue siendo el mismo: si aportas valor, acabas pudiendo capturarlo de vuelta en algún momento.

El siguiente paso del software para mí es lo que llamo Business Driven Development. Entender métricas, contexto y objetivos de negocio, decidir qué construir, y cada vez menos preocuparse por el cómo. Eso obliga al ingeniero a pegarse a producto, a cliente y a negocio.

No es un ejecutor más rápido, sino alguien que captura contexto, lo modela y orquesta.

Esto siempre ha ido de resolver problemas valiosos de negocio (la tecnología nunca ha sido la protagonista). Y esto suele costar interiorizarlo en el mundo del desarrollo. Pero ahora es más importante que nunca hacerlo si nos queremos adaptar.

Para gestionar todos estos cambios y darles coherencia, hemos creado internamente un equipo de Developer Experience (DevExp) precisamente para cuidar de que el proceso SDLC con IA sea homogéneo, eficaz y eficiente.

En este ejemplo que muestro, un agente valora la calidad de los tickets antes de pasarlos al pipeline de ejecución (los tickets son uno de los primeros cuellos de botella en cuanto a calidad trabajando con Spec Driven Development).

Formación como estrategia ofensiva

Si tu producto es tu propio equipo (como es nuestro caso), ¿cómo no vas a invertir en él en un momento como este?.

Este año hemos decidido aplicar una política de EBITDA cero: el margen lo queremos reinvertir en formación, herramientas y experimentación.

Un ingeniero de una empresa americana nos formó para ser power users de Claude Code. A partir de ahí desarrollamos nuestra metodología propia, la documentamos y formamos a toda la plantilla.

Un CPO experto nos está dando doce semanas de formación en metodología de producto. Como he dicho antes, creo firmemente que el futuro de los ingenieros pasan por acercarse aún más al producto, al problema a resolver y al negocio.

Además, hemos creado un espacio semanal llamado Asteroids en el que alguien de nuestro equipo cuenta en 5 minutos algún descubrimiento o aprendizaje relacionado con la IA. Trimestralmente hacemos lo mismo durante 3 horas, pero compartiendo aprendizajes más macro a niveles de proyectos en lo que llamamos "Super Standups".

Hemos habilitado también al equipo no técnico (porque la transformación es cultural, no solo de stack). Para ello creamos una formación en Claude Cowork de 2 horas que puedes reutilizar para tu equipo.

La ventaja de empezar joven

La realidad es que las empresas grandes se podrían quedar atrás en esta carrera.

Tienen legacy, org charts cementados, miles de personas a reentrenar, vendors que financian la inercia, comités que aprueban la prudencia.

La empresa joven y ágil pierde en escala, pero gana en algo más valioso ahora mismo: capacidad de adaptación.

Para ejecutar esta transición se necesita un equipo senior consolidado dispuesto al cambio, ausencia de sistemas viejos que defender, cultura de tirar trabajo a la basura cuando aparece una forma mejor y una convicción que no se delega.

Esta convicción solo se construye sentándote con un coding agent. No se delega al CTO, no se delega al consultor y no se compra en un informe.

Nosotros somos pequeños e inmaduros como empresa. Tenemos un equipo senior consolidado, proclive al cambio. Formamos parte de Afianza, un grupo más grande que nos da músculo financiero y un laboratorio de investigación.

Esa combinación, rara como es, creo que nos da unos buenos mimbres sobre los que poder construir un proyecto AI native ambicioso.

No esperes

Las cosas como son: los agentes hoy fallan. Pierden contexto, repiten errores, alucinan y ejecutan cosas que no les pediste. Cualquiera que te diga que tiene una plantilla mágica con la que sus agentes operan la empresa solos está vendiendo humo o tiene un caso de uso muy específico. La tecnología hoy es buena para algunos workflows y mediocre para otros.

Pero eso no es excusa para no ponerte en marcha. Es más bien la razón para construir desde ya, porque la curva no se aplana sola. Las empresas que estén dentro cuando empiece a funcionar bien van a llevar años de ventaja en datos acumulados, en metodología y en cultura.

Las que esperen a "que esté maduro" van a llegar tarde, como llegaron tarde al cloud las que esperaron a que estuviera maduro en 2012.

El moat no está en el modelo (el modelo lo tiene cualquiera con una API key). El moat está en haber pasado meses iterando con tu equipo, en haber acumulado contexto que ninguna empresa más antigua tiene, y en haber construido la cultura que permite seguir adaptándote.

Empieza desde arriba

No puedes fijar una visión que no entiendes. La razón es más bien operativa, no filosófica: estas herramientas cambian de capacidades cada tres meses. Una visión basada en lo que oíste en un keynote del trimestre pasado ya está obsoleta cuando la presentas.

Yo diseño mis propios agentes y mi propio sistema con Obsidian, que me ayudan cada semana a hacer más con menos. Y ha sido precisamente el ejercicio de explorar y crear esto durante meses (aparte de pasarme muchas horas leyendo y escribiendo) lo que me ha ayudado a modelar mi visión sobre todo lo que he compartido en este artículo.

Nos queda todo por construir, pero estamos en camino. Ojalá más empresas y profesionales se sumen a este reto, eligiendo hacer lo correcto por encima de lo fácil.

---

¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇

Felipe Polo
Emprendedor y fundador de Orbitant.
Comparte aprendizajes sobre escalado de consultoras, liderazgo, IA aplicada e ingeniería de software.

"Si quieres continuar nuestro viaje construyendo una empresa AI native puedes seguirme en Twitter."