Cuando alguien se plantea correr IA en local, casi todos los artículos empiezan por el hardware: que si gráficas, que si gigas de RAM, que si tal procesador. Pero esa es la pregunta equivocada para empezar. La buena es: ¿qué quieres que haga la IA? Porque de ahí sale el tamaño de modelo que necesitas, y solo entonces tiene sentido hablar de equipo.

Este artículo va de eso: qué tipo de modelo sirve para qué, cómo de listo es cada franja, y qué máquina te pide. Sin humo y con modelos concretos que la comunidad ya ha probado.

La idea de fondo en dos minutos

Un modelo de lenguaje hay que cargarlo entero en memoria para usarlo. Se mide en parámetros: 7B, 14B, 32B, 70B... (la "B" es de miles de millones). Más parámetros = más capacidad de razonamiento y conocimiento, pero también más memoria y más lento.

Lo que hace todo esto viable en un equipo normal es la cuantización: reducir la precisión de los números internos del modelo para que ocupe menos. El formato más usado, Q4_K_M, recorta el tamaño casi a la mitad con una pérdida de calidad mínima en modelos medianos y grandes. Es el punto dulce; úsalo por defecto.

Regla de bolsillo para estimar lo que ocupa un modelo en Q4: GB ≈ parámetros × 0,6. Un 32B ocupa unos 19 GB. A eso súmale el contexto (la memoria de la conversación o de los ficheros que le das a leer), que añade entre 2 y 10 GB según lo largo que sea.

Y el detalle que casi todos olvidan: tu sistema operativo y tus aplicaciones también necesitan RAM. Si le das toda la memoria al modelo, el equipo se arrastra. Reserva siempre un mínimo de 8 GB para el sistema, y mejor 16 GB si vas a trabajar mientras (navegador, editor y modelo a la vez). La cuenta real es: modelo + contexto + colchón de sistema.

Qué hace cada franja de modelo y para qué te sirve

Aquí está lo importante. No es "cuánto ocupa" sino "para qué me vale de verdad".

Modelos de 7B — para tareas acotadas

Es el escalón de entrada. Sirven para cosas concretas y de bajo riesgo: autocompletar código, reformular un texto, resúmenes cortos, clasificar, responder preguntas sencillas. Para programación seria se quedan cortos —cometen errores y pierden el hilo en cuanto la cosa se complica—, pero para trastear, aprender y tareas repetitivas cumplen.

Para qué lo querrás: un asistente ligero siempre disponible, autocompletado, pequeñas automatizaciones de texto.

Modelos probados por la comunidad: Llama 3.1 8B, Qwen2.5 7B, y para código Qwen2.5-Coder 7B.

Equipo: cualquier portátil moderno con 16 GB de RAM.

Modelos de 14B — el todoterreno ligero

Salto notable en coherencia. Ya generan código decente para funciones y componentes concretos, redactan bien y aguantan más contexto sin despistarse. Van rápidos y entran en equipos de gama media. Buena opción si priorizas velocidad y tu trabajo no exige el máximo de calidad en cada respuesta.

Para qué lo querrás: generación de código de tareas concretas, redacción, un asistente más capaz, trabajo cotidiano sin grandes exigencias.

Modelos probados por la comunidad: Qwen2.5-Coder 14B (muy bueno para su tamaño), Phi-4 14B, DeepSeek-Coder-V2 Lite (16B).

Equipo: 24-32 GB de RAM.

Modelos de 32B / 35B — el punto dulce del trabajo serio

Esta es la franja que recomendaría a la mayoría de la comunidad. Un buen modelo de 32B especializado en código genera código sólido en PHP, JavaScript, HTML y CSS, entiende proyectos de tamaño medio, refactoriza con criterio y funciona bien como motor de agentes (Claude Code, OpenCode o similares apuntando a tu modelo local). La calidad ya es de verdad, no un apaño.

Aquí Q4_K_M brilla: la pérdida frente a versiones más pesadas es casi imperceptible, porque el modelo tiene margen de sobra para absorber la cuantización. Y un consejo práctico: para código, más contexto rinde mejor que más bits de precisión. Quédate en Q4 y usa la RAM que ahorras para darle al modelo más ventana donde leer tu proyecto.

Para qué lo querrás: desarrollo serio en tu máquina, agentes de código, asistente principal de trabajo, análisis de proyectos medianos.

Modelos probados por la comunidad: Qwen2.5-Coder 32B (la referencia para código abierto en esta franja), GLM-4 32B (más generalista, buen complemento), Gemma 2 27B.

Equipo: 48 GB de RAM. Si tienes que elegir un solo objetivo, apunta aquí.

Modelos de 70B — calidad alta para quien la necesita

Más criterio en tareas complejas, ambiguas o de razonamiento. La diferencia se nota en problemas difíciles, no tanto en generar código rutinario del día a día. El salto de hardware es grande: necesitas 96 GB de RAM, lo que ya implica un equipo dedicado. Tiene sentido si montas un servidor de inferencia o si tu trabajo justifica esa calidad extra.

Para qué lo querrás: razonamiento complejo, tareas donde el 32B se queda corto, un servidor de IA personal de alta calidad.

Modelos probados por la comunidad: Llama 3.3 70B, Qwen2.5 72B.

Equipo: 96 GB de RAM.

Modelos de 120B+ — territorio servidor

Calidad cercana a los modelos comerciales en muchas tareas, pero exige 128 GB de RAM y una máquina pensada para ello. Para la mayoría de freelances y agencias pequeñas es más capacidad de la que se aprovecha a diario, salvo que la privacidad absoluta de datos sensibles sea un requisito de negocio (datos de clientes, información fiscal), en cuyo caso correrlo 100% en local sí es un argumento de peso.

Para qué lo querrás: máxima calidad en local, privacidad total para datos delicados, servidor de equipo.

Modelos probados por la comunidad: gpt-oss 120B, Qwen3 de gran formato.

Equipo: 128 GB de RAM.

Tabla resumen

RAM aconsejada en Q4_K_M, contexto de trabajo razonable y colchón de sistema ya incluido:

> En equipos de memoria unificada (Mac Apple Silicon, mini PC con AMD Ryzen AI Max) la RAM del sistema y la del modelo salen del mismo sitio, por eso el colchón es innegociable. En un PC con gráfica dedicada la limitación es la VRAM de la tarjeta, que en consumo rara vez pasa de 24 GB — por eso los equipos de memoria unificada se han vuelto tan atractivos para correr modelos grandes en local.

Recomendación según lo que eres

"Solo quiero probar y aprender." Portátil con 16 GB y un modelo de 7B-14B. Cero inversión, empiezas hoy.

"Quiero usarlo en serio para programar, en mi máquina." Apunta a 48 GB y un 32B tipo Qwen2.5-Coder. Es el equilibrio realista entre calidad, velocidad y coste, y donde el local empieza a competir de verdad con la nube.

"Quiero un servidor de IA dedicado, encendido siempre, sin tocar mi equipo de trabajo." Un mini PC con AMD Ryzen AI Max+ 395 y 128 GB (de los que ~96 GB se asignan a la GPU) te permite correr un 70B con contexto largo y un modelo ligero para un asistente, a la vez, con bajo consumo para tenerlo 24/7. Hoy es la opción más interesante en relación capacidad/precio para uso local serio.

Para empezar bien

Usa LM Studio o Ollama. Gestionan la descarga, la cuantización y exponen una API compatible con OpenAI, así que conectas tus herramientas (incluido el flujo de agentes) a tu modelo local igual que harías con un servicio en la nube. LM Studio es más visual; Ollama, más de terminal.

En Mac, descarga la versión MLX del modelo si existe. Está optimizada para Apple Silicon y va bastante más rápido que la genérica a igual calidad.

No te obsesiones con la cuantización máxima. Para desarrollo, un modelo en Q4 con más contexto rinde mejor en la práctica que el mismo modelo en Q8 con menos espacio para leer tu proyecto.

Si te llevas una sola idea: define primero qué quieres que haga la IA, y de ahí sale el modelo. Para desarrollo serio, un 32B en un equipo de 48 GB es el punto donde el local deja de ser un experimento y se convierte en herramienta de trabajo.

WordPress 7.0 «Armstrong» se publicó el 20 de mayo de 2026, doce días después del corte original del 9 de abril y tras un ciclo de release candidate accidentado. La versión llega con la promesa más ambiciosa que el núcleo ha hecho en años: una capa de inteligencia artificial integrada de serie, sin depender de plugins individuales para conectar OpenAI, Anthropic o Google. Pero llega también con bajas. La edición colaborativa en tiempo real, que durante meses se vendió como el otro pilar de Armstrong, se retiró doce días antes del lanzamiento porque no estaba lo suficientemente estable. Lo que queda merece un repaso ordenado, porque para quien desarrolla sobre WordPress los cambios son estructurales.

Este artículo recoge todo el bloque de IA tal como ha quedado en la versión final, incluidas las decisiones de última hora.

Lo que aterriza en el núcleo

WordPress 7.0 introduce tres piezas conectadas: el AI Client, la Abilities API y la nueva pantalla Ajustes → Conectores. Las tres juntas reescriben la forma en que un sitio expone capacidades de inteligencia artificial.

AI Client

El AI Client es una API PHP agnóstica del proveedor. Un plugin que quiera generar texto, resumir contenido o pedir un análisis ya no implementa la SDK de OpenAI por su cuenta. Llama al núcleo, el núcleo enruta al proveedor configurado, y devuelve la respuesta normalizada. Esto centraliza tres cosas que antes vivían dispersas: autenticación, rate limiting y sanitización de la respuesta.

La consecuencia operativa es directa: si tienes diez plugins que usan IA, no necesitas diez claves de API distintas con diez configuraciones distintas. Una clave por proveedor, en un solo sitio, y todos los plugins compatibles la reutilizan.

Abilities API

La Abilities API es la pieza más interesante para quien construye herramientas. Permite que plugins, temas y el propio núcleo declaren sus capacidades en un formato legible por humanos y por máquinas. Es la base que hace posible que un agente de IA externo descubra qué puede hacer un sitio sin que el sitio tenga que exponer una documentación a mano.

Donde antes había que escribir endpoints REST personalizados, registrar shortcodes, documentar parámetros y rezar para que el cliente los entendiera, ahora se declara una ability con su esquema. El agente la encuentra, la entiende y la usa.

Esto encaja, con bastante elegancia, con la infraestructura MCP (Model Context Protocol) que ya está usándose en otros sitios. WordPress no implementa MCP en el núcleo, pero la Abilities API expone la información que un servidor MCP necesita para envolverla y servirla a clientes como Claude Code o Cursor.

Ajustes → Conectores

La nueva pantalla Ajustes → Conectores centraliza la configuración de proveedores de IA. Trae tres registrados de serie: OpenAI, Anthropic y Google (Gemini). La idea es la misma que con la pantalla de Aplicaciones: pones la clave una sola vez, eliges el modelo, y cualquier plugin del sitio que use el AI Client puede tirar de ese conector.

Para quien gestiona varios sitios, esto cambia la conversación con clientes. Ya no se trata de "instala este plugin de IA y mete tu clave", sino de "configura Anthropic en tu WordPress y el resto va solo".

La modificación de última hora: adiós a la edición colaborativa

Hasta 12 días antes del lanzamiento, Armstrong se presentaba públicamente con dos banderas: IA nativa y edición colaborativa en tiempo real (al estilo Google Docs o Notion). En las release candidate finales, el equipo decidió retirar la edición colaborativa por inestabilidad.

Esto importa por dos razones:

1. No es un bug menor. Era una característica de portada, y se cae a dos semanas del release. La razón oficial es que no estaba lista; la conclusión razonable es que reescribir la sincronización del editor para soportar múltiples cursores en directo era más complejo de lo previsto.
2. No hay fecha confirmada para 7.1. La edición colaborativa entra en la rama de "feature project" y se valorará para una versión menor próxima, pero no hay compromiso público de calendario.

Para quien planificó procesos editoriales pensando en colaboración nativa, el mensaje es claro: por ahora, plugins como Multicollab o flujos de revisión con redacciones paralelas siguen siendo necesarios.

Cambios secundarios que conviene tener en cuenta

Más allá del bloque IA, Armstrong trae cambios que afectan al desarrollo cotidiano:

• Admin rediseñado con DataViews. La pantalla de listas (posts, páginas, usuarios, productos en WooCommerce con su parche correspondiente) usa el componente DataViews del editor. Vista de tabla, tarjeta y lista, con filtros persistentes. Visualmente moderno; funcionalmente, hay reescritura de hooks que personalizaban las listas anteriores.
• PHP 7.4 como mínimo. WordPress 7.0 ya no se instala en PHP 7.3 o inferior. La mayoría de hostings serios están en 8.1 o 8.2, pero hay sitios viejos en 7.3 que se quedan atrás.
• Bloques nuevos: Breadcrumbs e Icons en el núcleo. Iconos como bloque, no como librería externa.
• Atajos del Command Palette ampliados y nueva atajo global. Pequeño detalle de UX que ahorra clics.
• Visual revisions: revisiones con comparación visual lado a lado, no solo diff de texto.

Lo que significa para quien construye

Tres conclusiones operativas tras dos días con la versión final delante:

Para plugins de IA existentes: hay trabajo de migración. Cualquier plugin que mantenga su propia gestión de claves y proveedores tiene incentivo claro para refactorizar a AI Client. No es obligatorio (los plugins viejos seguirán funcionando), pero es donde irá el ecosistema.

Para integraciones con agentes IA externos: la Abilities API es la pieza estratégica. Si construyes algo que un agente Claude, Cursor o ChatGPT debe entender, declarar capacidades como abilities es ahora el camino correcto. La alternativa de seguir con endpoints REST sueltos pierde sentido.

Para sitios cliente: no hay urgencia para actualizar la primera semana. Los temas y plugins compatibles están saliendo estos días, y la combinación de admin rediseñado + PHP 7.4 mínimo merece staging antes que producción. Plazo razonable: actualizar en 2-3 semanas, con los temas y plugins clave ya validados.

En resumen

Armstrong es una versión estructural, no estética. Lo que se ve cambia menos que lo que pasa por debajo. La parte de IA llega entera y bien pensada; la parte colaborativa, no llega. Y la decisión de cortar a tiempo, aunque incómoda, es la correcta: una colaboración en tiempo real inestable habría sido peor noticia.

Para nosotros, en Flowtitude, la Abilities API es la pieza que más interés tiene. Es la primera vez que el núcleo de WordPress incorpora un mecanismo nativo para que agentes externos descubran qué puede hacer un sitio. Esto cambia el suelo sobre el que estamos construyendo Kodavio y todo el bloque de IA + WordPress.

¿Qué pasaría si pudieras pedirle a una inteligencia artificial que construya una página completa en Bricks Builder con un solo comando, y que el resultado respete tu sistema de diseño, tus clases CSS y tu estilo visual? Eso es exactamente lo que propone Agent to Bricks, un proyecto de código abierto que actúa como puente entre agentes de IA y el editor visual Bricks Builder en WordPress.

El repositorio, mantenido por el desarrollador Ashraf Ali, cuenta actualmente con 61 estrellas en GitHub y ha recibido actualizaciones recientes, con su última versión v2.3.0 publicada el 7 de mayo de 2026. No se trata de un plugin más de IA para WordPress, sino de una solución que funciona desde la terminal, con interfaz gráfica dedicada, y que permite automatizar tareas que normalmente requerirían horas de trabajo manual.

Cómo funciona en la práctica

Agent to Bricks se compone de tres elementos que trabajan en conjunto. Primero está el plugin de WordPress, que se instala como cualquier otro y expone una API REST segura sobre la que el resto del sistema opera. Luego está la CLI, una herramienta de terminal que permite ejecutar operaciones sobre las páginas de Bricks: extraer contenido, modificar elementos, buscar y reemplazar, aplicar estilos y empujar cambios de vuelta al sitio. Finalmente existe una aplicación de escritorio que facilita el trabajo visual con menciones interactivas como @page, @color o @element para referenciar elementos dentro del prompt sin necesidad de cambiar de pestaña.

El flujo más básico sería algo así: un usuario escribe un prompt como "cambia todos los botones de la página de precios para que usen el color principal de la marca", el agente de IA interpreta la instrucción consultando el contexto del sitio mediante bricks discover, genera el JSON correspondiente y lo envía de vuelta con bricks push. Todo sucede en segundos y sin tocar la interfaz visual de Bricks.

Un caso de uso concreto

Imaginemos que un cliente envía por correo electrónico una lista de quince testimonios para incluir en cinco páginas distintas. Sin Agent to Bricks, eso implica abrir cada página, buscar la sección adecuada, copiar el texto, formatear y guardar. Con Agent to Bricks, el flujo sería básicamente esto: el agente lee el correo, extrae los testimonios, los organiza por página y los inserta en cada una usando los elementos nativos de Bricks. El tiempo estimado pasa de dos horas a treinta segundos, según calcula el propio autor del proyecto.

Otro escenario habitual es la migración de contenido desde otros constructores visuales. Agent to Bricks incluye un comando de conversión que toma HTML convencional con clases CSS personalizadas y lo transforma en elementos nativos de Bricks, mapeando las clases a los identificadores internos del constructor. Esto significa que no se pierde el diseño original ni hay que recrear todo manualmente sección por sección.

Lo que lo hace diferente

A diferencia de otras herramientas de IA para WordPress que funcionan como plugins autónomos con suscripciones mensuales, Agent to Bricks es completamente gratuito y de código abierto bajo licencia GPL-3.0. El usuario elige qué agente de IA utilizar y aporta sus propias claves de API, en lugar de pagar a un intermediario que las gestione.

Conviene matizar lo que esto significa en términos de privacidad. El sitio del proyecto utiliza el lema "your machine, your keys", y es cierto que el orquestador corre en local: el plugin, la CLI y la aplicación de escritorio se ejecutan en tu equipo, y tus claves de API son tuyas. Pero el contenido del prompt (instrucción más contexto del sitio en JSON) sí viaja al proveedor de IA que elijas: si configuras Claude, los datos van a Anthropic; si usas Codex o GPT, van a OpenAI; si conectas Gemini, van a Google. La frase "los datos no salen de tu máquina" solo se cumple literalmente si conectas un modelo totalmente local (Ollama, LM Studio u otro motor en tu propio hardware). En cualquier otro caso, lo que cambia respecto a un plugin SaaS comercial es que no hay un intermediario adicional, no que el flujo sea offline.

Dicho esto, el enfoque no intenta reemplazar el proceso de diseño sino integrarse en el workflow existente. El sistema incluye snapshots automáticos antes de cada cambio, lo que permite revertir cualquier modificación con un solo comando. También existen perfiles de estilo que permiten definir fuentes, colores y espaciado una vez, de modo que cada sección generada por IA respete la identidad visual del sitio sin intervención adicional.

Instalación y requisitos

Para usar Agent to Bricks se necesita WordPress 6.0 o superior con Bricks Builder 1.9 instalado, PHP 8.0 como mínimo, y luego instalar el plugin desde el panel de WordPress. La CLI está disponible para macOS, Linux y Windows como binario descargable desde la pestaña de releases del repositorio en GitHub. La aplicación de escritorio funciona como interfaz visual sobre la CLI y permite gestionar múltiples sitios simultáneamente.

Toda la documentación, incluyendo guías de instalación, referencia de comandos y tutoriales, se encuentra en agenttobricks.com, donde el desarrollador también ofrece plantillas prediseñadas y perfiles de estilo listos para descargar.

Agent to Bricks, Kodavio y el ecosistema agentes-IA-Bricks

No vamos a esquivar lo obvio: Agent to Bricks resuelve un problema muy parecido al que resuelve Kodavio, nuestro propio plugin. Ambos buscan que un agente de inteligencia artificial pueda operar sobre Bricks Builder con contexto real del sitio, en lugar de improvisar contra una hoja en blanco. Es competencia directa, y nos parece sano hablarlo de frente.

Las dos propuestas comparten objetivo pero divergen en filosofía. Agent to Bricks empaqueta el flujo en una CLI propia + aplicación de escritorio + plugin de WordPress, todo bajo licencia GPL-3.0. El usuario instala las tres piezas, configura sus claves de IA y opera desde la terminal o la app. Kodavio elige otro camino: expone WordPress como servidor MCP estándar, de modo que cualquier cliente MCP existente (Claude Code, Cursor, OpenCode, futuros que aparezcan) lo descubre y opera sin necesidad de instalar CLI ni app de escritorio. Mismo problema, dos rutas: tooling integrado vs. protocolo abierto.

A esto se suma Novamira, que estos días está abriendo su lanzamiento público con un tercer ángulo: integrar la IA directamente dentro de la experiencia de construcción visual en WordPress, sin pasar por terminal ni cliente externo. Tres formas distintas de resolver lo mismo, conviviendo en el ecosistema sin canibalizarse.

Por qué publicamos esto

Apoyamos las iniciativas. Más todavía si son de código abierto. Agent to Bricks lleva GPL-3.0 encima, lo cual significa que cualquiera puede leer su código, mejorarlo, forkearlo y compartirlo. Eso, a largo plazo, es bueno para Bricks, para WordPress y para la comunidad — incluso para Kodavio, porque obliga a que cada propuesta sea mejor en lo suyo.

Si tu necesidad es una CLI rápida, una app de escritorio dedicada y todo el control en tu máquina con licencia libre, Agent to Bricks es una respuesta sólida y la recomendamos sin reservas. Si tu necesidad es que cualquier cliente MCP existente o futuro pueda operar tu WordPress con permisos granulares y trazabilidad, Kodavio es la nuestra. Y si Novamira encaja mejor en tu flujo, también nos parece bien.

Una pregunta para la comunidad

Agent to Bricks plantea una pregunta interesante para quienes trabajan con Bricks Builder de forma habitual: ¿cuánto tiempo invertido en tareas repetitivas podría reutilizarse si una inteligencia artificial pudiera aplicar cambios masivos sobre páginas completas respetando siempre el sistema de diseño establecido? La comunidad de Flowtitude ya trabaja con Bricks en proyectos reales y conoce de primera mano cuánto puede consumir la edición manual a escala. Este tipo de herramienta podría cambiar esas dinámicas, y vale la pena probar si realmente lo hace.

Si decides probar Agent to Bricks o Kodavio en algún proyecto real, te leemos. Las dos rutas son legítimas, y la comunidad gana cuando se comparten resultados honestos — incluyendo los casos donde una de las dos no encaja.

WooNuxt es un proyecto de código abierto que combina la flexibilidad de gestión de productos de WooCommerce con la velocidad y el rendimiento de un sitio estático generado con Nuxt 3. En lugar de depender de la interfaz habitual de WordPress para el storefront, WooNuxt consume los datos a través de WPGraphQL y genera páginas públicas optimizadas para SEO y tiempos de carga mínimos.

La propuesta es sencilla: usar WooCommerce como panel de administración y base de datos, y dejar que Nuxt se encargue de toda la capa de presentación. Esto permite tener un e-commerce headless donde WordPress solo gestiona contenidos y pedidos, mientras el frontend se despliega en cualquier hosting estático como Netlify, Vercel o PandaStack.

El repositorio principal registra 952 estrellas y 302 forks en GitHub, lo que da una idea del interés que ha generado en la comunidad de desarrollo. La última versión publicada es la 4.21.0, fechada el 4 de mayo de 2026.

Tecnologías que forman el stack

WooNuxt se apoya en Nuxt 3 como framework principal de frontend, junto con Vue 3 y TypeScript para escribir código mantenible. El acceso a datos se realiza mediante consultas GraphQL a través de WPGraphQL y la extensión WooGraphQL, lo que elimina las llamadas REST tradicionales de WooCommerce y permite obtener solo la información exacta que cada vista necesita.

Para los estilos se utiliza Tailwind CSS, lo que facilita personalizar la apariencia sin escribir CSS personalizado. Los plugins de WordPress requeridos incluyen WooCommerce, WPGraphQL, WooGraphQL, WPGraphQL CORS y un plugin específico llamado woonuxt-settings que automatiza la configuración inicial.

Modelos de renderizado disponibles

Aunque el nombre del proyecto sugiere generación estática pura, WooNuxt soporta múltiples estrategias de renderizado. Para catálogos pequeños se puede usar el comando generate de Nuxt y obtener páginas estáticas completas. Para catálogos grandes con miles de productos, el proyecto recomienda usar renderizado híbrido con ISR (Incremental Static Regeneration), donde las páginas de producto se generan bajo demanda y se recargan en segundo plano cuando expira el TTL configurado.

Esto es importante porque un catálogo extenso generado de forma estática puede resultar lento de construir y pesado de desplegar. La estrategia ISR permite mantener tiempos de construcción razonables mientras se conservan las ventajas de caché del contenido estático.

Métodos de pago soportados

WooNuxt integra de serie soporte para Stripe, PayPal Standard y pago contra reembolso. El plugin de configuración automática se encarga de recuperar los ajustes de pasarela desde WooCommerce y exponerlos a través de GraphQL, por lo que no hace falta configuración manual adicional en el frontend.

Idioma, localización y traducciones

El proyecto incluye traducciones listas para usar en inglés, alemán, español, francés, italiano y portugués. Esto lo convierte en una base sólida para proyectos de comercio electrónico que necesiten atender múltiples idiomas sin partir de cero.

Cómo empezar

El flujo de inicio recomendado es el siguiente: primero instalar y activar el plugin woonuxt-settings en el WordPress donde se tenga WooCommerce funcionando. Este plugin instala automáticamente todos los plugins de WordPress necesarios para el proyecto.

Después se clona el repositorio de WooNuxt, se configuran las variables de entorno GQL_HOST y NUXT_IMAGE_DOMAINS, y se despliega con un clic usando los botones de Netlify o Vercel que el proyecto ofrece en su documentación. También existe la opción de usar PandaStack para un despliegue rápido.

Ejemplo práctico: tienda de productos artesanales

Imaginemos que alguien quiere abrir una tienda online para productos artesanales y prefiere gestionar todo desde WordPress por la comodidad del panel de administración, pero quiere que la experiencia de compra sea lo más rápida posible en el navegador.

Con WooNuxt, esa persona instala los plugins necesarios en su WordPress existente, configura el producto en WooCommerce igual que lo haría normalmente, y despliega el frontend de Nuxt en Netlify. Los clientes acceden a una tienda que carga en milisegundos gracias a las páginas estáticas, mientras el dueño sigue usando WordPress para añadir productos, procesar pedidos y gestionar inventario.

Si el catálogo crece a cientos de productos, se ajusta la configuración ISR en nuxt.config.ts y el sistema sigue funcionando sin necesidad de reconstrucciones completas.

Reflexión final

WooNuxt representa una forma práctica de separar la complejidad de un CMS como WordPress de la experiencia de usuario que un frontend moderno puede ofrecer. Para equipos que ya conocen WooCommerce pero quieren mejorar rendimiento y flexibilidad, es una ruta directa sin tener que migrar toda la base de datos de productos a otra plataforma.

La comunidad Flowtitude tiene aquí un caso interesante para explorar: combinar el poder de un sistema de e-commerce maduro como WooCommerce con la velocidad del frontend estático y la personalización que permite Tailwind CSS. Es un nicho técnico con poca competencia en contenido en español, lo que abre espacio para tutoriales y materiales formativos.

Esta semana le he pedido a mi asistente de IA: "revisa la home de este cliente, dime qué bloques hay y propón mejoras". Y lo ha hecho directamente sobre el sitio. Sin pantallazos, sin pegarle URLs, sin describirle nada con palabras.

El puente entre los dos lo hace un plugin que se llama Kodavio. Por debajo usa MCP (Model Context Protocol), un estándar abierto, así que sirve para cualquier asistente moderno — no te casas con ninguno.

El asistente puede leer, proponer y tocar contenido — siempre con tu permiso, paso a paso.

Voy a abrir una beta privada con plazas muy limitadas para escuchar feedback real antes del lanzamiento público. Si te interesa probarlo 👉 Lista de espera: https://flowtitude.com/kodavio/

WordPress 7.0 incluye un Cliente IA integrado en el núcleo. Es una API en PHP que permite a cualquier plugin enviar prompts a proveedores de inteligencia artificial y recibir los resultados directamente. Hasta hace poco, quienes querían añadir capacidades de generación de imágenes en WordPress dependían de servicios externos o integraciones complicadas. Ahora eso cambia, y la buena noticia es que ya existe documentación oficial con un ejemplo funcional.

Un detalle importante antes de seguir: el núcleo de WordPress no incluye ningún proveedor por defecto. La conexión a OpenAI, Google AI o Anthropic se instala como un plugin proveedor separado. El Cliente IA es la interfaz común; los plugins proveedores aportan la implementación concreta.

Cómo funciona el Cliente IA de WordPress

Lo primero que hay que entender es que tu plugin nunca se comunica directamente con un proveedor de IA. En lugar de eso, describes qué necesitas (texto, una imagen, un formato de salida específico) y cómo lo necesitas (proporción de aspecto para imágenes, temperatura para generación de texto, etc.). Con esa información, WordPress redirige la petición a un modelo adecuado del proveedor que el administrador del sitio tenga configurado.

Esto tiene implicaciones prácticas importantes. Los propietarios de sitios eligen su proveedor (Anthropic, Google, OpenAI u otro soportado) y gestionan las claves API desde Ajustes > Conectores, una pantalla centralizada que elimina la necesidad de que cada plugin tenga su propia página de configuración de credenciales. Los plugins son portables: uno que funciona con un proveedor funciona con todos. Y cuando nuevos proveedores o modelos estén disponibles, los plugins existentes ganarán soporte automáticamente sin actualizaciones.

La interfaz principal es una sola función: wp_ai_client_prompt(). Esta devuelve un objeto WP_AI_Client_Prompt_Builder con métodos que siguen las convenciones de WordPress (snake_case). Desde ahí puedes encadenar métodos para describir tu prompt. Por ejemplo, para generar una imagen indicas el texto del prompt, el tipo de archivo de salida (base64-encoded inline), y opcionalmente la orientación (square, landscape o portrait).

El sistema de preferencias de modelos permite sugerir modelos ideales sin forzarlos. Puedes llamar using_model_preference() con una lista de modelos preferidos y WordPress los intentará en orden, cayendo atrás a modelos compatibles si los preferidos no están disponibles. Tu plugin sigue funcionando sin importar cuál modelo haya disponible.

Antes de mostrar cualquier funcionalidad de IA a los usuarios, es obligatorio verificar si el proveedor configurado realmente soporta lo que necesitas. El método is_supported_for_image_generation() devuelve true solo cuando hay un proveedor configurado con un modelo que soporte generación de imágenes. Esta verificación no hace llamadas a la API ni incurre en costes.

Un caso de uso concreto: plugin de generación de imágenes en la biblioteca de medios

El blog oficial de desarrollo de WordPress publica un plugin de ejemplo funcional que añade un botón "Generar archivo de imagen" directamente en la Media Library. El flujo es simple: el usuario hace clic en el botón, escribe un prompt de texto, el plugin envía ese prompt al Cliente IA, muestra la imagen generada como vista previa, y permite guardarla como un attachment nuevo en la biblioteca de medios.

La arquitectura del plugin separa responsabilidades. El archivo principal plugin.php verifica que el Cliente IA exista y carga tres archivos incluidos: prompt.php con las funciones reutilizables para construir los prompts del Cliente IA, rest-api.php con los endpoints REST para generar la imagen y para subirla a la Media Library, y admin.php que gestiona el registro y carga condicional de los scripts del frontend.

El archivo prompt.php define una función que configura el builder para generación de imágenes. Devuelve el builder en lugar del resultado, lo que permite que el mismo código se reuse tanto para hacer la petición real como para hacer la verificación de soporte. No se especifica proveedor ni modelo, solo se describe qué se necesita y WordPress se encarga del resto.

Los endpoints REST son dos: uno para generar la imagen y otro para guardarla en la Media Library. Separarlos tiene sentido porque permite al usuario revisar la imagen generada antes de comprometerla. El endpoint de generación toma el prompt y la orientación opcional, llama generate_image_result() y devuelve el resultado directamente. El de subida decodifica la imagen base64, la escribe a disco con wp_upload_bits(), crea el attachment con wp_insert_attachment() y genera los metadatos con wp_generate_attachment_metadata().

En el frontend, el script se carga de forma condicional solo en la pantalla de la Media Library (upload.php) y solo si el usuario tiene capacidad para subir archivos y el proveedor configurado soporta generación de imágenes. Esta triple verificación asegura que el botón "Generar imagen" solo aparezca cuando realmente funcionará.

El código fuente completo está disponible en GitHub en wptrainingteam/ai-client-imagegen. Los requisitos para probarlo son WordPress 7.0, un proveedor de IA configurado con soporte para generación de imágenes (desde Ajustes > Conectores), y Node.js versión 20 o superior para compilar los assets del frontend.

Qué significa esto para la comunidad Flowtitude

Si trabajas con Bricks Builder o extensiones de WooCommerce, este Cliente IA abre posibilidades concretas. Puedes generar imágenes de productos sin salir de tu entorno de administración. Un desarrollador de temas Bricks podría crear un bloque que genere imágenes de cabecera con prompts de texto. Una tienda WooCommerce podría generar imágenes de placeholder mientras carga fotos de productos reales, o crear variaciones de imágenes para tests A/B.

Lo más relevante es que toda la complejidad de comunicación con proveedores de IA, autenticación, selección de modelos y normalización de respuestas queda encapsulada detrás del Cliente IA. Tu plugin se enfoca en su propósito específico y la parte de IA es solo otra llamada a una API interna de WordPress.

El equipo de desarrollo espera que la comunidad explore el plugin de ejemplo y lo lleve más allá. Entre las ideas mencionadas están generar múltiples variaciones de imágenes para que el usuario elija su favorita, usar la capacidad de generación de texto del Cliente IA para crear nombres de archivo más descriptivos basándose en el contenido de la imagen, o integrar edición de imágenes existentes pasando una imagen actual como archivo adicional al prompt.

¿Quieres saber cómo podría mejorar tu flujo de trabajo este Cliente IA nativo en WordPress? ¿Hay alguna función específica de tu tienda online o sitio en Bricks donde veas potencial para integrar generación de imágenes con IA?

La llegada de Bricks 2.2 reabrió una conversación que en la comunidad llevaba tiempo latente: si Bricks cada vez resuelve mejor estilos, clases, variables y estructura visual desde dentro del builder, ¿siguen teniendo sentido frameworks como ACSS o Core Framework?

La pregunta es buena, pero se queda corta si solo la planteamos como una guerra entre Bricks nativo y frameworks externos. Falta una tercera pieza que para Flowtitude es clave: Tailwind. No como moda de developers, sino como forma de pensar interfaces desde utilidades, tokens, velocidad de composición y compatibilidad natural con flujos de IA y código.

Bricks nativo: menos capas, más control directo

El argumento a favor de Bricks nativo es muy claro. Si el builder ya te permite manejar mejor estilos globales, clases, variables, spacing y componentes, reducir dependencias tiene sentido. Menos plugins significa menos superficie de mantenimiento, menos conflictos, menos curva de aprendizaje y más control desde el propio entorno visual.

Para proyectos pequeños o equipos que quieren simplicidad, esta es una ventaja enorme. Puedes construir un sistema visual adaptado al proyecto sin traer una metodología completa desde fuera. Y si tu equipo vive principalmente dentro de Bricks, cuanto más nativo sea el sistema, menos fricción habrá.

Pero aquí aparece el primer matiz: que algo sea nativo no significa automáticamente que sea sistemático. Puedes construir con Bricks puro y aun así acabar con estilos inconsistentes, clases duplicadas, escalas improvisadas y decisiones visuales repartidas por todo el proyecto.

ACSS y Core Framework: convenciones y guardrails

ACSS y Core Framework no aportan solo clases. Aportan criterio empaquetado: escalas, nomenclatura, estructura, convenciones, responsive, tokens y una forma de mantener coherencia entre páginas y componentes.

Ese valor es importante. Para un equipo, no tener que decidirlo todo desde cero puede acelerar mucho. Un framework opinionado actúa como una barandilla: limita algunas decisiones, pero a cambio evita caos.

Por eso no diría que Bricks 2.2 vuelve obsoletos a ACSS o Core Framework. Diría que obliga a justificar mejor su uso. Si el framework aporta velocidad, consistencia y una metodología que tu equipo realmente usa, sigue teniendo sentido. Si solo está ahí porque «siempre lo instalamos», entonces Bricks nativo empieza a ser una alternativa muy razonable.

Tailwind: la tercera vía que no deberíamos dejar fuera

Tailwind cambia el debate porque no intenta ser exactamente lo mismo que ACSS o Core Framework dentro de Bricks. Tailwind propone otra mentalidad: construir interfaces con utilidades pequeñas, composables y muy cercanas al lenguaje del CSS real.

Para Flowtitude esto importa especialmente. Tailwind es nuestro framework CSS favorito porque encaja muy bien con cómo se está moviendo el trabajo moderno:

• Es fácil de leer para alguien con base de CSS.
• Es muy compatible con componentes y sistemas reutilizables.
• Funciona especialmente bien con IA, porque los modelos entienden patrones Tailwind con mucha precisión.
• Permite iterar rápido sin inventar nombres de clases para cada microdecisión.
• Encaja con flujos donde hay código, prompts, builders visuales y herramientas como WindPress.

Tailwind v4 refuerza aún más esa dirección al apoyarse en CSS moderno, variables y una configuración más cercana al propio CSS. Eso lo hace interesante para WordPress, especialmente si lo combinamos con herramientas que permitan llevar Tailwind al entorno visual sin convertir cada proyecto en una build compleja.

Entonces, ¿qué elegir?

No lo decidiría por dogma. Lo decidiría por tipo de proyecto y equipo.

Bricks nativo tiene sentido si quieres una base ligera, pocos plugins y un sistema muy adaptado al proyecto. Es ideal para equipos que trabajan casi todo dentro del builder y quieren mantener el stack simple.

ACSS/Core Framework tiene sentido si valoras convenciones ya hechas, velocidad inicial y guardrails fuertes. Es ideal para equipos que quieren consistencia inmediata y una metodología visual estable.

Tailwind tiene sentido si tu flujo mezcla builder, código, IA y componentes. Es especialmente potente cuando quieres que el sistema visual sea fácil de expresar tanto para humanos como para agentes de código. Si trabajas con prompts, snippets, componentes reutilizables o WindPress, Tailwind no es un extra: puede ser el idioma común del sistema.

La mezcla posible: Bricks como interfaz, Tailwind como lenguaje

La opción más interesante no es necesariamente elegir uno y descartar el resto. Puede que el futuro del trabajo con Bricks pase por usar Bricks como capa visual y Tailwind como lenguaje de diseño y código.

Eso permitiría algo muy potente: diseñar visualmente, mantener consistencia con utilidades, apoyarse en IA para generar componentes y seguir teniendo una estructura comprensible para developers. En lugar de enfrentar builder y código, Tailwind puede actuar como puente.

ACSS y Core Framework también pueden cumplir ese papel, pero Tailwind tiene una ventaja especial: ya es un lenguaje compartido por gran parte del ecosistema frontend y por los modelos de IA. Cuando pides a un agente que cree una interfaz con Tailwind, normalmente entiende muy bien la jerarquía, el spacing, el responsive y los patrones habituales.

La pregunta real

La pregunta no es «¿Bricks nativo vuelve obsoletos los frameworks?». La pregunta es: ¿dónde vive tu sistema de diseño?

Puede vivir en Bricks. Puede vivir en ACSS o Core Framework. Puede vivir en Tailwind. O puede vivir en una combinación bien pensada. Lo peligroso no es elegir una herramienta u otra. Lo peligroso es no tener sistema y confundir velocidad con consistencia.

Para Flowtitude, Tailwind merece estar en el centro de esta conversación porque conecta tres mundos que nos importan mucho: diseño visual, código limpio e IA aplicada a la creación web.

Pregunta para la comunidad: si empezaras hoy un proyecto nuevo en Bricks, ¿usarías Bricks nativo, ACSS/Core Framework, Tailwind o una mezcla? Y sobre todo: ¿por qué?

Si construyes sitios con Bricks, esta versión te interesa. El 12 de mayo de 2026 se publicó Bricks 2.3.5, una release centrada en corregir errores y afinar funcionalidades que muchos usamos cada día: Query Filters, WooCommerce, CSS personalizado y navegación del builder. Varias de estas mejoras arrancaron en la 2.3.3 y se han ido refinando versión a versión.

El importador de CSS ya no rompe tus pseudo-clases

Antes de la 2.3.3, si traías una hoja de estilos externa a Bricks mediante el Framework Importer, las pseudo-clases como :hover, ::before o ::after podían perderse en el proceso. Tu código funcionaba en la hoja original, pero al importarlo en Bricks podía comportarse de forma distinta.

Desde la 2.3.3, el importador mantiene los pseudo-elementos y pseudo-clases intactos. Es un cambio discreto en el changelog, pero muy útil para quienes trabajan con frameworks CSS externos o heredan proyectos con hojas de estilos complejas.

En la 2.3.5 también se corrigió que %root% en CSS personalizado mostrara el ID o nombre de clase en lugar del valor esperado, y que el textarea de CSS personalizado se cortara al redimensionar.

Query Filters: rendimiento, reparación y filtros más estables

Query Filters concentra varios cambios importantes en estas versiones.

En Bricks 2.3.3:

- El sistema de indexación evita trabajo repetitivo en sitios que actualizan muchos meta fields de posts.

- La función Fix DB repara problemas de schema de tabla, no solo trunca tablas de filtros.

- Los selectores de filtro mejorado solucionan problemas con opciones de selección múltiple.

En Bricks 2.3.5:

- Se corrigió que el scroll infinito no funcionara con global queries.

- Se arreglaron problemas del Enhanced Filter Select, incluido un caso con campos ACF en modo multiselect que generaba meta queries incorrectas.

- Se corrigió el orden incorrecto de taxonomía en páginas de archivo.

Si usas Query Filters con ACF, global queries o filtros mejorados en archivos, estas versiones traen mejoras tangibles.

WooCommerce: swatches con teclado, lightbox y badges corregidos

Desde la 2.3.3, los swatches de variación de WooCommerce en Bricks son operables con teclado, algo importante para la accesibilidad de tiendas construidas con Bricks.

En la 2.3.5 también se corrigieron varios problemas:

- El lightbox de la galería de producto funciona correctamente desde el Quick View Popup.

- Los badges de porcentaje de descuento en productos agrupados ya no causan errores fatales si se elimina un producto hijo del grupo.

- Se resolvió una anomalía en checkout cuando se habilitaba la opción de agregar al carrito con límite de un producto por compra.

Otros detalles que importan en el día a día

- Controles de espaciado con memoria: desde la 2.3.3, los controles de spacing recuerdan su estado linked por control individual, con estados separados para All y Opposites.

- Slots de componentes preservados: copiar y pegar una instancia de componente conserva el contenido del slot.

- Validación de licencia más resiliente: si el servidor de licencias no responde temporalmente, Bricks mantiene el estado guardado localmente y reintenta la validación.

- Video element: desde la 2.3.5 soporta tags dinámicos para definir el tiempo de inicio y fin en videos de YouTube.

- CSS externo: la 2.3.5 muestra un aviso si usas CSS externo pero WP CRON está desactivado.

Caso práctico: cómo aplicar estas mejoras

Imagina una tienda online construida con Bricks y WooCommerce. Usas Query Filters para que los visitantes filtren productos por categoría, precio y atributos personalizados mediante ACF. También importas CSS de un framework para mantener consistencia con otros proyectos.

Con Bricks 2.3.5 puedes:

1. Importar CSS sin perder :hover ni ::before.

2. Usar filtros mejorados con campos ACF multiselect sin meta queries incorrectas.

3. Navegar por swatches de variación con teclado.

4. Usar scroll infinito en archives con global queries sin que se rompa.

¿Ya actualizaste a Bricks 2.3.5?

Estas mejoras no son revolucionarias en el sentido de añadir una gran función nueva, pero refinan partes que pesan mucho en el trabajo diario: importación de CSS, filtros más estables, mejor soporte de WooCommerce y una licencia más resiliente.

Para la comunidad Flowtitude: ¿cuál de estas mejoras te resulta más útil en tu flujo actual? ¿Hay algún problema que aún no se haya resuelto con estas actualizaciones?

Tailwind acaba de publicar 4.3.0. La 4.x sigue añadiendo utilidades en lugar de obligar a [arbitrary-values], y esta release trae varias que se usan a diario:

• Container sizing — control fino del comportamiento de containers responsive sin tener que escribir media queries propias.
• Scrollbar styling — utilities nativas para personalizar scrollbars (ancho, color, track). Adiós al CSS custom para algo tan básico.
• Zoom utilities — efectos de zoom controlados desde clases (zoom-in, zoom-out, escalas).
• Tab controls — utilities para tablist/tabpanel que se integran limpio con accesibilidad.
• variant mejorado — combina varias variantes (hover, focus, breakpoints…) en un solo bloque sin tener que encadenar selectores complicados: @variant hover focus { … }.
• Canonicalización — Tailwind ahora colapsa direccionales (border-t border-b → border-y) automáticamente al optimizar el output.

Esta semana iremos publicando piezas sueltas explicando cada una con ejemplos prácticos en Bricks + WindPress.

Más información: 👉 https://github.com/tailwindlabs/tailwindcss/releases

WindPress acaba de sacar la 3.3.81. Es una actualización corta y específica: añade soporte nativo para Oxygen 6 en la versión Pro y arregla un pequeño problema interno del autocompletado.

Si trabajas con Bricks Builder: no hay cambios para ti. La integración con Bricks queda exactamente igual y windpress-fix sigue funcionando sin tocar nada. Actualizar es seguro, pero no aporta nada nuevo a tu día a día.

Si trabajas con Oxygen 6: aquí sí merece la pena. Ahora tienes en Oxygen la misma experiencia que ya tenía Bricks: selector de variables, clases sueltas y compilación automática.

Más información: 👉 https://github.com/wind-press/windpress/releases/tag/v3.3.81