18 meses de vibe coding WordPress: la charla de Marsland

En pocas palabras: No hay un plano fijo: Jamie Marsland mostró en «There Is No Blueprint» (WordPress Day for AI Faro 2026, 28/10/2026) que 18 meses de vibe coding en WordPress van de un juego de tipografías a un plugin que WordPress.com terminó forkeando, usando Cursor o Claude Code.

Jamie Marsland, Head of WordPress.com YouTube y fundador de Pootlepress, presentó «There Is No Blueprint: 18 months of vibe coding WordPress» en el WordPress Day for AI Faro 2026. La charla repasa año y medio de vibe coding dentro de WordPress: arranca en un juego de tipografías y termina en un plugin que WordPress.com terminó forkeando. El video quedó publicado en WordPress.tv el 28 de octubre de 2026.

El vibe coding en WordPress es describir en lenguaje natural lo que querés construir (un bloque, un plugin, una app liviana) y dejar que una IA como Cursor o Claude Code genere el código, probando y corrigiendo hasta que funcione. No hace falta saber programar, pero sí entender en qué capa de WordPress encaja el problema: editor, API REST, base de datos o panel de administración. Esa es, de hecho, la parte que más se presta a confusión y la que desarrollamos a continuación con un criterio de decisión concreto.

¿Qué es el vibe coding y por qué llegó a WordPress?

El vibe coding es describirle a una IA el resultado que querés en lenguaje de todos los días y dejar que ella escriba el código, mientras vos testeás e iterás hasta que anda. El término agarró vuelo rápido en WordPress por una razón concreta: el CMS tiene piezas bien delimitadas (bloques, plugins, la API REST) donde una IA puede apuntar sin tener que tocar todo el sistema de una.

Ahora bien, no es magia. En su guía de junio de 2026, Marsland insiste en que el mayor desbloqueo no es el prompt perfecto, sino entender qué tipo de cosa estás construyendo. Si le pedís a la IA «construí una feature» sin esa aclaración, ella tiene que adivinar dónde va, y esa adivinanza suele salir mal.

Criterio de decisión: en qué capa de WordPress encaja tu idea

Antes de escribir el primer prompt, conviene responder una sola pregunta: ¿qué comportamiento necesito cambiar? La respuesta suele ubicar el proyecto en una de estas cinco categorías, y acertar la categoría reduce casi todo el riesgo de que la IA construya algo que no sirve:

• ¿Necesitás que el visitante interactúe sin recargar la página? (búsquedas instantáneas, filtros, calculadoras) → la pieza correcta suele ser la Interactivity API, no un plugin completo.
• ¿Necesitás que alguien sin perfil técnico edite contenido repetible? (testimonios, FAQs, secciones de precios) → eso es territorio de bloques de Gutenberg, no de código a medida en cada página.
• ¿Necesitás que WordPress converse con otra app o automatización? (publicar desde una app externa, sincronizar datos) → eso pasa por la API REST y, normalmente, application passwords.
• ¿Necesitás una app liviana sin backend complejo? (notas, borradores, planificadores) → puede alcanzar con local storage del navegador y publicar después vía REST API.
• ¿Necesitás cambiar el comportamiento general del sitio? (reglas de WooCommerce, permisos, automatizaciones de administración) → ahí sí corresponde un plugin, con todo lo que eso implica en materia de revisión antes de producción.

La utilidad de este filtro no es teórica: cada categoría mal elegida se traduce en código que funciona en la demo y se cae en producción, que es justamente el problema que Marsland documentó durante 18 meses.

Ejemplo hipotético: aplicar el criterio a un caso ficticio

El siguiente caso es hipotético, no corresponde a un hecho real ni a un proyecto documentado en las fuentes: sirve solo para ilustrar cómo se usaría el criterio de decisión anterior.

Imaginemos un sitio de WooCommerce donde alguien, sin perfil técnico, quiere que los visitantes puedan filtrar productos por precio sin que la página recargue. Siguiendo el criterio de arriba:

1. Identificar la capa: el pedido es «interacción sin recarga», así que la pieza indicada es la Interactivity API, no un plugin nuevo desde cero.
2. Prompt inicial: algo del tipo «construí este filtro de precio usando la WordPress Interactivity API, simple, mantenible, sin dependencias extra».
3. Probar en aislado: antes de tocar el sitio real, se prueba en un entorno local tipo WordPress Studio o en un staging, nunca directo en producción.
4. Verificar: si el resultado final empaqueta algo como plugin, se corre Plugin Check antes de subirlo, y los warnings se le devuelven a la IA para que los corrija.
5. Iterar: recién ahí, con el resultado ya probado, se repite el ciclo prompt → build → test → refine hasta que el filtro funcione sin romper otras páginas de la tienda.

Este recorrido ficticio resume, en miniatura, lo que la charla de Marsland describe a escala real: el salto de la demo al release completo no ocurre por pedirle mejor a la IA, sino por meter pasos de verificación entre cada iteración.

¿Qué contó Jamie Marsland en «There Is No Blueprint» en WordPress Day for AI Faro 2026?

Marsland presentó un repaso de 18 meses vibe-codeando dentro del ecosistema WordPress, según la ficha oficial publicada en WordPress.tv. El recorrido arranca en algo chico y casi lúdico (un juego de tipografías) y escala hasta un plugin que WordPress.com decidió forkear para uso propio. La ficha oficial no detalla el nombre de ese plugin ni muestra la demo puntual; eso quedará claro cuando circule más material de la charla.

¿Quién es este Marsland que habla con tanta propiedad del tema? Alguien con kilometraje real en WordPress: según su perfil de WordCamp US 2026, tiene más de 200.000 suscriptores en YouTube, fundó Pootlepress (plugins usados por miles de sitios) y entrenó a más de 5.000 personas en WordPress durante la última década. No es un influencer de IA de paso por el tema: viene del lado del desarrollo de WordPress desde hace rato.

Te puede servir nuestra cobertura de desarrollar temas WordPress con IA y GitHub para ver cómo se aplica una lógica similar en otro tipo de proyecto.

¿Qué significa llevar un proyecto vibe-codeado a un ciclo de release completo?

Significa someter el código que generó la IA al mismo proceso que cualquier feature tradicional de WordPress. La ficha de la charla lo nombra de forma explícita: pruebas de regresión, documentación de soporte, videos y testeo con usuarios reales. Esa fue, según lo que describe la propia presentación, la etapa final de los 18 meses: pasar de un prototipo gracioso a algo que WordPress.com pudo sostener en producción.

Ese salto es el que casi nadie cuenta cuando habla de vibe coding. Subís una idea, la probás en local, funciona bárbaro, te entusiasmás, lo mandás a un entorno real y ahí aparecen los problemas que el prompt original nunca contempló: compatibilidad con otros plugins, edge cases que ningún usuario de prueba tocó, documentación que no existe porque nadie la escribió. La guía de Pootlepress propone un flujo concreto para esto: construir, testear en WordPress Studio, correr Plugin Check, y volver a pasarle los warnings a la IA para que los corrija. Nada sofisticado, pero funciona como filtro antes de tocar un sitio real, tal como se ve en el ejemplo hipotético de más arriba.

Si el plan es llevar algo vibe-codeado a un sitio en producción, conviene hacerlo primero en un entorno de staging y recién después subirlo a un hosting WordPress como el de Donweb, donde al menos la infraestructura no es la variable que te va a romper el experimento.

¿Cuáles son los límites y fracasos del vibe coding que muestra la charla?

La propia descripción de la charla habla de «demos, fracasos y preguntas», no de una fórmula resuelta. Marsland no presenta el vibe coding como un proceso cerrado: después de 18 meses, sigue sin existir un blueprint (de ahí el título de la charla) que diga cómo pasar de una idea vibe-codeada a un producto WordPress confiable sin tropezones en el camino. Tema relacionado: todo sobre wp-community y el core de WordPress.

En su guía, Marsland lo resume con una frase que vale citar tal cual: «AI loves complexity. You ask for something simple. It quietly builds a tiny version of NASA» («la IA ama la complejidad: le pedís algo simple y sin que te dés cuenta te construye una versión mini de la NASA»), escribió el fundador de Pootlepress en su sitio.

¿Es seguro mandar a producción código que generó una IA sin revisarlo? No. La propia guía lo marca como no negociable: correr Plugin Check siempre, porque el código generado por IA puede verse prolijo y tener problemas de seguridad, compatibilidad o performance que no se ven a simple vista. Ojo: este blog no cubre temas de hardening ni vulnerabilidades en profundidad, para eso está el blog hermano seguridadenwordpress.com.

¿Qué consecuencia práctica tiene esto para la educación de desarrolladores WordPress?

La consecuencia directa, según plantea la propia charla, es que la educación para desarrolladores WordPress tiene que enseñar menos sintaxis y más criterio. En qué capa de WordPress encaja un problema, cómo testear lo que escupe una IA, cómo iterar en vez de esperar el prompt perfecto a la primera. Esto se conecta con lo que analizamos en cómo armar una landing page en WordPress.

La guía de Marsland describe el flujo real como «idea → prompt → build → test → refine → repeat», no como «un prompt → resultado perfecto». Y agrega algo interesante: la gente que mejores resultados obtiene con vibe coding no es necesariamente la más técnica, es la que mejor explica problemas, simplifica ideas y testea rápido. Eso cambia bastante el perfil que un curso o un bootcamp de WordPress debería formar de acá en adelante.

Errores comunes al vibe-codear en WordPress

• Pedir «una feature» sin especificar la capa. Si no le decís a la IA si es un bloque, un plugin o algo vía REST API, ella adivina dónde va, y esa adivinanza suele salir mal.
• Saltarse Plugin Check antes de producción. El código generado por IA puede verse bien y tener fallas que solo aparecen al correr el análisis.
• Esperar el prompt perfecto en una sola pasada. El flujo real es iterativo: construir, probar, corregir, repetir, no una sola consulta mágica.
• Probar directo en el sitio real. Un entorno aislado como WordPress Studio existe justamente para romper cosas sin consecuencias.
• Dejar que la IA complique de más. Pedís algo simple y, si no aclarás «mantené esto simple», la IA suele construir una versión diminuta de un sistema enterprise.

Preguntas Frecuentes

¿Qué es el vibe coding en WordPress?

Es describirle a una IA en lenguaje natural lo que querés construir dentro de WordPress (un bloque, un plugin, una integración vía REST API) y dejar que ella genere el código, iterando con pruebas hasta que funciona. No requiere saber programar, pero sí entender en qué parte del sistema WordPress encaja el problema. Mirá también la vulnerabilidad XSS en AMP for WP.

¿Quién es Jamie Marsland?

Es Head of WordPress.com YouTube en WordPress.com, fundador de Pootlepress y una voz conocida en la comunidad WordPress, con más de 200.000 suscriptores en su canal según su perfil de WordCamp US 2026. Entrenó a más de 5.000 personas en WordPress durante la última década.

¿Qué plugin de vibe coding forkeó WordPress.com?

La ficha oficial de la charla en WordPress.tv menciona que WordPress.com forkeó un plugin surgido del proceso de vibe coding de Marsland, pero no especifica su nombre. En probar cambios en un entorno de staging profundizamos sobre el paso previo a llevar cualquier plugin vibe-codeado a producción.

¿Es seguro usar código generado por IA en un sitio WordPress en producción?

No sin revisión previa. La guía de Marsland recomienda correr siempre Plugin Check antes de subir código generado por IA a producción, porque puede contener problemas de seguridad, compatibilidad o performance que no se detectan a simple vista. Lo complementamos en el fallo CSRF crítico en Newsletters.

¿Qué errores o fracasos tuvo el proceso de vibe coding en WordPress?

La propia descripción de la charla habla de «demos, fracasos y preguntas» a lo largo de 18 meses, sin presentar un proceso resuelto. El título «There Is No Blueprint» resume justamente eso: todavía no existe una fórmula estándar para pasar de una idea vibe-codeada a un producto WordPress confiable.

Conclusión

Lo que cambia con esta charla no es que el vibe coding «funcione» en WordPress, sino que alguien con credenciales reales en la comunidad lo documentó durante 18 meses enteros, con fracasos incluidos. Eso le da un piso de evidencia que antes no estaba: no es una anécdota de un prompt que salió bien una vez, es un recorrido con release completo, pruebas de regresión y testeo de usuarios.

Para cualquiera que esté evaluando meter IA en su flujo de desarrollo WordPress, el criterio práctico es simple: primero identificá la capa (Interactivity API, bloque, REST API, local storage o plugin), después tratá todo código vibe-codeado como código de un junior que nunca viste trabajar. Lo revisás, lo testeás en un entorno aislado, corrés las herramientas de verificación disponibles (Plugin Check, como mínimo) y recién después lo subís a un sitio real. La velocidad que promete la IA solo vale algo si no te explota en producción.

Fuentes

• WordPress.tv – «There Is No Blueprint: 18 months of vibe coding WordPress», charla de Jamie Marsland en WordPress Day for AI Faro 2026
• Pootlepress – «How to Vibe Code in WordPress for Non-Techies», guía de Jamie Marsland (junio 2026)
• WordCamp US 2026 – Perfil de speaker de Jamie Marsland