Por qué AI te exige pensar más tu ingeniería - Javier Guignard

Contenido del curso

Expert

Builders

Entrevistas

Ignites

Demoday

Cursos Empresas Blog Live Conf Eventos Precios

0:0019:23

Por qué AI te exige pensar más tu ingeniería - Javier Guignard

Platzi Conf 2026 Bogotá

Clase 19 de 32

Clase 19 / 32

Recursos

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.

DOUGLAS VLADIMIR ARÉVALO

Hace 19 días

Lo que yo puedo entender es la IA no te perdona una mala instrucción. Un programa viejo sí.

lo explico:

Antes, sin IA: Tú como developer le decías a la máquina: si pasa 404, muestra "no existe". Era una orden directa. Si tú pensabas poco, el código igual funcionaba, solo daba un resultado malo.

Ahora, con IA: Tú le dices: "haz algo cuando no encuentres la página". La IA tiene 61 códigos posibles para elegir, y 1000 formas de mostrarlo. Si tú no piensas bien QUÉ quieres, ella inventa algo.

Por eso la IA te exige más ingeniería:

1. Ya no piensas en CÓMO hacerlo, sino en QUÉ quieres realmente. Antes pensabas: ¿qué código escribo? ¿qué resultado exacto quiero, para quién, en qué tono, con qué límites? Eso es ingeniería de pensamiento.

2. La IA es ambigua, tú debes ser específico. Si le dices "hazlo bonito", te da cualquier cosa. Si le dices "fondo oscuro #0A3D4D, 3 errores 404, 418, 402 con su descripción, estilo Platzi Conf", te da exactamente la imagen que me mandaste. La claridad es tuya, no de ella.

3. El error ya no está en la máquina, está en tu prompt.

Con código tradicional, si fallaba era bug del código. Con IA, si falla el 90% de las veces es porque tu instrucción fue pobre. Te obliga a pensar mejor para no echarle la culpa a la IA.

En resumen: La programación vieja te exigía pensar como máquina. La IA te exige pensar como humano muy claro, para que la máquina te entienda.

Es lo que llamamos Prompt Engineering: no es escribir bonito, es pensar con precisión.

Expert

Manifiesto

Estado de Platzi: Nuevos Lanzamientos - Team Platzi

Lo que AI nunca podrá remplazar - Luis Ronca

El lado oscuro de la inteligencia artificial - Pirry

Construye una startup que no se quiebre con el éxito - Myriam Cosío

How GPUs are Accelerating Science - Katrina Riehl

¿Y si todo sale bien con AI? - Freddy Vega

Desarollando gusto para el futuro del diseño - Catalina Lotero

Tu futuro no se puede automatizar - Rodrigo Rojo

Cómo educamos en tecnología a un millón de Salvadoreños - Secretario de Innovacion de El Salvador

El miedo te robará tus mejores oportunidades - Carolina García G.

Construye con AWS sin preocuparte de la factura - Nelly Andrade

Introducción a Ciencia de datos en GPUs - Naty Clementi

¿El futuro es de los generalistas o especialistas? - Daniel Rodriguez

Builders

Ser estudiante en Platzi: 11 años después - Erasmo Hernández

Cómo Platzi escaló la educación con Al - Estefany Salas

¿Qué significa ser developer hoy en día? - Ana Cunha AWS

Send money as easy as an email - Ioana Chiorean

Por qué AI te exige pensar más tu ingeniería - Javier Guignard

Deja de crear contenido basura (AI-Slop) - Mael Vallejo

Cómo saber si AI te está mintiendo - Raúl Aguilar

Cómo crear un "chatbot" que tu cliente no odie - Edu Piña

Entrevistas

Cómo Rappi y Simetrik escalan el aprendizaje interno

Antártida y espacio: los bienes comunes de la humanidad

Ignites

Lo que me pasó despues de cerrar redes sociales - Roberto Zuñiga

Software autorregenerativo: la lección de la salamandra

La curiosidad me dio un mejor empleo - Jose Peinado

La psicología detrás de tus decisiones - Jaime Tello

El código que el vibe coding no puede arreglar - Willmer Garzon

¿Realmente necesitas AI para todo? - Mariangélica Useche

Demoday

Qué preguntan los jueces en un Demo Day de startups

Cómo Tinkadia ganó con inclusión e IA

Por qué AI te exige pensar más tu ingeniería - Javier Guignard