BI as Code: Why Code-First Analytics Powers Agentic BI

Every BI tool is about to be operated by AI agents. The question is whether your analytics stack is built in a way that agents can actually work with.

Drag-and-drop dashboards, point-and-click metric builders, and GUI-configured data models share a problem that barely mattered in the self-service era but matters enormously in the agentic era: none of them produce artifacts that machines can reliably read, modify, test, or version-control.

BI as Code is the practice of defining metrics, data models, relationships, and analytics logic in code files (version-controlled, testable, reviewable, and composable) instead of storing them as opaque state inside a proprietary application. It is an architectural prerequisite for any BI system that will be operated by AI.

What does BI as Code actually mean?

BI as Code means your analytics definitions live in files, stored in a Git repository. A metric like "Monthly Recurring Revenue" is defined in a code file that specifies the measure, the grain, the filters, the entity relationships, and the business rules, rather than configured through a series of dialog boxes and saved as internal application state.

Consider the difference.

GUI-first BI: A metric is created by clicking through a metric builder. The definition is stored in the tool's internal database. To see what it does, you open the tool and inspect it. To change it, you click through the builder again. To know when it changed, you check an audit log, if one exists.

Code-first BI: A metric is defined in a modeling file:

metric monthly_recurring_revenue {
  description: "Sum of active subscription amounts, normalized to monthly"
  measure: sum(subscription.monthly_amount)
  filter: subscription.status = 'active'
  time_dimension: subscription.started_at
}

This definition lives in a Git repository. Every change produces a diff. Changes go through code review. Automated tests validate that the metric compiles and returns expected results against test data. CI/CD deploys validated definitions to production.

The difference sounds procedural. In the context of AI agents, it is structural.

Why BI as Code matters for the AI era

AI agents read and write code. They cannot click buttons.

An agent that needs to understand your metric definitions, modify a data model, create a new analytical view, or validate a calculation works through a machine-readable interface. Code is that interface. A GUI offers nothing an agent can parse.

This creates a clear architectural divide:

Dimension	GUI-first BI	Code-first BI
Agent readability	Agents cannot inspect GUI state	Agents can parse code files directly
Agent modification	Agents cannot click through config wizards	Agents can generate and modify code
Version control	Changes tracked in internal audit logs (if any)	Every change is a Git commit with full diff
Testability	Manual validation in the UI	Automated tests in CI/CD
Code review	Impossible: changes are immediate	Pull requests for metric and model changes
Reproducibility	State depends on the tool's internal database	Any state can be recreated from code
Collaboration	One person edits at a time, merge conflicts are invisible	Standard Git branching and merging
Rollback	Undo if available, otherwise manual revert	git revert

In the self-service era, GUI-first was a reasonable trade-off: it lowered the barrier for non-technical users to create dashboards. In the agentic era, the trade-off reverses. Business users no longer need to operate the tool directly, the agent does. And the agent needs code.

The dbt parallel

This pattern has played out before. dbt won the data transformation layer by making transformations code-native during the cloud warehouse shift, rather than by building a better ETL UI.

Before dbt, transformations were defined in GUI-based ETL tools: Informatica, Talend, SSIS. The definitions were stored as proprietary XML or internal database state. They were difficult to version-control, impossible to code-review, and fragile to test.

dbt said: transformations should be SQL files in a Git repository, with tests, documentation, and CI/CD built in. It defined a high-centrality layer in the data stack, made it code-native, spread through practitioners who valued software engineering workflows, and then monetized enterprise governance needs.

The same shift is now reaching the analytics layer. The code-native approach that data engineers adopted for transformations is coming to metrics, data models, and business logic. The agentic BI movement accelerates this because agents need the same properties that made dbt successful: version control, composability, testability, and machine readability.

BI as Code in practice

Three approaches exist in production today.

LookML (Looker). Looker pioneered code-first BI with LookML, a proprietary modeling language that defines dimensions, measures, and relationships in code files. LookML brought version control and code review to BI. Its limitation is that the query layer (Explore) is still GUI-driven and the modeling language is tightly coupled to Looker's rendering engine.

dbt Metrics Layer. dbt extended its transformation layer to include metric definitions, creating a shared semantic layer that downstream tools can consume. The approach is code-native by nature, but the metrics layer sits below the analytics interface: it defines metrics without defining the full analytical experience.

AMQL (Holistics). Holistics' AML (Analytics Modeling Language) and AQL (Analytics Query Language) define the full analytics stack in code: data models, metrics, relationships, permissions, and composable analytical operations. AQL is composable along the dimension where SQL is least composable: aggregation. Period-over-period comparisons, running totals, nested aggregations, and cross-grain ratios are first-class operations in the language, built into the grammar itself.

AQL in action: AI generates composable analytics logic that the semantic layer compiles to SQL deterministically. See agentic BI development for the full local development workflow.

This composability distinction matters. A metric catalog in code is valuable. But if follow-up analysis (compare to last quarter, break down by segment, show as percentage of total) requires leaving the governed layer and falling into raw SQL, the code-first benefit degrades at the exact moment analytical complexity increases.

Why this matters beyond developer preference

The common objection to BI as Code is that it raises the barrier for non-technical users. In the self-service paradigm, that objection had weight: if the goal is for business users to build their own dashboards, code is a disadvantage.

Agentic BI changes the calculation. Business users no longer need to interact with the analytics definition layer directly. They state a business question. The agent interprets it, queries governed definitions, composes the analysis, and presents findings. The human reviews, challenges, and decides.

In this model, the analytics definition layer is infrastructure, like an API schema or a database migration. It should be readable by machines, reviewable by data teams, testable in CI, and version-controlled in Git. These are properties of code.

The data engineering layer already works this way. Pipelines are code (Airflow, Dagster). Transformations are code (dbt). Infrastructure is code (Terraform). The analytics layer is the last major piece of the data stack that still lives primarily in GUIs.

BI as Code closes that gap. It makes the entire path from data ingestion to analytical output machine-readable, version-controlled, and agent-compatible.

The bottom line

BI as Code is a structural requirement for any analytics system that will be operated by AI agents, well beyond a workflow preference for engineers who happen to like text editors.

Agents need to read definitions. Code is readable. Agents need to modify logic. Code is modifiable. Agents need to be audited. Code is diffable. Agents need to be tested. Code is testable.

The tools that survive the agentic analytics shift will be the ones that made their analytics definitions machine-native. The ones that stored business logic in opaque GUI state will find that their AI copilot can only go as far as the interface allows, which, for multi-step analytical work, falls short quickly.

The foundation for agentic BI is a better substrate. And that substrate is code.