Cómo construí un plugin de WordPress en 2 minutos con IA (y lo que se equivocó)

Le di a un agente de IA un único prompt: "Construye un plugin de WooCommerce que oculte el botón 'Añadir al carrito' en los productos con la etiqueta 'coming-soon' y lo sustituya por un formulario de alta a newsletter que envíe a Mailchimp." Dos minutos después tenía un ZIP funcionando. Esto es exactamente lo que pasó.

El planteamiento

No me interesaba escribir un plugin desde cero. Me interesaba probar cuánto del tedioso trabajo de scaffolding puede hacer hoy una IA sin vigilancia constante. Mi banco de pruebas era un WordPress 6.4 con WooCommerce 8.5 en una sandbox Docker, justo el entorno que tienen la mayoría de mis clientes. También disponía de credenciales de Mailchimp de cuenta de prueba. Nada estaba mockeado.

Lo que la IA acertó a la primera

El plugin generado tenía la cabecera correcta, los campos Plugin Name, Requires at least y Requires PHP. Se enganchó al hook correcto de WooCommerce (woocommerce_single_product_summary) con una prioridad sensata. Añadió un guard defer para no romper si WooCommerce estaba desactivado. Creó una página de ajustes dentro de WooCommerce, saneó entradas con sanitize_text_field y escapó salidas con esc_html y esc_attr. Todo con el formato de WordPress Coding Standards que normalmente tendría que reformatear a mano.

La sorpresa real fue la desinstalación. Sin que se lo pidiera, añadió un uninstall.php que limpiaba las tres opciones creadas. He visto plugins de pago que salen al mercado sin eso.

Lo que falló

La integración con Mailchimp usaba la API v3 y un Bearer token, correcto, pero guardaba la API key en texto plano en la tabla de opciones. Para un prototipo rápido es aceptable. Para un plugin real lo guardaría en una opción cifrada o requeriría un flujo de conexión que al menos la hashease en reposo. La IA no lo mencionó.

El formulario no tenía nonce. Para un form que publica en admin-ajax.php eso es un bug real, no una cuestión de estilo. Tuve que añadir wp_nonce_field en el formulario y check_admin_referer en el handler. Dos líneas, pero del tipo que no puedes enviar a producción sin ellas.

Por último, la consulta de etiquetas del producto usaba get_the_terms dentro de un bucle sin caché. En una archive con 48 productos por página eso son 48 consultas extra. Lo refactoricé con un solo get_posts con meta query y cacheé el resultado en un transient de cinco minutos. La IA aceptó el refactor cuando le pegué el snippet corregido y le pedí explicar por qué el original era más lento, lo cual fue una buena verificación.

El desglose de tiempo

Generación: 1 minuto 47 segundos. Arreglos manuales (nonce, caché, pulido de copy): 18 minutos. Empaquetado y tests: 5 minutos. Total extremo a extremo: unos 25 minutos para un plugin que a un cliente le habría cobrado entre tres y cuatro horas.

Lo que aprendí

La IA no está reemplazando a los desarrolladores de plugins en 2026. Lo que está haciendo es comerse el primer 80% del trabajo, la parte menos interesante: boilerplate, enganche de hooks, páginas de ajustes, escapes, saneadores, hooks de desinstalación. Precisamente la parte que yo hacía más lento, porque era la que más me aburría.

El 20% restante es por lo que de verdad te contratan: estrategia de caché, revisión de seguridad, UX de la página de ajustes, y saber cuándo NO enviar algo. Eso no desaparece. Pero llegar a ello en dos minutos en vez de tres horas cambia la economía del trabajo por completo.

¿Lo usaría en producción?

Para un cliente: generar, revisar línea por línea, añadir las piezas de seguridad que faltaban, añadir tests alrededor de las llamadas a la API, y enviar. Para mi propia web, ya he sustituido tres plugins-snippet por versiones generadas con IA y no me he arrepentido de ninguna.

Lo que más me importa es la revisión. Si no puedes leer el código que produce la IA, no deberías enviarlo. Eso no es consejo nuevo: vale para cualquier código que no hayas escrito tú, y es tan cierto con IA como cuando copiabas de Stack Overflow en 2015.