Entendiendo el uso de los asistentes de código: Gobernando la IA con arquitecturas «Schemaless» y RawTree

Ricardo Edo
CTO, VP of Engineering, Galeo Tech

En GALEO hemos adoptado Kiro de AWS como nuestro asistente de código impulsado por Inteligencia Artificial para todo el equipo de ingeniería. Como ocurre con cualquier organización en plena adopción de herramientas de IA, la velocidad a la que los desarrolladores integran estas soluciones contrasta con la capacidad de los equipos de operaciones para gobernarlas. Las preguntas críticas no tardan en aparecer: ¿Quién está usando realmente la herramienta? ¿Cómo se distribuye el coste real entre los distintos usuarios y equipos?

La consola de administración de Kiro en AWS ofrece métricas de uso agregadas, sin desglose por usuario, modelo o excesos de cuota. Cuando un usuario agota sus créditos de suscripción, el servicio no se detiene sino que sigue generando costes por exceso (overages) que resultan completamente invisibles hasta que llega la factura mensual. Puedes configurarla para que se detenga, pero sería como quitarnos el correo o las herramientas ofimáticas a mitad de mes, esto ya no se puede parar.

El reto de la gestión del dato: esquemas que se transforman cada mes. AWS ofrece una vía de escape: exportar distintos logs crudos de uso diario en formato CSV y JSON a un bucket de S3. Convertir esos logs en un dashboard analítico parece un reto de ingeniería de datos trivial, hasta que te enfrentas a la naturaleza del ecosistema IA actual. Kiro es un producto que evoluciona a un ritmo vertiginoso. Cada vez que se añade un nuevo LLM al asistente, aparecen nuevas columnas en los logs sin previo aviso. 

• En marzo, nuestro esquema inicial constaba de 14 columnas estables. 
• En abril, los logs mutaron para incluir métricas como claude_opus_4.6_messages. 
• En mayo, aparecieron claude_sonnet_4.5_messages y minimax_m2.5_messages. 
• Para junio, ya contábamos con qwen3_coder_next_messages.

En una base de datos relacional tradicional, esto supone un desafío operativo: requiere migraciones constantes, actualizaciones de esquema y un mantenimiento continuo de las pipelines ETL cada vez que AWS soporta un nuevo modelo. 

La solución técnica: Analítica «Schemaless» con RawTree. Para evitar construir un sistema frágil, decidimos prescindir de los esquemas rígidos. La solución arquitectónica pasa por utilizar RawTree, un motor de base de datos analítica schema-free que permite ejecutar consultas SQL completas sobre datos dinámicos y no estructurados.

RawTree además es AI friendly (https://rawtree.com/llms.txt), y el concepto de “Schemaless” se da intencionadamente la mano con este nuevo paradigma de desarrollo, donde pasamos a un plano de supervisión superior, solo queremos expresar con detalle lo que queremos y lo que debe hacer, pero cada día que pasa nos preocupamos menos por los detalles del como, solo de los resultados. 

Obviamente esta afirmación no es del todo cierta en cualquier escenario, pero para casos de uso como este, de una herramienta corporativa, nice to have, no afecto a mis clientes ni a la operativa de nadie, es el escenario perfecto para delegar al máximo sin preocuparnos de los detalles.

Nuestra arquitectura de ingesta es 100% Serverless y orientada a eventos:

1. Ingesta automática: Los CSV diarios aterrizan en nuestro bucket de S3 exportados por el propio servicio Kiro de AWS, cada vez que aparece un nuevo fichero generamos un evento con los triggers de s3.
2. Event-Driven: Este evento dispara una función AWS Lambda (Python 3.12) que realiza la ingesta directa de los nuevos registros mediante un HTTP POST hacia RawTree. No hay transformaciones ni definiciones de tipos; enviamos el CSV tal cual.
3. Persistencia dinámica: Cuando Kiro añade una nueva columna (por ejemplo, claude_opus_5.0_messages), no hay despliegues ni roturas en el pipeline; la columna simplemente aparece en la tabla y está lista para ser consultada mediante SQL de forma inmediata.
4. Capa de consumo: Para la visualización, hemos levantado un backend en Django que expone endpoints REST, ejecutando consultas SQL contra RawTree. Finalmente, un frontend interactivo construido en Vue.js renderiza el análisis de costes y el uso de modelos.

La anatomía del dato. La gran ventaja de RawTree es que nos permite ingestar un esquema base con métricas de negocio fijas, y dejar que las métricas de uso de LLMs muten libremente. Un registro diario por usuario en nuestra base de datos se ve así:

• Atributos base (Estables): Date (YYYY-MM-DD), UserId, User_Email, Client_Type (KIRO_IDE o KIRO_CLI) y Subscription_Tier.
• Métricas de negocio (Estables): Total_Messages, Credits_Used, Overage_Credits_Used y Overage_Cap (fijado en nuestro caso en 10.000).
• Atributos dinámicos (Auto-expandibles): auto_messages (cuando la IA elige el modelo), y contadores específicos por modelo que aparecen solos cuando Kiro se actualiza, como claude_opus_4.* o claude_sonnet_4.*.

Visibilidad total. Todo este flujo de datos en tiempo real desemboca en nuestro frontend en Vue.js, donde hemos estructurado la visibilidad que AWS no nos daba de serie, a través de cinco paneles clave:

1. Executive Summary: KPIs de un vistazo (usuarios activos, mensajes, créditos consumidos y excesos) con minigráficos de tendencia temporal.
2. Cost Analysis: Gráficos apilados que cruzan los créditos diarios consumidos frente al overage (sobrecoste), proyectando el gasto mensual e identificando qué usuarios superan su límite.
3. Model Usage: Distribución y tendencias de adopción de los distintos modelos de IA a lo largo del tiempo.
4. Users & Top Users: Tablas interactivas que filtran por nivel de suscripción, ordenan el volumen de mensajes y destacan con badges a los usuarios que generan excesos de coste.
5. Subscription Tiers: Comparativa del coste por usuario, tasas de exceso y métricas de eficiencia entre distintos niveles de suscripción.

Key Insights: Del dato crudo a la acción Tener esta arquitectura nos ha permitido  entender exactamente cómo nuestra ingeniería interactúa con la Inteligencia Artificial. Los datos de los últimos meses nos han revelado cuatro insights operativos fundamentales:

• La delegación del coste: Cerca del 89% de los mensajes se envían en modo «automático». Los usuarios prefieren que la herramienta decida qué modelo usar, lo cual tiende naturalmente hacia opciones más baratas.

• Un pequeño grupo de power users genera la mayor parte del sobrecoste: Ahora sabemos que es más eficiente aplicar intervenciones personalizadas a estos usuarios que cambiar las políticas globales.

• La paradoja de los Tiers altos: Los usuarios con suscripciones de nivel superior generan casi el doble de mensajes por persona. Sin embargo, también generan significativamente más overage, ya que el servicio no corta el acceso cuando agotan sus créditos.

• Evolución acelerada de modelos: La adopción de las nuevas versiones de los LLMs ocurre en cuestión de semanas. Analizar estos cambios mes a mes es vital, ya que afecta directamente al coste por mensaje de toda la organización.

Gracias a RawTree, hemos podido llevar a cabo este proyecto en apenas unas horas y con la garantía de que perdurará en el tiempo ante la evolución de los datos de Kiro, o la incorporación de datos provenientes de otras herramientas.