Esta semana he tenido seis situaciones distintas trabajando con IA donde la herramienta me ha ahorrado horas, pero también me ha intentado colar soluciones que no eran las correctas. Quería contarlos porque casi siempre se habla de lo que la IA hace bien y bastante poco de lo que cuesta revisar lo que entrega, y en mi día a día esos dos lados van juntos casi sin excepción.
Para quien no me conozca, soy freelance. Trabajo bastante subcontratado para agencias y, desde hace un tiempo, también llevo algún cliente final de forma más puntual. Los casos que cuento esta semana vienen mezclados de los tres frentes: proyectos míos personales, proyectos de clientes finales y proyectos que me derivan desde alguna de las agencias con las que colaboro.
Antes de meterme en los casos, conviene recordar algo que se pierde con facilidad. La IA generativa funciona prediciendo texto probable, no texto correcto. Genera código que estadísticamente tiene sentido en función de los patrones que ha visto, pero eso no significa que sea ni la mejor solución para tu caso ni que esté libre de errores. Muchas veces se inventa funciones, aplica patrones que no encajan con la arquitectura del proyecto o repite malas prácticas que ha visto en cualquier sitio. Si no llevas la revisión con criterio, lo que ganas en velocidad lo pierdes en deuda técnica más adelante.
Todo esto lo trabajo desde mi setup público de DDEV con Claude Code y OpenCode, que tengo en ddev-ai-workspace y del que ya he hablado en posts anteriores. Es un repositorio mío donde he ido recogiendo cómo estoy trabajando en mis proyectos y en los de mis clientes con lo que considero buenas prácticas. Si te dedicas a Drupal y usas DDEV, te recomiendo echarle un ojo y probarlo. Aparte del repo solo necesitas suscripción a los modelos que quieras utilizar o sus API keys.
El parche que no había que hacer
Uno de los patrones que me está saliendo más de lo que me gustaría es que le explicas un problema en Drupal a la IA y la solución que te propone es generar un parche para un módulo contribuido o, peor todavía, para el core. Esta semana me ha pasado dos veces.
En el primer caso, el problema real no estaba en el módulo contribuido sino en una incompatibilidad con código custom que teníamos nosotros en el proyecto. La solución correcta era adaptar el código custom, no parchear el contrib. En el segundo, lancé una investigación profunda desde Claude para comprobar si ya existía algún parche en la comunidad que arreglara el problema, y resulta que sí lo había. En los dos casos la IA detectó bien la causa del bug, lo analizó correctamente y entendió por qué se producía, pero la solución que proponía era la incorrecta.
Sin criterio para juzgar la propuesta, habría acabado manteniendo parches custom sobre módulos contribuidos, lo cual es una mala práctica de manual y un dolor de cabeza garantizado en cuanto toque actualizar.
Refactorizar templates sin perder la cabeza
En otro proyecto estamos migrando frontend a Tailwind CSS y esta semana he refactorizado un buen pedazo de templates, hooks de preprocess y ficheros JavaScript y CSS de un tema antiguo a uno nuevo. Tengo unas skills propias que leen los comentarios HTML que Drupal pinta en la web y a partir de ahí identifican qué template hay que modificar, cuál hay que crear y cuándo hace falta implementar un hook_theme_suggestions para meter una plantilla nueva. Funciona bastante bien y me ahorra muchas horas.
Lo que pasa es que si no revisas el código con cuidado, te encuentras varios problemas. El más típico es CSS y JavaScript inline metido directamente en el archivo .twig cuando lo correcto en Drupal es tener componentes con sus archivos separados. Otro es generar plantillas duplicadas que perfectamente podrían ser una sola plantilla genérica con una pequeña variación. Y el tercero, que es el más insidioso, es replicar patrones malos que ya existían en el código antiguo. Si la base que está mirando para inspirarse contiene malas prácticas, te las copia con entusiasmo y la bola de nieve sigue creciendo.
Lo tengo todo especificado en mis skills, pero aun así a veces la IA falla e ignora los prompts que tiene configurados, así que la lectura en diagonal del diff antes de aceptar nada es obligatoria. Cuando detecto algo mal le digo simplemente "esto no, hazlo así" y se corrige, pero alguien sin experiencia maquetando en Drupal no detectaría el problema y acabaría con una arquitectura de plantillas que en seis meses pasa factura. Otra cosa que también me he encontrado es que cuando detecto un patrón mal hecho, le pido que busque en qué otros sitios está aplicado el mismo patrón y lo arreglemos en todos a la vez, para sacar lógica de negocio de los twig y meterla en preprocess donde toca.
Aun así, lo que esa misma tarde he sacado adelante habría sido perfectamente una semana de trabajo a mano.
De interfaz admin a comando Drush sin reescribir el módulo
En otro proyecto tenemos un módulo custom para ejecutar migraciones incrementales desde un Drupal 7. Aparte de lanzar las migraciones, ofrecía una opción desde la interfaz de administración para limpiar los nodos y entidades que ya no existían en el sistema origen, algo necesario porque la web destino está en desarrollo y queremos que se mantenga lo más sincronizada posible con los contenidos reales. El cliente nos pidió convertir esa parte en un comando Drush para poder dejarla automatizada por cron junto con la migración incremental.
A mano, refactorizar el código para extraer la lógica de la pantalla de admin, montarla en un comando Drush bien estructurado con sus parámetros y dejarla probada habría sido un buen pedazo de trabajo. Pasarle el contexto a la IA y pedirle que reorganice el código existente para que el mismo flujo funcione tanto desde admin como desde consola lo ha reducido a una fracción del tiempo. La parte aburrida de cablear los parámetros del comando, validar entradas y mover el código entre clases sin duplicarlo la ha hecho el agente, y yo me he quedado con la parte de revisar la arquitectura final y comprobar que ambas vías ejecutan exactamente la misma lógica.
Media hora para resolver el bug que llevaba horas
El caso más claro de la semana lo viví con una persona de una agencia que llevaba horas intentando entender por qué la paginación de una views de taxonomía desaparecía de forma aparentemente aleatoria. Me lo explicaron, lo repliqué en local, confirmé que no era cosa del JavaScript y le pasé el contexto a mi IA: este es el problema, esto ya lo he descartado, busca la causa. Y mientras la IA investigaba, yo seguí con mis otras tareas en paralelo.
Cuando terminó el análisis, había detectado correctamente que el problema venía de un EVA, una views como campo, dentro de un view mode de un tipo de contenido. La paginación del EVA y la de la página de taxonomía estaban entrando en conflicto porque compartían el mismo identificador de paginador. Hasta ahí, diagnóstico perfecto. Pero la solución que me propuso era equivocada. Me dijo que quitara ese campo de un tipo de contenido concreto, cuando en ese tipo de contenido el campo ni siquiera estaba activado. Como la views de taxonomía es genérica y muestra varios tipos de contenido, la IA se había liado y confundió en qué tipo estaba el problema real.
Al revisarlo le dije que no era ese tipo de contenido y la dejé investigando otra vez. Cuando volvió me dijo "ah, es verdad, no es ese, es este otro", y a partir de ahí pudimos llegar a la conclusión correcta. Que tampoco era cambiar el ID del paginador, sino que el view mode estaba mal configurado. En las plantillas twig solo pintamos dos campos y el título, así que el EVA y el resto de campos que están activados en ese view mode no tenían que estarlo. Con desactivarlos en el view mode arreglamos el bug y, de paso, mejoramos el rendimiento porque al renderizar ese view mode ya no se cargan en memoria un montón de campos que nunca llegan a pintarse.
De horas perdidas a media hora bien gastada. Y no es que la IA lo hiciera todo bien, es que aceleró la parte lenta del diagnóstico mientras yo me ocupaba de las decisiones dudosas.
Updates y PHPCS en bucle, en segundo plano
Para mis proyectos personales en mantenimiento he montado algo distinto. Le pido a la IA que me actualice Drupal y los módulos contribuidos, que compruebe que todo sigue funcionando después de la actualización y que me genere las correcciones de los problemas que detecta mi propio módulo contribuido drupal/audit, que tengo configurado para identificar malas prácticas en plantillas twig, problemas de rendimiento en código custom, configuraciones que no deberían estar como están y los avisos típicos de PHPCS y PHPStan.
Como el módulo trae su propio comando Drush, la IA sabe lanzarlo, interpretar los resultados por categoría y aplicar las correcciones que tocan en cada caso, así que el bucle se queda cerrado de extremo a extremo sin que yo tenga que ir verificando manualmente qué hay que arreglar. La mayoría de esos avisos no son graves, pero son justo el tipo de cosa que vas posponiendo eternamente porque no es prioritario.
Lo dejo corriendo con un RALPH loop en segundo plano y va resolviendo iteraciones por su cuenta. Cuando vuelvo a mirar, las correcciones están hechas. Solo me toca revisar por encima que lo que ha hecho tiene sentido, lanzar los tests para confirmar que nada se ha roto y subir a producción. Lo que antes era una tarea aburrida que aparcaba semanas ahora se queda solucionada con unos minutos de supervisión, y de paso se mantiene en bucle de forma recurrente en vez de ser un sprint puntual que hago cuando me acuerdo de que existía.
Aplicar cambios a migraciones en segundo plano
Volviendo al proyecto de las migraciones, tengo desde hace tiempo un par de tareas automatizadas en mi workspace específicas para modificar y generar ficheros YAML del módulo Migrate, sobre las que ya he hablado en una charla en la DrupalCamp y en otros posts del blog. Esta semana el cliente nos ha pedido varios cambios sobre la migración después de revisar los primeros resultados, y la forma de aplicarlos ha sido literalmente decirle a la IA "estos son los ficheros, estos son los cambios, aplícalos". La IA modifica los YAML, lanza la migración, comprueba que los resultados son correctos y me lo deja todo listo para revisar y hacer el commit.
Lo que antes me habría llevado varios minutos o un par de horas de pruebas en local ahora se queda hecho de forma desatendida en segundo plano mientras yo sigo con otras tareas. Solo entro a revisar que el cambio aplicado tiene sentido, que los resultados cuadran con lo que el cliente pidió, y a partir de ahí avanzo.
Lo que saco en claro de esta semana
Si la IA se usa bien, ahorra mucho tiempo y desbloquea cosas que antes no eran rentables. Mientras estoy en una reunión o atendiendo una tarea que no es de programación, puedo dejar al agente analizando un bug o aplicando correcciones automáticas en segundo plano, y eso multiplica lo que sale adelante en una semana. La refactorización de plantillas que esta tarde me ha llevado unas horas, hace dos años habrían sido tranquilamente una semana de trabajo. El bug de la paginación que en agencia llevaba horas, en media hora estaba resuelto.
Lo que no cambia es que cada cosa que entrega la IA hay que revisarla. Y no porque "a veces se equivoca", sino porque más veces de las que me gustaría te entrega algo que funciona pero está mal planteado. Si recargas la página en el navegador parece que todo va bien, pero si abres el código ves CSS donde no toca, plantillas duplicadas que no deberían existir, lógica de negocio en twig en lugar de en un preprocess, o configuraciones que cargan en memoria entidades enteras solo para mostrar dos campos. Funcionar funciona, pero la mantenibilidad sufre y la deuda técnica se acumula sin que el cliente lo vea.
Y luego está el efecto bola de nieve. Si el código existente ya tenía malas prácticas, la IA las replica encantada en cada nueva parte que genera, así que cualquier base con problemas previos amplifica esos problemas a velocidad agéntica. Por eso la revisión no es opcional ni "buena práctica recomendada", es lo que separa que la IA te ayude de verdad o solo te ayude a generar más deuda más rápido.
Algo que he ido aprendiendo es que cuanto más trabajas con IA, más necesitas tener alguna forma sistemática de medir la calidad del proyecto, porque a ojo se te cuela cualquier cosa. Por eso uso el módulo audit en cada proyecto, configurado con los checks que tienen sentido para ese cliente, y por eso monté también DruScan, un dashboard SaaS que se conecta con el módulo y guarda histórico de las puntuaciones por entorno de desarrollo, validación y producción. Eso me da una foto de cómo evoluciona la salud del código a lo largo del tiempo, que se vuelve especialmente útil cuando hay más gente tocando el proyecto aparte de mí, que en mi caso pasa bastante porque colaboro con varias agencias en proyectos de distinto tamaño. El módulo es gratuito y ya está documentado en otros posts de este blog, y DruScan tiene una opción gratuita por si os interesa probarlo. Si lo hacéis, agradezco cualquier feedback.
Para el cálculo económico la cuenta sale clara. Aunque los tokens cuestan, si una persona usando IA bien hace en una tarde lo que antes le habría llevado una semana, el ahorro en horas frente al gasto en tokens es enorme. Y para tareas automatizadas como updates o correcciones de PHPCS, la alternativa real no es hacerlo más barato a mano, es no hacerlo nunca porque no llega a ser prioritario. Pasar de aparcar esa deuda durante meses a tenerla controlada con unos minutos de supervisión por iteración es de las cosas que más se notan en la calidad final del proyecto.