Un sitio Drupal no se termina el día que se publica: empieza. Durante años habrá que aplicar actualizaciones de seguridad, adaptar el código propio a cada versión mayor, revisar rendimiento y permisos, y seguir desarrollando sobre una base que no deja de moverse. Ahí es donde una web se degrada en silencio, o donde sigue rindiendo años después.
Cuando decidimos integrar la inteligencia artificial en nuestro trabajo, la pregunta de partida fue qué parte de nuestro método ganaría en profundidad y cobertura si la ejecutara un sistema que no se cansa de comprobar. El resultado recorre el ciclo de vida completo: conocimiento de base, auditoría, desarrollo, dependencias y migración de versión.
La IA ejecuta, la metodología es nuestra
Abrir un chat con un modelo de lenguaje y pedirle código funciona para una demostración. Mantener durante años una plataforma de la que depende un negocio pide otra cosa: un modelo genérico desconoce las convenciones del proyecto, cita APIs que ya no existen y no responde ante nadie de sus decisiones.
Por eso cada proceso (auditar, desarrollar, actualizar, migrar) está escrito por nuestro equipo como una metodología explícita: qué pasos se dan, qué se comprueba antes de avanzar, qué se entrega y quién aprueba. Los agentes la ejecutan sin reinterpretarla ni saltársela, porque en cada punto crítico hay una comprobación automática o una persona que da el visto bueno. La metodología, el conocimiento y los criterios de calidad no viven en el motor de IA ni dependen de él: viven en nuestro sistema, versionados y bajo nuestro control.
Una base de conocimiento Drupal verificada, no recordada
El punto débil de cualquier IA aplicada a Drupal es el conocimiento de versión. Drupal publica dos versiones menores al año, depreca APIs en cada una y retira lo deprecado en la siguiente versión mayor. Un modelo entrenado con documentación de hace dos años mezcla Drupal 9, 10 y 11 sin saberlo.
Hemos construido una base de conocimiento propia por versión mayor, de Drupal 8 a 11 y con Drupal 12 en preparación: APIs PHP, hooks, plugins, Twig y theming, JavaScript, estándares de código, deprecaciones por versión menor, lo que retiró cada versión mayor al entrar y la cadena de herramientas que corresponde a cada salto. Cada dato está contrastado contra el código fuente de Drupal core, fechado y con su fuente. Cuando un agente necesita saber cómo se hace algo en Drupal 11.2, lo consulta en lugar de recordarlo, y una corrección en la base llega a todos los procesos a la vez.
Auditoría: 12 ejes y un diagnóstico que no corrige
Un Drupal en producción cambia cada mes, aunque lo hayamos construido nosotros. Antes de cualquier intervención, lo primero es saber en qué estado está. Nuestra auditoría lo analiza en 12 ejes: plataforma y ciclo de soporte, actualizaciones pendientes y vulnerabilidades conocidas, parches y su vigencia, módulos instalados y módulos que faltan, calidad del código propio, contenido y configuración, tema y frontend, rendimiento y caché, permisos y roles, salud operativa, recorrido funcional por tipo de contenido y por rol de usuario, y SEO técnico.
Cruza tres fuentes: el código del proyecto, el panel de administración de preproducción o producción, recorrido con un navegador real y sesión iniciada, y la línea de comandos de Drupal sobre una réplica local en contenedores. Cada hallazgo se clasifica por severidad y esfuerzo y llega en un doble backlog: uno para ti, en lenguaje de negocio, y otro interno con el detalle técnico.
La diferencia práctica respecto a una auditoría a mano está en la cobertura. Un equipo humano muestrea: los permisos más sensibles, los módulos más críticos. El sistema revisa cada permiso, cada ruta por rol y cada API deprecada, y una persona de nuestro equipo valida los hallazgos y decide qué importa.
Y una decisión de diseño importante: la auditoría solo diagnostica. Cada hallazgo se deriva al proceso especializado que debe resolverlo, lo que evita el error clásico de arreglar de paso algo que nadie ha validado.
Desarrollo: cinco fases y un revisor adversarial
Escribir código propio de Drupal es donde más aporta la IA y donde más daño hace sin método. Nuestro proceso de desarrollo asistido sigue cinco fases.
Las cinco fases del desarrollo asistido
Ninguna línea se escribe sin un plan aprobado por una persona ni se da por buena sin pasar las comprobaciones automáticas.
El agente trabaja siempre sobre una réplica local del proyecto, nunca sobre producción.
Antes de proponer nada, estudia el código existente, separa lo que ha verificado de lo que solo ha inferido y declara sus supuestos. En proyectos grandes construye un grafo del código propio, con sus componentes y dependencias, para no perderse.
Redacta un plan con criterios de aceptación verificables y decisiones de arquitectura registradas. Sin la aprobación literal de un desarrollador de nuestro equipo, no se ejecuta.
Primero se escribe la prueba que debe fallar; después el código, en bloques pequeños que pasan los estándares de código de Drupal, análisis estático y pruebas unitarias.
Se comprueba la definición de «hecho» con datos reales y en un navegador real, y un segundo agente actúa como revisor adversarial: su único objetivo es encontrar lo que el primero ha hecho mal.
El mismo método funciona en modo revisión sobre código ya escrito, sea nuestro o heredado de otro proveedor.
Dependencias, parches y migraciones de versión
Un proyecto Drupal típico arrastra decenas de módulos contribuidos y, con frecuencia, parches sobre core o contrib que pueden dejar de aplicar en el peor momento. Mantenemos un registro central de versiones validadas, con los parches que funcionan en cada una y las pruebas que los comprueban. Sobre ese registro, los agentes sustituyen o retiran parches, los generan a partir de las propuestas de corrección de la comunidad, detectan paquetes desactualizados y vulnerabilidades conocidas, y suben versiones solo cuando pasan una verificación previa. Lo que se aprende en un proyecto (un parche que hay que sustituir, una incompatibilidad, una versión que funciona) se anota en el registro y beneficia al siguiente. Al terminar recibes un resumen de actuaciones: qué se ha cambiado, por qué y con qué resultado.
Saltar de versión mayor es el momento de más riesgo en la vida de un sitio, y el código propio es el que más sufre: APIs retiradas, servicios que cambian de firma, plantillas y JavaScript que dejan de funcionar. Nuestro proceso de migración combina refactorización automática con Rector, análisis estático con PHPStan al nivel de la versión objetivo, verificación de compatibilidad de todas las dependencias, revisión de calidad del código y validación del proyecto migrado en un entorno real. La base de conocimiento dice qué herramienta y qué configuración corresponden a cada salto. Y si tu equipo sigue subiendo código mientras migramos, el proceso reconcilia esos cambios con lo ya migrado.
Por qué la IA no decide por nosotros
Cuatro garantías de control
Lo que hace distinto a este sistema no es lo que la IA puede hacer, sino lo que no puede hacer sin nosotros.
Ningún plan se ejecuta, ningún cambio llega al repositorio y nada se envía fuera sin que una persona de nuestro equipo lo autorice, cada vez.
Cuando un agente dice «hecho», unos scripts deterministas lo comprueban: análisis estático, pruebas, recuentos, conexiones. Si la comprobación falla, no está hecho.
El agente trabaja con nuestra base contrastada contra Drupal core y con nuestro registro de versiones validadas, no con lo que recuerda.
Cada error detectado se convierte en una regla escrita que se incorpora al paso del método donde aplica, en términos genéricos y sin datos de ningún cliente.
Tus datos, credenciales y volcados de base de datos nunca forman parte del sistema: las metodologías son genéricas y el estado de cada proyecto vive en el propio proyecto.
Qué cambia para tu proyecto, y qué no
Cambia la cobertura: una auditoría o una migración ya no se apoyan en una muestra, sino en la revisión completa de lo que hay. Cambia la trazabilidad: cada decisión, verificación y aprobación quedan registradas y cruzadas con el historial del código, así que puedes pedirnos el porqué de cualquier cambio, también meses después. Y cambia la memoria: cada proyecto conserva un índice de su estado, sus decisiones y sus pendientes, de modo que una sesión de trabajo retoma donde la dejó la anterior, y tu proyecto hereda lo aprendido en los anteriores.
No cambia quién responde. El plan lo aprueba un desarrollador nuestro, el diagnóstico lo prioriza una persona y la responsabilidad sobre lo entregado sigue siendo del equipo. Lo que contratas es ese criterio y esa responsabilidad, con un sistema detrás que los hace más exhaustivos.
Lo que contratas es ese criterio y esa responsabilidad, con un sistema detrás que los hace más exhaustivos.
Fuentes
- Drupal Association, Drupal core release cycle, drupal.org — calendario de versiones menores y mayores y política de deprecaciones.
- Rector, Drupal Rector, drupal.org/project/rector — refactorización automática de deprecaciones por versión.
- PHPStan, phpstan-drupal, GitHub — análisis estático con reglas específicas de Drupal.