3198. Mi stack de inteligencia artificial

Hoy os cuento mi stack de inteligencia artificial, las herramientas que utilizo cada día y cómo las combino para trabajar y automatizar procesos.

Pero antes, recordemos que esta semana continúa el curso de gestión de proyectos con IA. En la quinta clase aprendemos a gestionar riesgos y tomar mejores decisiones. En la sexta automatizamos el seguimiento del proyecto para que los avances no dependan de ir explicando manualmente cada correo enviado, cada tarea completada o cada cambio en el CRM.

Ahora sí, vamos al lío. Cada año os hablo del software que utilizo, pero esta vez quiero centrarme en mi stack de inteligencia artificial. No es solamente una lista de modelos. También incluye aplicaciones, servidores, librerías, bases de datos y herramientas que, combinadas, forman mi manera de trabajar.

Empiezo por la pareja que tengo siempre a mano. Utilizo ChatGPT para hablar y Codex para trabajar. Voy probando otras alternativas, pero esta combinación es la que mejor me encaja por la velocidad, el aprovechamiento que consigo de los tokens y el ecosistema de plugins. Es mi experiencia con mis tareas, no una clasificación universal de qué herramienta es mejor.

Con ChatGPT suelo conversar desde el móvil o la web. Muchas veces lo hago por voz, con los AirPods, porque me resulta más natural explicar lo que tengo en la cabeza que escribirlo. Si hay otras personas alrededor, prefiero teclear para no molestar.

Para Codex, en cambio, prefiero la aplicación a la terminal. Me resulta más cómoda para organizar el trabajo y tener las distintas piezas a mano. La terminal sigue ahí por si la necesito, pero no es la interfaz que elijo para mi día a día.

La siguiente pieza es Whisper en local. Antes utilizaba aplicaciones independientes de transcripción. Ahora dejo que Codex ejecute el modelo dentro de mi entorno, de modo que no tengo que abrir otra aplicación, esperar el resultado, descargar un archivo y pasarlo después al agente.

El podcast es un buen ejemplo. Termino de grabar, entrego el MP3 y el flujo prepara la transcripción y las notas del programa para WordPress. Los lunes, el proceso de edición puede separar las preguntas de las respuestas para las versiones pública y premium. La transcripción pasa a ser una pieza de la automatización, no una tarea manual que interrumpe todo lo demás.

Después viene la infraestructura. Tengo un VPS que funciona como Dev Box, mi servidor de desarrollo. Ahí reúno los proyectos, el código y los entornos en los que trabajo. Lo veo como un laboratorio donde preparo cada cambio antes de enviarlo al lugar en el que debe funcionar de verdad.

Eso no significa que todas las webs públicas estén alojadas en ese mismo servidor. Desarrollo y producción son entornos distintos. Por ejemplo, trabajo sobre el código de Boluda.com en la Dev Box y después lo despliego en su alojamiento de producción. Otros proyectos utilizan otros servidores, y varios proyectos pequeños pueden compartir uno.

También tengo mi plantilla de agentes persistentes. Son ocho agentes más el CEO, nueve en total, con distintas responsabilidades. No necesitan que mantenga el portátil abierto ni que vaya recordándoles cada tarea. Se activan según la programación que he preparado o cuando ocurre un evento relevante.

Aquí distingo dos formas de iniciar el trabajo. Una es el evento que dispara una automatización. Por ejemplo, una venta puede poner en marcha un proceso que revise la información del cliente, actualice un registro y prepare un informe. La otra es la ejecución periódica, en la que el agente revisa lo que corresponde cada cierto tiempo.

En mi caso, utilizo systemd en un servidor de Hetzner para organizar esas ejecuciones. Los agentes realizan sus revisiones y trasladan la información al CEO, que es quien habla conmigo. No se trata de tener nueve conversaciones abiertas todo el día, sino de repartir responsabilidades y ordenar cómo llega el resultado.

El siguiente elemento es uno de los pilares de todo el sistema. Skills, skills y más skills. Cuando un agente resuelve una tarea después de varios intentos, no quiero que la próxima vez vuelva a tropezar con los mismos problemas. Quiero conservar el procedimiento que ha funcionado.

Por eso, cuando termino una tarea que voy a repetir, le pido que cree una skill con el camino correcto y los errores que debe evitar. Así podemos convertir la experiencia de una sesión en unas instrucciones reutilizables, reducir pruebas innecesarias y gastar menos tiempo y tokens en encontrar de nuevo la solución.

No doy por supuesto que el agente recordará todo lo que acaba de hacer en cualquier conversación futura. Los archivos de contexto guardan información y las skills describen procesos. Ambas cosas se complementan, pero una skill resulta especialmente útil cuando queremos repetir un trabajo concreto con unos pasos y unas comprobaciones claras.

A continuación están los plugins públicos y privados. Utilizo integraciones para acceder a servicios y herramientas desde el mismo entorno, y también preparo plugins propios cuando necesito algo adaptado a mi manera de trabajar. El de Boluda.com es público, pero otros los he creado solo para mí.

Uno de los ejemplos más claros es mi cliente de correo basado en IA. Antes gestionaba los mensajes dentro de un proyecto dedicado a Gmail. Ahora he preparado un plugin con su propia interfaz para ver los correos y trabajar con ellos desde la aplicación, sin ir cambiando constantemente al navegador.

Esta distinción me parece importante. Un plugin puede servir para consultar información mediante una conversación, pero también puede incorporar una aplicación con su interfaz. Para mis herramientas personales estoy utilizando cada vez más este segundo enfoque, porque me permite tenerlas junto al lugar en el que ya estoy trabajando.

Luego vienen los hechizos. Ahí están FFmpeg, ImageMagick, Pillow, Playwright y otras herramientas que el agente puede utilizar para ejecutar tareas. No son todas modelos de IA, ni necesitan serlo. Su valor está en lo que podemos hacer al integrarlas en un proceso.

Para la información, separo dos necesidades. Cuando quiero trabajar con textos largos, libros, ideas o transcripciones, utilizo una vector store como parte de mi cerebro digital. Es el espacio donde preparo ese contenido para poder recuperarlo y consultarlo después.

Cuando la información tiene campos definidos, recurro a una base de datos. Una ficha de contacto puede tener nombre, apellidos, cumpleaños y relación conmigo. Un registro de episodios o de aplicaciones puede tener sus propios campos. Para proyectos pequeños utilizo SQLite y para otros que necesitan una base de datos más completa, PostgreSQL.

La idea no es meterlo todo en el mismo sitio por costumbre. Elijo cómo guardar la información según cómo voy a consultarla y utilizarla. Para mi forma de trabajar, los documentos largos y las fichas estructuradas resuelven necesidades distintas y tienen circuitos diferentes.

También utilizo GitHub para conservar el código y el historial de los proyectos. Los commits y los cambios enviados al repositorio me permiten seguir la evolución del trabajo. Eso sí, no equivale a guardar absolutamente todo. Las claves y los secretos se quedan fuera del repositorio.

Para probar otros modelos utilizo Cursor, mientras que mantengo Claude a mano para revisar las novedades que van apareciendo. Probar una herramienta no significa que tenga que conver