Negocios y WordPress

✏️ 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 contenido en un contexto de listado.

Eso implica algo importante: si tu tema usa funciones pensadas para extractos, el `more` no sustituye ese comportamiento. Solo tiene sentido si la plantilla está montada para tirar de contenido recortado y no de excerpt.

Este bloque del episodio recuerda una idea muy valiosa para quien trabaja con WordPress a medida: antes de tocar nada, conviene entender qué función está usando el tema y qué comportamiento quieres realmente. Muchas veces el problema no está en WordPress, sino en mezclar conceptos que parecen similares pero no lo son.

OpenCode, OpenRouter, Kilo Code y el coste real de trabajar con IA

Otra parte fuerte del episodio gira alrededor de las herramientas de desarrollo con IA y, sobre todo, del miedo razonable a depender demasiado de un único proveedor. Aquí entran OpenCode, OpenRouter, Codex, Codex Bar, Kilo Code y Visual Studio Code.

La reflexión es muy reconocible para cualquiera que ya esté trabajando con agentes: ahora mismo usamos la IA a un ritmo que probablemente no se sostenga igual en el futuro si todo se mantiene en planes muy subsidiados. Por eso el episodio insiste en tres ideas:

vigilar el coste real, no solo la cuota mensual

no casarte con un único proveedor o modelo

explorar alternativas locales o más abiertas antes de necesitarlas por obligación

Libertad frente a comodidad

Codex aparece como la opción cómoda cuando ya tienes una cuenta de ChatGPT y el flujo te resulta familiar. OpenCode y OpenRouter entran en cambio como piezas para ganar flexibilidad: cambiar de proveedor, probar modelos gratuitos, separar tareas más serias de tareas menores y no depender por completo de una sola interfaz.

La conclusión provisional que sale del episodio es muy honesta: aunque la libertad interesa, la comodidad pesa mucho en el trabajo diario. Y eso explica por qué cuesta salir de una herramienta cuando ya conoce tu contexto, tu proyecto y tu forma de trabajar.

Lo importante no es la novedad, sino el sistema de trabajo

Kilo Code y sus pasarelas aparecen como punto intermedio interesante porque combinan acceso a ficheros, extensiones y diferentes proveedores desde un entorno más conocido. Pero el mensaje de fondo no es “esta herramienta gana”, sino otro bastante más útil: cada vez importa más separar agente, modelo y pasarela para poder decidir mejor cómo trabajas.

No es un debate solo técnico. También es económico y estratégico. Si una parte del trabajo puede resolverse con modelos más baratos o gratis, y otra necesita más potencia, tiene sentido diseñar ese reparto con criterio en vez de tirar siempre de la opción más cómoda.

Una skill para ordenar música y lo que enseña sobre automatización real

El ejemplo más divertido del episodio probablemente sea también uno de los más reveladores. Elías cuenta cómo ha ido construyendo una skill para ordenar canciones descargadas, renombrarlas con un formato coherente, clasificarlas por décadas y estilos, y convertir ciertos archivos con FFmpeg cuando superan un umbral concreto de calidad.

Más allá de lo anecdótico, el caso enseña varias cosas:

la automatización útil suele nacer de una necesidad muy concreta

las reglas importan más que el brillo de la herramienta

cuanto mejor defines la estructura de destino, menos improvisación necesitas después

Ese bloque aterriza muy bien la diferencia entre usar IA para jugar y usarla para operar mejor. No se trata solo de pedir cosas y ver qué sale, sino de montar un sistema que funcione con cierta estabilidad mientras tú haces otra cosa.

También aparece un matiz importante: automatizar más significa consumir más tokens, más tiempo de cómputo y más recursos. Por eso el episodio vuelve a la misma idea de antes: la IA aporta valor cuando el ahorro de tiempo y fricción compensa el coste operativo que introduces.

WordPress vs IA: el problema no es WordPress, sino qué parte estás rehaciendo

La parte central del episodio llega con una discusión que ahora aparece mucho en comunidades técnicas: gente que dice que ha dejado WordPress porque con IA ya puede hacer su web más rápido y mejor. La respuesta que plantea el episodio no es defensiva, pero sí bastante crítica con ese relato cuando se formula de manera simplista.

La tesis principal es esta: muchas personas no están abandonando WordPress como sistema, sino una implementación concreta cargada de builders, plugins, decisiones heredadas y capas que quizá nunca debieron estar ahí.

La analogía que mejor resume este bloque es la de la casa o la reforma. Si lo que te molestaba era una bañera, quizá no tenía sentido tirar la casa entera para construir otra desde cero. Del mismo modo, si lo que fallaba era una parte de una web, no siempre hace falta sustituir todo el stack para resolverlo.

Qué sigue resolviendo muy bien WordPress

El episodio insiste en que WordPress todavía aporta mucho valor estructural, incluso en plena aceleración de la IA:

sistema de usuarios, roles y permisos

REST API y hooks

backend editorial ya resuelto

ecosistema de plugins y extensiones

base sólida para tiendas con WooCommerce

Todo eso sigue ahorrando muchísimo trabajo respecto a rehacer cada pieza desde cero. La IA puede acelerar personalizaciones, integraciones o frontend, pero no vuelve irrelevante que ya exista una base probada para operar.

Qué sí queda más cuestionado

Donde sí se nota un cambio fuerte es en las capas de maquetación repetitiva y en ciertos flujos basados en builders o temas multipropósito. La conversación apunta que herramientas como Elementor o incluso Bricks pueden seguir teniendo usos concretos, pero también que la IA hace más fácil volver al código en muchas partes del frontend sin perder velocidad.

Eso cambia bastante el equilibrio. Antes un builder podía ser el atajo natural para maquetar rápido. Ahora, si puedes generar HTML, CSS y lógica más limpia con ayuda de IA, algunas capas dejan de compensar tanto. No porque sean “malas”, sino porque el coste-beneficio ya no es el mismo.

El valor real se mueve hacia el criterio

El cierre del debate va más allá de WordPress. Si la ejecución técnica se abarata, lo que gana valor es otra cosa:

entender el negocio del cliente

elegir bien la arquitectura

decidir qué reutilizar y qué rehacer

interpretar datos y proponer mejoras

ampliar mantenimiento hacia SEO, UX, contenidos y rendimiento

La IA no elimina al profesional útil; deja más en evidencia al que solo aportaba ejecución sin criterio.

Cierre

El episodio 254 deja una conclusión bastante clara: la IA no convierte automáticamente a WordPress en una tecnología obsoleta, pero sí obliga a revisar mucho mejor por qué usamos cada capa. Si antes ya tenía sentido evitar complejidad innecesaria, ahora todavía más.

También deja una lectura práctica para quienes trabajan con clientes y proyectos propios: cada vez compensa menos vender solo implementación y cada vez compensa más vender criterio, estructura, mantenimiento ampliado y capacidad de decidir bien.

Si te interesa ese tipo de conversación, en la comunidad de Telegram de Negocios y WordPress siguen compartiendo ideas, herramientas y dudas muy en la línea de este episodio. Y si además te mueves en la comunidad WordPress, conviene tener también en el radar citas como WordCamp Galicia 2026, que el episodio menciona como parte del cierre. Esa quizá sea la mejor forma de resumir el 254: no se trata de elegir entre WordPress o IA como si fueran bandos, sino de usar cada cosa donde realmente aporta más.

✏️ 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 una página ya preparada en vez de obligar a WordPress a reconstruirla desde cero en cada visita, la respuesta mejora muchísimo. Por eso la caché de página sigue siendo uno de los pilares del WPO. A partir de ahí aparecen matices importantes, como las exclusiones necesarias en una tienda online o en páginas con partes dinámicas.

Junto a eso, se comenta el Time to First Byte, la importancia de medirlo y de entender qué está tardando realmente antes de que el navegador empiece a recibir contenido. El episodio menciona explícitamente el uso de GTmetrix y, sobre todo, del apartado Waterfall para detectar recursos problemáticos y cuellos de botella con más criterio.

Otro bloque clave es el de imágenes, vídeos y medios:

lazy loading para no cargar lo que aún no se ve

tamaños adecuados según el uso real de cada imagen

compresión razonable

evitar incrustados pesados cuando una alternativa más simple cumple mejor

Aquí sale un ejemplo muy bueno: muchas veces no hace falta incrustar un mapa de Google o un slider entero si una dirección clicable o una solución más ligera resuelven mejor el objetivo. Reducir carga no es solo comprimir archivos, también es dejar de servir cosas que apenas aportan valor.

Lo mismo ocurre con JavaScript y CSS. El episodio habla de diferir scripts, de evitar cargar recursos globales cuando solo se usan en una página concreta y de revisar con cuidado qué necesita estar disponible desde el primer momento y qué puede esperar. Esa parte enlaza con otro punto importante: no todo lo que la herramienta permite cargar debería cargarse siempre.

Builders, DOM, base de datos y limpieza estructural

Otra clave del episodio es que el rendimiento no depende solo del hosting o del plugin de caché, sino también de la estructura que arrastras. Y ahí entran el DOM, los builders, los metadatos, las consultas y la limpieza de base de datos.

La conversación no plantea un ataque simplón a Elementor, Bricks o JetEngine. De hecho, se reconoce que las herramientas han mejorado y que muchas veces son útiles. Pero también se remarca que cada capa extra tiene un coste, y que ese coste puede notarse en HTML inflado, listados más pesados, más scripts, más estilos o una base de datos más desordenada.

Se mencionan varios frentes donde conviene afinar:

grids o loops duplicados que podrían resolverse mejor

abuso de `postmeta`, repeaters o estructuras demasiado cargadas

residuos que dejan plugins al desaparecer

carga condicional de plugins para que no trabajen donde no deben

fuentes mal servidas o con demasiadas variantes

Ese bloque baja muy bien una idea importante: optimizar también es simplificar la arquitectura del proyecto. A veces el problema no está en una imagen grande o en una fuente mal cargada, sino en que la propia solución está pidiendo demasiado para hacer una tarea relativamente simple.

Por eso el episodio insiste en revisar DOM, consultas, tablas, PHP y estructura general. Incluso cuando se habla de CDN, se deja claro que ayuda en contextos concretos, pero nunca sustituye las buenas decisiones de base. Primero simplificar, luego acelerar.

IA, Auto Skills y NovaMira: menos dependencia de capas innecesarias

La parte de IA no aparece como un tema separado, sino como una forma de reforzar el mismo principio de fondo: construir mejor con menos fricción. En ese contexto se habla de skills, de sistemas propios y de reutilizar conocimiento operativo en vez de empezar siempre desde cero.

Uno de los ejemplos más claros es Auto Skills, que sirve para descubrir skills relacionadas con tu stack y con el tipo de proyecto que estás tocando. La reflexión que sale de ahí es útil: si ya existen procedimientos bien definidos para WordPress, performance o desarrollo, reutilizarlos puede ahorrarte muchísimo contexto y bastante improvisación.

También aparece NovaMira como conexión MCP para WordPress, con acceso a PHP, WP-CLI, ficheros y operaciones más potentes dentro del proyecto. Lo interesante no es solo la herramienta concreta, sino lo que permite: resolver tareas que antes empujaban a meter plugins o builders cuando en realidad bastaba con una solución más directa a nivel de código y estructura.

En esa misma línea, el episodio plantea que con IA se vuelve más factible construir:

grids complejos sin depender de varios loops visuales

sliders ligeros sin añadir plugins específicos

filtros y pequeñas interacciones con una implementación más limpia

procesos internos para revisar y documentar optimización

La conclusión de ese bloque es bastante potente: si la IA te ayuda a crear soluciones más nativas y mejor pensadas, también puede ayudarte a mejorar el rendimiento, porque reduce la tentación de añadir otra capa para resolver cada necesidad.

Además, entre las menciones laterales del episodio aparece WordPress.com Social como ejemplo de novedad del ecosistema y una reflexión útil sobre cómo algunas herramientas nuevas pueden encajar, pero sin perder nunca de vista el criterio principal: usar lo que aporta valor real y no lo que solo añade ruido.

Cierre

El episodio 253 deja una idea muy clara: el WPO para WordPress no es una fase final, sino una forma de pensar el desarrollo. Caché, Time to First Byte, imágenes, JavaScript, CSS, fuentes, builders, base de datos y CDN importan, sí, pero lo decisivo es cómo tomas decisiones antes de que todos esos problemas se acumulen.

También deja otra lectura útil: la IA puede ser una aliada real del rendimiento cuando la usas para simplificar, documentar, medir y construir soluciones más directas, no cuando la conviertes en otra capa más de complejidad.

Si trabajas con WordPress y quieres mejorar velocidad, claridad técnica y mantenibilidad, este episodio apunta bien el camino: menos inercia, más criterio, mejores mediciones y una arquitectura mucho más limpia desde el principio. Ese suele ser el verdadero atajo.

✏️ 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 herramienta exacta: si puedes mantener contexto, estado y objetivo, empiezas a trabajar de otra forma.

Kilo Code, Gastown y la idea de montar una “empresa” de agentes

El episodio amplía esa visión con Kilo Code, Gastown y Wasteland, que aparecen casi como un experimento de hacia dónde puede ir este modelo de trabajo. La propuesta suena incluso un poco exagerada: una especie de empresa de agentes especializados con infraestructura en la nube, roles concretos y una lógica más autónoma para ejecutar tareas de desarrollo.

Más allá del nombre o de la capa más friki del concepto, la parte relevante es esta: la conversación ya no gira solo alrededor del mejor modelo, sino de qué arquitectura de trabajo construyes encima. Qué roles hay, cómo se reparte el contexto, cómo se versiona, cómo se valida y qué piezas siguen siendo humanas.

Ese matiz es importante porque aterriza una idea bastante útil para cualquiera que esté mezclando IA con desarrollo real: la ventaja no está solo en que el sistema escriba código, sino en que pueda encajar dentro de un flujo con prioridades, checkpoints y especialización.

MCP, artefactos y maquetación con IA sin volver al builder

Uno de los bloques más valiosos del episodio es la defensa de un flujo más limpio para diseñar y maquetar con IA. En lugar de meter capas y plugins intermedios porque sí, la propuesta es trabajar con una fuente de verdad clara: arquitectura del proyecto, CPTs, campos personalizados, wireframe y framework CSS propio.

Ahí entra MCP con JetEngine como pieza de contexto. La gracia no es “hablar con WordPress” de forma genérica, sino poder extraer la estructura real del proyecto y usarla para que la IA maquete con sentido desde la primera pasada. Si el sistema conoce los tipos de contenido, los campos y la estructura que debe pintar, se equivoca menos y necesita menos correcciones.

La conversación lo contrapone bastante bien con el uso indiscriminado de builders. No porque Elementor o Bricks sean inútiles, sino porque si ya has resuelto el diseño, el contexto y la implementación con artefactos bien definidos, volver a traducirlo todo a otra capa puede meter más fricción que valor.

Además, se insiste en algo práctico: cuando la base está bien montada, ya no solo se acelera la maquetación. También se vuelven más accesibles pequeñas mejoras que antes daban pereza, como sliders ligeros, ajustes visuales o comportamientos más avanzados sin cargar el proyecto de complejidad innecesaria.

Skills, workshop y criterio: la IA funciona mejor cuando el sistema está bien pensado

El cierre del episodio refuerza una idea que atraviesa toda la conversación: lo importante no es acumular herramientas, sino convertir procesos repetidos en piezas reutilizables. Por eso las skills aparecen como núcleo del sistema: ahorran contexto, reducen ruido y permiten que la IA repita mejor lo que ya has validado.

También se habla del workshop, de sistemas propios, de Git como base para versionar, de staging, de validaciones y de todo lo que todavía no conviene automatizar del todo. Ese matiz es clave porque baja el discurso a tierra: delegar no significa desaparecer del proceso, sino diseñar mejor los puntos donde la IA puede ayudar sin romper nada.

Incluso cuando aparecen herramientas más pequeñas o laterales, como TidyCal para reservas de pago o NovaMira para trabajar con WordPress y builders, el criterio sigue siendo el mismo: si una pieza simplifica un problema concreto, bien; si añade otra capa innecesaria, probablemente sobra.

Cierre

Este episodio 252 deja una lectura bastante clara: delegar el código a los agentes no va de entregarles el volante sin más, sino de construir un sistema mejor. Modular 3.0, WordPress 7, Codex remoto, Kilo, MCP, JetEngine o las skills apuntan todos en la misma dirección: más contexto útil, más automatización con sentido y menos dependencia de flujos torpes o repetitivos.

Si estás mezclando WordPress, IA, mantenimiento, diseño y desarrollo real, aquí hay una idea que merece quedarse: antes de añadir otra herramienta, revisa si ya tienes una fuente de verdad clara, un proceso versionable y un criterio de delegación sólido. Ahí es donde la IA empieza a aportar de verdad.

✏️ 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 cómo conectar la IA con WordPress de una forma realmente útil. La idea no es solo pedirle que cree contenido, campos o estructuras, sino darle acceso a contexto técnico del proyecto: tipos de campo, formatos, relaciones y estado real del sistema.

Ese matiz es importante porque cambia por completo el papel de la IA. En vez de operar a ciegas, puede leer antes de escribir, inspeccionar antes de generar y trabajar con una base técnica más cercana a lo que ya existe en el proyecto.

La conversación conecta esto con vídeos y contenidos propios sobre WordPress, capabilities y automatización, y con una visión bastante pragmática: MCP no aporta tanto por “hacer cosas” como por mejorar la calidad del contexto con el que las hace.

También aparece como telón de fondo la idea de WordPress como ecosistema suficientemente flexible para seguir siendo útil en proyectos modernos. En ese sentido encaja bien el hub temático de WordPress, que sirve como referencia de contexto y especialización en torno al CMS.

NovaMCP, Bricks, Elementor y el cortocircuito del builder

La parte más crítica del episodio aparece cuando se habla de NovaMCP, Bricks y Elementor. Se reconoce el interés del plugin y su potencial para exponer tools, leer estructura del sitio, editar archivos, ejecutar código o trabajar con widgets y estilos globales.

Pero justo ahí aparece la objeción más valiosa del episodio: si ya estás diseñando con IA desde fuera, con dirección de arte, framework CSS y artefactos propios, añadir una capa intermedia para volver a traducir eso a un builder puede ser más fricción que ayuda.

En otras palabras, el problema no es si Bricks o Elementor son compatibles con IA. Lo son. El problema es si esa compatibilidad mejora de verdad el sistema o si simplemente añade complejidad, gasto de tokens y dependencia de otra interfaz más.

La crítica no es anti-builder. De hecho, se reconoce que pueden tener sentido para ciertos layouts, para importar CSS o para iterar rápido sobre una base ya creada. Pero la conclusión práctica es bastante clara: si la IA te ayuda precisamente a salir del builder, volver a meterlo en el centro del flujo puede ser un paso atrás.

Make, flyers, emails y automatizaciones pequeñas que ya ahorran tiempo

El cierre del episodio baja la IA a automatizaciones mucho más concretas y accesibles. Aquí no hacen falta agentes complejos, ni un VPS, ni una infraestructura excesiva. Se habla de Make como herramienta para analizar flyers, capturas de pantalla o emails, extraer información estructurada y crear registros útiles en otros sistemas.

Los ejemplos son muy claros: detectar información de carteles, convertir una captura en un JSON trabajado, o reenviar un email para que la IA extraiga campos, genere un resumen y cree el evento correspondiente en Airtable.

La enseñanza de este bloque es sencilla pero potente: no siempre hace falta montar un sistema sofisticado para obtener valor real de la IA. Muchas veces basta con un webhook, un módulo bien planteado y una extracción estructurada que elimine trabajo repetitivo.

Ese enfoque además encaja muy bien con el tono general del episodio: menos obsesión por la herramienta de moda y más foco en si resuelve una tarea concreta con claridad y sin meter complejidad innecesaria.

Cierre

Este episodio 251 deja una idea bastante útil para cualquiera que esté mezclando IA, WordPress y desarrollo diario: no todo lo que se puede conectar conviene conectarlo. Codex, Kilo Code, Vercel, GitHub Actions, MCP, Bricks, Elementor o Make pueden encajar en un sistema potente, pero no por acumulación sino por criterio.

La parte valiosa no está en usar más capas, más agentes o más builders, sino en elegir qué papel juega cada pieza. Cuando eso se hace bien, la IA acelera de verdad. Cuando no, solo añade ruido.

Si te interesa esta mezcla de WordPress, automatización, agentes y decisiones técnicas con impacto real, este episodio deja bastante material para replantear flujos, quitar pasos innecesarios y quedarte con lo que sí aporta valor.

✏️ 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, una herramienta de investigación para mejorar la memoria de Codex aprovechando el contexto de pantalla.

Ese enfoque tiene una ventaja evidente: reduce la necesidad de repetir contexto y permite que la IA entienda mejor el trabajo acumulado. Pero también trae una advertencia importante: si se guarda contexto sensible en archivos locales o se depende de permisos de pantalla, la productividad no puede separarse de la privacidad y la seguridad.

WP Apps, extensiones aisladas y el futuro de WordPress

El episodio también toca el debate sobre cómo debería evolucionar WordPress cuando aparecen nuevas formas de extenderlo. WP Apps plantea un modelo de extensiones aisladas, con permisos acotados y sin acceso directo a base de datos, sistema de archivos o ejecución PHP.

Ese planteamiento conecta con una preocupación de fondo: WordPress necesita seguir siendo flexible, pero también más seguro y predecible. Si el ecosistema quiere mantener su valor, no basta con añadir capas. Tiene que resolver mejor cómo conviven extensibilidad, seguridad y rendimiento.

La idea de las extensiones aisladas resulta interesante porque cambia la pregunta de “qué plugin instalo” a “qué permisos necesita realmente esta pieza del sistema”.

Matt Mullenweg, gobernanza y el rumbo del proyecto

La parte de WordPress no se queda solo en herramientas. También aparece el debate sobre el rumbo del proyecto y las críticas de Matt Mullenweg a procesos, contribución y gobernanza.

La referencia relacionada en Notion es el análisis de WP Podcast sobre Matt Mullenweg y el rumbo de WordPress, donde se recogen tensiones sobre Five for the Future, transparencia, tickets acumulados y control del proyecto.

Este bloque es importante porque equilibra la conversación. La IA y las nuevas herramientas aceleran mucho, pero WordPress sigue teniendo preguntas estructurales abiertas. Si el proyecto quiere seguir siendo la base de tantos negocios, la gobernanza importa tanto como la tecnología.

Cierre

Este episodio deja una conclusión bastante clara: la IA ya está en todas las capas del trabajo digital, pero el valor real sigue estando en cómo la integras. Claude Design, Codex, Bricks, WP Apps o Mosaic son piezas distintas de un mismo cambio: cada vez podemos construir más rápido, pero también necesitamos procesos más claros.

La clave no es perseguir cada novedad, sino decidir qué entra en tu sistema, qué problema resuelve y qué coste añade. Ahí es donde se separa una herramienta útil de una distracción.

Si algo queda claro es que la pregunta ya no es si usar IA o no, sino cómo usarla sin perder claridad, control y sentido práctico.

Enlaces

TomaBumping

BatallasRap

Skills Fernando Tellado