Descubrí que la IA me roba el 60% del trabajo

Después de estar más de un año trabajando con inteligencia artificial en mis proyectos de Drupal e ir depurando mis procesos, he llegado a lo que creo que son los porcentajes que definen mi forma actual de trabajar: 20-60-20.

Veinte por ciento de planificación humana, sesenta de ejecución con IA, veinte de revisión final. Esto me ha permitido reducir a la mitad el tiempo que invierto en desarrollo Drupal manteniendo, y en algunos casos mejorando, la calidad del código. Pero hay que ser honesto: estos son mis porcentajes aproximados según lo que estoy viendo que es mi caso de uso, los que uso cuando priorizo hacer el trabajo bien hecho. Si prefieres velocidad sobre calidad, tus números serán radicalmente diferentes.

Cómo funciona en la práctica con Drupal

El primer 20% es trabajo completamente mío. Me siento, pienso la arquitectura del módulo Drupal, decido qué approach voy a tomar. Escribo una especificación detallada: qué hooks necesito, qué servicios, qué plugins, las dependencias entre módulos, los edge cases importantes, los requisitos de rendimiento, las consideraciones de seguridad. Este tiempo es pura planificación y especificación, y es 100% humano.

Luego viene el 60%. Y aquí es donde la cosa se pone interesante, porque este porcentaje no siempre se gestiona de la misma forma. Uso dos modos de trabajo distintos según la complejidad de la tarea Drupal que tenga entre manos.

El modo supervisado: cuando priorizo calidad

Si lo que me interesa es la calidad del código más que la rapidez de implementación, voy revisando y dando guías, llevando de la mano a la IA para que no se vaya por las ramas ni tome caminos que no quiero en el ecosistema Drupal.

Este approach lo uso sobre todo en tareas muy complejas de Drupal donde tengo pocos ejemplos para darle a la IA. Como casos de ejemplo, serían cuando hago un módulo Drupal muy a medida, muy específico, que no he hecho un módulo como ese similar antes, con lo cual no tengo ejemplos de proyectos de otros clientes en los que basarme. O cuando es un análisis de rendimiento complejo con código custom en Drupal que tengo que entender exactamente qué está haciendo y dónde está el problema, quizás en una implementación de un servicio complejo o un plugin custom que afecta al rendimiento global del site.

Básicamente es esto: cuando es código Drupal a medida, muy personalizado, no estándar, no funciones que hago de forma recurrente para distintos clientes, sino que son cosas muy concretas para un único cliente y que hasta tengo que hacer investigación de cuál sea la mejor forma de implementarlo siguiendo las mejores prácticas de Drupal. En estos casos, prefiero ir por fases: la IA genera una parte, yo reviso, doy feedback, ajusto la dirección, y continuamos. Aquí el 60% sigue siendo trabajo de la IA, pero con mi supervisión activa constante.

El modo loop (Ralph): cuando tengo todo especificado en Drupal

Si son tareas de Drupal bastante simples o muy normalizadas y ya tengo varios ejemplos y reglas claras que puedo especificar, ahí sí que ejecuto un loop automatizado tipo Ralph.

El mejor ejemplo son las migraciones Drupal. Si tengo un patrón establecido de cómo hago las migraciones en ese proyecto, con ejemplos de migrate plugins anteriores, con las transformaciones comunes documentadas, con tests que validan el resultado... puedo soltar la IA en modo loop y dejarla trabajar sola.

Otro ejemplo claro son los módulos estándar: crear un módulo con su info.yml, implementar hooks básicos, generar formularios con Form API, o crear bloques con el sistema de plugins de Drupal. Cuando la estructura es repetitiva y conocida, el modo loop funciona perfectamente.

En esos casos, puedo dejarlo perfectamente una hora corriendo sin estar encima. No estoy supervisando cada paso durante esa hora, la IA trabaja completamente autónoma. Pero cuando termina, lo reviso todo antes de hacer los commits. Recuerda: la regla es que la IA nunca hace commits por su cuenta, siempre reviso yo primero.

Este es el verdadero trabajo desatendido. Ese 60% se convierte en tiempo real que puedo dedicar a otros proyectos Drupal o a tareas que antes descuidaba.

El último 20%: donde mucha gente se equivoca

El último 20% vuelve a ser completamente mío. Y aquí es donde veo que muchos desarrolladores Drupal fallan: este tiempo no es opcional si quieres mantener calidad.

Una regla que nunca violo: la IA nunca hace commits por su cuenta. Da igual que esté en modo supervisado revisando constantemente o que haya dejado el modo Ralph corriendo una hora, en ningún caso permito que la IA ejecute git commit o git push. Todos los commits los hago yo personalmente, siempre después de revisar el código.

¿Por qué? Porque antes de hacer commit reviso todos los ficheros que ha generado o modificado la IA. Y aquí hay un matiz importante sobre qué significa "revisar". Si son cambios más mundanos, los leo en diagonal, de forma superficial, comprobando que la estructura general tiene sentido y se parece a cómo yo escribiría ese código. Pero si veo algo problemático o es un código más complejo, ahí sí que me detengo a entender exactamente qué está haciendo y cómo lo está implementando.

La regla de oro es esta: si no entiendes el código que te ha generado la IA, para. Busca en internet, investiga, y entiende exactamente si lo que te está implementando es correcto o no antes de seguir adelante.

Solo con este tipo de revisión he encontrado problemas graves: código spaghetti que no tiene sentido, violaciones de las mejores prácticas de Drupal, implementaciones que funcionan pero que no escalan o que son un desastre de mantenimiento. No me fío de lo que hace la IA a ciegas. Es una máquina estadística que genera código plausible, no perfecto.

En resumen: el 40% del trabajo lo hago yo (20% antes + 20% después), y aproximadamente el 60% me lo hace la IA. Esto es manteniendo, o incluso mejorando, la calidad del código Drupal respecto a cuando lo hacía todo manual.

Mi sistema Ralph con OpenCode para Drupal

El modo loop que acabo de mencionar funciona gracias a una adaptación que he hecho del patrón Ralph específicamente para mi flujo de trabajo con Drupal. Para quien no lo conozca, este patrón consiste en ejecutar la IA en un bucle continuo y autónomo. En lugar de darle una tarea y esperar que la complete de una sola vez, la ejecutas en loop donde cada iteración tiene contexto fresco. La IA elige la tarea más importante, la implementa, ejecuta tests, y repite. Todo sin supervisión constante.

Pero con una diferencia crucial respecto al Ralph original: en mi sistema, la IA nunca hace commits ni push. Antes permitía que la IA hiciera commits automáticos, pero me di cuenta de que generaba código que a veces no revisaba bien y acababa haciendo mal las cosas. Ahora es una regla estricta: todos los commits y push los hago yo personalmente, siempre después de revisar el código.

En su día probé Claude Code, la herramienta que popularizó este concepto, pero lo dejé. Desde hace tiempo estoy usando exclusivamente OpenCode y he adaptado el concepto de Ralph a mi flujo de trabajo Drupal con esta herramienta.

El resultado es que puedo dejar corriendo procesos durante horas mientras trabajo en otro proyecto Drupal o en otras tareas. Lo uso sobre todo para tareas rutinarias y bien definidas en Drupal:

Generar migraciones base en Drupal. Cuando tengo que crear los migrate plugins iniciales para un proyecto nuevo con patrones que ya tengo establecidos, definir los process plugins custom que uso habitualmente, configurar los source plugins para conectores a APIs o bases de datos externas.

Refactorizar módulos Drupal simples. Reorganizar código, mejorar la estructura de los servicios, añadir type hints, convertir funciones procedural en servicios inyectables, todo ese trabajo mecánico que consume tiempo pero no requiere decisiones complejas de arquitectura.

Añadir tests a módulos Drupal existentes. Generar la cobertura de tests unitarios o de kernel que nunca se hizo en su momento, ejecutarlos, corregir los que fallan, iterar hasta que todo pasa. Drupal tiene un sistema de testing muy potente y la IA puede aprovecharlo bien cuando sabe qué está haciendo.

Crear plugins estándar de Drupal. Blocks, Field Formatters, Field Widgets, Queue Workers, Cron hooks... todos esos plugins que siguen patrones muy definidos en Drupal y que la IA puede generar sin problemas una vez le das el contexto adecuado.

Arreglar problemas de PHPStan o PHPCS. Esas tareas de estático que son puramente mecánicas: el linter marca un error en el código Drupal, la IA lo corrige siguiendo los estándares de Drupal, vuelve a ejecutar, y sigue hasta que todo está limpio.

En todas estas tareas Drupal, el loop funciona porque son problemas bien definidos con criterios de éxito claros. Los tests de Drupal o los propios linters sirven de guía. La IA itera, falla, corrige, vuelve a probar, hasta que todo pasa.

Esto es probablemente el camino hacia ese futuro 10-80-10 o 5-90-5 en desarrollo Drupal. Cuando puedes soltar la IA durante horas con un bucle bien configurado y herramientas que validen automáticamente el progreso, el porcentaje de tiempo desatendido se dispara.

Pero insisto: el último paso de revisión humana sigue siendo crucial.

Por qué ese primer 20% es tan crítico en Drupal

Cuanto mejor seas en ese primer 20%, más real es ese 60% de trabajo desatendido. Si escribes una especificación superficial para tu módulo Drupal, la IA va a necesitar que la guíes constantemente y tu 60% se convierte en 40%.

Si no le das contexto sobre el proyecto Drupal, va a generar código que no encaja. Si no mencionas los requisitos de rendimiento o seguridad específicos de Drupal, tendrás que rehacerlo en el último 20%. Por ejemplo, si no le indicas que debe usar el servicio de caché de Drupal en lugar de hacer llamadas directas a la base de datos, puede generar código que funciona pero escala mal.

Pero si en ese primer 20% lo dejas todo claro, bien especificado, con contexto suficiente del proyecto Drupal, con ejemplos del código existente en tu codebase, con los edge cases identificados, con los requisitos de rendimiento y seguridad explícitos de Drupal, y especificando que genere tests y los ejecute, la IA puede trabajar de forma mucho más autónoma.

Y ese 60% de ahorro se convierte en tiempo real que puedes dedicar a otros proyectos Drupal o a mejorar aspectos que antes descuidabas.

Lo que nadie te cuenta: más tests en Drupal, mejor código

Algo curioso que he descubierto trabajando así con Drupal es que ahora implemento muchos más tests que antes. Y aquí viene lo interesante: no es que yo esté escribiendo más tests manualmente. Es que la IA los genera, y yo los reviso de forma más superficial que el código de producción.

Antes, escribir tests en Drupal era la parte más tediosa del desarrollo. Siempre quedaba relegada al final, y muchas veces se hacía de forma incompleta por falta de tiempo. Ahora, los tests se generan casi automáticamente junto con el código: tests unitarios para servicios, tests de kernel para lógica que depende de la base de datos, tests funcionales para flujos completos.

Con los tests soy menos estricto. Mientras pasen y veo que cubren los casos de uso principales, no me detengo línea por línea a leer cada assertion. Reviso en diagonal que el código tiene sentido y que los escenarios de test son decentes, pero no analizo el código interno del test con el mismo detalle que el código de producción. En mi caso, los tests aportan valor por su existencia y porque validan que el código funciona, no tanto por cómo están escritos internamente.

Pero hay algo aún más importante: los tests son fundamentales para que el sistema Ralph funcione con Drupal. El proceso loop que describí antes solo es posible si tienes tests. Sin tests, la IA no tiene forma de validar automáticamente si lo que está haciendo funciona o no. Con tests de Drupal, puede iterar de forma completamente autónoma durante horas, refinando el código hasta que todo funciona correctamente.

Es un cambio de paradigma: los tests pasan de ser esa tarea aburrida que haces al final a ser la herramienta que permite que la IA trabaje de forma autónoma y confiable en tus proyectos Drupal.

Por eso una de mis recomendaciones clave es: si vas a trabajar con IA en Drupal, asegúrate de que tu código tiene tests de algún tipo. Pueden ser tests unitarios con PHPUnit, tests de kernel que usan el entorno de Drupal, tests funcionales con BrowserTestBase, lo que sea. Pero necesitas alguna forma automatizada de validar que el código hace lo que debe hacer.

La trampa del 5-95: velocidad sin calidad en Drupal

Ahora bien, hay que ser claros sobre algo: puedes hacer 5-95 ahora mismo. Dedicas un 5% a explicarle superficialmente a la IA que quieres un módulo Drupal, dejas que haga el 95% del trabajo, y lo subes a producción sin revisión profunda.

Muchas agencias y freelancers Drupal lo están haciendo. Y funciona... hasta que no funciona.

El problema es que si no sabes detectar si el código Drupal que te ha generado la IA sigue las mejores prácticas o es código spaghetti, si no sabes identificar posibles problemas de seguridad (como validación de permisos incorrecta o XSS potenciales), si no revisas el rendimiento de las queries, si no validas que los edge cases están cubiertos... estás jugando a la ruleta rusa con tus proyectos Drupal.

Ese 5-95 significa básicamente: "Confío ciegamente en que la IA lo ha hecho todo bien". Y la IA, recordemos, es una máquina estadística. Te da lo que es probable que funcione, no lo que definitivamente funciona bien en el contexto específico de Drupal.

Así que sí, puedes reducir tu tiempo al 5% si quieres. Pero no te sorprendas cuando dentro de unos meses ese módulo Drupal te empiece a dar problemas de rendimiento, bugs sutiles, o vulnerabilidades de seguridad. La IA te hace código plausible, no código perfecto para Drupal.

Hacia dónde vamos: del 20-60-20 al 10-80-10 en Drupal

La realidad es que estos porcentajes están cambiando rápido. Hace seis meses estaba más en un 30-50-20. Cada pocos meses me acerco más a ese 20-60-20 actual.

Y la tendencia es clara: vamos hacia un 10-80-10, o incluso un 5-90-5, en desarrollo Drupal.

¿Por qué? Porque los modelos de IA están mejorando constantemente y están aprendiendo cada vez más sobre Drupal. Son más inteligentes, saben hacer más cosas, están más especializados. Lo que hace seis meses requería supervisión constante, ahora lo hacen de forma autónoma. Lo que hace tres meses generaba código Drupal que necesitaba refactorización pesada, ahora genera código que solo necesita ajustes menores.

Si la tendencia continúa al ritmo actual, en un año probablemente estaré en un 10-80-10 real para la mayoría de tareas Drupal. Y en dos años, quizá en un 5-90-5 para muchas implementaciones estándar de Drupal como módulos base, integraciones comunes, o features repetitivas.

El valor real está en saber qué NO hacer en Drupal

La conclusión a la que he llegado es paradójica: cuanto mejor desarrollador Drupal seas, más trabajo puedes delegar con seguridad. No porque la IA sea mejor programando que tú, sino porque sabes exactamente qué especificar, qué supervisar superficialmente, y qué revisar en detalle.

Sabes detectar cuándo el código Drupal que ha generado es sólido y cuándo es spaghetti disfrazado. Sabes qué tests de Drupal son necesarios para validar que todo funciona correctamente. Sabes reconocer cuando un servicio está bien inyectado o cuando un hook podría causar problemas de rendimiento.

Los desarrolladores Drupal que se quejan de que "la IA genera código malo" normalmente son los que no están invirtiendo en ese primer 20%. Le piden un módulo Drupal sin contexto, sin especificación clara, sin pensar en la arquitectura de servicios, sin especificar que genere tests. Y obtienen código superficial sin forma de validar que funciona.

Los que dicen "la IA me hace el trabajo perfecto" probablemente no están haciendo ese último 20% de revisión crítica. Y están acumulando deuda técnica sin saberlo.

Mis porcentajes no son los tuyos

Quiero ser claro: estos son mis porcentajes porque yo priorizo hacer el trabajo bien hecho en Drupal. Si tu prioridad es sacar proyectos rápido y tu cliente no va a notar la diferencia entre código Drupal limpio y código funcional-pero-sucio, tus porcentajes serán diferentes.

Puedes hacer 5-95 y salir del paso.

Pero si te preocupa la mantenibilidad a largo plazo de tus proyectos Drupal, la seguridad, el rendimiento, la escalabilidad... ese 20% final de revisión es donde demuestras tu valor real como desarrollador Drupal. La IA te ahorra el trabajo tedioso, pero tú sigues siendo quien garantiza la calidad del código que entregas.

En definitiva, el 20-60-20 no es una fórmula universal. Es mi forma actual de balancear velocidad con calidad en desarrollo Drupal. Y la tendencia clara es hacia un 10-80-10 conforme los modelos mejoran. Pero ese último porcentaje de trabajo humano, ese control de calidad final, seguirá siendo necesario mientras queramos código Drupal que no solo funcione, sino que funcione bien.

Y si hay algo que quiero que te lleves de este artículo es esto: invierte en tests para Drupal. No solo porque mejoran tu código, sino porque son la herramienta que permite que la IA trabaje de forma verdaderamente autónoma. Sin tests, la IA es un ayudante que necesita supervisión constante. Con tests bien configurados para Drupal, se convierte en un trabajador autónomo que puede iterar y mejorar durante horas sin tu intervención.