A finales de julio decidí rehacer este blog de arriba abajo y hacerlo con una IA. No una ayuda puntual para un fragmento de código: el rediseño entero, la traducción al inglés, el SEO, la migración a producción y el mantenimiento del servidor.
Salieron 72 commits en cuatro días, 250 ficheros y más de 18.000 líneas. El resultado es medible y es mejor que lo que había. Y por el camino se rompieron cuatro cosas, una de ellas en producción y en vivo.
Este artículo cuenta las dos mitades. La primera se cuenta mucho; la segunda casi nunca, y es la que sirve para algo.
Lo que salió bien
Empiezo por aquí porque sin esto lo demás suena a queja, y no lo es. El sitio quedó objetivamente mejor, y esto no es una impresión: son cifras que se pueden comprobar entrando.
El último punto conviene matizarlo, porque es más interesante de lo que parece. Copias tenía: el contenedor entero se respalda con Proxmox Backup Server, que es lo que hace mucha gente y está bien. Lo que no tenía era un volcado lógico de la base de datos, de esos de los que puedes sacar una sola tabla. Parece un matiz menor. Más adelante se ve que no lo es.
Lo primero que se rompió: un patrón demasiado goloso
Renombrar 125 ficheros de imagen a nombres descriptivos parecía la tarea más aburrida de todas. La complicación está en que WordPress no guarda una imagen, guarda un juego: el original y los tamaños que genera a partir de él.
Para renombrar el juego entero, el guion pedía «todos los ficheros que empiecen por el nombre viejo». Con una captura mía llamada login.png, eso encuentra correctamente login-1024x576.png y login-300x169.png. El problema es que en esa misma carpeta había otras tres capturas, sin ninguna relación con la primera: login1.png, login-npm.png y loginadmin.png. Todas empiezan por «login». Se las llevó por delante.
Y había un segundo efecto, más retorcido: cuando el nombre nuevo empezaba por el viejo, el patrón recogía el fichero que se acababa de crear y volvía a renombrarlo. Así apareció un ollama-listar-modelosar-modelos.png. El fallo no fue elegir mal el nombre, fue usar «empieza por» sin exigir que a continuación viniera un separador.
Daño total: 24 imágenes originales con el nombre destrozado y 68 derivados. Y el guion terminó diciendo que había renombrado 97 ficheros correctamente. Ninguna excepción, ningún aviso, ningún error. Se descubrió al comprobar después, una por una, que las 141 URL de imagen respondían.
Lo segundo: borrar filas de un esquema que no era el que yo creía
Limpieza de base de datos. Había filas huérfanas en la tabla de relaciones de términos, esas que enlazan una entrada con sus categorías. El código comparaba cada fila contra la tabla de entradas y borraba las que no encontraban su entrada. 83 filas.
El problema es que en esa tabla la columna que yo daba por hecho que era el identificador de una entrada no siempre lo es. Polylang, el plugin que gestiona los dos idiomas, la usa para guardar el idioma y las traducciones de cada término.
Resultado: seis de mis diez categorías perdieron su idioma. Las cinco inglesas empezaron a devolver 404. En producción, con el sitio ya publicado.
Apareció al verificar otro cambio: comprobando el título de un archivo de categoría salió «Page not found» donde tenía que salir el nombre. Y aunque no hubiera aparecido ahí, habría salido igual veintidós minutos después: la revisión completa de las 54 URL del sitio, que incluye las diez de categoría, ya estaba planificada y se ejecutó a las 17:59. Se arregló restaurando esa tabla concreta desde la copia de las 17:24.
Lo tercero: tres minutos en blanco, con el código de estado diciendo que todo iba bien
El cambio a producción fue a las 16:50. Copié el tema hijo, la base de datos, los medios, todo. Olvidé el tema padre.
Un tema hijo de WordPress no puede renderizar nada sin su padre. Lo interesante es cómo falla: no lo registra como error fatal.
Código 200. Cero bytes de cuerpo. Las cabeceras correctas, la cookie de idioma puesta, y ni una línea en el log de PHP ni en el de nginx. La página estaba en blanco y todo lo que se podía consultar decía que estaba bien.
Lo cazó la comprobación posterior al cambio, que mide el contenido de cada página y no solo su código de estado. Por eso apareció: si esa comprobación se hubiera limitado a preguntar «¿responde 200?», como hacen casi todos los monitores, habría dado el visto bueno. Diecisiete minutos entre el cambio y el arreglo.
Lo cuarto: actuar antes de leer la comprobación
Este es distinto, y por eso lo dejo el último. Iba a eliminar unas tablas huérfanas de plugins ya desinstalados. Antes había que comprobar si algún plugin instalado las usaba. Escribí la comprobación y el borrado en la misma orden.
La comprobación dijo que sí, que Rank Math usa una de ellas. Pero el borrado ya se había ejecutado en la misma línea, así que leí el aviso después del daño. Se restauró de un volcado hecho un paso antes.
No fue un fallo de conocimiento. Fue de proceso. Verificar y actuar tienen que estar separados, o la verificación es decorativa.
Ninguna de las cuatro se detectó por casualidad
Esto es lo que más me interesa dejar claro, porque es lo contrario de lo que suele contarse. Ninguno de los cuatro salió a la luz por un golpe de vista afortunado ni porque alguien pasara por allí. Los cuatro los encontró una comprobación que existía precisamente para eso, y ninguno llegó a un lector.
La disciplina no se improvisó sobre la marcha: era parte del encargo. Estas cinco cosas, bastante aburridas todas, estaban puestas desde el principio.
- Respaldo antes de cada paso destructivo. No una copia general y ya: un volcado concreto justo antes de tocar, incluso para operaciones que parecían triviales.
- Copias automáticas que se prueban restaurando. La de las 17:24 salvó las categorías. Si se hubiera limitado a escribirse en disco sin comprobar nunca que se podía restaurar, no habría servido de nada.
- Ensayo en seco. Casi todos los guiones destructivos se ejecutaron primero en modo simulación, mostrando qué iban a hacer sin hacerlo. Ahí se cazaron varios errores que no llegaron a esta lista.
- Verificar midiendo, no mirando. Después de cada cambio, comprobar las URL una por una en lugar de dar por bueno el «Success» del guion. Los cuatro fallos se cazaron aquí: en tres de ellos el guion había terminado diciendo que todo había ido bien.
- Permiso mínimo. Nada de esto tocó producción hasta el final, y el entorno de pruebas nunca tuvo acceso al correo ni a la analítica del sitio real.
Y ahora lo que de verdad aprendí
Los cuatro fallos de arriba los encontró la propia máquina, comprobando su trabajo. Pero hubo otros dos que no encontró, y esos son los interesantes.
El primero fue el logo de la cabecera. Se pintaba a tamaño natural: una cabecera de 473 píxeles de alto, imposible de no ver al entrar en la portada. Había un arnés recorriendo 54 URL y midiendo estructura, enlaces, imágenes y datos estructurados, y daba cero problemas. Llevaba días así en el entorno de pruebas.
El segundo fue el contraste en modo oscuro. Los títulos de sección eran casi invisibles. Al medirlo aparecieron entre 19 y 23 fallos por página, uno de ellos con un contraste de 1,08 a 1 cuando el mínimo aceptable es 3. Se arregló, se volvió a medir, dio cero. Y seguía roto: si tienes el sistema en oscuro y pulsas el interruptor del sitio para verlo en claro, fallaba otra vez. La medición probaba dos estados cuando en realidad son cuatro.
La conclusión que saco no es que la verificación automática sea inútil. Encontró los cuatro fallos de la primera mitad de este artículo, y sin ella dos de ellos habrían llegado a producción sin que nadie se enterase.
La conclusión es más incómoda: la verificación automática no falló por ser mala. Falló porque midió lo que se le ocurrió medir. Comprobaba que las imágenes cargaban, y no que tuvieran un tamaño razonable. Comprobaba el contraste en dos temas, y no en las cuatro combinaciones posibles. Cada comprobación es una hipótesis sobre qué puede salir mal, y lo que no se te ocurre no se mide.
Un ojo humano mirando la pantalla encontró en dos segundos lo que ese arnés daba por bueno. No porque sea más listo, sino porque no parte de una lista.
¿Lo volvería a hacer?
Sí, y con las mismas precauciones, que resultaron ser exactamente las que hicieron falta.
Lo que cambiaría es la idea de que verificar automáticamente sustituye a mirar. No lo hace. Son dos cosas distintas: una escala y la otra descubre. La máquina puede comprobar 54 páginas en dos minutos y no se cansa; una persona mira una sola y ve lo que no estaba en la lista.
Si vas a trabajar así, mi recomendación cabe en una frase: haz un respaldo justo antes de cada paso destructivo, no solo uno general al empezar. El que salvó las categorías se hizo a propósito minutos antes de la limpieza que las rompió, no era el de la noche anterior. Esa diferencia es la que decide si pierdes una tabla o el día entero.
Seguir leyendo en IT Rafa
- Código generado por IA: el coste real en seguridad, con los datos de los estudios publicados.
- Tu asistente de IA personal: instalar OpenClaw en Linux
- Cómo autohospedar el modelo DeepSeek en tu propio servidor