Crea plugins de WordPress con IA y OpenSpec | Taller completo en directo

Durante años, hacer desarrollo a medida sobre WordPress significaba elegir entre dos males: pagar muchas horas de programación o resolverlo apilando plugins comerciales que traían diez funciones que no necesitabas por cada una que sí. La inteligencia artificial ha cambiado esa ecuación, pero no de la forma que la mayoría cree. No basta con pedirle cosas a un chat. Hace falta un método.

Esta es la grabación completa del taller que impartí sobre desarrollo guiado por especificaciones aplicado a WordPress. Hora y media, en directo, partiendo de una carpeta vacía y de una instalación limpia. Debajo del vídeo tienes el resumen escrito de todo lo que se cuenta, por si prefieres leerlo.

El error más común: pedirle el plugin entero a la IA

Abrir el chat, escribir «hazme un plugin para gestionar inscripciones deportivas» y darle a Enter. Lo he visto muchas veces y lo cometí yo el primero. El modelo empieza a consumir tokens, va tomando decisiones de alcance sobre la marcha, resuelve a su manera todo lo que tú no has especificado, y al final te entrega algo que funciona a medias y que no se parece a lo que tenías en la cabeza. Si se lo pides dos veces, te entrega dos plugins distintos.

El problema no es la herramienta. El problema es el reparto de papeles. En un proyecto de desarrollo de software a medida siempre ha habido alguien que analiza y alguien que programa, y esos dos papeles no son intercambiables. Cuando le delegas a la IA el análisis además de la programación, estás dejando que un junior muy rápido decida el alcance del proyecto. Va a ir rápido, sí, pero hacia donde a él le parezca.

De functions.php a las especificaciones: una escalera de cuatro peldaños

Cualquiera que lleve tiempo haciendo mantenimiento de WordPress reconoce esta secuencia. El primer peldaño es meter código directamente en el functions.php de la plantilla. Alguien lee en un blog que pegando cierto fragmento la web hace algo concreto, lo pega, funciona, y a la siguiente actualización del tema desaparece sin dejar rastro. Nos encontramos webs de clientes con las actualizaciones desactivadas precisamente por esto, lo que a su vez las convierte en un problema de seguridad.

El segundo peldaño es hacerlo en el functions.php del tema hijo, que al menos sobrevive a las actualizaciones. El tercero es un plugin de fragmentos tipo Code Snippets, que ordena un poco el desastre pero deja la lógica de negocio del proyecto encerrada dentro de la base de datos de un plugin de terceros. Y el cuarto peldaño, el que hoy tiene sentido, es hacerte tu propio plugin.

Antes ese cuarto peldaño era caro y por eso casi nadie subía. Hoy no lo es. Y por eso mismo conviene subir bien, con un método que deje el resultado documentado y mantenible, en lugar de improvisar.

Qué es el Spec-Driven Development y por qué cambia el resultado

El desarrollo guiado por especificaciones consiste en no pedir nunca el proyecto entero de una vez, sino trocearlo en fragmentos pequeños y perfectamente definidos. En lugar de «hazme un plugin de inscripciones», le planteas una capacidad concreta: un formulario que permita registrarse, con estos campos, con estas validaciones, con este correo de confirmación. Esa es una especificación.

A partir de ahí el ciclo tiene cuatro pasos. Propones lo que quieres conseguir. La herramienta te devuelve por escrito lo que ha entendido, y te pregunta lo que no tiene claro en forma de opciones cerradas. Revisas esa propuesta y la corriges hasta que refleja de verdad tu intención. Implementas, y solo entonces se toca el código. Y cuando has probado que funciona, archivas: esa propuesta pasa a formar parte de la documentación consolidada del proyecto.

Lo interesante viene después. Seis meses más tarde el cliente quiere añadir inicio de sesión con Google. Como el sistema ya tiene una especificación de inicio de sesión escrita y archivada, no se empieza de cero: se recupera esa especificación y se itera sobre ella. El proyecto acumula memoria en lugar de acumular parches. Y esa es exactamente la diferencia entre un desarrollo a medida que envejece bien y uno que se vuelve intocable a los dos años.

Las directrices del proyecto: CLAUDE.md y AGENTS.md

Son dos ficheros de texto donde defines cómo debe comportarse la IA en ese proyecto concreto, y son más importantes de lo que parecen. Ahí es donde escribes en qué idioma se documenta, que cada vez que subas versión se incremente el número y se anote el cambio en el changelog, que el plugin tiene que ser multiidioma desde el principio, o que este cliente en particular sigue en PHP 7.4 y no puede actualizar, así que el código tiene que ser compatible con esa versión.

Ese último punto es puro mantenimiento web: quien lleva carteras de sitios sabe que la versión de PHP del hosting manda, y que un desarrollo que no la respeta es una llamada de teléfono garantizada en el peor momento.

Qué construimos en directo

Partimos de una carpeta vacía y de un WordPress instalado la noche anterior, sin plugins ni trucos preparados, y montamos un sistema completo de registro, inicio de sesión y área privada. Sin WooCommerce y sin apoyarnos en ninguna solución existente. Con widgets nativos de Elementor en lugar de shortcodes, confirmación de la cuenta por correo electrónico, validación de contraseña y una pantalla de configuración propia en el escritorio de WordPress.

Y con sus fallos. El taller no está editado: hay redirecciones que no funcionan a la primera, un formulario que se vacía cuando no debería y una segunda iteración para añadir una columna de estado en el listado de usuarios. Precisamente ahí está lo que quería enseñar, porque el método no consiste en acertar a la primera sino en tener un sitio ordenado donde corregir.

Plugin a medida o suscripción anual: la cuenta que casi nadie hace

Hace poco concursé por un trabajo en el que puntuaban positivamente no usar plugins a medida. Querían que todo se resolviera con complementos comerciales aunque hubiera que pagarlos. Entiendo el miedo que hay detrás, pero la cuenta no salía: para conseguir una funcionalidad concreta había que contratar una suscripción anual de un paquete que hace veinte cosas, de las cuales el cliente necesitaba exactamente una.

Y ese coste no es solo económico. En nuestro trabajo de mantenimiento de WordPress nos encontramos constantemente webs con esos paquetes de veinte funciones activados al completo, cargando JavaScript y CSS en todas las páginas del sitio, cuando el cliente solo quería poner bonito un formulario. Es una de las causas más frecuentes de las webs lentas que nos llegan para optimizar.

Un plugin pequeño, que hace una sola cosa y la hace bien, no arrastra ese peso. Y ahora que desarrollarlo cuesta una fracción de lo que costaba, la balanza se ha movido de sitio. Hoy resolvemos entre el 60 % y el 70 % de las necesidades de nuestros clientes con plugins de WordPress a medida en lugar de con suscripciones.

La objeción legítima: ¿y quién lo mantiene después?

Es la pregunta correcta, y hay que responderla con honestidad: mantener un desarrollo hecho por otra persona siempre ha sido complicado. Lo que ha cambiado es que ahora el proyecto no se entrega solo como código. Se entrega con sus especificaciones escritas, su registro de cambios y su documentación completa, generada durante el propio desarrollo y no a posteriori a regañadientes.

Llevo desarrollando desde 2003 y he visto demasiados proyectos entregados sin documentación y sin pruebas, porque eran las dos partidas que el cliente pedía recortar cuando quería bajar el presupuesto. Eso ya no tiene sentido: hoy la documentación y el plan de pruebas salen prácticamente gratis, así que no hay excusa para no entregarlos.

Seguridad: el argumento que se ha dado la vuelta

Durante años, quien encargaba un desarrollo a medida se consolaba pensando que su código no estaba documentado en ninguna parte y que por eso nadie iba a atacarlo. Ese razonamiento ya no se sostiene. Hoy hay agentes automáticos buscando vulnerabilidades las veinticuatro horas, y una pieza de código artesanal con fallos evidentes es más fácil de romper que una base bien construida.

La contrapartida es que esas mismas herramientas juegan a tu favor si las usas bien. En el taller cuento un uso muy práctico para tareas de mantenimiento: cuando una web ha sido comprometida, te la descargas con su base de datos, la levantas en un servidor aislado y pones al agente a buscar código malicioso dentro. Encuentra en minutos lo que a mano puede llevarte una tarde entera de desesperación.

Lo que necesitas para seguirlo

¿Esto nos quita trabajo o nos da más?

Es la pregunta que sale en todas las charlas y la contesto con prudencia, porque nadie lo sabe del todo todavía. Lo que sí puedo contar es lo que veo en nuestra empresa. La productividad por persona se ha multiplicado de forma muy visible; la facturación no ha subido en la misma proporción, pero tampoco ha bajado, y las horas que echamos son mucho más provechosas que hace un año.

Hay un efecto secundario del que se habla poco: mantener el foco cuesta más. Cuando el desarrollo avanza tan rápido acabas atendiendo dos proyectos y varios tickets de soporte a la vez, y te toca apuntar en un papel por dónde ibas. La herramienta ha dejado de ser el cuello de botella; ahora el cuello de botella es tu cabeza.

Mi apuesta es sencilla: ponte en la punta de la flecha, cada uno en lo suyo. Quien hace marketing, en marketing. Quien hace desarrollo, en desarrollo. Si te subes al carro, creo que vas a tener más trabajo, no menos.

Preguntas frecuentes

¿Hace falta saber programar para seguir el taller?

Ayuda mucho, pero no es imprescindible para entender el método. En hora y media apenas se ve código PHP en pantalla: lo que se ve es cómo se escribe una especificación, cómo se revisa lo que propone la herramienta y cómo se detecta que algo no está haciendo lo que debería. Ahora bien, si vas a entregar el resultado a un cliente, alguien con criterio técnico tiene que revisarlo. Aceptar código sin leerlo ni probarlo sigue siendo mala idea.

¿Se puede desarrollar así para WooCommerce o para bloques de Gutenberg?

Sí. En el taller trabajo con widgets de Elementor porque es lo que más uso, pero basta con especificarlo de otra manera para que genere bloques nativos del editor de WordPress. Lo mismo aplica a WooCommerce: integraciones con pasarelas de pago, sincronización con un ERP o generación automática de facturas contra una API externa. En el vídeo enseño precisamente ese caso, conectando WordPress con un sistema de facturación a través de su API.

¿Es esto el final de WordPress?

Se está diciendo, ahora que cualquiera puede pedirle una landing a un modelo. Yo creo que no. WordPress mueve más del cuarenta por ciento de las webs del mundo y tiene tres cosas que no se improvisan: infraestructura, una forma de trabajar consolidada y una comunidad enorme detrás. Además hay un argumento que le doy siempre a mis clientes: con WordPress no te secuestra nadie. Si un día no te entiendes con tu proveedor, buscas otro y puede continuar el trabajo. Con un desarrollo cerrado y propietario, eso es mucho más difícil.

¿Cuánto cuesta hoy un plugin de WordPress a medida?

Bastante menos que hace dos años, y esa es la novedad. Desarrollos que antes suponían meses de trabajo hoy se resuelven por una fracción del coste, funcionan mejor y se mantienen mejor porque llegan documentados. Lo que no ha cambiado es la parte de análisis: sigue haciendo falta alguien que entienda tu negocio y sepa traducirlo a requisitos. Esa parte no la ha abaratado nadie.

Servicios relacionados

• Desarrollo de software a medida para empresas
• Desarrollo de plugins para WordPress y WooCommerce
• Mantenimiento de WordPress: actualizaciones, seguridad y rendimiento

Sobre el ponente

Dámaso Velázquez es CEO de WebProgramación, consultora tecnológica que fundó en 2010 y que tiene su sede en el Parque Científico de la Universidad de Salamanca. Desarrolló software a medida en .NET desde 2003 hasta 2018, cuando una WordCamp en Madrid le hizo cambiar de rumbo. Hoy la mitad de la facturación de la empresa viene de WordPress. Imparte charlas y talleres sobre desarrollo asistido por IA en comunidades WordPress y universidades, y colabora en Proyecto Tutor formando en competencias digitales a pequeñas empresas del medio rural.