Esta es la primera parte de la historia.
Todo empezó con una intención bastante sencilla: actualizar mi sitio personal, arturocuenca.com.
Quería revisar los proyectos que muestro en mi portafolio y darle más espacio al trabajo que estoy haciendo con inteligencia artificial. También quería retomar mi blog, al que llamo Cuaderno: una sección de mi sitio donde comparto lo que voy construyendo, las pruebas que hago y lo que aprendo durante el proceso.
Este artículo cuenta cómo empezó uno de esos proyectos.
Mi sitio ya estaba construido en WordPress, la plataforma que utilizo para administrar sus páginas y publicar artículos. Quería encontrar una forma de trabajar sobre él con ayuda de inteligencia artificial, conservando el contenido y el diseño que ya tenía.
La pregunta era: ¿podía conversar con un asistente como ChatGPT o Claude, pedirle que consultara los artículos de mi sitio y preparar cambios desde esa misma conversación?
Esa pregunta terminó abriendo un proyecto nuevo.
La imagen de portada, titulada “Un puente propio”, representa esa idea. A un lado aparece una burbuja de conversación; al otro, una página web. Entre ambos hay un puente. Es una manera de explicar lo que quería construir: una conexión que permitiera llevar lo que pido en una conversación hasta mi sitio de WordPress.
Primero, conectar lo que ya existía.
Empecé probando una solución que conectaba WordPress con un asistente de inteligencia artificial. Con ella pude explorar una forma distinta de trabajar: consultar desde el chat el contenido que tenía guardado en mi sitio y usar esa información para preparar cambios.
Al empezar a utilizarla, también encontré un límite: la cantidad de uso incluida en la versión gratuita. Cada prueba, corrección y nuevo ajuste consumía parte de ese margen. Cuando se agotaba, continuar implicaba esperar a que se renovara o contratar un plan con mayor capacidad.
El costo era parte de la decisión, pero también lo era el ritmo de trabajo. Estaba explorando. Necesitaba probar una idea, ver el resultado, corregir y volver a intentar. Quería tener más control sobre ese ciclo y sobre cuánto podía avanzar en una sesión.
Esa experiencia me llevó a preguntarme qué supondría construir una conexión propia, enfocada en las acciones que necesitaba para mi sitio. También tendría dependencias y límites, pero podría decidir cómo desarrollarla y qué funciones agregar.
Además, necesitaba entender mejor qué información recibía el asistente, qué podía modificar y cómo comprobar que había hecho lo que le pedía.
Un ejemplo pequeño lo hizo evidente: solicitar una lista de los artículos de mi blog, ordenados por fecha de publicación.
Parecía una consulta sencilla. Sin embargo, recibir los títulos y los números que WordPress utiliza para identificar cada artículo no era suficiente. También hacían falta las fechas y comprobar que la consulta incluyera todos los resultados, aunque estuvieran repartidos en varias páginas.
Para que la conversación fuera útil, la conexión tenía que entregar información suficiente.
La idea de construir un puente propio.
Decidí desarrollar una conexión a la medida y la llamé Cuenca WordPress Bridge. La palabra “bridge” significa “puente” en inglés.
El objetivo inicial era sencillo: permitir que el asistente identificara mi sitio, consultara su contenido y preparara borradores de artículos que yo pudiera revisar dentro de WordPress.
Un borrador es una versión guardada que todavía no está publicada. Eso me permitía probar la escritura y la edición antes de mostrar cualquier cambio a los visitantes.
La inteligencia artificial me acompañó en la escritura del código, en las pruebas y en la interpretación de los errores. Mi trabajo fue definir qué necesitaba, decidir hasta dónde debía llegar cada acción y contrastar las respuestas del asistente con lo que realmente sucedía en WordPress.
Ahí apareció una de las partes más interesantes del proceso: diseñar una herramienta conversacional también implica decidir sus límites.
¿Qué significa “editar” en este contexto? ¿Puede modificar cualquier artículo o solamente los borradores que ha creado? ¿Cómo compruebo que guardó el cambio? ¿Qué pasa si repito una solicitud?
Responder esas preguntas me ayudó a definir cómo debía funcionar el puente.
Trabajar en una copia del sitio también tuvo su historia.
El desarrollo comenzó en una copia de mi sitio guardada en mi Mac. A eso me refiero cuando digo que estaba trabajando “en local”: las pruebas se hacían en mi computadora, antes de llevarlas al sitio público.
Para ejecutar WordPress en esa computadora utilicé MAMP, una aplicación que reúne los componentes necesarios para que el sitio funcione.
Pero tenerlo abierto en mi Mac no bastaba para que un asistente externo pudiera conectarse. Para eso utilicé un túnel de Cloudflare: una conexión que permitía al asistente acceder, mediante una dirección web, a la copia de WordPress que estaba ejecutando en mi Mac.
Poner todo a funcionar también exigió atención. Tuve que resolver un conflicto que impedía arrancar Apache, el servidor web que utilizaba MAMP. También tuve que actualizar las direcciones de conexión cuando cambió el túnel y revisar los permisos del puente.
En un momento, el asistente podía consultar el contenido, pero no crear borradores. La conexión funcionaba; faltaba habilitar el permiso para escribir.
Desde fuera, todo podía parecer el mismo problema: “no funciona”. Al revisar cada parte, aparecieron causas específicas que podía comprobar y corregir.
Avanzar consistió, muchas veces, en convertir una duda grande en una prueba pequeña.
La ilustración “Del borrador a la publicación” resume el proceso que quería seguir: crear un borrador, revisarlo y hacer los ajustes necesarios. Las flechas entre revisar y ajustar muestran que ese paso puede repetirse varias veces.
Solo cuando el contenido está listo llega la publicación, que en esta primera versión del puente seguía siendo un paso manual dentro de WordPress.
La idea que resume esa imagen es sencilla: el puente crea y edita; yo decido cuándo publicar.
Dos párrafos como primera prueba.
La primera prueba de escritura fue deliberadamente pequeña: pedirle al asistente que creara un borrador con un párrafo y después agregara otro.
El borrador apareció en WordPress. La actualización también. Pero al abrir la vista previa, ambos textos se veían unidos, como si fueran un solo párrafo.
Eso me obligó a mirar más allá del mensaje de éxito que devolvía la herramienta.
Revisé el HTML guardado, es decir, el código que organiza el texto en párrafos, títulos y otros elementos de una página. Ahí encontré que los dos párrafos ya no estaban separados como esperaba.
Corregí el borrador, volví a consultar su contenido y comprobé la vista previa. Esta vez, los dos párrafos estaban donde debían estar.
Fue un resultado pequeño, pero significativo. Había recorrido el ciclo completo: pedir un cambio, guardarlo, volver a leer lo que se había guardado y comprobar cómo se veía en el sitio.
Otra ilustración, “Cómo se conecta todo”, muestra el recorrido de una solicitud desde ChatGPT hasta la copia de mi sitio.
El recorrido empieza en ChatGPT. La conexión pasa por el túnel de Cloudflare y llega a mi Mac. Dentro de la computadora están el puente y la copia de WordPress, funcionando con MAMP.
Cada parte cumple una función: ChatGPT es donde hago la solicitud; Cloudflare proporciona el acceso desde fuera; y Cuenca WordPress Bridge recibe mis solicitudes y realiza en WordPress las acciones que tiene permitidas.
Así, una conversación puede llegar hasta el contenido de mi sitio local.
Lo que conseguí en esta primera etapa.
Al terminar estas pruebas, el puente ya permitía consultar contenido, crear borradores y modificar únicamente los que había creado a través de esa conexión. Hice la prueba de escritura sobre un único borrador, que mantuve sin publicar.
Ese alcance ya abría una posibilidad práctica: preparar un artículo desde una conversación y revisarlo dentro de WordPress, con el diseño real de mi sitio.
Este texto nació de ese proceso. Lo elegí como el primer artículo que quería llevar por ese recorrido, desde la redacción hasta su publicación.
Lo que quiero compartir en Cuaderno.
Me interesa explorar la inteligencia artificial a través de herramientas que uso y problemas que puedo observar de cerca.
En este caso, la necesidad inicial era actualizar mi portafolio y retomar mi blog. En el camino terminé desarrollando una conexión propia y tomando decisiones sobre permisos, edición, verificación y experiencia de uso.
La inteligencia artificial me ayudó a pasar de una idea a un prototipo funcional. Fui dando forma al prototipo al probarlo, encontrar sus límites y decidir qué debía resolver primero.
Al cerrar esta primera etapa, ya podía preparar y revisar borradores desde una conversación. Todavía faltaba llevar ese trabajo al sitio público.
Eso es lo que quiero contar en Cuaderno: cómo una necesidad concreta se convierte en un proyecto, qué decisiones tomo en el camino y qué aprendo cuando las cosas no salen como esperaba.
En este caso, empecé queriendo actualizar mi sitio. Terminé construyendo una herramienta para trabajar en él.