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.
