You're on Aider: it writes the change on a branch, Data Workers carries it into production
Your engineers pair with Aider in the terminal and every edit lands as a git commit. Data Workers reviews the data impact of each pull request, proposes the fix and carries approved data changes into production with a receipt.
Your engineers already pair with Aider. They cd into the dbt project, run aider with the model they like, add a few files to the chat and ask for the change. Aider maps the repository, edits across files, lints each edit and, with --auto-test, runs your --test-cmd and fixes failures, then commits every change to the branch with a Conventional Commits message and "(aider)" on the author. When an edit is wrong, /undo takes it back. Some work in ask mode first and switch to code mode once the plan is agreed; others leave AI! comments in their editor and let watch mode pick them up. Git is the safety net, and it works. Data Workers is the agentic data platform that meets Aider where its work lands: on the branch and the pull request. Aider writes the change. Data Workers reviews what that change does to the data, proposes the fix, and carries the approved change into production with a receipt.
Key takeaways
- •Aider is the pair programmer. Data Workers is the data reviewer and the production crew. Aider writes and commits the code; Data Workers reviews the data impact of the pull request, routes the change to its owner and ships it safely.
- •They meet in git. Every Aider edit is a commit on a branch. Every pull request gets a Data Workers review: lineage, schema, row counts, downstream readers outside dbt, and a risk level, kept as one current comment on the PR.
- •The review feeds straight back into Aider.
/run gh pr view --commentsbrings the review into the chat, and Aider commits the fix on the same branch. - •Git undoes code. Data Workers undoes data. Aider's commits make code reversible; Data Workers keeps a rollback point in the warehouse and a receipt for every production change.
- •Engineers can also run Data Workers alongside Aider from any MCP client in the next terminal pane, for questions, blast radius and incident work during the session.
Aider is the pair programmer. Data Workers is the data reviewer and the production crew.
Aider holds the repository: the files in the chat, a map of the rest, your conventions file, and the history it writes into git. What it doesn't hold is the state of the estate: which Snowflake tables are canonical, which Looker Explores and reverse ETL syncs read a column, who owns customer data, and what a change does to row counts once it runs. That is what Data Workers holds. The Data Context Wizard keeps one governed context graph across warehouses, dbt, orchestration and BI. The Data-Agents Swarm (20+ specialist agents) does the data work, from reviewing what a pull request does to the data to planning and applying the migration. The Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember. Spellbook Data Catalog (in preview) is where people review, approve, roll back and audit.
Here is one change, end to end. It is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 10:05 | Aider | An analytics engineer asks Aider to rename customer_id to account_id in dim_customers and its references |
| 10:09 | Aider | Aider edits 4 files; --test-cmd runs dbt build on dev and passes; Aider commits to rename-account-id |
| 10:14 | GitHub | The engineer opens PR #412 |
| 10:17 | Data Workers | Reviews the PR: risk HIGH. A Looker Explore and a Census sync to Salesforce read customer_id from Snowflake, outside the dbt project |
| 10:20 | Aider | The engineer runs /run gh pr view 412 --comments; Aider reads the review and adds customer_id back as a compatibility column |
| 10:26 | GitHub | Data Workers re-reviews: risk LOW. A reviewer approves and merges |
| 10:41 | Spellbook | The customer data owner approves the production change, as the domain requires |
| 10:44 | Snowflake | The owner applies the drafted change blue/green, with its rollback SQL on file |
| 10:58 | dbt | The production run passes; quality checks pass |
| 11:05 | Looker, Census | Explore and sync row counts match; the receipt is written |
Nobody reverted anything. Aider did what it does best: wrote a clean multi-file change, tested it, committed it, and then wrote the fix the review asked for. Data Workers did the data work: it saw the two readers that no test in the repository could see, gave the engineer a fix Aider could make in one message, routed the production change to the person who owns customer data, applied it reversibly and proved it held. The compatibility column now has an owner and a removal date in the receipt, so the next migration wave can drop it once the Explore and the sync move to account_id.
| What Aider does | What Data Workers does |
|---|---|
| Pairs with the engineer in the terminal, in ask, code or architect mode | Answers data questions from governed context: lineage, ownership, definitions, recent changes |
| Edits files across the repository using its repo map | Reviews what the pull request does to the data, in dbt and in every system outside it |
| Lints and runs your tests after each edit, and fixes failures | Checks row counts, schema and downstream readers, and gives the PR a risk level |
Commits every edit with attribution; /undo reverts it | Keeps a rollback point in the warehouse; one approval reverts the data change |
| Leaves a clean git history for the branch | Writes a receipt that outlives the PR: who asked, who approved, what changed, how to undo |
Why doesn't Aider just do this itself?
Focus and risk. Aider is an open-source pair programmer that runs on the engineer's machine with the model the engineer chooses. Its design puts git at the center: it commits every edit, commits your dirty files separately before touching them, and marks what it wrote, so any change can be reviewed or undone with tools every engineer already knows. That is exactly the right design for code, and it is why so many engineers trust it with their repositories.
A production data change is a different kind of object. Once a rename runs in Snowflake, git revert doesn't bring back the Looker Explore or the Salesforce sync that broke. Doing it safely takes context about systems Aider never opens, a blast radius across them, an approver per data domain, a rollback point in the warehouse, checks after the change runs, and a receipt an auditor can read next quarter. It also means carrying responsibility for changes in tools a terminal pair programmer doesn't own. Aider is right to stop at the commit. Data Workers starts at the pull request, and the two fit together through the workflow your team already uses.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, another contract and another handoff. Data Workers covers the whole data lifecycle with one context, one approval flow and one audit trail. Aider owns a valuable slice of it: writing and committing code with an engineer at the keyboard. It leads where that is the work: pipeline code.
| Stage | Data Workers | Aider | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Aider builds a repository map and reads the conventions files you add; it doesn't keep a catalog. Data Workers keeps one governed context graph across warehouses, dbt, orchestration and BI. |
| Analytics & Insights | 8 | 4 | Aider's ask mode explains code and answers questions about the repository. Data Workers answers business questions from governed definitions, lineage and ownership. |
| Data Quality | 8 | 5 | Aider writes tests and, with --auto-test, runs your suite after each edit and fixes failures. Data Workers runs and repairs checks across platforms and keeps them running. |
| Observability & Incidents | 8.5 | 2 | Aider fixes the error in front of it; it doesn't watch production. Data Workers detects, traces and closes incidents across systems with a receipt. |
| Pipelines & Ingestion | 8.5 | 9 | Aider leads. It writes dbt models, SQL and DAG code across files, lints and tests each edit, and commits it to your branch. Data Workers owns the change in production behind approval. |
| Schema & Migration | 8 | 6 | Aider writes migrations and multi-file refactors well. Data Workers checks the blast radius in every downstream system before a schema change lands. |
| Governance & Access | 8.5 | 2 | Aider marks its commits with an author attribution or a Co-authored-by trailer, so git shows what it wrote. Data Workers routes changes to data owners and proposes least-privilege grants behind approvals. |
| Security & Privacy | 8 | 4 | Aider runs on the engineer's machine and sends code to the model you choose. Data Workers flags sensitive column names in pull request review across the estate. |
| Cost / FinOps | 8 | 2 | Aider doesn't work on your warehouse bill. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 4 | Aider writes training, feature and evaluation code when you ask. Data Workers keeps the features and training data under every model healthy and traced. |
How Aider and Data Workers work together
Aider stays on top, where engineers pair, commit and open pull requests. Data Workers sits underneath: the Context Wizard, the Swarm, the Conductor and the guardrails. Git and the pull request are the handoff. Spellbook is where people look: data owners review and approve production changes, roll them back and read the audit trail.
The pull request is the meeting point. Data Workers reviews each pull request in stages: lineage and schema first, then row counts, then a guarded value comparison where the risk calls for it, ending in a LOW, MEDIUM or HIGH verdict. It keeps one current review comment on the PR, updated on every push, so the thread never fills with stale copies. A HIGH finding doesn't stop at the comment. It goes to the agent that acts on it: a migration plan from the schema agent (generate_migration), a diagnosis from the incident agent (diagnose_incident), a governance review (request_governance_review) or a quality check (run_quality_check). No agent approves its own HIGH finding; a person signs off.
Setup today. Aider reads its settings from .aider.conf.yml in the git root, the working directory or your home directory. Point its test loop at your dbt project and load your team's conventions so every edit follows them. Example:
# Example: .aider.conf.yml in the dbt project root
read: [CONVENTIONS.md] # naming rules, "never rename a column without a compatibility window"
test-cmd: dbt build --select state:modified+ --target dev --state ./prod-artifacts
auto-test: true # run the test command after every edit and fix failures
git-commit-verify: true # run your pre-commit hooks on Aider's commits
attribute-co-authored-by: true # mark Aider's commits with a Co-authored-by trailerWhen a review lands, bring it into the session and let Aider act on it:
> /run gh pr view 412 --comments
> Apply the Data Workers review: keep customer_id as a compatibility column on dim_customers.Data Workers next to Aider, in the session. For questions and blast radius before the PR exists, engineers run Data Workers from an MCP client in the next terminal pane. Every Data Workers agent is a standard MCP stdio server. Following the client setup docs, clone the repository and register the agents you need. Example with Claude Code:
claude mcp add dw-context-catalog -- /path/to/dataworkers-claw-community/start-agent.sh dw-context-catalog
claude mcp add dw-schema -- /path/to/dataworkers-claw-community/start-agent.sh dw-schema
claude mcp add dw-quality -- /path/to/dataworkers-claw-community/start-agent.sh dw-qualityThen ask, before Aider writes a line: "What reads dim_customers.customer_id?" The context agent's blast_radius_analysis and the schema agent's assess_impact return the Explores, syncs and models in the path, and the answer goes into Aider's chat as a read-only file. The same agents work from Codex, Cursor, OpenCode or Cline; see You're on Codex and You're on Cline for those setups.
The same change on the autonomy ladder. Autonomy is set per domain, on the ladder L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous.
- •L0 manual. The engineer greps LookML and asks in Slack who uses
customer_id. Aider writes the rename; the break shows up after the deploy. - •L1 observe. Data Workers reviews the PR and names the Explore and the sync. Nothing changes until people act.
- •L2 propose. Data Workers proposes the compatibility column and the migration plan with its blast radius. Aider writes it; the customer data owner approves the production change in Spellbook.
- •L3 act reversibly. For a domain you trust, Data Workers drafts approved schema changes blue/green with rollback SQL, queues the follow-on runs once the owner applies them, and writes the receipt.
- •L4 autonomous. The Conductor runs the whole migration wave: moves the Explore and the sync to
account_id, verifies both, and drops the compatibility column on schedule. Engineers read the receipt.
Aider's git safety net and Data Workers' guardrails stack. Turning one up never turns the other down.
What changes for your team
Engineers keep their pair programmer. What changes is what happens after the commit: the review, the routing, the production change and the proof now run through Data Workers, at the autonomy level each domain sets.
Reviewers stop approving SQL diffs they can't evaluate, because every PR arrives with its data impact attached. Data owners stop learning about renames from a broken dashboard and start approving scoped changes in Spellbook. On-call stops chasing which merge broke a sync: the receipt links the commit, the PR, the approver and the rollback point. The platform team gets one review gate and one audit trail for every pull request, whoever or whatever wrote it.
Keep Aider, or consolidate?
Keep Aider if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too. With a pair programmer, keeping it is the usual answer: Aider is where your engineers write code, and Data Workers makes sure every data change that code carries is reviewed, approved and reversible. Data Workers reviews the pull request whoever wrote it, so a team mixing Aider with Codex or Cline gets one review gate and one audit trail. If you already run a dedicated PR data-diff tool, Recce vs Data Workers covers how the review compares and what happens after it. For the whole category, see Your company just rolled out AI assistants. Now what?.
The case for your CFO
Your engineers already write data code with Aider, and they write more of it, faster. The outcome to buy now is that every one of those changes is reviewed for its effect on the data before merge, and carried into production safely after: fewer broken dashboards and syncs reaching leadership and customers, fewer mornings lost to "what changed?", and an audit trail for every production change.
The risk story is plain. At L1, Data Workers only reads, reviews and explains. At L2, it proposes and a named owner approves. At L3, it acts only where a change is reversible, and keeps the rollback point. L4 is reserved for domains you've trusted on evidence. Every action leaves a receipt: who asked, who approved, what changed, what it touched, and how to undo it. Aider keeps its own safety net in git, so code and data are both reversible. Nothing migrates: Aider, GitHub, dbt, Snowflake, Looker and Census all stay. The cost case and how to model it are on the ROI page, and deployment and data handling are on the security page.
Why now: coding agents multiply the number of pull requests that touch data, and human review of SQL diffs doesn't scale with them. The safety page walks through what agents can and can't do at each level, and the build-vs-buy page covers what it takes to wire review, approvals and rollback yourself.
The first win is small and visible: a Data Workers review on every pull request in one dbt project, so the next breaking rename is caught on the PR. Start with a pilot; pricing has the details, and the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Our engineers keep Aider for the code; Data Workers reviews every data change it writes and carries the approved ones into production with a receipt."
Getting started
Start with a pilot. Pick one dbt project where engineers already pair with Aider, turn on Data Workers reviews for its pull requests, and run the domain at L1 for the first weeks so every PR gets a risk level and a list of downstream readers. Move to L2 when the reviews hold up, so Data Workers proposes fixes and owners approve production changes in Spellbook, and to L3 for the schema changes your team approves every time. See pricing; the pilot is credited in full against the first year.
FAQ
Does Data Workers change how engineers use Aider? No. Aider keeps its commands, modes, config and git workflow. The only new step is reading the Data Workers review on the pull request, and /run gh pr view --comments brings it into the chat when the engineer wants Aider to act on it.
What does the review check that our dbt tests don't? dbt tests check the models in the project. The Data Workers review also looks outside it: BI Explores and workbooks, reverse ETL syncs and other readers of the changed columns, plus row-count and schema differences between environments, ending in a LOW, MEDIUM or HIGH risk level.
Who approves the production change? The data owner for that domain, in Spellbook, at the level you set. Code review still happens on the pull request as it does today. A HIGH finding always needs a person; no agent approves its own.
Can engineers use Data Workers inside an Aider session? They run Data Workers from an MCP client next to Aider, such as Claude Code, Codex, Cursor or OpenCode, and add the answer to Aider's chat as a read-only file or with /run. Many teams do this for blast-radius questions before a refactor.
Whose credentials touch Snowflake? Data Workers' own credentials, scoped per domain, so no personal warehouse keys sit on laptops for production changes. The engineer and the approver are recorded on the receipt.
What happens if a merged change still breaks something? The receipt links the commit, the pull request and the rollback point. Data Workers traces the break, and one approval rolls the data change back while Aider reverts or fixes the code on a new branch.
Sources
- •Aider, home page (AI pair programming in your terminal; git integration, linting and testing, IDE use, install): https://aider.chat/ (checked Oct 2, 2026)
- •Aider, "Git integration" (commits every edit, dirty commits, /undo, /diff, --git-commit-verify, attribution and Co-authored-by): https://aider.chat/docs/git.html (checked Oct 2, 2026)
- •Aider, "Linting and testing" (--lint-cmd, --test-cmd, --auto-test, fixes failures): https://aider.chat/docs/usage/lint-test.html (checked Oct 2, 2026)
- •Aider, "Chat modes" (code, ask, architect, help): https://aider.chat/docs/usage/modes.html (checked Oct 2, 2026)
- •Aider, "In-chat commands" (/run, /read-only, /web, /test, /code): https://aider.chat/docs/usage/commands.html (checked Oct 2, 2026)
- •Aider, "Specifying coding conventions" (--read CONVENTIONS.md): https://aider.chat/docs/usage/conventions.html (checked Oct 2, 2026)
- •Aider, "Aider in your IDE" (AI! and AI? comments): https://aider.chat/docs/usage/watch.html (checked Oct 2, 2026)
- •Aider, "YAML config file" (.aider.conf.yml locations and keys): https://aider.chat/docs/config/aider_conf.html (checked Oct 2, 2026)
- •Aider, "Release history": https://aider.chat/HISTORY.html (checked Oct 2, 2026)
- •Aider on GitHub (Apache-2.0): https://github.com/Aider-AI/aider (checked Oct 2, 2026)
- •Data Workers, "Client Setup" (agents start as MCP stdio servers via start-agent.sh): https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository (
blast_radius_analysisin agents/dw-context-catalog;assess_impact,generate_migration,apply_migration(blue/green) androllback_migrationin agents/dw-schema;diagnose_incidentin agents/dw-incidents;request_governance_reviewin agents/dw-governance;run_quality_checkin agents/dw-quality): https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026) - •Data Workers blog, pre-merge data review (LOW/MEDIUM/HIGH verdict, blast radius, schema and row-count diffs, HIGH findings routed to the schema, incident and governance agents): https:///blog/data-change-review-agent/ (checked Oct 2, 2026)
- •Aider on PyPI (aider-chat, latest release Feb 12, 2026): https://pypi.org/project/aider-chat/ (checked Oct 2, 2026)