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

Contenido del curso

Expert

Builders

Entrevistas

Ignites

Demoday

Cursos Empresas Blog Live Conf Eventos Precios

0:004:57

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

Platzi Conf 2026 Bogotá

Clase 29 de 32

Clase 29 / 32

Recursos

Refactorizar 250.000 líneas de código en Platzi sin un solo incidente es posible cuando aplicas spec-driven development, una forma de programar con inteligencia artificial donde tú decides el plan y la IA lo ejecuta con contexto claro. Si trabajas con bases de datos, microservicios o refactors grandes, esto te interesa.

Por qué borrar código es más peligroso que escribirlo

Imagina quitarle 250.000 ladrillos a una estructura. Suena aterrador, ¿no? Pues eso fue exactamente lo que pasó en uno de los proyectos más importantes de Platzi: cero incidentes, cero rollbacks y cero estudiantes quejándose en redes sociales.

Y aquí viene lo interesante: esas 250.000 líneas no fueron lo más difícil. El verdadero reto llegó unas semanas antes, al meterle mano a una sola tabla de la base de datos.

¿Una tabla? Sí. Pero en esa tabla vivía la lógica de muchísimos microservicios, con muchos casos de uso y un montón de cosas que considerar. Para colmo, era contexto repartido: la información estaba dispersa y las personas que crearon esa lógica ya no estaban en el equipo.

¿Por qué es más riesgoso borrar código que escribirlo? Porque cuando escribes y algo falla, lo arreglas al instante. Cuando borras, el problema aparece semanas después, cuando los usuarios ya se están quejando.

Cómo usar la inteligencia artificial sin que invente cosas

La primera idea fue ir directo a la nube y empezar a ejecutar. Pero quienes usamos IA sabemos algo clave: usarla sin darle un contexto claro hace que invente cosas.

En lugar de eso, la IA se usó como herramienta de análisis, no de improvisación. La instrucción fue concreta:

Analizar todos los microservicios que utilizan la tabla.
Generar una documentación completa del código actual.
Explicar qué casos de uso se están utilizando.

Una vez inventariado todo esto, llegó la pregunta que ordena cualquier refactor: ¿qué tiene que seguir siendo verdad cuando el refactor termine? Esa comparación entre lo que hay hoy y lo que necesitas es el corazón del proceso.

Qué es el spec-driven development

Aquí aparece el concepto central. El spec-driven development [02:20] consiste en programar con inteligencia artificial indicándole con precisión qué necesitas, en lugar de dejar que la IA entre a tus sistemas y haga lo que ella quiera.

¿Qué es el spec-driven development? Es una forma de trabajar con IA donde tú defines la especificación de lo que necesitas antes de ejecutar. La IA programa siguiendo tu plan, no su propia interpretación.

El orden importa: primero especificas, luego ejecutas. La IA te ayuda muchísimo, pero tú eres quien decide el plan y tú eres quien lo hace.

Por qué documentar mientras refactorizas te salva en producción

Al ejecutar el refactor apareció lo inevitable: casos de uso que no estaban contemplados. La respuesta fue ir documentando mientras el refactor avanzaba, no después.

Y esa decisión resultó clave. Para subir un cambio tan grande, primero se analizó el momento de menor tráfico de la plataforma [03:35]. Aun así, al desplegar se cayeron muchos flujos.

¿La solución? Esa documentación construida en el camino permitió darle a los agentes de inteligencia artificial un contexto exacto, y con ese contexto la IA devolvió un arreglo exacto.

¿Por qué documentar durante un refactor grande? Porque en refactors con mucha incertidumbre, esa documentación se convierte en el contexto preciso que necesitas para que la IA te dé soluciones correctas cuando algo falla en producción.

Cuándo usar specs y cuándo experimentar libremente

No todos los cambios necesitan el mismo nivel de rigor. La regla es sencilla y la puedes aplicar hoy mismo:

Usa specs cuando vayas a considerar muchos casos de uso.
Usa specs cuando toques la lógica de negocio, que siempre es delicada.
Experimenta con bycode cuando estés probando algo sin consecuencias críticas.

El riesgo de ejecutar un feature no está en la cantidad de cosas que mandes a hacer. Está en si no sabes darle el contexto a la IA. Puedes ejecutar muchísimo, siempre que el contexto sea claro.

Este principio va más allá de la programación. En la vida también conviene analizar todas las variables antes de ejecutar. Los programadores sabemos que deberíamos documentar, y aquí queda demostrado por qué vale la pena hacerlo desde el inicio.

¿Ya aplicas specs en tus refactors o todavía dejas que la IA decida por ti? Cuéntalo en los comentarios.

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

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