Claude Code escribió la mayoría del código de una tienda WooCommerce real: qué falló

Un desarrollador ha construido en solitario la tienda online de una marca de ropa femenina sobre WordPress y WooCommerce, con Claude Code escribiendo la mayor parte del código. El inventario vive en 1C, el ERP y sistema de punto de venta que domina el comercio ruso, que solo se comunica hacia fuera por XML. El autor cuenta lo que se rompió por el camino y avisa de que esto no es la versión de vídeo promocional: es la de los bugs.

El presupuesto descartaba la respuesta por defecto del mercado: Bitrix, el CMS comercial dominante allí, que trae módulo de intercambio de stock y una red de integradores que ya saben facturarlo. Licencia, renovación anual y honorarios se comían casi el presupuesto entero de esta otra obra antes de escribir la primera funcionalidad. A eso se sumaba el diseño: la clienta traía un prototipo en React con cuatro colores, dos tipografías y radio de borde cero en todas partes, y lo quería copiado, no aproximado. Meter eso en un tema prefabricado cuesta más que escribirlo desde cero.

Los requisitos tampoco se encogieron: stock en tiempo real por cada par talla-color, pago con tarjeta y pago instantáneo por un procesador local, envío por mensajería, banner de cookies y casillas de consentimiento para la ley de privacidad local, y seguimiento de eventos de comercio electrónico.

El stack

Tema de bloques (FSE) hecho desde cero, sin ningún plugin de page builder: cada uno de esos añade peso, ata el proyecto al calendario de releases de otro y mete una capa entre el diseño y el código que controlas. Los tokens de diseño van a theme.json, el archivo nativo de WordPress, que genera las variables CSS por su cuenta; ninguna hoja de estilos toca un valor crudo. WooCommerce Blocks para el carrito, la Store API para el mini carrito, PHP 8 con una estructura inc/ modular y campos personalizados registrados en código en lugar de desde el panel. El frontend va con ES modules, sin jQuery, con IntersectionObserver para las animaciones y history.pushState para el estado de los filtros. La sincronización con el ERP usa el protocolo CommerceML.

Lo que evitó el desastre

Tres cosas, y el autor dice que la primera importó más de lo que esperaba.

Claude Code lee un archivo de instrucciones, CLAUDE.md, al arrancar cada sesión. Ahí metió el sistema de diseño como prohibiciones planas: exactamente cuatro colores, ningún hex crudo en el repositorio, radio cero, espaciado solo desde la escala de 8 píxeles. Dejar a un LLM suelto hace que improvise, y que improvise justo como destroza un sistema de diseño estrecho. Con la regla escrita, cuando el agente necesita un tono nuevo no busca un hex: lo deriva con oklch() de un token existente.

La memoria fue lo segundo, porque el contexto del agente se reinicia y el proyecto no: duró meses. Cada lección real acabó en un markdown que el agente relee en la sesión siguiente. "WooCommerce Blocks no carga jQuery", "los exports delta del ERP borran variantes de producto en silencio".

Y la verificación. El agente tiene Playwright por MCP: abre la página, recorre el flujo, hace la captura y la compara con el prototipo. La regla es que no hay "arreglado" sin una comprobación real detrás.

El propio autor lo deja claro: esto no es menos trabajo que escribir el código a mano. Es la misma cantidad de pensamiento, comprimida en revisión en lugar de en tecleo. Lo que cambia no es el esfuerzo, es dónde se pone.