WordPress

✏️ Suscribirse

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.

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.

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 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:

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 ya tiene disponibles. El objetivo es ajustar la herramienta al trabajo que necesita hacer.

Cerrar un directo activa un proceso que aprovecha el contenido generado. AssemblyAI proporciona la transcripción y los subtítulos; a partir de ese material, Kilo recoge los momentos importantes para las notas de la sesión en la web y propone una idea para un short.

Para las explicaciones visuales, Yannick está utilizando HyperFrames. El sistema identifica pasajes que pueden ganar claridad con un motion graphic, prepara un guion y genera piezas ajustadas a su estilo visual. Además, le indica dónde colocarlas y las sincroniza con lo que está diciendo.

Automatizar la preparación del material le permite tenerlo a mano sin renunciar a decidir cómo utilizarlo. El estilo minimalista de esas animaciones es una elección suya, no una limitación que atribuya a la herramienta.

Con la newsletter sigue un criterio parecido. Las automatizaciones con n8n reúnen información de las sesiones y de las consultas de Discord, conservando el aprendizaje y evitando identificar a los miembros. Después, Yannick quiere seguir redactando el mensaje y añadiendo sus reflexiones.

La clase gratuita Empieza aquí busca dar una base para entender el resto de sus contenidos. En unos 54 minutos combina una parte conceptual con una práctica.

Primero explica prompts, contexto, artefactos, modelos, agentes, skills y conexiones MCP. Después construye un sistema pequeño para validar ideas y proyectos, conectado con Notion.

El aprendizaje consiste en entender cómo varias tareas forman un sistema reutilizable, sin exigir que todo el mundo use su mismo editor. Yannick trabaja con Visual Studio Code y Kilo, y comenta sus primeras pruebas con Kilo Desktop como una posible entrada más accesible para quienes no han tocado código.

La newsletter que está preparando servirá también para seguir lo que ocurre en la comunidad: sesiones, consultas resueltas y reflexiones de la semana, sin tener que verlo todo para enterarse de los avances.

La última reflexión parte de un problema concreto: las dificultades para conectar membresía, cobros y facturación. Yannick cuenta incidencias en su combinación de Restrict Content Pro, Stripe, PayPal y Quaderno, que le han llevado a reenviar facturas y revisar integraciones.

Con las posibilidades actuales de desarrollo con IA, se pregunta hasta qué punto tendría sentido construir un sistema propio de facturación o membresía que responda mejor a su forma de trabajar. Que sea más fácil desarrollarlo no elimina la necesidad de revisar seguridad y obligaciones legales.

La conversación lo presenta como una posibilidad que quiere estudiar, no como un reemplazo ya terminado. También comenta su intención de contar con ayuda especializada para abordar los aspectos legales de los proyectos.

LMB Brain muestra una forma de avanzar por pasos: guardar contexto útil, detectar repeticiones y convertirlas en procesos que ayuden al negocio. Desde la estructura de datos de una web hasta la preparación de una newsletter, el criterio sigue estando en decidir qué delegar y qué parte del trabajo quieres conservar.

¿Qué tarea de tu negocio repites lo suficiente como para empezar a convertirla en un proceso reutilizable?

✏️ Suscribirse

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.

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.

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.

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:

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 alejarse de los packs de horas y facilitar que el cliente entienda qué problema va a resolver y qué queda fuera.

Yannick ha relanzado La Máquina del Branding y, esta vez, la transformación va bastante más allá del diseño. Para arrancar ha priorizado una estructura clara y sencilla, construida con ayuda de su sistema de agentes.

La migración también reduce dependencias: salen Elementor y JetSmartFilters, se mantiene JetEngine y se reconstruyen funcionalidades con código. NovaMira le está ayudando a revisar lo que había, entender snippets y reorganizar piezas de la web.

Pero el cambio principal está en el contenido. La idea es trabajar en proyectos completos en directo y enseñar el proceso real, con pruebas, decisiones y errores. Las sesiones quedarán grabadas y se acompañarán de capítulos, resúmenes y materiales descargables.

A partir de ese trabajo saldrán dos formatos:

Si el proyecto es una web de tatuajes, también habrá que entender ese mundo. Si es la gestión de un hotel canino, interesará explicar por qué sus procesos son como son. El contexto forma parte de la historia y ayuda a entender para qué sirve lo que estamos construyendo.

Yannick está probando una cadena de herramientas para apoyar ese flujo: AssemblyAI para las transcripciones, fal.ai para generación audiovisual, Blender para trabajar con escenas y OpenCode para ejecutar tareas con distintos modelos.

También está explorando n8n para automatizaciones relacionadas con vídeos, Discord y otros procesos. No se trata de migrarlo todo de golpe: hay que valorar qué compensa mantener y qué tiene sentido rehacer.

Las sesiones producirán además pequeñas herramientas y skills descargables. El resultado útil no será solo ver un vídeo, sino poder aprovechar parte del sistema construido durante el proyecto.

Que ejecutar una idea cueste menos no significa que cualquier idea merezca ejecutarse. Sigue haciendo falta criterio para decidir qué construir, cómo organizarlo y para quién tiene valor. Eso vale para programar, diseñar una automatización o preparar el guion de un vídeo.

La edición de este podcast es un ejemplo. Elías cuenta el proceso para pedir a la IA que detecte fragmentos prescindibles sin romper el discurso. La transcripción ayuda a decidir qué sobra, pero los límites del corte tienen que ajustarse sobre la señal de audio.

Yannick compara esa experiencia con Descript y con su forma de editar viendo la onda. Seleccionar texto es cómodo, pero una frase bien identificada no garantiza una unión limpia. En vídeo aparece otra ventaja de las herramientas con línea de tiempo: podemos revisar y corregir visualmente lo que ha hecho el sistema.

En la conversación entran Filmora y DaVinci Resolve, así como la posibilidad de añadir recursos visuales al material editado. Son pruebas y siguientes pasos, no un proceso completamente resuelto.

La última pregunta del chat nos lleva a WordPress Headless. Para una web corporativa puede resultar interesante conservar WordPress como gestor y tener una parte pública más limpia.

Pero en proyectos complejos hay que revisar la compatibilidad con plugins, permisos y funcionalidades del ecosistema. El SEO y las redirecciones también requieren atención. Separar las partes añade decisiones técnicas que hay que justificar con las necesidades del proyecto.

En la agenda que comentamos durante la grabación aparecen Raiola Marketing Conference, la meetup de WordPress en Collado Villalba, WP Includes Forum y WordCamp Valencia, además de una posible visita a Zamora.

Yannick comparte también su experiencia en la meetup de Logroño, donde coincidieron perfiles de diseño, programación y distintos niveles de familiaridad con la IA. Hablar con personas que trabajan de otra manera ayuda a contrastar lo que estamos probando.

Son referencias a la agenda del momento de grabación, no una convocatoria actualizada de esos encuentros.

El episodio termina con una conversación abierta sobre el propio podcast. WordPress sigue presente, pero comparte espacio con automatización, agentes, herramientas de IA y proyectos digitales de todo tipo.

Elías plantea si el formato ha cumplido una etapa y si tendría sentido hacer estos encuentros alternando los canales de ambos. Yannick propone pensar también en el nombre y escuchar ideas de la comunidad.

No hay una decisión tomada. Sí hay algo que valoramos del formato actual: el compromiso de reunirnos con regularidad, compartir lo que estamos haciendo y mantener la conversación incluso cuando no traemos una gran novedad preparada.

La tecnología está cambiando deprisa y nosotros estamos ajustando servicios, herramientas y contenido con ella. Pero el punto de partida sigue siendo un problema concreto y una decisión con sentido: qué merece la pena automatizar, qué necesita un cliente o qué historia queremos contar.

Puedes ver el episodio completo en YouTube y contarnos qué estás cambiando tú. Y, si tienes una propuesta para el futuro del podcast, nos encantará leerla.

✏️ Suscribirse

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.

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:

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.

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.

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 procesos automatizados. En este último, la cuestión no es automatizarlo todo: hay que decidir qué partes pueden delegarse sin perder calidad y dónde debe mantenerse el control.

La renovación también afecta a su propia web, construida en WordPress sin un builder. Yannick explica que eso le permite programar soluciones sin adaptar cada idea a los widgets disponibles en una herramienta.

Los vídeos de YouTube contarían después la historia del proyecto: qué se quería conseguir, qué dificultades aparecieron y cuál fue el resultado. La biblioteca de formación existente seguiría disponible, y las nuevas series mantendrían un enfoque aplicado.

Héctor de Prada y Juanma presentan la segunda edición de WP Agency Forum como un espacio para responsables de agencias WordPress. La conversación se centra en problemas de negocio: captar clientes, gestionar equipos, pagar nóminas, mejorar márgenes y adoptar IA sin perderse en las novedades.

El programa presentado combinaba charlas prácticas, mastermind y networking guiado. Compartir con personas que afrontan retos parecidos puede aportar tanto valor como escuchar una ponencia: permite contrastar decisiones y descubrir colaboraciones.

La edición anunciada estaba prevista para el 7 de octubre en Madrid. En la grabación se describían contenidos sobre visibilidad en modelos de lenguaje, dirección de equipos, marca personal y evolución de las agencias, además de una mesa redonda. Esa presentación sirve de marco para una pregunta que sigue siendo útil: qué valor aporta una agencia cuando sus clientes también tienen acceso a herramientas de IA.

Hacer lo mismo más rápido puede mejorar un proceso, pero no resuelve por sí solo la diferenciación. La conversación propone ampliar el valor del servicio y apoyarse en el criterio humano para evaluar resultados. La herramienta está cada vez más disponible; decidir qué hacer y saber cuándo algo no funciona sigue siendo parte del trabajo profesional.

También se aborda la productividad en mantenimiento y hosting. Modular DS aparece como ejemplo de gestión de sitios, y Héctor anuncia API y MCP durante la charla. Elías destaca asimismo la utilidad de colaborar en cuentas de hosting que pertenecen al cliente: el acceso operativo y la titularidad del servicio son decisiones relevantes para una agencia.

Yannick explora AssemblyAI y n8n para convertir las sesiones de laboratorio en material reutilizable: transcripciones, resúmenes de avances y referencias a lo que salió bien o mal. Esa información podría alimentar después otros contenidos, incluida la newsletter. Documentar el trabajo mientras ocurre abre más posibilidades que intentar reconstruirlo al final.

Elías cuenta también su búsqueda de acceso remoto a OpenCode. Tras probar alternativas, configura una aplicación llamada CC Pocket y señala una dificultad importante: encontró dos aplicaciones con ese mismo nombre. La experiencia relatada corresponde a una configuración concreta y todavía no supone una evaluación prolongada de su fiabilidad.

Kilo Code aparece como otro entorno que combina trabajo con agentes, acceso remoto y opciones en la nube. El cierre deja abierta la exploración de esos flujos: poder continuar una sesión desde el móvil resulta útil, pero sigue haciendo falta entender dónde se ejecuta el trabajo y qué contexto conserva.

La evolución de los agentes, el cambio de La Máquina del Branding y los retos de las agencias apuntan en una dirección común: organizar el trabajo alrededor de problemas y proyectos reales. Preparar tareas, dar continuidad a los objetivos y revisar los resultados ayuda a convertir las herramientas en trabajo útil.

¿Qué proceso de tu negocio necesita ahora más contexto y criterio para que puedas delegarlo con confianza?

✏️ Suscribirse

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.

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 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.

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.

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 capacidades que ofrece cada herramienta, pero lo importante en la práctica es qué contexto tiene el sistema, qué puede hacer y cuándo debe pedir revisión.

El sistema de trabajo descrito en el episodio conecta proyectos con distintas fuentes: carpetas locales, documentación y tareas pendientes. También asigna modelos según la complejidad del trabajo para repartir mejor el consumo. Un ejemplo es una tarea recibida por correo para localizar escenarios de Make que usaban un módulo próximo a quedar obsoleto. El sistema revisó los escenarios, encontró uno y propuso el cambio para que se confirmara.

La intención no es dejar que el sistema actúe sin supervisión. Puede investigar, preparar un plan y avanzar trabajo, pero la persona conserva el control sobre qué se ejecuta y qué queda por revisar. El mismo principio aparece al hablar del correo: resumir mensajes no basta si la acción real es archivarlos, responderlos o convertirlos en tareas. El valor está en completar el proceso con trazabilidad y con las reglas adecuadas.

En la parte dedicada a Kilo Code se comentan tres funciones que resuelven necesidades diferentes. Kilo Memory conserva información útil entre sesiones, aunque no sustituye la documentación del proyecto. Kilo Remote permite continuar desde el móvil el trabajo vinculado a los proyectos. Agent Manager permite lanzar varios agentes a la vez y trabajar en paralelo con worktrees, por ejemplo para comparar alternativas de diseño sin rehacer cada versión sobre la anterior.

Las tres funciones se relacionan con una misma necesidad: mantener el contexto disponible mientras el trabajo cambia de lugar o se reparte entre varias tareas. La memoria ayuda a no repetir información; el acceso remoto permite retomar el trabajo; la coordinación en paralelo abre caminos de exploración distintos. En todos los casos sigue haciendo falta revisar lo que produce cada agente.

El cierre del episodio presenta un cambio de enfoque para La Máquina del Branding. La idea es dejar de priorizar la herramienta de moda y partir de problemas y proyectos variados: puede aparecer WordPress, inteligencia artificial, diseño, branding u otras soluciones, según lo que necesite cada caso.

Ese trabajo se desarrollaría en laboratorios compartidos, con sesiones de varias horas que muestran la investigación y las pruebas mientras ocurren. Después, de ese proceso saldrían vídeos más breves para YouTube: no un tutorial largo grabado en tiempo real, sino una historia clara sobre el problema, las decisiones y el resultado. La comunidad tendría acceso al proceso completo y quien llegue al vídeo podría entender rápidamente qué se hizo y por qué.

El cambio también amplía a quién se dirige el contenido. Además de profesionales que crean webs para clientes, se quiere hablar a personas que tienen una idea o necesitan sacar adelante su propio negocio. La tecnología queda al servicio de esa necesidad: primero se entiende el problema y luego se decide qué herramienta conviene.

En el episodio también se comenta la extensión oficial de WordPress, con accesos y utilidades para trabajar con sitios desde el navegador. Es una novedad concreta dentro de una conversación más amplia sobre cómo elegir herramientas con criterio.

Make, Maia, Hetzner y Kilo muestran caminos distintos para incorporar IA al trabajo, pero ninguna función elimina la necesidad de contexto ni de revisión. Los agentes pueden investigar, proponer y ejecutar tareas cada vez más completas; el criterio sigue estando en definir qué problema resolver, qué información necesita el sistema y dónde debe intervenir una persona.

Ese mismo enfoque conecta con el nuevo formato de La Máquina del Branding: trabajar en proyectos reales, compartir el proceso y convertirlo en historias útiles para más personas. ¿Qué tarea de tu trabajo te gustaría explorar primero con un sistema de agentes?

✏️ Suscribirse

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.

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.

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 con HTML, CSS, PHP y JavaScript, ¿cuándo compensa añadir un builder entre medias?. Los builders pueden facilitar determinadas tareas, pero también obligan a la IA a traducir sus decisiones a una estructura intermedia. Esa traducción puede hacer el proceso más lento y tosco.

La idea que recorre todo el episodio es que una skill no tiene que ser algo espectacular. Puede ser una pequeña definición de proceso que evita repetir las mismas instrucciones una y otra vez.

Por ejemplo, se puede crear una skill para trabajar sobre una bóveda de Obsidian. El sistema analiza las carpetas, identifica los archivos importantes y ayuda a procesar un inbox. Cuando mueve o clasifica una nota, también puede registrar qué ha hecho y por qué.

El valor no está únicamente en ahorrar tokens. También está en conservar el contexto y hacer explícito el criterio. Si una persona tiene una forma concreta de organizar clientes, presupuestos o documentación, esa forma de trabajo puede quedar escrita en una skill para que el agente la aplique de forma consistente.

El mismo enfoque sirve para tareas pequeñas. En el episodio hablamos de analizar historiales de sesiones, decidir cuáles son pruebas y cuáles conviene conservar, y borrar solo las que cumplen unas reglas claras. También aparece el ejemplo de crear una skill para organizar fiestas temáticas, con acreditaciones, juegos, ruletas y elementos que se repiten en cada edición.

Son ejemplos distintos, pero comparten la misma estructura: si un proceso se repite y tiene reglas, se puede documentar para que la IA lo ejecute con menos intervención. Las skills pueden servir para un negocio, para un proyecto web o para una afición personal.

El siguiente paso es organizar varias skills y varios agentes dentro de un sistema mayor. Codex y OpenCode aparecen como dos entornos para construir esa capa de trabajo.

La propuesta incluye un agente orquestador, un estratega, un desarrollador y un becario o documentador. No todos necesitan el mismo modelo ni la misma profundidad. El orquestador puede ocuparse de analizar el trabajo disponible y proponer el siguiente paso, mientras que el desarrollador recibe el contexto técnico de un proyecto concreto.

Las fuentes de trabajo pueden ser distintas. Algunas tareas viven en proyectos con un roadmap, mientras que otras son tareas sueltas etiquetadas en Todoist. El orquestador puede revisar esas fuentes y proponer varias opciones, teniendo en cuenta el coste, el beneficio y el estado real de cada trabajo.

El objetivo final es que el sistema no se limite a ejecutar una tarea y terminar. La aspiración es crear un loop: elegir una tarea, definirla bien, ejecutarla con el agente adecuado, comprobar el resultado y proponer la siguiente.

Pero para llegar ahí hace falta ser muy preciso. Una tarea no debería decir simplemente “mejora esta web”. Tiene que definir el objetivo, los requisitos, las limitaciones y las condiciones que indican cuándo está terminada. Si falta información, el agente debe preguntar en lugar de inventarla.

También es importante no mezclar demasiadas responsabilidades. Diseño, estructura HTML, contenidos, SEO y desarrollo pueden estar relacionados, pero no siempre deben resolverse en una sola tarea. La IA trabaja mejor cuando el contexto y el alcance están claramente delimitados.

Otra conclusión importante es que la calidad del resultado no depende solamente del MCP o del builder elegido. Si se pide a la IA que haga una web sin darle una dirección, el resultado será genérico aunque la herramienta sea muy potente.

Antes de generar una interfaz conviene definir varias capas:

Este trabajo convierte decisiones intuitivas en un proceso que la IA puede entender. No se trata solo de decir “hazlo bonito”, sino de explicar qué debe conservarse, qué componentes existen, cómo se combinan y qué reglas no se pueden romper.

Por eso el episodio cuestiona la idea de hacer un curso centrado únicamente en maquetar con Elementor o Bricks. Esas herramientas pueden ser útiles y seguirán teniendo su lugar, pero enseñar a crear un proyecto profesional exige hablar también de estrategia, identidad, estructura, SEO, automatizaciones y despliegue.

El episodio termina con un anuncio personal: la serie de contenidos y La Máquina del Branding van a ampliar su enfoque.

La intención no es abandonar WordPress. Cuando WordPress sea la base adecuada, se seguirá utilizando. El cambio consiste en no tratarlo como la única respuesta para cualquier proyecto ni reducir el trabajo digital a instalar un CMS, elegir un builder y maquetar unas páginas.

La IA permite que una persona pueda abordar más áreas: identidad visual, imágenes, vídeo, audio, aplicaciones, automatizaciones, conexiones entre servicios y desarrollo web. Eso abre la posibilidad de atender proyectos más completos sin que cada parte tenga que depender de un especialista distinto o de un proceso manual interminable.

La idea no es crear un CMS nuevo para cada necesidad ni reinventar herramientas que ya funcionan. Se trata de elegir la base adecuada, conectar lo que ya existe y utilizar la IA para adaptar el sistema a cada caso.

Las skills y los agentes no sustituyen el criterio. Lo hacen más reutilizable. Una buena automatización empieza por entender cómo se trabaja, convertir ese conocimiento en reglas y decidir qué puede delegarse con seguridad.

NovaMira, CrocoBuilder, Codex y OpenCode son piezas interesantes de este cambio, pero ninguna herramienta resuelve por sí sola la falta de planificación. La ventaja está en construir un sistema con contexto, límites, revisión y procesos claros.

¿Qué tarea repetitiva de tu negocio, proyecto o vida personal convertirías primero en una skill?

✏️ Suscribirse

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.

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 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.

La versión 2.4 de Bricks, actualmente en beta, introduce cambios significativos que apuntan directamente a la integración con IA:

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.

Crocoblock ha lanzado CrocoBuilder, su nuevo builder para WordPress, y la primera impresión es que nace con bases sólidas que otros builders ignoraron al salir:

Está en early access con un 40% de descuento. Crocoblock tiene trayectoria con productos como JetEngine y Flex, así que merece la pena seguir de cerca cómo evoluciona.

Yan presentó su sistema de diseño asistido por IA, que separa el trabajo en cuatro archivos con propósitos distintos:

La clave está en que los agentes no reciben solo «usa este CSS»: reciben instrucciones precisas sobre cuándo usar cada clase y dónde aplicarla. Esto reduce drásticamente las invenciones de la IA y mantiene la coherencia visual.

El flujo de trabajo usa Stitch con MCP integrado en VSCode: Yan genera prototipos, edita contenidos y ve vistas previas sin salir del editor. Stitch trabaja con agentes en paralelo (muy rápido) y permite transformar el Tailwind de salida al framework propio mediante skills personalizadas. El proceso es: aprobar el HTML → aprobar el framework CSS → generar todos los templates → pasar a PHP. Las decisiones de diseño se hacen antes de tocar código, y cualquier cambio posterior se integra en el framework para no perder coherencia.

Uno de los bloques más prácticos del episodio fue la estrategia de subsidio: cómo usar modelos de IA potentes pagando mucho menos de lo que realmente consumen. Las cifras que Elías compartió son reveladoras:

La estrategia es clara: usar los modelos buenos (los subsidiados) para planificar y tareas complejas, y modelos más ligeros para ejecución rutinaria. Y aprovechar que OpenCode permite cambiar de modelo en cualquier momento para adaptar el coste a la tarea.

Un apunte práctico: Handy, la app de transcripción para Mac, ahora soporta modelos con streaming y postprocesado por API. Elías habla en español y un prompt con OpenRouter traduce a inglés técnico en tiempo real, con un coste de centésimas de céntimo por traducción.

El episodio deja varias ideas claras. La ventaja competitiva en 2026 no está en qué herramienta de IA usas, sino en el sistema de trabajo que construyes alrededor: skills reutilizables, mapeo de componentes, estrategia de subsidio y diseño por capas antes de tocar código. Las herramientas cambian rápido —Bricks añade MCP, Crocoblock lanza un builder nuevo, OpenCode conecta proveedores— pero los principios se mantienen: separar responsabilidades, documentar decisiones y no depender de una sola fuente de IA.

¿Qué herramientas estás usando tú para desarrollar con WordPress e IA? ¿Tienes tu propia estrategia de subsidio? Cuéntanos en el chat o en el grupo de Telegram. Y si quieres profundizar en alguno de los temas que hemos tocado, recuerda que tienes nuestras webs negocioswp.es, eliasgomez.pro y lamaquinadelbranding.com.

✏️ Suscribirse

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.

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:

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.

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`.

Cuando usas el extracto de WordPress, puedes trabajar de dos maneras:

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.

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.

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:

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.

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.

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:

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.

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.

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

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.

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 cierre del debate va más allá de WordPress. Si la ejecución técnica se abarata, lo que gana valor es otra cosa:

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

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

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.

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.

En diseño, WordPress 7.1 incorpora varias peticiones recurrentes de la comunidad:

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.

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 y alguien capaz de detectar si la solución encaja.

El segundo caso es más cotidiano y quizá por eso resulta todavía más revelador. Un formulario de alta hecho con Gravity Forms mostraba reseñas de Google en uno de sus pasos. El plugin que las cargaba empezó a fallar y, además, las reseñas mezclaban experiencias de una tienda, un bar y el servicio principal del negocio. Aunque la puntuación general era buena, el contenido automático dejó de ayudar a la conversión.

La posible solución no fue añadir más automatización, sino elegir manualmente unas pocas reseñas. Menos dinamismo puede significar más control, menos fallos y un mensaje comercial más claro. Es la misma lógica que permite sustituir un mapa interactivo innecesario por una dirección bien enlazada: una web no mejora por acumular componentes, sino por resolver mejor lo que necesita el usuario.

El episodio menciona también mejoras en un alta con Kadence Membership, el envío de datos de facturación a Stripe y una integración con FacturaDirecta. Son trabajos distintos, pero comparten patrón: partir del proceso real, localizar el dato que falta y conectar solo las piezas necesarias.

El balance de mitad de año deja una idea clara: los agentes han encontrado su sitio cuando se integran en un proceso profesional completo. Ya no se trata solo de generar una función o resolver una duda, sino de participar en investigación, desarrollo, pruebas, navegación y mantenimiento.

Codex, por ejemplo, puede inspeccionar la renderización del frontend, abrir el navegador, trabajar con MCP, usar aplicaciones del ordenador y mantenerse iterando sobre un objetivo. Esa autonomía permite pedir una revisión y descubrir que el agente ha comprobado por su cuenta si una parte se rellena mediante JavaScript.

Pero la misma conversación ofrece el contrapunto perfecto. Ante un problema con reseñas, el agente se puso a buscar plugins genéricos sin preguntar primero cuál estaba instalado. Un profesional competente habría empezado por identificar el objeto exacto del problema. La IA puede recorrer muchos caminos, pero no siempre elige el más sensato si le falta contexto.

Por eso el siguiente objetivo no es automatizar una web entera con una instrucción gigantesca. Es construir y enseñar un flujo que cubra:

El valor está en encadenar bien las fases y reservar puntos de control, no en fingir que todas pueden mezclarse sin supervisión.

La parte visual sigue siendo una de las más difíciles. Pedir “hazme un diseño” suele producir resultados correctos, pero poco personales y con escasa voluntad de tomar decisiones. Herramientas como Stitch y los documentos de diseño se plantean en el episodio como una fase intermedia: explorar propuestas, dar vueltas a una maqueta y validarla antes de trasladarla a un framework CSS.

Ese proceso conserva el control creativo. También permite seguir diseñando manualmente cuando tenga sentido y usar la IA para convertir una propuesta ya decidida en CSS y componentes. La automatización entra después de fijar la dirección, no antes.

La evolución del servicio de automatización ocupa otro de los debates centrales del episodio. Si una persona con cierta soltura técnica puede pedir a ChatGPT que conecte dos herramientas, el valor de un profesional no puede limitarse a ejecutar ese encargo aislado.

La propuesta pasa a ser más consultiva: analizar la empresa, detectar qué procesos ofrecen mayor beneficio y elegir varias áreas conectadas. En muchos negocios, esas prioridades pueden agruparse en:

El cliente puede llegar con una necesidad concreta, pero la experiencia humana ayuda a descubrir dependencias y oportunidades que no había formulado. La IA puede transcribir reuniones, ordenar información y proponer opciones; aun así, decidir qué automatizar primero exige entender el negocio, el coste de mantenimiento y el beneficio esperado.

El episodio plantea también una duda muy práctica: seguir construyendo escenarios en Make o mover ciertas automatizaciones a scripts ejecutados en un servidor.

Make ofrece una interfaz visual que puede facilitar cambios sencillos, como modificar el asunto de un correo. Sin embargo, limita el sistema a los módulos y capacidades de la plataforma. Un script en un VPS ofrece mucha más libertad, pero también puede resultar completamente opaco para un cliente no técnico.

No existe una respuesta universal. La mejor tecnología es la que resuelve el proceso y puede mantenerse con los recursos reales del proyecto. Para algunos clientes, las “bolitas” de Make son comprensibles; para otros, resultan tan extrañas como una línea de código y el mantenimiento seguirá dependiendo del profesional.

Aquí aparece una oportunidad especialmente interesante: documentar cada automatización, sus conexiones, decisiones y forma de depurar. Con una biblioteca de artefactos, ejemplos y soluciones anteriores, los agentes pueden aprender cómo trabaja el profesional y proponer respuestas coherentes con su metodología. La documentación deja de ser solo una entrega para el cliente y se convierte en contexto reutilizable para la IA.

El siguiente paso es conseguir que los agentes trabajen con más autonomía sin perder trazabilidad. En el episodio se describe una forma de multitarea bastante realista: dejar a Codex trabajando, revisar su avance cada cierto tiempo y combinar esa tarea mental con otro trabajo físico.

Para que ese modelo sea útil fuera del escritorio aparecen dos necesidades:

Kilo Cloud y el control remoto desde el teléfono apuntan en esa dirección. También se comenta la posibilidad de trabajar en un VPS, conectarse por SSH y desplegar después. El objetivo no es complicar la infraestructura por afición, sino poder delegar tareas largas y recuperar el control cuando realmente haga falta.

Para Elías, esa autonomía se conecta con Luna Music, el análisis de Search Console y Analytics, la mejora de la web y una profesionalización general del servicio de DJ. Para Yánick, el objetivo es mostrar un desarrollo web completo con agentes, desde el contenido y el diseño hasta el testing y el mantenimiento.

El episodio cierra el repaso con varias herramientas y proyectos a seguir:

También se recuerdan dos citas de la comunidad: RMC Galicia en septiembre y WordCamp Galicia en octubre. Más allá de la novedad concreta, todas estas referencias muestran el mismo movimiento: las herramientas intentan acercar la ejecución al contexto visual, al trabajo remoto y a agentes cada vez más capaces.

El episodio 255 deja dos conclusiones conectadas. La primera es que WordPress sigue evolucionando para ofrecer mejor colaboración, más capacidades nativas y una relación más estrecha con la IA. La segunda es que disponer de agentes más potentes no elimina la necesidad de procesos claros; la hace todavía más evidente.

En desarrollo y automatización, el trabajo valioso se desplaza hacia el criterio, la arquitectura, la consultoría y la documentación. Ejecutar cuesta menos, pero elegir bien qué ejecutar, cómo mantenerlo y cuándo simplificar sigue siendo la diferencia entre una prueba vistosa y un sistema que funciona.

La pregunta útil para los próximos meses no es cuántas tareas puede hacer un agente. Es otra: ¿qué sistema de trabajo necesitas para poder delegarlas con confianza? Si quieres seguir compartiendo experiencias sobre WordPress, IA y negocio digital, puedes unirte a la comunidad de Telegram de Negocios y WordPress.

✏️ Suscribirse

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.

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.

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:

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.

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:

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.

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:

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.

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:

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.

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

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.

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.

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”.

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.

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.

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.

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.

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.