✏️ Suscribirse https://www.youtube.com/watch?v=D0dpjxQfOmE ¿Qué ocurre cuando dejamos de pensar en una herramienta aislada y empezamos a conectar procesos, conocimiento y proyectos? En este episodio contamos cómo estamos usando agentes y skills para trabajar, producir contenido y experimentar con nuevas ideas de negocio. Delegación y skills para el trabajo diario Elías explica que, aunque tiene agentes preparados para distintas tareas, no siempre se acuerda de invocarlos o de elegir el modelo más apropiado. Por eso ha añadido a sus instrucciones una pauta para que el asistente valore cuándo merece la pena delegar y avise si otra capacidad sería más adecuada. La intención es reducir decisiones repetidas sin convertir cada petición en un proceso complejo. También cuenta cómo ha preparado un flujo para Reflexiones de un Geek desde Bilbao: reunir pequeñas grabaciones, editarlas y preparar los materiales del episodio. La skill de audio y vídeo ha ido creciendo hasta contemplar clips y recursos visuales de apoyo. Una prueba con Descript, sin embargo, le hizo replantearse el flujo al comprobar que sus peticiones al editor de IA consumían créditos adicionales. Otra mejora ha sido crear una skill que revisa la coherencia de otras skills después de modificarlas, buscando duplicidades y contradicciones. Es un ejemplo de cómo una tarea repetida puede incorporarse al propio sistema de trabajo. Contratrazo y Gravity: aprender a través de proyectos Yannick comparte el avance de Contratrazo, una web de demostración que ya funciona en WordPress y que seguirá incorporando funcionalidades. El proyecto utiliza un briefing ficticio, pero se aborda como un encargo real para recorrer las decisiones y los problemas que pueden surgir. El otro proyecto es Gravity, un anuncio de prueba para una marca de perfumes. En él ha usado Blender para preparar referencias de escenas y ayudar a dirigir el resultado audiovisual. Los errores y ajustes del proyecto se convierten en instrucciones reutilizables para futuros anuncios, desde el guion y el storyboard hasta las referencias visuales. La idea de La Máquina del Branding es enseñar mediante proyectos completos en directo: mostrar lo que funciona, lo que falla y por qué se toman ciertas decisiones. Yannick hablará también de su forma de enseñar a la IA a desarrollar proyectos en WordCamp Valencia. De un sistema para webs a un sistema para negocios El sistema LMB está evolucionando para acompañar proyectos más allá del desarrollo de una web: desde explorar una idea hasta pensar en su lanzamiento, marketing y mantenimiento. Yannick quiere que sea modular, de modo que pueda incorporar recursos ya probados, como el flujo de producción audiovisual de Gravity. Una de sus pruebas consiste en crear perfiles de clientes y pedirles opiniones sobre precios, propuestas o miniaturas. Pueden servir para explorar preguntas y enfoques, aunque esas respuestas simuladas no sustituyen el contraste con clientes reales. Los dos coinciden en la importancia de conocer el proceso y aportar criterio. Un sistema puede ayudar a ejecutar tareas, pero la experiencia de quien dirige el proyecto sigue siendo clave para juzgar un plano, una estrategia o una solución técnica. Memoria, contexto y complejidad de los agentes Elías cuenta cómo conecta las instrucciones del asistente con sus mapas y notas de Obsidian, para recuperar el contexto de cada área y llevar reflexiones útiles a las notas correspondientes. Yannick compara ese enfoque con la memoria de sus herramientas y con resúmenes propios de cada proyecto. Tener más contexto también tiene un coste. Si cada tarea pequeña activa demasiadas reglas, consultas y documentos, el sistema puede gastar más tiempo y recursos de los necesarios. La conversación apunta a mantener información accesible y actualizada sin convertir cada cambio sencillo en una reunión interminable. Experimentos cotidianos y seguridad en PHP Comentan ejemplos de lo qu

✏️ Suscribirse https://www.youtube.com/watch?v=2pnxHJzAu5U Un sistema de IA para el negocio puede empezar con algo tan sencillo como una carpeta y unos cuantos documentos. En este episodio, Yannick nos enseña cómo está construyendo LMB Brain: un lugar donde reunir contexto, seguir sus proyectos y convertir tareas repetidas en procesos reutilizables. También repasamos sus últimos eventos, las novedades de JetEngine y el trabajo que está haciendo alrededor de las sesiones de La Máquina del Branding. La idea que conecta todo es avanzar con necesidades reales y mantener el control sobre lo que se delega. Los eventos y una metodología que sale de WordPress Yannick viene de participar en la meetup de Collado Villalba y en WP Agency Forum. De la primera destaca el ambiente cercano de una charla en un bar. Del segundo, una dinámica de networking que organiza grupos para que los asistentes conozcan otras agencias y compartan sus problemas. En esas conversaciones percibe interés por la IA, pero también incertidumbre. Cuesta anticipar cómo se trabajará dentro de un año, y esa sensación aparece tanto en profesionales independientes como en agencias. La siguiente cita que comenta es WordCamp Valencia, con una charla sobre cómo está enseñando a la IA a desarrollar proyectos WordPress. Lo que quiere compartir es la forma de trabajar: investigar, planificar y conservar lo aprendido para reutilizarlo. El sistema que empezó aplicando a webs se está extendiendo a otros proyectos: un anuncio de perfume y, más adelante, un videojuego. Cuando termine un proceso probado, la intención es recoger ese conocimiento en agentes y skills que sirvan para futuros trabajos. JetEngine: estructura de datos y consultas a archivos Aunque está reduciendo plugins y builders, Yannick sigue utilizando JetEngine para organizar la estructura de sus proyectos. Le resulta útil para crear arquitectura de datos mediante MCP, aunque ya no dependa de sus widgets para resolver el frontend. Entre las novedades comenta los repeaters dentro de otros repeaters. Pueden encajar en algunos casos, pero plantea una alternativa: cuando la estructura se complica, quizá resulte más cómodo separar la información en tablas y relacionarlas. La otra novedad que destaca es File Query, con consultas a archivos JSON, CSV o XLSX desde Query Builder. Hay información que interesa consultar sin convertir cada elemento en una entrada de WordPress. Una agenda externa o una lista grande de registros puede encajar mejor en ese planteamiento, especialmente cuando intervienen automatizaciones con n8n. El cierre del episodio recupera su postura sobre los builders: no prevé utilizarlos en proyectos propios. Aun así, deja abierta la posibilidad de probar CrocoBuilder mediante MCP como ejercicio para contrastar el resultado. LMB Brain crece a partir del trabajo real LMB Brain comenzó con pocos documentos, entre ellos uno sobre su tono al escribir. Después fueron apareciendo preguntas sobre suscripciones, finanzas, contenido o proyectos, y la información útil se fue guardando para próximas consultas. El sistema se construye según se necesita, y las skills aparecen cuando una tarea empieza a repetirse. No parte de intentar automatizar todo el negocio de una vez. La organización distingue varias piezas: Contexto: información estable del negocio y su forma de trabajar. Estado: dónde están los proyectos y qué asuntos requieren atención ahora. Proyectos: pequeños registros que permiten mantener una visión de conjunto. Editorial: criterios y materiales para sus contenidos. Workflows: procesos repetibles, como preparar un evento o cerrar una sesión. Los archivos completos de cada proyecto siguen en su ubicación propia. El cerebro conserva el contexto y el estado necesarios para relacionar el trabajo, sin meter todas las webs y sus recursos dentro de una única carpeta. También está preparando una skill para elegir modelos según la tarea y los servicios que

✏️ Suscribirse https://www.youtube.com/watch?v=HKJNqUc_a98 Estamos cambiando herramientas, servicios y hasta la forma de crear contenido. Pero la pregunta que atraviesa este episodio es bastante sencilla: ¿qué queremos resolver y cómo tiene sentido hacerlo ahora? Hablamos de agentes de IA que ejecutan tareas, de un negocio que necesita dejar atrás el trabajo manual y de cómo convertir proyectos reales en contenido útil. Y terminamos planteándonos si Negocios y WordPress sigue siendo el nombre adecuado para todo lo que estamos contando. Agentes de IA que trabajan mientras nosotros hacemos otras cosas Elías empezó investigando qué diferencia a un agente de una skill o una tarea programada y acabó descubriendo que ya estaba usando buena parte de ese planteamiento. Si unas instrucciones permiten procesar el correo y podemos programar su ejecución, ya tenemos un proceso que trabaja con cierta autonomía. En su caso, utiliza Codex para ejecutar las skills que procesan Gmail y el Inbox de Todoist. Mantener la conversación en el mismo chat le permite revisar propuestas, resolver dudas y ajustar las instrucciones con lo que va aprendiendo. Después ha replicado el procesamiento del correo con agentes de Make. El flujo reúne mensajes por conversación, agrupa hilos relacionados y crea tareas en Todoist. Por ejemplo, un aviso de caída de una web y otro de recuperación pueden acabar en una única tarea que permita revisar lo sucedido. La autonomía tiene una contrapartida: cuesta más entender y corregir lo que pasa dentro de una caja negra. En un chat resulta sencillo decir «esto sí quiero revisarlo» y afinar la regla. En una automatización hay que pensar también cómo vamos a supervisar sus decisiones. Yannick cuenta además sus primeras impresiones de Kilo Swarm: varios agentes trabajan en partes distintas de un proyecto y comparten descubrimientos o bloqueos. La coordinación importa tanto como repartir tareas; lo que descubre un agente puede cambiar el trabajo que están haciendo los demás. Elegir el modelo también forma parte del proceso No todas las tareas necesitan el modelo más potente. Ambos comentan cómo mantienen reglas y escalas para relacionar la dificultad del trabajo con los modelos disponibles, su coste y las suscripciones que ya tienen. También hablamos de modelos orientados a devolver clasificaciones y valores estructurados. Para una tarea como asignar categorías a un vídeo, conviene distinguir entre necesitar una decisión concreta y necesitar una respuesta extensa en lenguaje natural. Un hotel canino necesita procesos, no una colección de herramientas Uno de los posibles proyectos de Elías es un hotel canino que lleva muchos años funcionando y acumula demasiado trabajo manual. Su aplicación actual se ha quedado corta: la información de las mascotas está dentro de la ficha del cliente y resulta difícil gestionar relaciones, cuidados y estancias. La propuesta es llevar esa información a Airtable y separar las entidades que el negocio necesita manejar. A partir de ahí, preparar vistas para el trabajo diario: Qué mascotas entran y salen cada día. Qué cuidados especiales necesita cada una. Qué reservas hay y cómo afectan a la ocupación. Qué pagos se han recibido y qué importes quedan pendientes. WhatsApp seguiría siendo un canal de comunicación habitual. La mejora puede ser tan práctica como abrir la conversación del cliente desde su ficha, con un mensaje preparado a partir de los datos de la estancia. Antes de automatizar hay que definir las reglas reales del negocio. Un suplemento por almacenar comida refrigerada parece un detalle pequeño, hasta que debe entrar en el cálculo de lo que se cobra. Esas condiciones van apareciendo durante las conversaciones y afectan al alcance y al presupuesto. Esto conecta con el servicio que Elías está redefiniendo: vender una solución que incluya una base de datos, vistas de trabajo y un proceso principal, con límites claros. El objetivo es

✏️ Suscribirse https://www.youtube.com/watch?v=cq6E8XO6CFk Trabajar con agentes de IA cambia mucho cuando dejamos de pedirles tareas sueltas y empezamos a organizar qué pueden hacer, qué información necesitan y cómo deben continuar un proyecto. El reto no es probar más herramientas, sino conseguir que ayuden a sacar trabajo adelante. Esa idea conecta la evolución del sistema de Elías, la nueva etapa de La Máquina del Branding y la conversación con Héctor de Prada y Juanma sobre WP Agency Forum. Preparar las tareas antes de delegarlas a los agentes El sistema de Elías empezó tomando tareas de los roadmaps de proyectos locales. Después incorporó proyectos de Todoist y aparecieron dos problemas: demasiadas propuestas y tareas que todavía no estaban listas para ejecutarse. La solución pasa por distinguir tres estados: Needs input: falta contexto o hay que estudiar la tarea antes de hacerla. Ready: la tarea está preparada para entrar en el trabajo que puede asumir el sistema. Manual: requiere intervención personal y queda fuera de la ejecución con agentes. Una skill reúne el proceso y distingue dos modos. WORK busca trabajo ejecutable; PREPARE ayuda a aclarar las tareas pendientes de contexto. Así, una sesión puede dedicarse a explicar qué hay que hacer y otra a ejecutarlo, sin volver a discutir continuamente tareas que aún no están preparadas. También entran en juego los objetivos: una mejora de SEO, por ejemplo, puede generar varias tareas relacionadas. Si un objetivo ya está en marcha, conviene ofrecer trabajo que lo haga avanzar, además de atender las urgencias que cumplan los criterios. La continuidad importa tanto como elegir la siguiente tarea. Modelos y skills para procesos que se repiten Elías explica una escala de cinco niveles para subir de modelo cuando una tarea necesita más capacidad. También distingue entre un modo orientado a inteligencia y otro a eficiencia. Yannick cuenta cómo combina proveedores y reserva modelos más capaces para consultas de estrategia o trabajos concretos. La conversación refleja experiencias personales de uso y consumo. No basta con escoger un modelo porque permita más peticiones: hay que comprobar si resuelve el trabajo con el contexto y la autonomía que esperamos. Si obliga a supervisar cada paso, el ahorro de consumo puede no traducirse en ahorro de tiempo. Las skills permiten reutilizar procesos que antes dependían de prompts o scripts sueltos. Entre los ejemplos aparecen el registro de tiempo con TMetric, el diario de Obsidian, la consulta de Google Analytics y el análisis de actividades guardadas en Airtable. En el caso de los paseos, Make ejecuta la sincronización a través de RunKeeper y la skill analiza los datos. Un archivo adicional puede completar información que no llega por esa integración. El interés está en obtener una comparación útil, no en acumular cifras sin interpretarlas. También se comenta una skill para analizar MP3 mediante su espectro: el bitrate declarado por un archivo no basta para determinar la calidad de su origen. Convertir estos procesos en instrucciones reutilizables reduce el trabajo de explicar cada vez qué hay que consultar y cómo presentar el resultado. La nueva Máquina del Branding se centra en proyectos Yannick presenta una etapa en la que el proyecto guía el contenido. La herramienta se elige según la necesidad: una web, una aplicación o un canal de YouTube pueden exigir procesos distintos. Aprender a conseguir un resultado pesa más que recorrer todas las opciones de un programa. La propuesta tiene dos espacios. El laboratorio muestra el desarrollo de proyectos propios en sesiones en directo; la mesa de proyectos ayuda a la comunidad a analizar y avanzar sus ideas. Durante la grabación se planteaban dos sesiones semanales de laboratorio y una sesión los viernes para proyectos de la comunidad. Los primeros trabajos previstos eran una web completa con su sistema de agentes y un canal de astronomía con

✏️ Suscribirse https://www.youtube.com/watch?v=tm_Vi2dA7lg La inteligencia artificial empieza a entrar en más partes del trabajo diario: automatizaciones, gestión de tareas, programación y creación de contenido. En este episodio probamos varias de esas posibilidades y aparece una idea común: la utilidad de un agente depende tanto de la herramienta como del contexto que recibe y de cómo revisamos su trabajo. Los nuevos agentes de Make llevan la IA al escenario Make incorpora agentes dentro de sus escenarios. En la conversación, la diferencia respecto al enfoque anterior está en que el agente se configura como parte de un escenario, con módulos que pueden funcionar como herramientas. También se comenta la posibilidad de pasar tareas a subagentes y de aportar información desde archivos o servicios conectados. Eso abre usos interesantes para procesos que hoy se hacen en local. Por ejemplo, algunas tareas podrían resolverse desde una automatización alojada en Make, con acceso a información de la empresa, en vez de depender del ordenador o de montar infraestructura propia. La decisión seguiría dependiendo del problema: a veces encajará una automatización; otras, una skill, un proceso local o una aplicación existente. La conversación también distingue el trabajo del agente de los pasos deterministas del escenario. El agente puede decidir qué herramientas utilizar según lo que encuentre, mientras que los demás módulos continúan ejecutándose según el flujo configurado. Esa combinación permite introducir decisiones de IA sin convertir toda la automatización en una caja negra. Maia analiza bien, pero la ejecución necesita revisión Maia es el asistente conversacional que aparece en el editor de escenarios de Make. Se le pueden pedir cambios o ayuda para construir un escenario. En la prueba contada en el episodio, su análisis ofreció una sugerencia útil, pero al pedirle que la ejecutara movió módulos de forma confusa y no pudo resolver una desvinculación. Por eso, la impresión fue más favorable para tareas acotadas, como ayudar a mapear muchos campos, siempre revisando el resultado, que para delegarle cambios completos. Que un asistente entienda una petición o proponga una mejora no significa que vaya a modificar correctamente una automatización. La experiencia también sirve para explicar por qué importa el contexto. Un chat dentro del editor puede conocer el escenario, pero no necesariamente la documentación, las decisiones y los datos del proyecto. La referencia a Maia, el asistente de Make, aparece precisamente dentro de esa conversación sobre lo que puede hacer un asistente cuando trabaja con información limitada. Probar otros modelos sin depender de un único proveedor Otra prueba del episodio es conectar OpenCode con el servicio de inferencia de Hetzner. La configuración se presenta como una alternativa compatible con la API de OpenAI para probar modelos como Qwen. En la conversación se menciona que el acceso era experimental, así que conviene entenderlo como una opción que se estaba explorando, no como una garantía permanente de disponibilidad. El interés no está solo en encontrar un modelo concreto. Poder cambiar de proveedor permite combinar modelos distintos según la tarea y el consumo disponible. En el episodio se habla de usar modelos más sencillos para tareas rutinarias y reservar los más capaces para trabajos que requieren más razonamiento. La flexibilidad entre proveedores aporta margen para ajustar coste y capacidad sin depender de una sola plataforma. La documentación relacionada con esta prueba está en el servicio de inferencia de Hetzner. Un sistema de agentes necesita instrucciones, contexto y control Parte de la conversación gira en torno a qué diferencia a una skill de un agente. Una skill carga instrucciones para realizar un proceso concreto. En un entorno de agentes también se pueden definir roles, modelos, delegación y trabajo en paralelo. La frontera depende de las ca

✏️ 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