Taipei dbt Meetup: los AI agents confiables dependen de la infraestructura de datos

Charla de Toshitaka Ito, Staff Solutions Architect de dbt Labs, apenas tres semanas después de completarse la fusión Fivetran + dbt Labs (junio 2026, ~$600M de ARR combinado). El tema: 可信賴的 AI Agent 取決於資料基礎架構 — los AI agents confiables dependen de la infraestructura de datos.

El problema central

La comparación que estructura toda la charla:

人類能夠補足缺失的脈絡，但 Agent 只會放大這些缺失 — los humanos compensan el contexto que falta; los agents solo amplifican esas carencias.

De ahí la capa “estrella” de la arquitectura conjunta: Governed Context — lineage, semantic layer (“revenue” significa lo mismo para todos los agents) y metadata. Sin esa capa, poner agents encima de tus datos solo acelera la propagación de errores.

Fusion engine: compilar local, ejecutar remoto

De las tres novedades de junio (dbt Core v2.0, dbt State, dbt Wizard), la más significativa es el Fusion engine, reescrito en Rust. El cambio de paradigma: antes cada error requería un round-trip al warehouse; ahora la query se compila y valida localmente (con DuckDB por debajo) y solo toca el warehouse cuando es válida.

Lo vi en el demo: dbt run procesó 31 modelos en 2,3 segundos — imposible si cada query fuera a Snowflake. Incluso detectó localmente un error de configuración (MERGE strategy requires unique_key) sin tocar el warehouse. Como desarrollador Java, la analogía es directa: es pasar de “compilar en producción” al compilador + LSP de IntelliJ — feedback inmediato.

dbt State: no reconstruyas lo que no cambió

dbt State detecta qué modelos cambiaron y solo reconstruye lo afectado — dbt Labs reporta ~30% de reducción en costos de compute. En el demo: primera ejecución construyó 32 modelos; la segunda, sin cambios, solo 2 (30 reutilizados).

La estrategia Deferral me pareció el killer feature para desarrollo: tu entorno DEV puede estar completamente vacío y los modelos upstream se referencian directamente desde PROD. En el demo, tras un DROP CASCADE total, construyó el modelo modificado en 17 segundos usando PROD como upstream. Clone es la variante con aislamiento: upstream copiado a DEV con zero-copy clones (punteros, no copias reales).

dbt Wizard: prometedor, pero beta es beta

El agent especializado en analytics engineering, conectado por MCP al índice local dbt_index — en lugar de mandar todo el schema en el prompt, consulta solo lo necesario (“zero token waste”). En el demo… falló: MCP client for dbt_index failed to start, índice de Fusion corrupto. El sistema sugirió “pregúntale al wizard” — pero el wizard era lo que estaba roto. 😄

La arquitectura, eso sí, es el mismo patrón que Claude Code: un CLI que la extensión lanza como proceso background, hablando MCP con un server local de contexto.

Del Q&A

Le pregunté (entre otros) por el mejor camino para usar dbt desde un code agent: su recomendación es dbt Wizard si ya estás en la plataforma, o dbt-agent-skills + dbt MCP server si vives en Cursor/Claude Code — viable pero más DIY.

Dos respuestas más que valen la pena:

• ¿Semantic Layer en vez de text-to-SQL? Sí, pero como primera línea con fallback a text-to-SQL: el semantic layer tiene alta precisión dentro de su coverage y, cuando no puede responder, da error en vez de inventar. El cuello de botella real no es la capacidad del modelo — es si los datos están organizados de forma que el agent pueda usarlos con seguridad.
• ¿El analytics engineer desaparece? El rol cambia hacia definir contexto, tests, metadata y governance. Y aunque cada equipo sea más pequeño, la demanda total puede crecer — el clásico argumento de la paradoja de Jevons aplicado al desarrollo: cuando una actividad se vuelve más eficiente, su uso total tiende a aumentar.

Sus best practices para agent coding cierran bien: tareas pequeñas, compile/build/test tras cada cambio, y siempre revisar el diff — tanto del código como de los datos. No confiar ciegamente en el output del agent.