Vibecoding vs WordPress

Antes de decidir si eso es un problema para WordPress, conviene precisar el término, porque se está extendiendo deprisa y cada uno lo entiende a su manera.

Conviene además añadir una advertencia sobre la propia cifra. Distintos conjuntos de datos cuentan historias distintas. W3Techs muestra la caída y el crecimiento de la categoría sin CMS detectable, pero es una sola medición basada en su propio método de detección. Otras fuentes ponen el acento en otro sitio. Eso no cambia la dirección, porque la dirección la confirman varias observaciones independientes, pero quien esgrime un único número como prueba está simplificando. Aquí no nos interesa el porcentaje exacto, sino el fenómeno: una parte del mercado se está alejando de verdad de los CMS de siempre hacia webs generadas a partir de un prompt.

#Qué es el vibecoding

El vibecoding consiste en construir una aplicación describiéndosela a un modelo de lenguaje y aceptando lo que produzca, sin leer el código línea a línea. Las herramientas son Lovable, Bolt.new, v0 de Vercel, Replit Agent y Base44. Escribes “hazme una tienda con login y pagos” y obtienes un frontend funcional, una base de datos (normalmente Supabase) y un despliegue en cuestión de minutos.

Para un prototipo, una herramienta interna o una landing de campaña que va a vivir una semana, esto es realmente bueno. Nosotros lo usamos para nuestras propias maquetas, para enseñar al cliente una dirección antes de que nadie escriba código de producción. El problema empieza solo cuando ese resultado se pone en producción como cimiento de un negocio.

#Vibe coding vs agentic coding: la ola de herramientas de 2026

Hoy, bajo el “que lo escriba la IA” caben dos cosas distintas, y conviene separarlas antes de juzgar lo que tienes delante. Las herramientas prompt-to-app (Lovable, Bolt.new, v0, Replit Agent, Base44) generan una aplicación entera en marcha a partir de una frase y esconden el código. El agentic coding es la ola que reventó en 2026: agentes de programación que trabajan dentro de un repositorio real (Cursor, Claude Code y los nuevos IDE agénticos Google Antigravity y AWS Kiro), movidos por modelos de frontera como Gemini 3, que editan ficheros, lanzan pruebas y abren pull requests igual que lo haría un desarrollador.

Las herramientas agénticas producen un código bastante más mantenible que la generación prompt-to-app, porque operan sobre una base de código real con control de versiones y no sobre una vista previa sellada. Es una mejora real, y por eso sube el interés de búsqueda a su alrededor. Ahí también se cuela el malentendido: generar mejor código no es lo mismo que responder por él. Un IDE agéntico seguirá metiendo una clave de Supabase en el bundle, seguirá dejando una ruta de administración sin autenticación, seguirá renderizando un catálogo solo en el cliente si nadie le dice lo contrario, porque el modelo optimiza para “la función va cuando la pruebo”, no para “esto aguanta tráfico real, una auditoría y las normas de accesibilidad de la UE”. La herramienta subió un peldaño. La distancia entre una demo que funciona y un sistema en producción del que alguien responde no se ha movido. Sea cual sea la herramienta que lo construyó, las preguntas del resto de este artículo siguen siendo las mismas.

#Dónde se rompen las webs vibecodeadas

Esto no es una defensa refleja de WordPress. Es la lista de lo que aparece de verdad cuando alguien llega con un “funcionaba y ahora no”:

• Claves en el bundle. El modelo mete una clave service_role de Supabase en código que acaba en el navegador. Cualquiera con las herramientas de desarrollador la lee. A lo largo de 2025, las claves filtradas de apps hechas en Lovable y bases de datos de Supabase con Row Level Security desactivado dejaron al descubierto tablas enteras de usuarios.
• Endpoints sin autenticación. El prompt “hazme un panel de administración” genera el panel, pero la ruta /api/admin nunca comprueba quién llama. Parece que funciona porque el autor la prueba con su propia sesión iniciada.
• Sin validación ni límites. Un formulario de contacto sin rate limiting ni sanitizado se convierte en una puerta abierta al spam y a los intentos de inyección.
• Invisible en el buscador. El contenido renderizado solo en el cliente, sin renderizado en servidor, es una página vacía para el robot de Google. Un catálogo de productos que no existe en el HTML no se indexará.
• Cero vía de mantenimiento. Ni migraciones de base de datos, ni copias de seguridad, ni versionado, ni pipeline. El primer cambio serio significa reescribir, porque nadie, ni siquiera quien escribió el prompt, sabe por qué se construyó así y no de otra forma.
• Entregabilidad del correo a merced del proveedor. El formulario generado envía los correos a través de un proveedor gratuito sin SPF, DKIM ni DMARC. Las confirmaciones de pedido acaban en spam, y el dueño se entera por sus clientes, no por el panel.
• Accesibilidad ignorada. Contraste, foco, manejo con teclado, etiquetas de los campos. El modelo genera una pantalla bonita, no una interfaz accesible. En la Unión, con las exigencias de la European Accessibility Act, esto no es cosmética, sino riesgo legal.
• Dependencia de una sola plataforma. El código está soldado a un hosting de preview concreto y a una base de datos concreta. Salir de ese ecosistema, cuando las facturas empiezan a crecer con el tráfico, significa una migración para la que nadie se había preparado.

Dos casos concretos de los últimos meses. Una startup de Madrid montó un panel de clientes en Bolt.new y salió a producción en una semana. A las dos semanas descubrieron que los usuarios veían y editaban datos de cuentas ajenas, porque la clave anon de Supabase estaba en el código y el Row Level Security nunca se activó. Otra empresa, una tienda online de Barcelona, levantó su “tienda” en v0. Bonita, rápida, y a los tres meses cero tráfico desde Google, porque todo el catálogo se renderizaba solo en el navegador. Ambas webs se veían impecables el día del lanzamiento. Esa es la trampa del vibecoding: la demo es perfecta y la factura llega después.

#Invisible para Google y también para la IA

Hay ironía en esto. El vibecoding es un producto de la era de la IA, y las webs que crea suelen ser invisibles precisamente para la IA. Si el contenido aparece solo cuando arranca el script en el navegador, no lo ve ni el robot de Google ni los motores de respuesta que alimentan las AI Overviews y funciones parecidas. El modelo que resume la web lee HTML, no renderiza aplicaciones. Si el catálogo no está en el HTML, no está en la respuesta.

Es una doble pérdida. La web pierde tráfico de los resultados clásicos y a la vez queda fuera del canal nuevo, ese en el que cada vez más empieza el recorrido de compra. La visibilidad en las funciones generativas se puede medir, y de eso hablamos aparte, pero primero el contenido tiene que existir en un código que la máquina sepa leer. Una web construida solo en el cliente no pasa ese umbral.

#Por qué el código generado es difícil de mantener

El problema no se acaba en agujeros sueltos. Es cuestión de estructura. El modelo optimiza para que la pantalla funcione ahora, no para que alguien desarrolle el código dentro de seis meses. En la práctica eso deja unos cuantos patrones que se repiten: la misma lógica copiada en cinco sitios en vez de extraída una sola vez, ausencia de capas, ausencia de pruebas que avisen de que un cambio ha roto algo, y dependencias elegidas por moda y no por estabilidad.

Cada una de esas cosas por separado se puede tragar. Juntas producen un código en el que un cambio pequeño rompe algo lejano, y nadie se entera hasta que llama un cliente. Mantener una web no es ir añadiendo funciones. Es la certeza de que añadir una función no va a tumbar nada. El código generado no da esa certeza, porque nadie lo diseñó pensando en el cambio.

#Cómo reconocer una web vibecodeada

No hace falta acceso al código. Bastan unas cuantas señales:

• Ver el código fuente (Ctrl+U) muestra un <body> casi vacío y un único fichero grande de JavaScript. El contenido aparece solo cuando carga el script.
• Desactivar JavaScript deja una página en blanco en lugar de texto.
• En Google, la web no tiene más páginas que la principal, aunque en el navegador se vean muchas.
• No hay página de login en el dominio propio, o el panel se apoya por completo en un servicio externo sin permisos configurados.
• Las cabeceras de respuesta apuntan a un hosting de tipo preview (Vercel, Netlify) sin capa de aplicación propia.

Ninguno de estos puntos por sí solo es una sentencia. Juntos dibujan una web que salió de un prompt y nunca recibió unos cimientos.

#Vibecoding vs WordPress en producción

La tabla no dice que el vibecoding sea malo. Dice para qué sirve cada herramienta. Para probar una idea en un fin de semana, el vibecoding gana sin discusión. Para una web que debe facturar dentro de un año, ganan los cimientos.

#Qué comprueba de verdad una auditoría de una web hecha por IA

Cuando nos llega una web así, no empezamos reescribiendo. Empezamos por el diagnóstico, porque “funcionaba y ahora no” suele tener varias capas. El orden es casi siempre el mismo:

1. La seguridad primero. Si en el código que se carga en el navegador hay claves que no deberían estar ahí. Si la base de datos tiene activadas las reglas de acceso. Si los endpoints comprueban permisos. Eso decide si la web se puede dejar en línea con seguridad mientras dura la reparación.
2. Renderizado e índice. Si el contenido está en el HTML o solo en el JavaScript. Cuántas páginas ve Google de verdad. Si hay redirecciones, canónicas y mapa del sitio. Eso responde a por qué no llega el tráfico orgánico.
3. Datos y continuidad. Dónde están los datos, si hay copias, si se pueden exportar. Sin esto, cualquier decisión posterior es arriesgada.
4. Decisión: salvar o reescribir. Solo ahora. A veces basta con añadir la capa que faltaba. A veces sale más barato y más seguro llevar el contenido a unos cimientos que se puedan mantener. La auditoría dice cuál de esas dos vías es más barata en el año, no solo esta semana.

Lo importante es que esto no es trabajo para otro prompt. Un prompt no lee el código ajeno con conciencia de las consecuencias. Un ingeniero sí.

#Por qué esto no es el fin de WordPress

La cuota cae porque la parte baja del mercado, esas webs sencillas que antes se montaban en WordPress “porque sí”, se está pasando de verdad a la IA. Y está bien. Era la parte menos rentable y más desechable del mercado. WordPress pierde el trabajo con el que, de todas formas, nadie ganaba dinero.

Queda el resto: tiendas WooCommerce con facturación real, webs multiidioma con hreflang correcto, proyectos sujetos al RGPD y a otros requisitos de cumplimiento, trabajos pensados para durar cinco años y sobrevivir a una docena de actualizaciones. Ahí el vibecoding no llega, porque ahí el objetivo no es generar una pantalla. Es un cimiento: seguridad, rendimiento medible en Core Web Vitals, mantenimiento y responsabilidad sobre lo que pase a las dos de la madrugada en plena punta del Black Friday.

WordPress no gana por estar de moda. Gana porque tiene dos décadas de ecosistema, una vía de mantenimiento predecible y una persona que sabe por qué algo se construyó así y no de otra manera.

#Cuándo WordPress tampoco es la respuesta

Para ser justos: no todo proyecto es WordPress. Si estás construyendo una aplicación en tiempo real, un producto que se apoya por completo en una sola interfaz de aplicación, un panel con lógica pesada en el cliente o algo que por naturaleza es una aplicación y no un sitio de contenido, otras herramientas serán mejores. WordPress lleva de maravilla contenido, tienda, integraciones y visibilidad en el buscador. No es un martillo universal, y tratarlo como tal acaba tan mal como meter una tienda en un prototipo vibecodeado.

La diferencia está en que elegir entre WordPress, una aplicación a medida u otra cosa es una decisión arquitectónica que alguien toma a conciencia, conociendo las consecuencias. El vibecoding no toma esa decisión. Genera lo que estadísticamente encaja con el prompt y deja las consecuencias para después.

#Quién responde cuando algo sale mal

Esa pregunta suele llegar tarde, porque llega solo cuando algo ya ha salido mal. Un prompt no tiene guardia. El modelo no te devuelve la llamada cuando un sábado por la noche la tienda deja de aceptar pagos. La web generada no tiene un responsable técnico que conozca su historia y sepa dónde mirar.

Un cimiento no es solo código. Es alguien que asume la responsabilidad de las consecuencias. En una época en la que cada vez se puede generar más, es precisamente la responsabilidad la que se vuelve un bien escaso. No se trata de no usar IA. Nosotros la usamos a diario. Se trata de que entre la pantalla generada y el negocio en marcha haya una persona que entienda la diferencia y responda de lo que llega a producción.

#Cuándo el vibecoding tiene sentido y cuándo llamar a un senior

En corto: para un prototipo, un MVP, una herramienta interna o una landing de campaña, vibecodea sin miedo. Rápido, barato, suficiente. Para una tienda, una web corporativa o cualquier cosa que tenga que dar de comer y seguir existiendo dentro de un año, hacen falta cimientos, no una pantalla generada.

Queda la pregunta del coste, que es la que más se repite: si la IA lo hizo en un día, la reparación debería ser barata. No siempre. El esfuerzo depende de lo hondo que lleguen los problemas. Si solo falta la capa de seguridad y un renderizado correcto, y el contenido y los datos se pueden trasladar, el trabajo es acotado y previsible. Si no hay cimiento ninguno y la web ya ha reunido clientes, datos y posiciones en Google, migrar conservando todo eso es un proyecto mayor que construir de cero sobre terreno limpio. Por eso la auditoría arranca por el diagnóstico y el presupuesto es siempre individual: solo después de comprobar qué hay que salvar se puede decir con honestidad qué vía sale más barata en el año.

Si ya tienes una web hecha por IA y algo empieza a fallar, desde filtraciones hasta pérdida de tráfico o el clásico “no se puede ampliar”, suele tener arreglo, pero no con otro prompt. Rescatamos webs hechas por IA: auditoría de seguridad, SEO desde cero y una decisión sobre qué reescribir y qué salvar. Lo hace un desarrollador que lee el código que nadie había leído antes.