Yo era escéptica del AI, y mi duda era específica. No si un modelo podía escribir código. Pero si podía entender la complejidad de un sistema real y tomar buenas decisiones dentro de él.
Quien lleva un tiempo construyendo con Drupal sabe que la respuesta a "¿podemos hacerlo en Drupal?" probablemente es "sí, pero..." ¿Cuánto va a costar, quién lo necesita y dónde vive? La misma funcionalidad se puede entregar de una docena de formas. En manos de un desarrollador experimentado obtienes una pieza bien integrada. En otras manos obtienes el mismo dato actualizado en diez lugares distintos. Un modelo entrenado con todo lo que hay en internet ha visto los dos tipos. ¿Podría elegir el correcto?
Empecé a usar AI solo cuando perdí mi trabajo y necesitaba adaptar solicitudes más rápido de lo que podía hacerlo a mano. Luego cayó en mis manos una migración de emergencia, y tuve que decidir si confiar en estas herramientas con trabajo real bajo una fecha límite real. Lo que encontré es casi lo opuesto de lo que temía. El AI no hizo mi ingeniería más barata. Hizo que mi criterio valiera más. Todo lo que sigue es la evidencia de eso.
El AI no hizo mi ingeniería más barata. Hizo que mi criterio valiera más.
Lo que heredamos
El proyecto fue una migración de emergencia de tres meses para una organización de voluntarios grande y con mucha trayectoria. Su sitio en Drupal y su instancia de Salesforce habían crecido juntos durante más de una década, a través de varias migraciones de datos, y el lado de Salesforce se estaba reconstruyendo con nuevos objetos y una estructura de datos más robusta. El lado de Drupal tenía que seguir, y tenía que mantener a los voluntarios inscribiéndose en los programas durante todo el proceso.
Antes de prometerle una fecha a alguien, medimos el sistema heredado. Código personalizado de principio a fin, sin core, sin contrib, sin extends. Nada construido extendiendo una clase del core, nada reutilizado. Cerca de 42,000 líneas, sin contar pruebas. El peor archivo individual tenía una complejidad ciclomática de 38, donde 10 es el techo aceptado para un método y cualquier cosa por encima de 50 se considera imposible de probar. El 6.6% de todas las líneas estaban duplicadas en algún otro lugar, frente a un referente de la industria de menos del 3 por ciento. Un verificador de tipos en su segundo nivel de estrictez más bajo encontró 88 lugares donde el código podía fallar en tiempo de ejecución. Calculada con el método SQALE, el estándar de la industria para convertir problemas de código en horas de remediación, la deuda llegó a unas 2,700 horas. El AI hizo su primera contribución. No habría podido evaluar eso en mi primera semana sin él.
Sin embargo, el número que dolía día a día no estaba en esa lista. La mayor parte del código personalizado no usaba las estructuras de datos estándar de Drupal, así que nada estaba donde un desarrollador de Drupal espera encontrarlo. Diez años de instinto sobre dónde buscar valían muy poco.
Lo que el AI hizo en realidad
Tres cosas, y quiero ser exacta sobre ellas, porque el hype hace que la exactitud sea difícil.
Me permitió entender el sistema. Leer código que ignoraba las convenciones del framework de la manera tradicional habría tomado semanas que no tenía. Con un modelo leyendo junto a mí, podía seguir cómo se comportaba el sistema anterior y conectar eso con lo que necesitaba la nueva estructura de datos. Aun así tenía que saber qué preguntas hacer y qué respuestas desconfiar, pero la lectura dejó de ser el cuello de botella.
Escribió código conmigo. Digo conmigo, no para mí. Migramos el código personalizado a las propias estructuras de Drupal: profiles para los roles de voluntarios, taxonomías para las cosas que en realidad son listas, Webform para los formularios, y entidades personalizadas a través de ECK, el Entity Construction Kit, donde nada estándar encajaba. Los módulos contribuidos de Webforms y Salesforce nos dieron un control y una visibilidad que el código anterior nunca tuvo. Podíamos ajustar los datos fácilmente y rastrearlos de punta a punta. Escribimos pruebas y documentación junto con el código, la parte que normalmente se descarta cuando el calendario está en llamas. Y sí, el modelo propuso cosas que violaban patrones de Drupal que yo conocía. Discutimos, un cambio a la vez, hasta que el código estuvo bien.
Sostuvo el proceso. Trabajé con AIDA, un conjunto de habilidades de Claude Code que Carlos construyó para mantener nuestro trabajo honesto. Cada tarea pasó por investigación, arquitectura, implementación y revisión, y se escribía una especificación antes de cualquier código. Hacer seguimiento de esas especificaciones mantuvo el MVP bajo control, para que un flujo de trabajo que acabábamos de arreglar no se volviera a modificar en silencio. Para los comandos Drush de la migración dibujamos diagramas mermaid de cada decisión para que la siguiente iteración no sobreescribiera lo que ya habíamos escrito. Bajo presión esa es exactamente la disciplina que yo habría saltado, y las herramientas no me lo permitieron.
Esto es lo que no hizo. No conocía la organización, cuáles programas importaban más, ni qué voluntarios se verían afectados primero si algo fallaba. No sabía qué código seguía la lógica del negocio y cuál era código sobrante que nadie había eliminado, hasta que lo discutíamos. No eligió por dónde empezar ni por dónde terminar, y no tomó las decisiones.
Cuando los datos empujaron de vuelta
El lanzamiento se sostuvo. Luego la herramienta de retroalimentación del sitio empezó a llenarse. Los voluntarios y los Team Leaders pueden reportar problemas desde dentro del sistema, y lo hicieron, en volumen. Durante un par de días lo difícil no era arreglar nada. Era leer los reportes y determinar cuáles eran el problema de una sola persona y cuáles eran el mismo problema con nombres distintos.
Emergió un patrón. Las cuentas creadas en los últimos tres años estaban bien. Las cuentas con una larga historia, no. Encontramos cuentas duplicadas y registros conectados a la cuenta equivocada. La causa principal no estaba en nuestro código. Era una década de migraciones de datos parciales, cada una cambiando el modelo de datos mientras los contactos de épocas anteriores nunca se alinearon del todo. Las cuentas más antiguas seguían cualquier patrón que estuviera vigente cuando fueron creadas, y nuestra migración había confiado en una consistencia que no existía.
Este es el momento del que trata realmente este post, porque lo que lo resolvió no fue una corrección.
La respuesta de ingeniería era obvia y lenta. Rastrear cada inconsistencia, escribir la limpieza, verificar, repetir. Mientras tanto, los voluntarios de larga data no podían inscribirse y los Team Leaders no podían operar sus programas, y los programas son el punto central.
Así que tuvimos que priorizar. Decidimos hacer que los voluntarios y los Team Leaders pudieran trabajar primero, y arreglar los datos y ajustar los controles detrás de ellos. En dos semanas la mayoría de los voluntarios y Team Leaders podían hacer su trabajo. Afinar las herramientas y los datos que fluyen entre Drupal y Salesforce tomó meses, y todavía estamos en eso. Pero sucedió en segundo plano, donde correspondía.
Algo más salió de esas semanas que nunca estuvo en el plan. Cerramos puertas. Los roles y permisos ahora deciden quién puede ver qué, de forma mucho más estricta que antes. No porque desconfiemos de nuestros voluntarios, sino porque en una era donde cualquiera puede apuntar un modelo a una exportación de datos, el acceso abierto a la información es un riesgo que una organización no puede cargar.
Esas decisiones vinieron de leer la organización, no el código. Ningún modelo las propuso.
El manual
Lo que sigue es el manual, las cinco reglas que me llevé de esos meses, escritas para no tener que aprenderlas dos veces. La mayoría no tienen nada que ver con el AI. Le entregaría estos aprendizajes a cualquiera que esté a punto de construir con AI bajo una fecha límite, con sistema heredado o sin él.
Mide antes de prometer. De donde sea que estés partiendo, ponle números primero. Complejidad, duplicación, errores de tipos, horas de remediación, o lo que sea equivalente en tu campo. Los números no te dirán qué construir, pero te dicen cuánto todavía no sabes, y ese es el número sobre el que debe apoyarse una hoja de ruta.
Escribe la especificación antes del código, y cambia una cosa a la vez. Cuando el AI hace que el código sea barato, una intención poco clara también se vuelve barata, y vas a producir mucha. La especificación es donde el humano decide qué debe existir, y hacerle seguimiento es cómo evitas volver a romper lo que acabas de arreglar.
Deja que el AI lea para que tú puedas escuchar. Las horas que no pasé rastreando el sistema anterior fueron horas con las personas que dependían de él, conectando lo que solía hacer con lo que tenía que hacer después. Ese intercambio sirvió al propósito de toda la organización.
Asume que el pasado va a romper tus patrones, y diseña el camino de recuperación antes del lanzamiento. Todo sistema de larga vida, y toda organización de larga vida, carga los fósiles de decisiones anteriores. Decide de antemano qué pasa cuando tus nuevas reglas se encuentran con un registro antiguo, y quién lee la retroalimentación cuando llega en volumen.
El AI propone, el arquitecto técnico decide. Te mostrará la solución bien integrada y la que actualiza datos en diez lugares, con la misma confianza. Distinguirlas es el trabajo.
Todavía escéptica
Todavía no creo que el AI escriba software. No en ningún sentido que me permita dejar de prestar atención. Lo que ahora creo es más acotado y, para mí, más incómodo. El AI cambia lo que vale un arquitecto técnico. Cuando la lectura y la escritura se vuelven baratas, la habilidad escasa es conocer el negocio lo suficiente para decidir qué construir y qué proteger, y mantener a un humano en el loop en cada punto donde se toma esa decisión.
Una cosa más sobre ese código heredado. Parecía Drupal construido en soledad. Patrones que nadie en la comunidad reconocería, soluciones a problemas que el framework ya había resuelto. No sé cómo llegó a ser así, y no estoy aquí para juzgar a quien lo escribió. Pero sé el remedio, porque es lo que más valoro de trabajar con Drupal. La comunidad. Aprender solo es difícil. Sentarse en las sesiones del camp y escuchar a las personas que escribieron el código explicar por qué funciona como funciona hace que todo el framework sea legible de una manera que ninguna lectura solitaria puede lograr. El AI puede leer el código contigo. No puede reemplazar la sala.