Buenas, quería compartir un experimento que vengo armando hace unos días/semanas y que quizás a más de alguien de acá le puede interesar desde el lado de infraestructura, automatización, agentes IA y desarrollo de producto.

Hace algunos meses empecé a construir PanguiApp, una app personal para centralizar descuentos, rewards, convenios y beneficios de tarjetas. La idea original era bien simple: dejar de buscar manualmente qué banco tenía qué promoción, dónde había descuentos para comer, qué rewards estaban vigentes, etc.

Partió como un proyecto para ahorrar tiempo y unos pesos.

Pero como trabajo harto con datos, se me fue un poco de las manos por el lado técnico.

La parte de datos

La app hoy tiene una data platform bastante más robusta de lo que probablemente necesita para el caso de uso.

El stack principal es:

• Pipelines en Rust
• Arquitectura lakehouse
• Iceberg Tables
• Trino como motor de consulta
• Data lake enriquecido diariamente con data histórica

Sí, probablemente es overengineering.

Pero también era parte del objetivo: quería usar el proyecto como laboratorio real para probar arquitectura de datos moderna, pipelines rápidos y una base que pudiera escalar si la app crece.

En simple, la idea es poder guardar harta data histórica de beneficios/ofertas, consultarla rápido y dejar la estructura lista para análisis, búsqueda, recomendaciones y automatizaciones futuras.

El mini datacenter casero

Después dejé el proyecto botado un par de semanas, hasta que me animé a comprar un mini PC chino por AliExpress y montarle Proxmox.

La idea era tener un entorno self-hosted para correr servicios propios, containers, automatizaciones y agentes sin depender completamente de plataformas externas.

En la práctica, el mini PC terminó siendo una especie de pequeño datacenter personal.

Ahí tengo corriendo distintos servicios y containers, entre ellos Hermes Agent, que es lo que estoy usando para orquestar agentes de IA de forma autónoma.

Agentes trabajando 24/7

Lo interesante es que ya no estoy usando IA solo como “copiloto” cuando me siento a programar.

Estoy armando loops programados para que cada 4 horas los agentes trabajen sobre tres líneas:

1. Buscar nuevas fuentes de datos para ampliar cobertura.
2. Mejorar calidad del código.
3. Mejorar diseño, UI y UX de la aplicación.

Cuando terminan, me reportan por Telegram:

• Qué hicieron.
• Qué archivos tocaron.
• Qué avances lograron.
• Qué problemas encontraron.
• Qué recomiendan hacer después.

Además, estoy usando un sistema de memoria/backlog para que no partan desde cero en cada iteración. La idea es que el agente mantenga continuidad y siga una línea coherente de desarrollo.

Esto ha sido clave, porque si no, el agente puede ponerse creativo y empezar a resolver cosas que nadie le pidió.

Contenido y redes sociales

También levanté un flujo aparte para contenido.

Estoy usando Postiz en Docker para agendar publicaciones y KIE AI para generación de imágenes y videos, porque tiene API/MCP y permite conectarlo al agente.

Hoy el sistema es capaz de:

• Detectar ofertas o contenido relevante.
• Generar una pieza de contenido.
• Agendarla.
• Reportar qué hizo.
• Dejar trazabilidad de la publicación.

Todavía no está 100% autónomo, pero el flujo ya empieza a agarrar forma.

Multi-provider para no quedar botado

El otro problema es el consumo de tokens.

Con agentes corriendo todo el día, se queman millones de tokens. Para no depender de un solo proveedor, configuré varios providers con fallback.

Estoy usando una mezcla de:

• ChatGPT Plus
• Ollama Cloud
• Kimi Code
• OpenRouter como última instancia vía API key

La lógica es simple: si un proveedor queda sin cupo o falla, el flujo cae al siguiente.

No es perfecto, pero ayuda bastante a mantener continuidad.

Lo que más me ha hecho sentido: Loop Engineering

Lo que más me está quedando claro es que el salto no está solo en “usar IA para programar”.

El cambio real está en diseñar loops.

En vez de pedirle una tarea puntual a un modelo, armas un flujo donde el agente:

1. Recibe un objetivo.
2. Ejecuta.
3. Evalúa lo que hizo.
4. Reporta.
5. Guarda memoria.
6. Vuelve a iterar después.

Mi rol empieza a cambiar.

Antes era: “tengo un problema, le pregunto a la IA, copio código, pruebo”.

Ahora se parece más a: “diseño el sistema que permite que el proyecto avance aunque yo no esté mirando todo el rato”.

Obviamente no es magia. Hay errores, hay que revisar commits, hay que acotar scopes, hay que evitar que el agente se vaya por las ramas y todavía requiere bastante supervisión.

Pero el cambio de paradigma se siente bien fuerte.

La IA deja de ser una herramienta puntual y empieza a comportarse más como un pequeño equipo operativo alrededor del producto.

Algunas cosas que he aprendido hasta ahora

• Si el scope es muy amplio, el agente se pierde.
• Si no hay memoria/backlog, cada sesión se siente como partir de cero.
• Los reportes por Telegram son clave para no tener que estar mirando logs todo el día.
• Los loops cortos y frecuentes funcionan mejor que sesiones eternas.
• El fallback entre modelos/providers es casi obligatorio si quieres continuidad.
• La parte difícil no es solo prompt engineering, sino diseñar bien el sistema, las restricciones y el ciclo de trabajo.
• Self-hosted da más control, pero también más cosas que mantener.
• La cantidad de ingresos por ads que tendrán empresas como Meta y Google aumentará un montón a medida que mas personas empiecen con estos proyectos. Aun no le he metido plata a ads, pero probablemente lo haga y que mis agentes lo gestionen todo

No lo comparto como “miren mi app”, sino como experimento técnico. Me interesa mucho escuchar experiencias, críticas o ideas de gente que esté metida en esto desde el lado más práctico. Pueden encontrar el proyecto googleando PanguiApp