Atlas is a terminal-native AI coding agent for dbt projects, where ref(), materialization strategy, and schema tests are the entire engineering surface. Run atlas in a project with a dbt_project.yml and a models/ directory, and Atlas reads your model DAG through ref() and source() calls, your schema.yml tests, and each model's materialization config. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a change to a model's materialization is something you read before dbt ever runs it against a warehouse.
Why dbt developers use Atlas
dbt developers use Atlas in 2026 because a dbt project is a graph, not a pile of SQL files. Atlas reads your model DAG through ref() and source() calls, your schema.yml tests, and each model's materialization config, so it knows which models a change actually breaks downstream.
The unit of work in dbt is the model, and its edges are ref() and source() calls. Renaming a column in a staging model is safe or catastrophic depending entirely on who refs it. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so asking who depends on this model returns the downstream models that ref() it rather than every .sql file mentioning the table name. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, which means the Jinja and SQL structure of a model is parsed rather than skimmed.
Converting an expensive table model to incremental
Ask Atlas to convert an expensive table model to incremental with a proper is_incremental() filter and unique_key. Atlas rewrites the config block and adds the guard so only new rows are scanned on a normal run, then surfaces all 3 pieces, config, filter, and unique_key, as one unified diff before writing.
An incremental dbt model is easy to get subtly wrong. Without a unique_key, a late-arriving row is inserted twice. Without an is_incremental() filter, the model rebuilds the world on every run and the materialization change bought nothing. Without the filter referencing the model itself through the this relation, the incremental predicate has no watermark to compare against. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, so the intended config block, the unique_key, and the is_incremental() predicate are all visible before any model file changes on disk.
Running dbt build against dev, never prod
Atlas runs dbt build against your dev target behind a permission prompt, never against prod. Every Atlas tool call is checked against 3 rules, allow, ask, and deny, so a dbt build in a dev schema can be allowed while any invocation naming the prod target sits behind a deny rule.
dbt is the rare toolchain where an agent's shell command has a direct blast radius in a warehouse. A materialization change plus a run against the wrong target can drop and recreate a production table. Atlas gates every tool call against allow, ask, and deny rules, which is exactly the control this needs: allow dbt build against the dev target, deny anything that names prod. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, so if the dev run shows the incremental predicate was wrong, the model file returns to its previous state cleanly.
Adding schema tests to new dbt columns
Atlas adds not_null and unique tests to the new columns, then formats the SQL with sqlfmt. Those 2 tests are the dbt contract, and a new column with no test is an untested column, which is the most common way a dbt pull request ships a silent data-quality regression.
dbt schema tests earn their keep because they run on every build. A unique test on a model's grain catches the fan-out from a bad join before a dashboard does, and a not_null test on a foreign key catches an inner join that quietly became a left join. Because Atlas has already read your schema.yml tests, it adds the new not_null and unique entries in the file and the format your project already uses rather than inventing a second convention. sqlfmt then normalizes the SQL in the diff, so review is about the logic rather than the whitespace.
Review and safety in a dbt project
Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so in a dbt project every change to a models/ file, a schema.yml test, or a materialization config is reviewed first. Atlas keeps you in the loop at 2 gates: that diff, and the permission prompt on any dbt build.
Review in dbt is not optional, because SQL that compiles is not SQL that is correct. Atlas keeps the human in the loop at two places that matter: the unified diff for every model and schema.yml edit, and the permission prompt on any dbt build. Analytics engineers can also point Atlas at their own tooling, since Atlas connects to Model Context Protocol servers and exposes their tools to the agent, and Atlas is extensible through plugins that contribute tools and hook into agent lifecycle events. The commit that lands contains the model change, the is_incremental() filter, and the tests together.
Getting started
- 01Run atlas in a project with a dbt_project.yml and a models/ directory.
- 02Let Atlas read your model DAG through ref() and source() calls, your schema.yml tests, and each model's materialization config.
- 03Ask Atlas to convert an expensive table model to incremental with a proper is_incremental() filter and unique_key.
- 04Let Atlas run dbt build against your dev target behind a permission prompt, never against prod.
- 05Have Atlas add not_null and unique tests to the new columns, then format the SQL with sqlfmt.
Frequently asked questions
- how to use an AI coding agent with dbt
- Run atlas in a project with a dbt_project.yml and a models/ directory. Atlas reads your model DAG through ref() and source() calls, your schema.yml tests, and each model's materialization config, then proposes edits as unified diffs.
- how do I convert a dbt table model to incremental
- Ask Atlas to convert an expensive table model to incremental with a proper is_incremental() filter and unique_key. Atlas rewrites the config block and shows the change as a diff before writing.
- can an AI agent run dbt build without hitting production
- Yes. Atlas runs dbt build against your dev target behind a permission prompt, never against prod, because every tool call is permission-gated against allow, ask, and deny rules.
- can AI write dbt schema tests
- Yes. Atlas adds not_null and unique tests to the new columns in your schema.yml, then formats the SQL with sqlfmt.
- does an AI agent understand dbt ref() dependencies
- Atlas reads the model DAG through ref() and source() calls, so it knows which downstream models a change breaks rather than guessing from table names in SQL text.
- can I roll back an AI change to a dbt model
- Yes. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and every model edit is shown as a unified diff first.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Onboard to an Unfamiliar dbt Codebase with Atlas in 2026
Atlas helps dbt developers in 2026 quickly build a mental model of new repositories. Leverage semantic search, `ref()` analysis, `dbt test`, and `sqlfmt` to understand complex dbt projects without reading every file.
Rename a symbol across the repo in dbt with Atlas in 2026
Effortlessly rename dbt macros, models, or columns across your entire project with Atlas. Leverage semantic understanding and dbt's toolchain for safe, accurate refactoring in 2026.
Automate GitHub Issue and Pull Request Triage in dbt with Atlas in 2026
Streamline dbt project maintenance in 2026. Atlas automates GitHub issue and pull request triage, integrating with `dbt test`, `sqlfmt`, and `dbt deps (packages.yml)` for safe, trusted, and efficient dbt development
Self-review your working diff before committing in dbt with Atlas in 2026
Catch your own dbt mistakes before they reach review or CI. Atlas helps dbt developers self-review uncommitted changes, run dbt test, and format with sqlfmt in 2026.
Debug a single failing test in dbt with Atlas in 2026
Pinpoint and fix failing dbt tests efficiently with Atlas in 2026. Leverage Atlas's AI to run `dbt test` in isolation, trace `ref()` calls, and apply precise code fixes.
Review a dbt Pull Request with Atlas in 2026
Atlas helps dbt developers in 2026 review pull requests by providing deep context beyond the diff. Catch subtle bugs in dbt models, tests, and materializations with intelligent code analysis and real dbt toolchain
Audit a dbt Repository with Parallel Subagents in Atlas in 2026
Sweep your dbt project for issues without context window limits. Atlas uses parallel subagents to audit `dbt_project.yml` and `schema.yml` files, leveraging `dbt test` and `sqlfmt` for comprehensive review.
Migrate a deprecated API across every callsite in dbt with Atlas in 2026
Migrate deprecated dbt APIs across your entire codebase with Atlas. Find every `ref()` and macro call, validate with `dbt test`, and format with `sqlfmt`.