dbt Charts: Open Sourcing a Declarative Language for AI-Driven Dashboards

dbt Charts enables governed, AI-generated analytics by moving dashboards into code

dbt Labs has open sourced dbt Charts, a declarative language designed to define interactive dashboards using a structured YAML format. This approach solves a critical friction point in AI-driven data analysis: while AI agents can easily generate reports, they typically produce a fragmented pile of HTML, CSS, and JavaScript files that are difficult to audit, maintain, and version control. By providing a standardized, code-based specification, dbt Charts allows agents to create dashboards that remain governed, readable, and integrated into existing software development lifecycles.

Unbundling the BI Stack

Traditional Business Intelligence (BI) tools were historically "full-stack," handling everything from data ingestion and transformation to visualization and identity management. The "modern data stack" (roughly 2015–2022) unbundled the infrastructure layers, moving compute to cloud warehouses and transformation to tools like dbt.

According to dbt Labs, the final piece of this unbundling is the visualization layer. While UI-first BI tools are efficient for humans, AI agents are fluent in code, SQL, and Git, but struggle with proprietary UIs. dbt Charts moves the "how" of visualization into a YAML-based code format, while keeping SQL as the language for the "what" (the data).

Technical Architecture and Features

Declarative YAML Specification

ndbt Charts uses a YAML dialect to declare a full interactive dashboard in a single file. This file typically includes:

• Variables: UI filters and parameters.
• Queries: SQL definitions for the data.
• Charts: Definitions of the chart type (e.g., area, bar, donut), titles, and mapping of SQL columns to axes.
• Rows: The layout arrangement of the charts on the board.

Rendering and Extensibility

The dbt Charts CLI (dct) can render these YAML boards into multiple formats, including static SVG, HTML, PNG, PDF, and even the terminal. The system supports over 1,100 configuration options across 16 chart types and allows for "composed charts" for more complex visuals. To maintain brevity, the language uses cascading styles where charts inherit properties from the board, and boards inherit from a global theme.

dbt Project Integration

When used within a dbt project, dbt Charts provides deep integration with the transformation layer:

• Git-based Versioning: The charts/ directory lives alongside models/ in the same repository, ensuring that changes to data models and their corresponding charts are shipped in a single branch and validated via CI.
• Ref Functions: Queries can use ref() to reference dbt models. If a model is renamed or a column is missing, the dct validate command will fail the pull request before the broken chart reaches production.
• Semantic Layer: Future support for the dbt Semantic Layer is planned to allow boards to use predefined metrics instead of raw SQL.

Optimizing for AI Agents

dbt Charts is specifically engineered to provide AI agents with a tight feedback loop. Because the output is a strict YAML and SQL specification, the system provides automated validation and visualization checks. For example, the CLI can warn an agent if a bar chart's bands are too narrow for the available pixel width or if a table's columns overflow their slot, allowing the agent to self-correct the layout before the board is rendered.

The dbtCharts.com Platform

Alongside the open-source language, dbt Labs has launched a public beta of dbtCharts.com. This hosted platform handles the remaining "bundled" aspects of BI that are difficult to decouple: hosting, access control, and user permissions. The platform includes:

• Conversational Analytics: A chat interface with permissioned read-only access to the warehouse.
• Visual Editor: A tool for making final manual adjustments to AI-generated charts.
• Git Synchronization: Every change made via chat or the visual editor is written back to the YAML file in the Git repository, preventing vendor lock-in.

Community Perspectives and Counterpoints

The announcement has sparked discussion among data engineers and developers regarding the utility of YAML-based specifications versus more flexible alternatives.

Arguments for the Approach

• Auditability: Users have noted that this creates "artifacts that are readable, maintainable and reproduce the same dashboard consistently," avoiding the "vibe coded JS slop" often produced by LLMs.
• AI-Friendliness: The structured nature of the language makes it easier for agents to generate and validate their work compared to navigating a complex UI.

Critical Perspectives

• The "YAML-Hell" Concern: Some developers expressed a strong dislike for using YAML as a "language," arguing that conditionals and variable binding become overly complex in data formats compared to actual programming languages like JavaScript or TypeScript.
• Innovation vs. Implementation: Some critics argue that decoupling BI is not a new concept and that AI can generate any format (JSON, XML, YAML) if instructed, making the specific choice of YAML less innovative than presented.
• Alternative Tools: Community members pointed to existing alternatives such as Malloy, Observable Framework, and Vega-Lite, which offer different approaches to "dashboards as code."
• The "Bitter Lesson": One commentator suggested that as models improve, they will become better at writing primitive libraries from scratch, potentially rendering specialized intermediate specifications obsolete.