Cuando pensamos en cómo la IA transforma la arquitectura de software, lo primero que imaginamos es agregar más código y más features. En Platzi hicimos lo contrario: una hackathon de tres días para romper, achicar y simplificar de forma agresiva la plataforma. Esta historia es para desarrolladores y líderes de ingeniería que quieren repensar sus sistemas en la era de los agentes.
En esa hackathon se movieron 250.000 líneas de código, se tocaron tres micro frontends y seis microservicios, con cero features nuevos. El objetivo no era crear, era reducir. Y terminó siendo una de las semanas más productivas del año, porque bajar costos en tokens y aumentar la productividad vino justamente de entender la plataforma y pensarla desde otro objetivo.
¿Por qué la arquitectura ahora es una decisión de user experience de los agentes?
Durante décadas escalamos nuestros sistemas rompiendo el monolito en microservicios y comunicaciones entre ellos. Pero no solo creció el sistema: también creció la infraestructura, la arquitectura y el organigrama de la empresa al mismo tiempo. Eso generó una arquitectura distribuida con equipos muy especializados.
Hace cinco años, el equipo de Payments en Platzi tenía su manager, su back-end, front-end, product manager y QA. Todo el conocimiento vivía ahí, en lo que se conoce como silos de conocimiento, no de personas sino de equipos. Eran seis o siete equipos de ocho a 10 personas cada uno.
Lo que cambió con la IA no es tanto quién escribe el código, sino quién lo lee. Casi todos los PR ya los escribe inteligencia artificial, pero seguimos leyéndolos nosotros y los agentes. Por eso empezamos a pensar la arquitectura como una experiencia de usuario para esos agentes.
¿Por qué reunir microservicios mejora el trabajo de los agentes de IA? Porque si un agente tiene que leer más repositorios para tener contexto, es más lento y gasta más dinero en tokens. Menos repos significa lectura más rápida y desarrollo más barato.
¿Cómo se simplificó la capa técnica de Platzi?
La arquitectura se separa en tres capas: la humana, la de coordinación y la técnica. La IA no va arriba de ellas, va metida en el medio.
En la capa técnica, unimos cinco piezas de pagos: el monolito histórico de Platzi más cuatro microservicios de cupones, recurrencia, el motor de pasarelas y el sistema de referidos. Todos tenían relación entre sí por tráfico de red y datos en bases de datos separadas.
Ahí estaba el problema. Para conocer el historial de un estudiante había que leer cinco bases de datos diferentes. Y todos crecían juntos: si entraba un pago, se generaba recurrencia, se revisaban referidos, se validaba el cupón y se transaccionaba con la pasarela. La promesa del microservicio es separar algo para que escale distinto, pero esto siempre escalaba junto.
La solución fue unificarlo:
- Volvimos esos servicios al monolito.
- Borramos gran cantidad de líneas de código.
- Apagamos infraestructura que ya no hacía falta.
- Dejamos todo el contexto de pago en un solo repositorio.
Así el agente lee fácil, nosotros leemos con menos dificultad y ahorramos en tiempo, velocidad de desarrollo y costo de tokens.
¿Cuándo sí conviene mantener un servicio distribuido?
No todo se colapsa al monolito. El sistema de B2B o enterprise estaba dentro del core de Platzi y lo terminamos de sacar esta semana. La razón es el convenio con El Salvador, con un millón de personas que reciben un WhatsApp o una push notification y entran todas al mismo tiempo.
Ahí, tener un sistema que escale solo da robustez y permite responder sin que el resto de la plataforma se caiga. La clave es separar por dominio real y por cómo escala, no solo porque exista un equipo llamado B2B.
También sacamos otras 250.000 líneas para separar backend de frontend, una práctica que arrastrábamos desde hace 10 o 15 años, y eliminamos los microfrontends. Un microfrontend es como un microservicio pero con código solo del frontend. Los movimos a un monorepo junto al sistema de diseño, un trabajo que empezó hace dos años cuando centralizamos el FL UI. Hoy ese monorepo permite lanzar landings como /inglés o /AI en muy poco tiempo, porque el agente tiene todo el contexto en un solo lugar.
¿Qué es un microfrontend? Es un fragmento de aplicación que contiene únicamente el código del frontend, lo que ve el usuario. Funciona como un microservicio, pero solo para la interfaz.
¿Cómo cambian las capas de coordinación y humana con la IA?
La capa de coordinación eran todos los managers y heads de ingeniería, producto, B2B y growth que coordinaban esos silos de conocimiento. Antes un equipo tenía ocho o 10 personas. Ahora cada feature la ataca entre uno y tres ingenieros que piensan en el end-to-end del producto y toman el ownership del problema.
Esa coordinación se volvió más corta y transparente. Pero ojo: si el organigrama sigue igual de grande, la arquitectura se vuelve a llenar. Hay estudios de la década del 90 que lo demuestran.
En la capa humana está el mayor cambio. Un engineering manager trabajaba cuatro patas: ingeniería, producto, negocio y las personas. Ahora todos los desarrolladores necesitan skills de manager:
- Saber de ingeniería para corregir las alucinaciones de la IA.
- Entender el producto para hacer el end-to-end de un feature.
- Entender el negocio para validar si sigue el norte de las métricas de la empresa.
- Orquestar agentes, no personas, dándoles libertad y restricciones.
¿Qué problemas humanos aparecen al programar con IA?
El equipo lo dijo con nombre y permiso. Jose Painado siente que están olvidando cómo programar. Edward ya no siente control cuando hay un incidente. Mus perdió ese contexto tan profundo. Ale Martínez usa el test basura solo para tener checks.
Estos problemas son reales: no es falta de contexto, es un contexto más grande pero menos profundo. Hay reviews rotos, tests ficticios que exigen un harness más potente para testear mejor, y un ritmo insostenible de escritura si no nos paramos a pensar. Probar sigue siendo el cuello de botella: la velocidad de escritura es increíble, pero seguir leyendo, testeando y revisando va a otro ritmo.
Antes de decidir tu arquitectura, hazte tres preguntas: ¿qué resuelve la ingeniería y qué es problema del organigrama? ¿Existen silos de conocimiento en equipos completos? ¿Tu rol especializado da valor por la complejidad real o por una visión más amplia que esa complejidad?
El siguiente skill del desarrollador es dirigir trabajo, el mismo que un manager: entender ingeniería, producto y negocio, y poner a trabajar a sus agentes. ¿Ya estás repensando tu arquitectura pensando en la experiencia de tus agentes? Cuéntame en los comentarios.
