Las siete leyes no escritas que la IA cobra más caro

Llevo unas semanas con una sensación rara en el cuerpo, y creo que no soy el único.

Esta semana, revisando lo que estaba haciendo un compañero de equipo, vi que había subido nueve pull requests en un día. Nueve. Cada una asociada a una versión de despliegue, porque tenemos despliegue continuo. Y no era una mañana caótica de hotfixes. Era trabajo normal, bien hecho, asistido por IA.

Eso es lo que la mayoría celebramos: velocidad. Pero hay otra cara. Las reglas no escritas de la ingeniería del software, esas que aprendes a base de romperlas y prometer que no volverá a pasar, ahora se cobran antes y más caro. La superficie de error es mayor. Y la mayoría no hemos actualizado nuestros hábitos al ritmo al que estamos generando código.

Hace unos días Anton Zaides publicó en manager.dev un artículo con siete leyes no escritas que todo ingeniero ha roto al menos una vez. En el vídeo de esta semana comenté tres en detalle. Aquí te traigo las siete, con mi perspectiva sobre cada una y por qué creo que la IA cambia el cálculo de todas ellas.

1. Si pasa algo en producción, casi siempre está relacionado con tu cambio. Primero rollback, después debug

Esta es la que más me ha costado interiorizar a lo largo de los años. Despliegas algo, salta una alerta diez minutos después, y tu cabeza inmediatamente construye el argumento de por qué tu cambio "no puede ser". Es de otra área. Tocaba otra parte del sistema. No tiene nada que ver.

Casi siempre tiene que ver. Y aunque no sea la causa raíz, el coste de revertir y estabilizar es muchísimo menor que el coste de tener al equipo investigando con producción en llamas durante una hora.

Yo lo aprendí porque me lo aprendí mal. Defender mi cambio se convirtió en un reflejo. Y en el camino, varios incidentes se alargaron más de lo necesario.

Con IA esto es aún más relevante. Estás subiendo más cambios, más rápido, y muchos de ellos los has revisado en modo "approving by default" porque la PR pintaba bien. La probabilidad de que un incidente esté relacionado con uno de los últimos diez deploys es alta, casi por construcción.

La regla es sencilla: ante un incidente, lo primero no es debuggear. Es preguntarse "¿qué se ha desplegado en la última hora?" y revertir. Estabilizar. Y desde ahí, ya investigas con calma.

2. Tus backups no existen hasta que has restaurado desde ellos

Esta es la que más fallos en frío genera, y la que más vergüenza da admitir. Tener backups configurados no es lo mismo que tener backups que funcionen.

Te hago las preguntas honestas:

• ¿Has restaurado alguna vez desde tu backup actual, no desde uno de hace dos años?
• ¿Sabes cuántos minutos de datos puedes perder en el peor caso?
• ¿Sabes quién tiene permisos para hacerlo, y si esa persona estará disponible un domingo a las tres de la mañana?
• ¿Sabes cuánto tarda la restauración hoy, con el volumen de datos que tienes hoy, no con el de cuando se diseñó el plan?

Si dudas en alguna, tienes deberes esta semana.

No voy a fingir que en Mercadona Tech esto está perfecto en todos los sistemas. Lo que sí tenemos claro es que la confianza en un backup es directamente proporcional a la última vez que lo restauraste. Y eso es algo que probablemente está infrarrepresentado en tu calendario.

¿Cómo afecta la IA aquí? De forma indirecta pero importante: estamos generando más sistemas, más rápido, más rincones de la arquitectura con datos críticos. Y la persona que generó la migración con Claude Code probablemente no se paró a pensar en el plan de restauración. Yo el primero, a veces.

3. Siempre vas a odiarte por cómo escribiste los logs

Esta me ha pasado tantas veces que ya casi me río. Empiezas un proyecto con la mejor intención: logs estructurados, request IDs, niveles bien definidos. Pasan seis meses, salta una alerta, y descubres que justo el campo que necesitas para entender qué pasó no se está logueando, o se está logueando como string mal formateado, o el dashboard de búsqueda no encuentra nada porque el JSON viene roto.

Y la IA aquí ha traído un problema nuevo. Antes el problema era que faltaban logs. Ahora el problema, con bastante frecuencia, es que sobran. Cursor y Claude Code generan logs verbosísimos, con detalles que nadie va a leer, hasta que un día tienes que buscar algo concreto entre cien líneas por petición. Y cuesta más encontrar la señal que cuando había la mitad.

El equilibrio no es fácil:

• Toda la información necesaria para reconstruir el flujo
• Con un identificador compartido entre servicios para una misma petición
• Sin enterrar lo importante bajo capas de info que solo sirvió mientras el agente estaba "iterando"

Mi sugerencia: cuando un agente te genere código nuevo, los logs son lo primero que reviso después de la lógica. No por estética. Porque si ese código falla en producción dentro de seis meses, lo único que vas a tener para entenderlo es lo que hayan dejado escrito hoy.

4. Siempre, siempre, ten un plan de rollback

De esta hablé en el vídeo. La idea es sencilla: cualquier cambio que toque datos, configuración o sistemas externos necesita un plan claro para volver atrás. No tiene que ser automático. Tiene que ser conocido y, lo más importante, probado.

Quiero añadir aquí un caso real que se me quedó corto en el vídeo. Hace un tiempo hicimos un cambio de esquema en una tabla muy usada. La migración subió bien. La validación pasó. Y dos horas después, un job nocturno empezó a fallar porque dependía del orden de las columnas (algo que no debería pasar, pero pasaba). El plan de rollback existía. La cosa fue que la migración inversa nadie la había ejecutado nunca contra una réplica con datos reales. Y la primera vez que la corrimos, en producción, con los nervios de un incidente, descubrimos que tardaba el doble de lo que pensábamos por un índice que no se había considerado.

Salió bien. Pero salió bien por suerte y porque el equipo tenía tablas. No porque el plan fuese sólido.

Con IA y la velocidad de generación actual, las migraciones se escriben y se aprueban en minutos. La tentación de no probar el rollback es enorme, porque "es pequeño, es sencillo, qué puede salir mal". Lo que puede salir mal es justo lo que no has ensayado.

Regla que intento aplicar: si la migración la generó un agente, el rollback también, y los dos se ejecutan al menos una vez contra una réplica antes de tocar producción. Sin excepciones que valgan.

5. Toda dependencia externa va a fallar

Es la que más subestimamos cuando integramos algo nuevo. Hoy es trivial añadir una API externa: te das de alta, copias la API key, dos horas y funcionando. Pero la pregunta que casi nadie hace en esa primera reunión es: "¿qué pasa con nuestro sistema cuando esto se caiga?".

Y se va a caer. No es pesimismo, es estadística. Un proveedor con un SLA del 99.9% suena fantástico hasta que sumas cinco proveedores con el mismo SLA y descubres que tu disponibilidad efectiva es bastante peor.

Las preguntas que debería hacer cualquier diseño antes de integrar una dependencia crítica:

• ¿Qué se rompe del producto cuando esto no responde? ¿Una funcionalidad o todo?
• ¿Hemos probado en preproducción el escenario de "API caída" o solo el escenario de "API lenta"?
• ¿Tenemos cache, cola, o algún tipo de degradación elegante?
• ¿Sabemos qué le contamos al usuario cuando pasa?

La IA no cambia esta ley. La cambia indirectamente, porque ahora añadir dependencias externas es todavía más fácil. Un agente puede integrar un nuevo SDK en una tarde. Y la presión hacia "más servicios, más conectados, más rápido" hace que estas preguntas se hagan menos, no más.

6. Si hay cualquier riesgo, regla de los cuatro ojos

También en el vídeo. Cuando vas a tocar algo no reversible (configuración de producción, comandos de base de datos, despliegue de infraestructura), siempre dos pares de ojos. Y ojo, esto vale incluso, o sobre todo, si llevas quince años en la industria.

Lo conté en el vídeo, pero lo repito aquí porque me parece importante. Hace unos meses subí una PR generada con asistencia de IA, la revisé yo, y se me coló un test que no tenía nada que ver con el cambio. No era dañino. Simplemente no debería haber estado ahí. Lo cazó la TL del equipo en review. Yo, que me considero cuidadoso revisando, lo dejé pasar.

¿Por qué? Porque mi mente, al revisar, estaba operando con el sesgo de "esto lo he escrito yo". Y técnicamente sí, lo había escrito yo, en el sentido de que había aceptado las sugerencias. Pero no las había escrito en el sentido de "tener en la cabeza cada línea". Y ese matiz hace que tu revisión sea más superficial, aunque no te des cuenta.

La conclusión a la que voy llegando: cuando el código lo genera un agente, tú no eres "la primera revisión". Eres "el primer filtro". La primera revisión sigue tocando, y debería ser otra persona. La regla de cuatro ojos en realidad ahora son seis: el agente, tú, y un humano más.

7. No hay nada más permanente que un fix temporal

La favorita de todos, porque todos la hemos roto. Esa frase de "luego lo arreglamos" es estadísticamente equivalente a "nunca lo voy a arreglar". Y todos lo sabemos cuando la decimos.

Aquí, sin embargo, creo que la IA cambia algo de fondo, y por primera vez en la dirección buena.

Antes, hacer un fix bien desde el primer momento costaba tiempo. Tiempo que muchas veces no tenías, o que el negocio no quería darte. Y el "fix temporal" era un equilibrio razonable entre velocidad y deuda asumida.

Ahora, ese cálculo está cambiando. El coste de hacerlo bien desde la primera vez se ha reducido. El coste de volver y arreglarlo después, también. Y, lo más interesante, ese "volver" se puede empezar a delegar.

Te cuento algo que estoy probando en mi día a día. Estoy experimentando con runners de integración continua que disparan agentes para arreglar cosas pendientes. Defines la tarea, le das contexto, y por la noche, mientras duermes, el agente abre una PR con el arreglo. Por la mañana revisas, comentas si hace falta, y mergeas o iteras. No es magia. Falla bastante. Pero está empezando a funcionar para cierto tipo de tareas.

Lo importante de esto no es la herramienta concreta. Es que el coste marginal de "volver a arreglarlo" ha bajado tanto que la excusa clásica del "no tengo tiempo" empieza a ser menos defendible. Y eso es una buena noticia para los proyectos.

Dicho esto, sigue habiendo fixes temporales que merecen quedarse temporales. La diferencia entre "esto es simple y limitado" y "esto está sujeto con cinta americana" sigue importando. Lo que cambia es que la cinta americana ahora es más fácil de quitar.

El tema que se repite

Si te fijas, las siete leyes apuntan al mismo sitio: la disciplina de la verificación. Comprobar que el cambio es seguro antes de hacerlo (4, 6), comprobar que se puede deshacer (1, 4), comprobar que tienes la información para investigar después (3), comprobar que tu plan B funciona (2), comprobar que tu sistema sobrevive cuando el de otro se cae (5), y comprobar que lo temporal acaba siendo realmente temporal (7).

Llevo meses dándole vueltas a esto desde otro ángulo, en lo que vengo llamando operar a ciegas. La idea es que cuanto menos código escribimos a mano, más importante se vuelve la capa de verificación. Porque la generación es barata y rápida. La verificación no.

Estas siete leyes son, en el fondo, formas concretas de esa idea más general. Y lo que noto en los equipos con los que hablo es que la mayoría siguen midiendo productividad por velocidad de generación. Cuando, en realidad, la productividad real está cada vez más en la calidad y velocidad de la verificación.

¿Te suena? Me imagino que sí.

Y para terminar con la honestidad que toca: no sé exactamente cómo va a evolucionar esto los próximos doce meses. Lo que sí tengo claro es que los equipos que se tomen en serio estas siete leyes, y las adapten al ritmo de la IA en vez de ignorarlas porque "ahora vamos más rápido", van a tener muchísimos menos incidentes que el resto. Y muchísimas menos noches de domingo investigando qué falló.

Pregunta para ti

¿Cuál de las siete es la que más rompes tú? La mía honestamente es la del rollback probado. Lo digo sin orgullo. Cuéntame la tuya respondiendo a este email.

PD: El vídeo de esta semana cubre tres de estas leyes en formato corto (rollback, cuatro ojos, fix temporal). Esta newsletter completa el cuadro con las cuatro restantes y los matices que en vídeo no daban.