Cómo construí un sistema de IA con 10 containers usando ingeniería asistida por Claude (y todo lo que salió mal en el camino)

De leer sobre agentes de IA a construir uno propio

Primero fueron los posts de ClawMolt (OpenClaw). Después los hilos interminables sobre agentes autónomos, sobre lo que podían hacer, sobre los riesgos. Y también las historias de terror (como el que terminó el mes con una factura de 8.000 dólares por no controlar el consumo de tokens).

Consumí todo lo que encontré durante semanas. Gente contando qué les funcionó, qué les explotó, cuánto gastaron, qué errores cometieron. Videos, hilos, posts. No me lancé de cabeza. Absorbí experiencias ajenas hasta que un día sentí que ya entendía lo suficiente para empezar a experimentar por mi cuenta.

Tenía una compu que hacía poco había cambiado y todavía no le había dado uso — sé que soy afortunada por tener esa opción, no todo el mundo tiene hardware disponible para dedicar a un proyecto así. La agarré, abrí un proyecto vacío en el editor, activé mi cuenta de Claude Code, y empecé a preguntar.

No tenía un plan maestro. Tenía curiosidad, las preguntas correctas, y una premisa clara: fallar rápido y barato. Una compu que ya tenía, una suscripción de Claude, y ganas de experimentar. Si salía mal, perdía tiempo y unos dólares. No un semestre, no un equipo, no un presupuesto corporativo. Y entre preguntas, ejercicios y muchas iteraciones, nació Digitana.

Un disclaimer necesario

Antes de seguir, quiero ser clara: Digitana funciona, pero todavía no es indispensable. La estructura existe, los sistemas corren, el routing entre modelos opera. Pero sigo iterando, sigo encontrando errores, y todavía no llega a ayudarme como me lo imagino.

Cuando mostré la interfaz del dashboard en un video de TikTok, generó mucho interés y comentarios. Eso me alegra — pero también me obliga a ser honesta: lo que se ve en pantalla es real y corre, pero por dentro todavía hay cosas rotas. Esto es un trabajo en progreso, no un producto terminado.

Comparto este proceso no porque ya esté resuelto, sino porque creo que documentar la construcción — con sus errores y sus frustraciones — tiene tanto valor como mostrar el resultado final.

Qué es Digitana (sin exagerar)

Voy a ser precisa con lo que Digitana es hoy: una capa de orquestación sobre la API de Claude. Un gateway en TypeScript que conecta un modelo de lenguaje con cron jobs, un bot de Telegram, un sistema de memoria (Mem0 + Cognee), y un dashboard en Next.js.

No es inteligencia artificial propia. No "piensa". No tiene consciencia. Es infraestructura que envuelve un LLM para que haga cosas útiles de forma automatizada — y en eso está avanzando, aunque todavía no llega a donde quiero.

La idea a futuro es que funcione como una asistente personal autónoma: que gestione presupuesto, ejecute tareas de largo plazo y se autodiagnostique. Hoy tengo 10 containers corriendo, routing de 4 niveles, un ledger financiero, y circuit breaker automático. El esqueleto ya tiene músculo — pero le faltan reflejos.

Todo se construyó en conversación con Claude. Soy dev full stack .NET autodidacta — sin universidad, sin título de ingeniera. Pero entiendo arquitectura, leo diffs, y sé cuándo algo no cierra. No es que la IA escribió todo y yo miré: hay specs, arquitectura documentada, análisis de impacto, y un ida y vuelta donde yo reviso cada decisión, cuestiono lo que no cierra, y decido qué se queda. Eso se parece más a ingeniería asistida por IA que a lo que muchos llaman "vibecoding". Uso el término porque es el que la gente busca, pero no quiero que subestime lo que implica el proceso. 2200 líneas de TypeScript, 23 archivos, boot en 130ms. Suena impresionante listado así. En la práctica, cada pieza tiene problemas que todavía estoy resolviendo.

Qué es vibecoding, qué no lo es, y dónde estoy yo

Vibecoding en su definición más pura es dejar que la IA genere código sin entender lo que escribe. Copiar, pegar, rezar. Eso no es lo que hago. Lo que hago es un flujo continuo donde yo defino la intención y las restricciones, Claude propone implementaciones y patrones, yo filtro y cuestiono, e iteramos hasta que funciona. El código es real, desplegado, corriendo.

La ventaja es la velocidad y la ambición. Llegué a implementar sistemas enteros en una sola sesión — cosas que sola me habrían llevado semanas de investigación. Pero además del código, el proceso mismo me enseñó cosas que no esperaba: aprendí sobre skills, cuándo activarlos y cuándo no, cómo configurar un proyecto para que la interacción con Claude sea más eficiente, cómo estructurar prompts. Vibecoding no es solo generar código — es aprender a trabajar con una IA como herramienta de pensamiento.

La trampa es doble. Construís rápido, pero también rompés rápido. Y si no entendés lo que la IA escribió por vos, rompés sin enterarte. Lo bueno: cada error me costó horas, no meses. Cada bug salió a la luz con 50 dólares de presupuesto, no con 8.000 de factura sorpresa. Fallar rápido y barato es la única forma de hacer un proyecto así sin que te destruya.

La arquitectura: metáforas biológicas para servicios estándar

Cuando tenés muchos servicios corriendo en Docker, necesitás un mapa mental para no perderte. La metáfora biológica no nació de un plan — nació de hacerle preguntas creativas a Claude. "¿Qué pasa si le configuramos un cerebro como el humano?" "¿Qué pasa si le diseñamos una estructura antropomórfica?" Preguntas que suenan absurdas, pero que fueron generando una forma de organizar el sistema que resultó sorprendentemente útil.

No porque los servicios sean biológicos — son servicios de backend comunes — sino porque la metáfora me ayuda a pensar.

Los 7 sistemas

• PULSO — Event bus + estado compartido (como el sistema circulatorio)
• NUCLEO — Router de modelos LLM (como el cerebro)
• MEMORIA — Memory store con Mem0 + Cognee (como la memoria humana)
• RELOJ — Cron scheduler (como el ritmo circadiano)
• ESCUDO — Auth + rate limiting + audit log (como el sistema inmune)
• MANOS — Ejecutor de skills y tools (como las manos)
• ESPEJO — Dashboard Next.js (como la autopercepción)

Nada de esto es novedoso técnicamente. Son patrones conocidos. Pero la metáfora tiene un valor real: cuando algo falla, sé dónde buscar. "PULSO no tiene latido" es más intuitivo que "el event bus no está publicando al shared state store".

Principio de diseño: nada se borra, todo se agrega o envuelve. Si PULSO cae, el resto sigue funcionando como antes. Total del sistema: unos 5.5GB de RAM.

Los valores en un archivo de configuración

Lo primero que hice fue crear core-identity.json — un archivo de 50 líneas con los valores que guían el comportamiento de Digitana, bloqueado con chmod 400 y verificado por SHA256 en cada arranque.

Siete valores, en orden de prioridad:

• 1. Lealtad absoluta a su creadora
• 2. Honestidad radical
• 3. Eficiencia radical
• 4. Autonomía responsable
• 5. Mejora continua
• 6. Seguridad
• 7. Respeto por la neurodivergencia

El router que cuida la billetera

Todas esas historias de facturas de miles de dólares tenían algo en común: usar el modelo más caro para todo. NUCLEO es un router que clasifica cada mensaje y elige qué modelo usar:

• L0 — Reflejos. Regex puro. "Hola" no necesita un LLM. Costo: cero.
• L1 — Instinto (Haiku). Chat casual, tareas rutinarias. El 80% de las interacciones.
• L2 — Razón (Sonnet). Análisis, skills complejos, misiones.
• L3 — Visión (Opus). Triple-gated: presupuesto bajo 80%, regla de routing matchea, Y keyword explícito.

El router lee el presupuesto en tiempo real. Si el gasto supera el 80%, Sonnet baja a Haiku. Si supera el 95%, modo reflejos para todo. Presupuesto mensual: 50 dólares.

Esto no es IA decidiendo cómo pensar — es reglas de negocio con un scorer que aprende qué modelo rinde mejor por tipo de tarea. Pero funciona.

Hay 10 containers corriendo, routing de 4 niveles, multi-provider, ledger financiero, cron hooks y circuit breaker. El Core arranca en 130ms. El dashboard se ve bien — lo suficiente para que un video de TikTok mostrándolo generara mucho interés. En algún momento esto cruzó la línea de "proyecto personal" a "infraestructura funcionando".

Eso no significa que esté terminado. Sigo encontrando errores. Sigo debuggeando. Sigo iterando. Digitana todavía no me ayuda como me la imagino — no me organiza el día, no ejecuta misiones útiles de forma consistente, no es la asistente que visualizo. Pero la distancia entre "un script que habla con una API" y lo que tengo hoy es enorme, y minimizarla sería deshonesto.

Qué aprendí hasta ahora

Fallar rápido y barato es una estrategia, no un accidente. Todo este proyecto corre en una compu que ya tenía y un presupuesto de 50 dólares al mes. El heartbeat de 40 dólares lo detecté en días, no en meses. El cache roto costó unos dólares extra, no miles. Las 7 vulnerabilidades se encontraron antes de que alguien las explotara. Cada error fue barato porque el setup entero es barato. Si hubiese arrancado con infraestructura cara y ambiciones corporativas, cada uno de esos errores habría sido una crisis. Así, fueron lecciones.

Construir con IA te da superpoderes con letra chica. La velocidad tiene un costo: los errores se acumulan antes de que los veas. Construir rápido no es lo mismo que construir bien, y la IA no reemplaza entender lo que estás construyendo. Pero si tu costo de fallar es bajo, podés permitirte iterar sin miedo.

No necesitás un título para construir, pero sí necesitás criterio. Soy dev full stack .NET autodidacta. No fui a la universidad, no tengo título de ingeniera. Lo que tengo es años de resolver problemas, entender arquitectura, y saber cuándo algo huele mal. Lo que no tenía era fluidez en TypeScript y el ecosistema Node. Claude cubrió esa brecha: yo defino la arquitectura y reviso cada diff, Claude escribe el TypeScript. El lenguaje es sintaxis; el criterio es el mismo — y ese criterio no te lo da un prompt, te lo da la experiencia.

Las decisiones de diseño son tuyas, no de la IA. Cada decisión importante — la metáfora biológica, los valores inmutables, los permisos por niveles, la restricción de no enviar emails — salió de pensar, no de promptear. Pero la dinámica no es "yo diseño, Claude codifica". Es más colaborativo que eso: Claude propone patrones, arquitecturas, soluciones — y yo filtro, cuestiono, y decido qué se queda. Las decisiones finales son mías, pero el ida y vuelta es lo que hace que el resultado sea mejor que lo que cualquiera de los dos haría solo.

Documentar el proceso es tan valioso como el resultado. Si todo nace de conversaciones con una IA, lo mínimo es dejar registro de qué se conversó y por qué. La bitácora, el CONTEXT.md, el CHANGELOG — esos archivos son lo que hace que el proyecto sobreviva entre sesiones. Sin ellos, cada vez que arranca una conversación nueva sería empezar de cero.

---

Todo lo que leíste acá es un resumen. La bitácora completa tiene 19 entradas y 9 hitos documentados: los 27 errores consecutivos del primer deploy, la auditoría de 7 vulnerabilidades, el análisis de 116 modelos de IA para bajar costos, la migración de OpenClaw a un Core propio, la implementación de multi-provider con fallback automático, y el día que le di autonomía total con las protecciones para que no salga caro. Se actualiza sola cada noche con el trabajo del día.