Hace unos meses le pedí a la IA un refactor de plantillas a Tailwind en un proyecto Drupal. Lo hizo rápido, se veía bien y no rompía nada. Ya lo conté en los seis casos reales de IA en Drupal, pero hay una parte que se me ha quedado dando vueltas.
Cuando me puse a revisar el diff, aquello estaba lleno de CSS y JS inline. Había plantillas duplicadas. Y unos cuantos malos patrones del código antiguo que la IA había copiado tal cual, porque si estaban ahí sería por algo.
Si me llego a fiar de que funcionaba, lo subo así.
Y eso es lo que me preocupa de verdad de programar con IA. No que haga código malo, que eso se ve enseguida. Me preocupa que haga código que casi siempre funciona.
El 80% ahora sale gratis
Cualquiera que lleve unos años en esto conoce el Pareto de los proyectos. El 80% de la tarea te lo quitas en nada y luego el último 20% se eterniza. Que si falta un detalle del formulario, que si hay que volver a pasar la migración, que si hay que cuadrar el despliegue con el cliente... Llevo más de quince años con Drupal y esto ha sido siempre así.
Lo que ha cambiado es que ahora ese 80% sale en diez minutos. Y sale con muy buena cara: código ordenado, comentado, con sus tests y todo en verde.
Tiene tan buena pinta que parece el 100%. Y como te ha costado tan poco, te pide el cuerpo darlo por bueno y pasar al siguiente ticket.
A ver, yo también he caído. Cuando la IA me da algo que está claramente mal no pasa nada, lo leo, veo que no tiene sentido y lo tiro. El peligroso es el otro. El que parece correcto pero esconde un fallo pequeñito, que apruebas sin pensarlo y que te explota tres meses después en un caso que nadie había contemplado.
¿Hacia dónde vamos?
Por lo que voy viendo, el sector va bastante en la dirección contraria a la que debería. Se presume de cuántos tickets ha cerrado el agente esta semana, de cuántas líneas ha escrito, de cuántos despliegues se han hecho. De cuántos de esos cambios ha habido que rehacer después se habla bastante menos.
Y luego está lo de los experimentos. Antes, si querías probar una idea, la hacías sencillita, porque complicarla eran días de trabajo y igual luego no servía. Si no funcionaba, fuera. Ahora le pides el experimento a la IA y te monta servicios, wrappers, configuración y hasta su página de administración en una tarde. Como ha salido barato, nadie lo quita. Y el proyecto va engordando con cosas que no usa nadie.
En Drupal esto se paga. Cada módulo custom es uno más que revisar en cada actualización de seguridad y que migrar cuando toque pasar a Drupal 12. Barato de escribir, sí. Barato de mantener, ni de lejos.
Drupal tiene un problema extra
Hay algo que es muy nuestro. La IA te da la solución más probable, la que más veces ha visto. ¿Y qué ha visto sobre Drupal? Pues quince años de respuestas en Drupal Answers, tutoriales de Drupal 8 de 2016, snippets de Drupal 7 adaptados a medias...
O sea, que lo más probable no es lo que haría un senior en Drupal 10 u 11. Lo más probable es un \Drupal::service() metido en una clase que debería usar inyección de dependencias. O un hook_form_alter de doscientas líneas en el .module, cuando en Drupal 11 ya tienes los hooks como atributos. O un |raw en Twig porque así se ve bien el HTML.
Y casi todo eso funciona, que es lo peor. Un test no sabe nada de cache bubbling. PHPStan te avisa de las APIs deprecadas, pero no te va a decir que esa función que acaba de escribir ya existe duplicada tres módulos más allá.
Los tests en verde ya no me dicen tanto
Hay otra trampa más. Si el agente escribe el código y también los tests, los tests comprueban lo que el agente entendió que querías. Si lo entendió mal, tienes un código incorrecto con unos tests que dicen que está perfecto.
No me malinterpretes, los tests siguen siendo necesarios. Pero para mí ya no bastan para decir que algo está terminado. Hace falta mirar también la complejidad, el código duplicado, la seguridad y las buenas prácticas de Drupal. Y que eso lo mida algo determinista, no otra IA opinando sobre si el código le parece bonito.
Las herramientas genéricas de análisis ayudan, pero no saben nada de Drupal. Te dirán que una función es compleja. No te dirán que tu plantilla rompe la caché o que tienes una vista de administración abierta a anónimos.
Aquí es donde entra Audit
Buena parte de estos problemas son los que intento atacar con Drupal Site Audit, un módulo que mantengo y que he contribuido a la comunidad. Analiza tu Drupal y te da una puntuación de 0 a 100 en seguridad, rendimiento, caché, configuración y calidad de código, con recomendaciones concretas de qué arreglar.
En la parte de código mira justo lo que comentaba antes. Funciones que se han vuelto demasiado complejas, código duplicado, malas prácticas de Drupal en las plantillas, problemas de seguridad en el código custom... Todo eso que un test no ve.
Y se puede lanzar con comandos de Drush que devuelven el resultado en JSON.
Mis skills y mis agentes están enseñados para usar esos comandos. Cuando el agente termina una tarea, pasa los audits sobre lo que ha tocado, lee los errores, los corrige y vuelve a pasarlos. Un bucle cerrado. El propio agente se da cuenta de lo que ha hecho mal y lo arregla antes de que yo llegue a verlo.
Así, cuando me toca revisar, ya no me encuentro el CSS inline ni las plantillas duplicadas. Y dedicó menos tiempo a revisar código mal implementado.
El sello final lo sigo poniendo yo
Que el agente pase todos los audits no significa que el trabajo esté bien. Significa que no tiene los errores que el módulo sabe detectar. Que no es poco, pero tampoco es todo.
Una IA puede bajar la complejidad de una función partiéndola en cinco métodos que no tienen ningún sentido. Los números mejoran y el código sigue igual de mal. O puede montarte una arquitectura que pasa todos los checks y que dentro de seis meses no hay quien la toque.
Por eso, cuando el agente termina, entro yo. Miro qué ha hecho, cómo lo ha hecho y si la arquitectura que hay por debajo tiene sentido para el proyecto.
La revisión final sigo haciéndola yo. Al menos de momento, porque igual dentro de un año los modelos escriben Drupal limpio de serie y todo esto me sobra. Ojalá.
Pero hoy no es así. Y lo que no quiero es volver a encontrarme código duplicado en un diff... y que se me pase.