✏️ Suscribirse https://www.youtube.com/watch?v=1Qb7al-ONgI La inteligencia artificial no solo está acelerando tareas concretas. También está cambiando la forma de organizar el trabajo: convertir criterios propios en instrucciones reutilizables, conectar herramientas mediante MCP y crear agentes capaces de seguir procesos completos. En este episodio de Negocios y WordPress hablamos de NovaMira, NovaMira Design, CrocoBuilder, Codex y OpenCode, pero el tema de fondo es otro: cómo pasar de pedir cosas sueltas a construir un sistema de trabajo alrededor de la IA. NovaMira y NovaMira Design: WordPress conectado a la IA Una de las primeras herramientas que comentamos es NovaMira, un plugin para WordPress con conexión MCP. La propuesta permite trabajar con distintas partes del ecosistema de WordPress, ejecutar consultas, utilizar PHP y conectar con plugins y builders. La parte gratuita ya resulta especialmente interesante para tareas relacionadas con WordPress y el servidor. La versión de pago añade funciones más orientadas a builders y a integraciones con diferentes plugins. La sensación general es que NovaMira quiere convertirse en una capa de conexión para trabajar con todo el ecosistema WordPress desde un agente. La novedad que más nos ha llamado la atención es NovaMira Design. En las pruebas permite trabajar con referencias visuales, archivos `design.md`, sistemas de diseño y direcciones de arte. La IA puede analizar un diseño y utilizar esa referencia para crear o modificar una web. Lo interesante es que esas direcciones de arte pueden mantenerse como una especie de memoria de trabajo. Se puede cambiar el sistema de diseño activo y hacer que la IA trabaje con una referencia distinta sin tener que explicarlo todo de nuevo en cada conversación. También cambia la forma de trabajar con los archivos. NovaMira puede crear y activar un tema sin que todo el código tenga que estar organizado desde el primer momento en un proyecto local. Eso resulta rápido para probar ideas, aunque también plantea una pregunta importante: qué control queremos conservar sobre el código y sobre el proceso de desarrollo. CrocoBuilder y el intento de hacer un builder preparado para la IA La otra gran prueba del episodio es CrocoBuilder, el nuevo builder de Crocoblock. La versión analizada todavía está en una fase beta temprana, pero la primera impresión es positiva. Uno de sus puntos fuertes es la estructura de sus componentes. Los widgets parten de una estructura JSON concreta, parecida a la forma en la que se describen componentes en otros entornos de desarrollo. Además, esos elementos pueden convertirse en bloques de Gutenberg. Esta decisión importa porque facilita la comunicación con la IA. En lugar de tener que interpretar una interfaz visual llena de capas, el agente trabaja con una estructura más clara y predecible. Otro aspecto interesante son los common styles. Ahí se pueden definir estilos globales para elementos como `body`, `h1`, imágenes y otros selectores básicos, separados de la identidad visual concreta del proyecto. Esto resuelve una dificultad habitual de otros builders: importar un framework CSS que mezcla clases, selectores HTML y estilos globales no siempre encaja bien con los paneles visuales. CrocoBuilder parece haber pensado esa separación desde el principio. También incluye herramientas MCP y skills para trabajar con el builder. Algunas de ellas incorporan validaciones finales, inspección en navegador y capturas para comprobar el resultado. La idea es que la IA no solo genere algo, sino que pueda revisar si lo que ha hecho funciona. Eso no significa que CrocoBuilder sea automáticamente el mejor builder para todo el mundo. Tiene sentido especialmente para quien ya trabaja dentro del ecosistema Crocoblock: con CrocoBuilder en el frontend y JetEngine en la parte de datos y backend se puede crear una suite bastante completa. La duda es más general: si la IA puede trabajar directamente

✏️ Suscribirse https://www.youtube.com/watch?v=pCawr0Z-x0A En este episodio repasamos el stack de inteligencia artificial que dos profesionales de WordPress usan a diario para desarrollar, diseñar y automatizar. No es una comparativa teórica: son herramientas que están en producción, con cifras reales de coste y con limitaciones conocidas. Desde cómo Codex resolvió un takedown en SoundCloud que llevaba mes y medio atascado hasta el nuevo builder Thinkcor de Crocoblock con MCP nativo, pasando por la estrategia de subsidio que permite usar modelos potentes pagando mucho menos de lo que consumen. Codex en acción: cuando la IA hace lo que la interfaz no deja Una de las anécdotas más ilustrativas del episodio es cómo Codex generó un script de consola para ejecutar un takedown en SoundCloud que la interfaz web no permitía hacer. Tras mes y medio sin respuesta de soporte, Elías pidió a Codex que investigara la API disponible, generara el código y le permitiera pulsar el botón que faltaba. El resultado: el takedown se ejecutó en minutos. Pero Codex no solo sirve para scripts puntuales. Elías también creó con él un mini cliente WordPress REST como skill reutilizable: un script que, con solo una contraseña de aplicación y las variables de entorno, permite crear posts, gestionar contenido y conectarse a cualquier WordPress sin necesidad de un plugin MCP ni un servidor intermedio. La idea es simple: si WordPress ya expone su API REST, ¿para qué añadir una capa más? Codex frente a OpenCode: dos interfaces, filosofías distintas Codex es una interfaz avanzada de ChatGPT pensada para programar: acceso a archivos del disco, MCPs, gestión de ramas Git y elección de modelo (desde el 5.4 en adelante). Funciona con carpetas y tareas, y permite crear e instalar skills directamente desde la interfaz. Su limitación principal es que solo ofrece modelos de OpenAI. OpenCode, en cambio, permite conectar múltiples proveedores de IA y elegir el modelo que quieras en cada momento. Esa flexibilidad es clave cuando quieres optimizar coste y rendimiento: puedes usar un modelo potente para planificar y uno más ligero para ejecutar. Elías usa OpenCode como herramienta principal de desarrollo diario precisamente por esa libertad, mientras reserva Codex para tareas más concretas donde la integración con el ecosistema OpenAI resulta cómoda. Una diferencia práctica importante: OpenCode consume menos tokens por sesión que Codex, en parte porque no realiza las mismas operaciones de verificación en navegador. Además, OpenCode permite perfiles de terminal por proyecto (directorio de inicio + comando de arranque), el operador `!` para ejecutar comandos de consola dentro de la interfaz, y agentes personalizados como Explorer y General que funcionan como subagentes dependientes del hilo principal. Bricks 2.4 beta: MCP nativo, abilities y CSS interpretado La versión 2.4 de Bricks, actualmente en beta, introduce cambios significativos que apuntan directamente a la integración con IA: Panel de IA con MCP nativo: un asistente integrado para conectar con Kilo, Cursor u otros entornos y recibir código directamente en el builder. Sistema de abilities: habilidades cargadas desde un repositorio de GitHub que amplían lo que el asistente puede hacer dentro de Bricks. Gestor unificado de componentes y templates: importación y exportación global, con sincronización bidireccional entre el código CSS y los paneles visuales. CSS interpretado automáticamente: el CSS que genera la IA o que se escribe en el panel de custom CSS se traduce directamente a las casillas de la interfaz visual. Personalización de interfaz por perfil de usuario y mejoras significativas en WooCommerce (checkout, mi cuenta) con mayor granularidad. Es un paso claro hacia la integración directa entre agentes de IA y el builder, sin necesidad de pasar por el navegador para ver resultados. CrocoBuilder de Crocoblock: un nuevo builder AI-native Crocoblock ha lanzado CrocoBuild

✏️ Suscribirse https://www.youtube.com/watch?v=mDd8YG7kLOE WordPress 7.1 promete más colaboración, mejores herramientas de diseño y una integración cada vez más clara con la IA. Pero el episodio 255 de Negocios y WordPress va bastante más allá de repasar una versión: sirve para hacer balance de cómo está cambiando el trabajo real de quienes desarrollamos webs, automatizamos procesos y mantenemos proyectos digitales. La conversación pasa por integraciones logísticas hechas con Codex, reseñas que complican un formulario, diseño asistido con IA, browser automation, consultoría de procesos y agentes capaces de seguir trabajando mientras nosotros hacemos otra cosa. La conclusión es menos espectacular, pero mucho más útil: la ventaja no está en delegarlo todo, sino en crear un sistema donde la IA tenga contexto, límites y un objetivo bien elegido. WordPress 7.1: colaboración, IA y mejoras que llevaba tiempo pidiendo la comunidad El primer gran bloque del episodio repasa una versión de WordPress muy centrada en colaborar mejor y preparar el editor para flujos asistidos por IA. Entre las novedades comentadas aparecen un modo de sugerencias parecido al de Google Docs, comentarios, reacciones con emojis y edición en tiempo real. Una de las ideas más interesantes son las directrices o guidelines. Permitirían definir criterios para el sitio, los textos, las imágenes o los bloques, de forma que la IA no genere contenido sin contexto, sino que siga unos estándares previos. Es una mejora técnica, pero también resume una tesis que atraviesa todo el episodio: un agente resulta mucho más útil cuando conoce las reglas del proyecto antes de empezar a ejecutar. En el apartado de conectores también se comentan mejoras como la generación por streaming, el soporte de embeddings para búsquedas internas y nuevas formas de autenticación. El objetivo parece claro: que WordPress pueda conectarse con servicios externos y aprovechar el contenido del sitio de una forma más natural. Un editor algo más capaz En diseño, WordPress 7.1 incorpora varias peticiones recurrentes de la comunidad: controles responsive desde la interfaz estilos para pseudoestados como `hover` y `focus` bloque de tabla de contenidos bloque de pestañas playlist de audio con visualización de onda API para registrar colecciones de iconos Son avances pequeños si se miran uno por uno, pero responden a una crítica habitual: Gutenberg funciona bien como editor de contenido, aunque todavía tiene limitaciones cuando se usa como herramienta de maquetación. Cuantas más capacidades básicas resuelva WordPress de forma nativa, menos dependencias hacen falta para construir una web mantenible. La versión también trae cambios internos importantes: salto a React 19, uso obligatorio de `iframe` en el editor de los temas de bloques, adaptación a la versión 3 de la Block API, soporte Unicode ampliado y mejoras en el recorte y la subida de imágenes. Para el usuario pueden pasar desapercibidos, pero para desarrolladores de temas y bloques implican revisar compatibilidad. Desarrollo con Codex: de integrar GLS a simplificar unas reseñas La utilidad de los agentes se entiende mejor cuando dejan de ser una promesa y entran en proyectos reales. Uno de los ejemplos del episodio es la ampliación de una aplicación en Python que conecta un negocio con distintas empresas de mensajería. El reto consistía en añadir GLS a una base donde ya existían otros proveedores. El trabajo se apoyó en Codex para estudiar la documentación, replicar el patrón de los conectores existentes, montar la infraestructura y preparar pruebas. La persona que dirige el proyecto no necesitaba dominar Python de antemano para avanzar, pero sí entender el objetivo, pedir la documentación correcta y validar que la nueva integración respetase el sistema existente. Ese matiz es importante: la IA reduce mucho la barrera de ejecución, pero el proyecto sigue necesitando una fuente de verdad, ejemplos previos

✏️ Suscribirse https://www.youtube.com/watch?v=3WjM7NNA0vk La IA permite construir más rápido, automatizar más tareas y rehacer piezas enteras de un proyecto con mucha menos fricción que antes. Pero esa facilidad también abre una pregunta incómoda: si ahora puedes montarlo casi todo con IA, para qué seguir usando WordPress en muchos casos. En el episodio 254 de Negocios y WordPress, esa pregunta no se responde con una postura extrema. La conversación mezcla problemas reales de despliegue y sincronización, un mini tutorial muy útil sobre extractos en WordPress, pruebas con OpenCode y OpenRouter, automatizaciones personales y un debate de fondo sobre criterio técnico. La conclusión no va tanto de elegir un bando como de entender qué parte del stack merece rehacerse y cuál sigue aportando muchísimo valor. Además, el episodio recuerda que el trabajo profesional cada vez depende menos de “picar código” o de encajar piezas al vuelo y más de tomar buenas decisiones de arquitectura, mantenimiento y negocio. Vercel, WP Rocket y Verifactu: cuando la velocidad también complica el sistema El episodio arranca con varios ejemplos que aterrizan muy bien la situación actual del desarrollo web. Por un lado aparece el caso de TomaBumping.com, ya apuntando a Vercel en lugar de quedarse en un flujo más manual con cPanel. La promesa es clara: despliegues más cómodos, conexión más natural con GitHub y una experiencia más moderna para mover una web basada en Next. Pero la parte interesante no es la migración en sí, sino el peaje que aparece enseguida. La sincronización con Notion, los builds nocturnos, los deploys constantes y los límites del plan gratuito dejan una idea bastante potente: la IA y los stacks nuevos te dan superpoderes, pero también pueden meterte en sistemas más pesados de operar si no revisas bien el flujo. Ahí sale una reflexión útil para cualquier proyecto: no siempre compensa sustituir una solución ya entendida por otra más moderna si el coste operativo sube demasiado. A veces el problema no es tecnológico, sino de encaje entre lo que necesita el proyecto y la infraestructura elegida. En ese mismo bloque aparecen dos recordatorios del ecosistema WordPress que siguen siendo muy prácticos: un contenido sobre WP Rocket orientado a optimización y rendimiento un repaso a VeriFacWoo, presentado como una solución bien montada para cubrir una necesidad legal y operativa muy concreta Ese contraste está muy bien traído porque resume el tono del episodio: puedes explorar herramientas nuevas, pero eso no invalida todo lo que WordPress y su ecosistema siguen resolviendo con mucha eficacia. Cómo funcionan de verdad el excerpt y la etiqueta more en WordPress Uno de los bloques más didácticos del episodio es la explicación sobre extractos y cortes de contenido en WordPress. Parece un detalle pequeño, pero afecta directamente a cómo muestras entradas en listados, feeds o plantillas personalizadas. La aclaración principal es esta: el `excerpt` no es lo mismo que meter un corte manual con la etiqueta `more`. Qué hace el extracto manual y qué hace el automático Cuando usas el extracto de WordPress, puedes trabajar de dos maneras: con un extracto manual escrito por ti con un extracto automático generado desde el inicio del contenido Por defecto, ese extracto automático se basa en unas 55 palabras, aunque se puede modificar. El problema es que un corte automático no siempre resume bien un post, porque a veces solo toma el arranque del texto y puede dejar frases partidas o un contexto poco representativo. Por eso la recomendación implícita del episodio es bastante sensata: si el resumen importa de verdad, conviene escribir un extracto manual. Qué hace la etiqueta more y por qué depende de cómo esté hecho el tema La etiqueta `more` actúa como un corte dentro del contenido, no como un extracto real. Sirve para decirle a WordPress hasta dónde mostrar el texto cuando la plantilla usa el con

✏️ Suscribirse https://www.youtube.com/watch?v=4ctXUc228nc Optimizar una web WordPress no va solo de activar un plugin de caché al final del proyecto. En este episodio 253 de Negocios y WordPress, la conversación gira alrededor de una idea mucho más útil: el rendimiento empieza en cómo construyes la web, en cuántas capas metes, en cómo mides, en qué recursos cargas y en si de verdad necesitas cada plugin, cada builder o cada script. Además, el episodio conecta ese enfoque con otra capa muy actual: la IA como apoyo para construir soluciones más directas, más limpias y menos dependientes de herramientas intermedias. Desde ahí salen dos temas que encajan muy bien entre sí: WPO para WordPress y una forma más madura de desarrollar con contexto, skills y conectores más potentes. WP Rocket como punto de partida para hablar de rendimiento real El episodio usa WP Rocket como puerta de entrada para aterrizar el tema del WPO en algo práctico y reconocible. La idea no es presentar la optimización como un ejercicio académico, sino como algo que afecta de forma directa a la usabilidad, al SEO, a la conversión y a la experiencia real del usuario. Una de las ideas que más se repiten es que herramientas como WP Rocket resultan útiles porque condensan muchas tareas habituales de rendimiento en una interfaz más simple: caché, retraso de scripts, optimización de carga y análisis de oportunidades sin obligarte a navegar por paneles mucho más técnicos desde el primer minuto. Eso no significa que el plugin lo resuelva todo por arte de magia. Lo que sí deja claro la conversación es que un buen plugin de rendimiento puede acelerar mucho el trabajo cuando detrás hay criterio técnico, especialmente en proyectos donde necesitas una mejora rápida, mantenible y comprensible también para otras personas del equipo o para el cliente. También aparece una idea interesante: el rendimiento no debe mirarse solo como “la web carga más rápido”, sino como una parte de la comunicación del sitio. Cuando una página carga mejor, distrae menos, es más clara y obliga a esconder menos cosas detrás de artificios innecesarios, normalmente también funciona mejor a nivel de negocio. El WPO empieza en el desarrollo, no en el parche final Uno de los mensajes más valiosos del episodio es que muchas webs llegan tarde a la optimización porque intentan arreglar al final decisiones malas que se tomaron al principio. Ahí entra una regla muy simple: no meter cosas que no hacen falta. La conversación insiste mucho en varios frentes: no añadir plugins por inercia no resolver con capas extra algo que puedes hacer de forma nativa no cargar recursos en páginas donde no se usan no diseñar primero una web pesada para intentar rescatarla después Ese criterio aplica a casi todo: sliders, mapas incrustados, formularios que cargan scripts en toda la web, animaciones que no aportan nada o builders que introducen más complejidad de la necesaria en proyectos sencillos. Aquí el episodio conecta muy bien rendimiento con estrategia. No se trata solo de “limpiar código”, sino de preguntarte si de verdad hace falta cada cosa que estás añadiendo. Muchas veces, una web mejora a la vez en velocidad, claridad y conversión simplemente porque elimina capas que nunca debieron estar ahí. También se recuerda algo muy útil para proyectos nuevos y para proyectos heredados: conviene medir mientras desarrollas. Si instalas un plugin importante, si metes WooCommerce, si añades una integración o si cambias una parte clave de la web, lo sensato es revisar ahí el impacto. Esperar al final para hacer una gran auditoría suele ser bastante peor que detectar los problemas por el camino. Caché, Time to First Byte, imágenes y recursos: el Pareto del rendimiento Cuando el episodio entra en la parte más técnica, el foco está en las mejoras que más impacto suelen dar con menos complicación. Y ahí el primer gran bloque es la caché. La explicación es muy clara: si puedes servir

✏️ Suscribirse https://www.youtube.com/watch?v=zNEtVzsR_JM Delegar más trabajo técnico ya no va solo de automatizar tareas sueltas. En este episodio 252 de Negocios y WordPress la conversación junta dos planos que cada vez están más conectados: por un lado, el mantenimiento real de webs con Modular 3.0; por otro, una forma más madura de trabajar con IA, agentes, WordPress, MCP y sistemas propios sin perder control ni criterio. Modular 3.0 aprieta justo donde más duele en mantenimiento WordPress La primera mitad del episodio tiene un bloque muy práctico con Héctor de Prada para repasar qué cambia en Modular 3.0 y por qué eso importa de verdad en operación diaria. No se habla de una mejora cosmética, sino de funciones que atacan problemas muy concretos: escaneo de malware, detección de enlaces rotos, backups, safe updates y restauración cuando algo se rompe tras una actualización. Uno de los puntos más útiles es que el mantenimiento se plantea desde la realidad de quien gestiona muchas webs. No se trata solo de mirar una instalación cada vez, sino de poder aplicar configuraciones globales, presets por plan de mantenimiento y altas masivas de sitios para no repetir el mismo trabajo una y otra vez. También se comenta algo importante: las herramientas de este tipo no valen solo para el técnico. Sirven para trasladar mejor el valor al cliente, explicar incidencias, documentar vigilancias y demostrar que detrás del mantenimiento hay criterio operativo, no solo “tener plugins instalados”. En esa misma línea aparecen otras piezas interesantes del roadmap: regiones de datos, staging en el propio servidor, una API pública y la posibilidad de abrir más el sistema hacia agentes y automatizaciones futuras. Si quieres seguir esa parte, en el episodio recuerdan el acceso a Modular desde Negocios y WordPress. WordPress 7 mete la IA dentro del admin y no en un chat aparte Otra parte potente del episodio es la revisión práctica de WordPress 7 y de sus conectores oficiales de IA. Lo interesante no es tanto que “WordPress tenga IA”, sino cómo la integra: botones contextuales para sugerir títulos, extractos, etiquetas alt, términos o incluso imágenes destacadas dentro del sitio donde ya estás trabajando. Ese enfoque cambia bastante la experiencia, porque la IA deja de estar en una pestaña externa y pasa a estar justo en el punto donde editas contenido o tomas decisiones. La conversación también menciona algunos límites y pequeños fallos, pero la sensación general es que el camino tiene sentido. Además de eso, se comentan otros cambios de WordPress 7: `view transitions` para evitar el salto brusco entre pantallas una paleta de comandos más visible gestor de fuentes visibilidad condicional por dispositivo CSS personalizado por bloque El debate de fondo no es si todo eso es espectacular, sino si WordPress está empezando a colocar mejor las capacidades que realmente ahorran tiempo dentro del flujo normal de trabajo. Codex remoto y objetivos largos: menos chat suelto y más continuidad Cuando el episodio entra en Codex, la idea clave ya no es “preguntarle algo a la IA”, sino convertirla en una capa operativa continua. Ahí se habla de control remoto, trabajo desde móvil, conexión entre dispositivos y tareas más largas que no se limitan a una única respuesta. La parte más interesante es el concepto de trabajar con objetivos en Codex. En vez de lanzar una acción aislada, se define una meta concreta y el sistema sigue iterando hasta completarla o hasta alcanzar un criterio verificable. Eso acerca mucho más la IA a una forma real de delegación técnica que a un simple chat de apoyo. También se comenta el uso de herramientas intermedias para control remoto, la aparición de la función oficial para trabajar con Codex desde cualquier sitio y pequeños detalles como el seguimiento de uso con herramientas como CodexBar o la continuidad entre máquinas. El fondo, sin embargo, es más importante que la herr

✏️ Suscribirse https://www.youtube.com/watch?v=2Ly7D9ZiSaE La IA sigue ensanchando el campo de juego, pero en este episodio 251 la conversación no gira alrededor de anuncios grandilocuentes, sino de cómo meterla en sistemas de trabajo reales. Se habla de agentes con Codex y Kilo Code, de una migración práctica de cPanel a Vercel, de MCP dentro de WordPress y de una duda muy concreta: si diseñas con IA desde fuera, hasta qué punto tiene sentido volver a pasar por el builder. Codex, archivos `agents` y orquestación práctica Uno de los bloques más claros del episodio es el salto de usar IA como chat a usarla como sistema de agentes con contexto y roles definidos. El caso que se comenta con más detalle es Codex, sobre todo a partir de la posibilidad de definir agentes en archivos `agents`, darles instrucciones propias y dejar que el orquestador principal los invoque cuando toca. La parte interesante no es el truco de configuración en sí, sino lo que cambia a nivel de flujo. En lugar de repetir cada vez el mismo contexto o lanzar tareas desde cero, el sistema empieza a delegar según el tipo de trabajo, con nombres, roles e instrucciones más estables. También se menciona el uso de VS Code frente a Cursor, el valor de tener el chat mejor integrado y el descubrimiento de pequeños detalles como autocompletado, cambio de cuenta o sesiones centralizadas. Pero el fondo no está en el editor, sino en que la IA empieza a comportarse como una capa operativa del proyecto, no solo como una ventana donde pedir cosas sueltas. En esa misma línea encaja la aparición en otros medios de IA, Automatización y Codex con Victor Correal en No es asunto vuestro, donde se cruza automatización, programación y trabajo real con agentes. Kilo Code y el desarrollo con IA como sistema El episodio no se queda en Codex, también contrapone otras formas de organizar el desarrollo con IA. Ahí entra Kilo Code, con énfasis en agentes especializados, ejecución paralela, worktrees, gestión más explícita del sistema y una experiencia pensada para producción, no solo para asistencia puntual. La comparación sirve para aterrizar algo importante: hoy ya no basta con preguntar cuál es la mejor herramienta. Lo que de verdad importa es qué arquitectura de trabajo te deja montar cada una, cómo delega, cuánto contexto conserva y cuánto control te deja sobre lo que está haciendo. Ese matiz atraviesa buena parte del episodio. Las herramientas pueden parecer similares desde fuera, pero cambian mucho cuando el uso pasa de “hazme esto” a “ayúdame a mantener un proyecto vivo con criterios, contexto y especialización”. Migrar de cPanel a Vercel sin humo El bloque más práctico del episodio es seguramente la migración de TomaBumping desde un entorno en cPanel a Vercel. El proyecto estaba hecho con Next.js y en origen parecía viable mantenerlo en el servidor actual, pero aparecieron límites reales en compilación, sincronización y ejecución de procesos. La conversación deja una idea útil: migrar no es solo mover el proyecto a un hosting más moderno, sino entender qué necesita realmente ese flujo para funcionar bien. En este caso, el repositorio ya estaba en GitHub, así que importar el proyecto a Vercel fue sencillo. Lo importante vino después: variables de entorno, builds automáticos y sincronización de datos desde Notion hacia archivos JSON. Ahí aparece el límite clave de Vercel: no está pensado para guardar ficheros persistentes en disco durante la ejecución de ciertos comandos. Eso obligó a repensar la sincronización y a sacar esa parte fuera del runtime habitual. La solución elegida fue usar GitHub Actions para lanzar la sincronización, guardar artefactos, hacer commit y push, y dejar que ese push disparase el deploy en Vercel. No es una historia de “Vercel lo hace todo solo”, sino de elegir bien qué capa hace cada cosa. MCP, capabilities y contexto útil dentro de WordPress Otro bloque importante del episodio gira alrededor de MCP y de

✏️ Suscribirse https://www.youtube.com/watch?v=3lfND1xwZsI La IA ya no aparece como un tema aparte, sino como una capa que atraviesa casi todo el trabajo digital. En este episodio 250 se habla de diseño, desarrollo, automatización, WordPress y sistemas reales, con varias herramientas nuevas sobre la mesa y una pregunta de fondo: qué aporta de verdad cada una y dónde sigue mandando el criterio. La IA como capa transversal en proyectos digitales La idea central del episodio es que la IA ya está metida en casi todos los procesos digitales. No solo en el desarrollo, también en el diseño, en la automatización y en la forma de plantear proyectos completos. En la conversación se insiste en que ya no tiene mucho sentido tratar la IA como una temática aislada. Se parece más a una herramienta transversal: está en todas partes, pero no sustituye el problema de fondo, que sigue siendo crear proyectos útiles, mantenibles y con sentido de negocio. Ese matiz es importante porque evita convertir el episodio en una lista de novedades. Lo relevante no es que aparezcan más herramientas, sino cómo encajan dentro de un flujo real de trabajo. Claude Design, diseño conversacional y límites reales Una de las novedades más comentadas es Claude Design, una herramienta experimental de diseño conversacional de Anthropic. La conversación gira alrededor de su capacidad para trabajar con contexto, documentación, materiales visuales y sistemas de diseño, no solo para generar una pantalla rápida. Con un flujo basado en lienzo visual, comentarios sobre elementos concretos y exportación hacia otros formatos o hacia Claude Code. El punto interesante no es solo lo que genera, sino lo que implica para un flujo profesional: si una herramienta consume mucho contexto, tokens y tiempo, la pregunta deja de ser si puede hacerlo y pasa a ser si compensa usarla en un sistema repetible. La conclusión práctica es que Claude Design puede servir para explorar y validar direcciones visuales, pero no sustituye un proceso con fases claras, control y responsabilidad. Stitch, Mosaic y el diseño como sistema La conversación también conecta con herramientas que intentan convertir el diseño en una pieza más estructurada del sistema. Ahí entran ideas como Stitch, Mosaic y la posibilidad de trabajar con fuentes de verdad visuales que puedan leer los agentes. El interés no está solo en generar pantallas rápido, sino en que el diseño tenga una base reutilizable, legible y mantenible. Si una herramienta ayuda a que el diseño entre mejor en el flujo de agentes, desarrollo y validación, aporta algo más que una demo visual. En ese contexto, Mosaic aparece como otro ejemplo de builder o herramienta visual que alimenta el debate sobre cómo construir interfaces cuando la IA empieza a reducir la fricción técnica. La pregunta útil no es qué herramienta parece más espectacular, sino cuál encaja mejor en el proceso que quieres mantener. Bricks, MCP y skills para acelerar sin perder control Otra parte del episodio baja el debate a WordPress y a la construcción de sistemas con herramientas concretas. Se habla de Bricks, MCP, workshops y de cómo preparar contextos reutilizables para que los agentes no dependan de prompts enormes cada vez. La referencia de Notion a Skills para Bricks apunta justo a esa idea: usar archivos, contexto y convenciones para que la IA trabaje mejor dentro de un entorno concreto. Esto encaja con una idea que se repite durante el episodio: la IA no elimina la necesidad de arquitectura, la hace más importante. Cuanto más rápido puedes producir, más necesario es tener límites, fases y criterios claros. Codex, memoria y contexto de proyectos reales Codex aparece como apoyo operativo dentro de un flujo de trabajo real, no como sustituto del proceso completo. Se menciona su uso para abrir proyectos, recuperar contexto y preguntar qué se ha hecho en las últimas semanas. La referencia relacionada es Chronicle para Codex

✏️ Suscribirse https://www.youtube.com/watch?v=C2GNbhMeQCQ WordPress sigue siendo la base. Lo que cambia es todo lo que construimos alrededor: IA, automatización, bloques, decisiones de arquitectura y nuevas formas de pensar el mantenimiento. En el episodio 249 se cruzan varios debates que hoy ya afectan a proyectos reales, desde webs editables por no técnicos hasta la aparición de CMS nuevos que prometen seguridad aislando cada plugin. La idea central del episodio es clara: la tecnología puede acelerar el trabajo, pero el criterio sigue siendo lo que hace que un proyecto merezca la pena. Da igual si hablamos de un membership site, de una web de directorio, de SEO o de una interfaz construida con IA. Si el sistema no sirve al negocio, no compensa. Un proyecto real para gente que sí va a tocar la web El episodio arranca con un caso práctico y muy cotidiano: una web para un entorno de aceites esenciales, comunidad, contenidos y usuarios reales que sí van a tocar el panel. No es una maqueta teórica. Es una estructura que tiene que funcionar hoy, pero también mañana, cuando otras personas entren a editarla sin saber código. Ahí aparece una de las claves del episodio: construir para que el proyecto no dependa siempre del desarrollador. Si la base está bien planteada, la persona que gestiona el contenido puede cambiar bloques, mover piezas y entender la lógica general sin romper nada. En ese contexto se menciona el uso de GeneratePress y GenerateBlocks como base flexible. No por la marca en sí, sino por la idea que representan: bloques, queries, campos personalizados y control sin encerrar el proyecto en un sistema rígido. IA dentro del flujo, no por encima del criterio Codex aparece como una herramienta operativa. Se usa dentro de Cursor para tareas concretas, como ajustes de CSS o cambios pequeños, y no como sustituto de la arquitectura ni del criterio. Esa es la diferencia importante: la IA ayuda a producir mejor, pero no debe decidirlo todo. El episodio insiste en que la IA tiene sentido cuando quita fricción, no cuando añade complejidad innecesaria. Si algo se puede resolver de forma simple y mantenible, esa suele ser la respuesta buena. Y si el proyecto ya tiene una estructura sólida, la IA puede servir para pulir detalles sin rehacerlo todo. Aquí también aparece una reflexión útil para cualquier negocio con WordPress: si hay usuarios, autenticación, seguridad o pagos, no tiene sentido reinventar la rueda desde cero. La plataforma sigue siendo una ventaja, y la IA sirve para extenderla, no para desmontarla. emDash, seguridad y el argumento de “sucesor espiritual” La segunda gran parte del episodio se mete de lleno en emDash, el CMS nuevo que se está presentando como sucesor espiritual de WordPress. El debate no va solo de marketing: va de qué problema intenta resolver realmente y qué sacrificios mete por el camino. El argumento fuerte que se pone sobre la mesa es la seguridad. EmDash plantea un modelo donde cada plugin corre aislado, en una especie de cajón cerrado, con permisos muy limitados. Eso suena bien si tu preocupación es minimizar daños, pero también tiene una consecuencia evidente: dependes de esa tecnología y pierdes parte del ecosistema abierto que hace fuerte a WordPress. Se menciona además el contexto técnico de Cloudflare, Astro y TypeScript, y cómo esa base les permite construir un CMS moderno, rápido y pensado para trabajar con IA desde el principio. Pero el episodio cuestiona la trampa de fondo: si para mantener esa seguridad necesitas un ecosistema tan cerrado, ¿sigues compitiendo de verdad con WordPress o simplemente estás creando otra categoría? WordPress, membresías y proyectos que necesitan flexibilidad La reflexión práctica del episodio es bastante clara: para muchos proyectos reales, WordPress sigue siendo la pieza correcta. Especialmente cuando hablamos de memberships, contenidos restringidos, reservas, e-commerce o sistemas con lógica de negocio y us

✏️ Suscribirse https://youtube.com/live/giO7NebCWVI Título (SEO): Elementor V4 vs Bricks: novedades, problemas reales y el futuro de WordPress con IA Meta descripción: Análisis real de Elementor V4, Bricks, Make y WordPress Playground. Novedades, problemas y cómo afecta la IA al desarrollo web. Elementor V4, Bricks y WordPress con IA: lo que está cambiando (de verdad) Elementor V4, Bricks, WordPress Playground y herramientas como Make o Claude están redefiniendo cómo creamos webs hoy. Pero no todo es avance: también hay fricciones, decisiones a medias y cambios que afectan directamente al flujo de trabajo real. Este episodio no va de hype. Va de qué está pasando de verdad y cómo te impacta si trabajas con WordPress. Elementor V4: avance técnico… pero aún sin workflow real El nuevo Elementor Editor V4 introduce conceptos clave como: Variables Clases reutilizables Widgets “atómicos” Nuevo panel de estilos unificado Sobre el papel, suena muy bien. En la práctica, hay varios problemas importantes. Variables en Elementor: buena idea, ejecución limitada Ahora puedes crear variables de: Color Tipografía (fuente) Tamaño Pero aquí empieza el problema: No puedes crear variables para todo (ej: sombras, efectos) No se integran bien en todos los contextos No son realmente flexibles como en otros builders Ejemplo claro: si quieres hacer una variación de color con color-mix, Elementor no lo interpreta como color válido. Resultado: no puedes reutilizarlo correctamente. 👉 Es decir: la idea es buena, pero está a medias. Clases en Elementor: sin control real del orden Otro punto crítico es el sistema de clases. Puedes crear clases reutilizables… pero: No puedes controlar el orden de aplicación No puedes reorganizarlas fácilmente No sabes con claridad qué prioridad tienen Esto rompe uno de los pilares del desarrollo moderno: controlar el CSS de forma predecible. Widgets atómicos: el mayor cuello de botella Aquí está el mayor problema ahora mismo. Todo el sistema nuevo (clases, variables, etc.) solo funciona en ciertos widgets “atómicos”. Eso significa que: Muchos widgets siguen con el sistema antiguo No puedes aplicar el nuevo flujo a toda la web Estás obligado a trabajar “a medias” Ejemplo: Encabezado normal → sistema antiguo Encabezado atómico → sistema nuevo Esto genera un escenario bastante incómodo: 👉 No puedes usar Elementor V4 como base sólida todavía Lo que sí está bien hecho No todo es negativo. Hay mejoras claras: Mejor organización del panel (contenido / estilo / interacciones) Mejor limpieza del DOM en widgets nuevos Base técnica más moderna Pero ahora mismo, el problema no es técnico. Es de producto: 👉 No hay un flujo completo usable en producción real Bricks: roadmap sólido y visión clara Mientras Elementor está en transición, Bricks sigue avanzando con bastante coherencia. Se han presentado varias novedades importantes en su roadmap: IA integrada en el builder Generación de layouts Asistencia dentro del editor Posible integración con MCP (Model Context Protocol) Esto apunta a algo interesante: 👉 Diseñar desde IA y renderizar directamente en Bricks WooCommerce más personalizable Checkout multipaso Más control sobre componentes Mejor integración visual Importación avanzada (HTML, clases, variables) Una de las ventajas actuales: Puedes importar variables directamente Puedes importar clases CSS Puedes pegar HTML y convertirlo en layout Esto acelera muchísimo ciertos flujos: 👉 especialmente cuando vienes de código o IA Edición colaborativa y control de cambios Modo colaborativo en tiempo real Posibilidad de guardar sin publicar Esto acerca Bricks a workflows más profesionales (tipo Figma o Git-like). WordPress Playground y My WordPress: WordPress sin h