Vibe coding en un WordPress en producción sin herramientas de pago
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
Se están promocionando muchísimas herramientas para hacer "vibe coding" en WordPress, así que pensé en probar Claude Code a fondo para ver si me estoy perdiendo algo.
Primera regla: no comprar nada para hacerlo. Ni maquetador, ni tema premium, ni servicio de staging, ni plugin de despliegue, ni plugin de sincronización. El tema es Twenty Twenty-Five, el gratuito que viene por defecto. Lo único que pago es la suscripción a Claude (que de todas formas ya tengo :-) ).
Esa es en realidad la idea de este artículo. No necesitas las herramientas caras. Necesitas tres cosas:
- entender cómo funciona WordPress de verdad - ¡hecho!
- conocer Claude Code lo bastante bien como para configurarlo como toca - ¡hecho!
- algo de creatividad - ¡hecho!
El 90% del CSS lo escribió Claude Code, y no voy a fingir lo contrario. Esas tres cosas son las que hicieron que fuera seguro, y de eso va el resto del artículo.
Dónde estaba el sitio
El sitio es yuvalk.com, el portfolio de mi hijo, director y guionista que estudia en la ESCAC (una de las mejores escuelas de cine que hay). Contenido en español, una instalación de WordPress pequeña y normal: un tipo de contenido propio para los proyectos (un corto, un vlog), una taxonomía para las tres secciones.
Y, como casi todos los sitios que crecen durante unos años, su código propio vivía donde no debía.
Yo mismo había pegado el PHP (un bloque para las tarjetas de sección, un orden personalizado, dos shortcodes, el snippet de analítica) en el functions.php del tema padre. Los estilos estaban repartidos por todas partes, incluidos diez snippets en un plugin de CSS.
Las dos cosas funcionaban. Las dos estaban a una actualización del tema de desaparecer, y los snippets vivían en una tabla de la base de datos donde ni git ni un agente podían verlos.
Pon a un agente de IA a trabajar en un sitio así, dile "haz que la portada parezca un cine", y editará encantado el functions.php del tema padre, porque ahí es donde está el código. No sabe que esa carpeta es una mina.
Tú sí, si sabes cómo funciona WordPress. Ese es el primer ingrediente.
Primer ingrediente: saber WordPress
Casi todo lo que la gente compra en forma de herramienta aquí, WordPress ya lo hace, o lo hacen unas pocas líneas de script.
Una copia local en vez de un servicio de staging
Una copia completa de producción, restaurada en MAMP en mi Mac. Eso es solo porque estoy acostumbrado a trabajar así; puedes usar lo que tú uses normalmente.
La regla desde el primer minuto: la copia va en un solo sentido. Producción baja a local. Nada vuelve a subir por ese camino, nunca, porque en el momento en que sobrescribes producción con una copia completa pierdes todo lo que alguien haya editado allí desde que lo bajaste.
Un tema hijo en vez de un tema premium o un maquetador
El tema hijo viene de serie en WordPress y no cuesta nada, y si quieres ver lo básico y antiguo que es el concepto, aquí estoy en la WordCamp Sevilla 2012 hablando de ello :-)
A este lo llamé yuvalk y todo se movió ahí: el PHP a un único archivo include, los diez snippets a una sola hoja de estilos (207 líneas) y las plantillas que se habían editado en el Editor del sitio a archivos de verdad. Los snippets pasaron a Borrador, y el plugin de CSS ya no tiene nada que hacer.
Un detalle que merece la pena enseñar. El tema padre en producción todavía tenía el código viejo dentro, y definir dos veces la misma función PHP es un error fatal. Así que el tema hijo se salta su propia copia mientras exista la vieja:
add_action( 'after_setup_theme', function () {
if ( function_exists( 'show_genre_type_statement' ) ) {
return; // the old copy in the parent theme is still there
}
require get_theme_file_path( 'inc/site-features.php' );
}, 20 );Subes el tema hijo, lo activas, actualizas el padre (que borra el código viejo) y el hijo toma el relevo solo. Sin caída, sin editar archivos a mano en el servidor. La guarda la propuso Claude. La leí dos veces antes de fiarme, y solo pude hacerlo porque conozco el orden de carga.
Scripts de WP-CLI en vez de un plugin de sincronización
La mitad de lo que significa "rediseñar la portada" no son estilos. Es contenido: poner el reel nuevo junto a la bio, quitar "(Inacabado)" del título de una película ahora que está terminada, añadir dos nombres a un crédito. Eso vive en la base de datos. Podrías repetir cada cambio a mano en producción. Uno de ellos te saldría un poco mal.
WP-CLI es gratuito y está instalado en muchos hostings compartidos, DreamHost incluido. Así que cada cambio se convirtió en un pequeño script en una carpeta db-changes, todos con la misma forma. Lee el estado actual. Si el cambio ya está hecho, dilo y para. Si el estado no es el que el script espera, para y no toques nada. Si no, aplícalo y di lo que has hecho.
$title = get_post_field( 'post_title', 210, 'raw' );
if ( 'El Murmullo del Agua' === $title ) {
WP_CLI::success( 'Already done. Nothing to do.' );
return;
}
if ( 'El Murmullo del Agua (Inacabado)' !== $title ) {
WP_CLI::error( 'Unexpected title: "' . $title . '". Nothing changed.' );
}Lo ejecutas en local, miras la página y luego ejecutas el mismo archivo en producción por SSH. Seis scripts en dos días, cada uno seguro de ejecutar dos veces, cada uno en git al lado del CSS que le corresponde. Esta es la parte que no había hecho antes, y la que mantendría incluso sin agente.
Segundo ingrediente: conocer Claude Code
El agente es tan seguro como lo que lo rodea. Nada de esto es un producto. Es git, rsync y un archivo de texto.
Un repo que versiona tu código, no WordPress
El .gitignore lo ignora todo y luego deja entrar solo lo que es nuestro:
/*
!/.gitignore
!/CLAUDE.md
!/bin/
!/db-changes/
!/docs/
!/wp-content/
/wp-content/*
!/wp-content/themes/
/wp-content/themes/*
!/wp-content/themes/yuvalk/El núcleo, los plugins, las subidas y wp-config.php no son tuyos, contienen secretos y no pintan nada en git. Lo que queda es lo bastante pequeño como para leerlo de una sentada, y eso importa cuando tu colaborador puede reescribir un archivo más rápido de lo que tú lo lees.
Un script de despliegue en vez de un servicio de despliegue
Un script corto en bash, bin/deploy. Sin argumentos hace un rsync en modo simulación contra producción y lista lo que cambiaría. Con --go sube la carpeta del tema hijo, y solo esa carpeta, y luego vacía la caché de páginas. Se niega a ejecutarse mientras el tema tenga cambios sin commit, así que producción siempre coincide con un commit que puedes señalar:
if [[ -n "$(git status --porcelain -- wp-content/themes/yuvalk)" ]]; then
echo "Uncommitted changes in the theme. Commit first."
exit 1
fiEsa negativa convierte "el agente ha subido algo" en "el agente ha subido el commit 4bd70ec, y aquí está el diff". Y la regla de que solo despliega cuando yo lo pido, con vista previa primero, está escrita donde Claude la lee en cada sesión.
Un CLAUDE.md que aprende
Un CLAUDE.md en la raíz del sitio: dónde vive cada cosa, el modelo de datos, las reglas (nunca editar el núcleo, los plugins ni el tema padre; solo URLs relativas; commit después de cada cambio que funcione).
Lo útil es lo que se fue acumulando. El wp normal no llegaba a la base de datos de MAMP, así que un pequeño wrapper que usa el PHP de MAMP fue a parar a bin y la regla al archivo. Las plantillas editadas en el Editor del sitio se guardan en la base de datos y pisan los archivos sin avisar, así que eso también entró, con el comando para comprobarlo. Cada vez que el agente tropezaba, el arreglo acababa en CLAUDE.md, y la segunda sesión fue claramente más rápida que la primera.
Tercer ingrediente: un poco de creatividad
Esta es la parte divertida, y aquí ninguna herramienta te ayuda de todas formas.
Las tarjetas de sección como pantallas de cine. Demasiado pesado. Pantallas de tele finas y modernas en su lugar. El reel recibe el mismo marco. Un poco de margen lateral. El bloque de testimonio que sostenía la bio, texto de doce píxeles junto a una foto redonda, sustituido por un nombre en condiciones, una línea con el rol y el párrafo, para que aguante al lado del vídeo.
Cinco commits en la segunda sesión, cada uno con vista previa contra producción antes de subir.
Algunas ideas que todavía no construimos (clips en bucle en vez de imágenes fijas, un preloader, inspiradas en un sitio que me gustó pero hechas a nuestra manera) fueron a un archivo de docs con lo que las bloquea: clips cortos y mudos por proyecto, que todavía no existen. Aparcadas, no perdidas.
La creatividad también cuenta en la fontanería. Una guarda que deja convivir dos copias del mismo código durante diez minutos. Un cambio de contenido que comprueba antes de escribir. Eso no te lo vende nadie. Sale de saber cómo encajan las piezas y de preguntarte "¿qué es lo más sencillo que no puede salir mal aquí?"
Para terminar
Pasé doce años en una empresa que vende un plugin de pago para WordPress, así que no tengo nada en contra de pagar por software :-) Pero paga por lo que hace algo que tú no puedes hacer.
Antes de comprar una herramienta, comprueba si WordPress ya lo hace. El agente no necesita el maquetador. Necesita a alguien que sepa qué carpeta es una mina, cómo montarlo para que una suposición equivocada te cueste un git revert y no un sábado, y cómo debería verse el sitio de verdad.
Entiende WordPress. Aprende a usar tu agente. Sé creativo y luego dale caña.