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