Dex by Exmergo

Turn Your Coding Agent into an Analytics Engineer

Developer Tools

Artificial Intelligence

Data & Analytics

Hi PH, Marco here, co-founder of Exmergo. We decided to open-source Dex, which we built internally for agent-native analytics engineering. We build a lot of product and marketing analytics internally, and as a small founding team we leverage our coding agents to do so quite heavily. We've found that your generic coding agent is obviously very good at writing SQL, but it's very bad at managing the entire analytics lifecycle. Relearning a schema every session. No strategy for a warehouse with messy unstructured data (e.g. CDC streams from Firestore to BigQuery). PII detection that's up to the agent's willingness to treat sensitive info delicately. No idea how much a query would cost until the bill showed up after the fact (disastrous for potentially giant JSONs nested within columns). So we wrote the parts that were missing. A cost guard first, then a profiler that works from aggregates instead of raw rows. Then a snapshot, so the next session could start where the last one stopped. After just a few analytics initiatives where we used it end-to-end, we decided to open-source it. And now after a few weeks of early user feedback, here it is on Product Hunt! https://github.com/exmergo/dex Here is the whole flow. Install it: npx skills add exmergo/dex Or the plugin route if you are in Claude Code. Point it at a warehouse and (optionally) a dbt project. If you want to try it with no credentials at all, point it at a local DuckDB file instead. /dex:explore reads the warehouse. It ranks what matters and profiles selectively, infers joins and then verifies them with real probes, and caches a draft map to .dex/. It is read-only, and a scan clears a cost ceiling before it runs: bytes on BigQuery, warehouse seconds on Snowflake, DBUs on Databricks, RPU-hours on Redshift. PII gets flagged, stays flagged, and never comes back in the answer. We flag PII quite aggressively, so false positives are to be expected. You can manually override PII-flagged columns in the `pii_overrides` entry in `.dex/config.yml`. /dex:transform writes the dbt work. Staging through marts, tests and docs alongside, MetricFlow semantic models on top. Every change arrives as a diff, validated against your dev target. Every transformation plan produces an at auditable `.dex/plans/.json`, and nothing touches the dbt project until an `transform apply` is run. /dex:maintain is the one I use daily, and honestly the most loved by our early users doing real data and analytics engineering. It diffs your warehouse and your project against the last snapshot and tells you what broke: a column renamed out from under a model, a load that arrived at 5% of its usual volume, a new join that quietly cost a fact table its uniqueness. Then it proposes the edits. On dbt Labs' ADE-bench, 75 tasks, Dex resolves 76% with Claude Sonnet 5 at roughly 2.5x lower cost than Claude Fable 5, per our open-sourced benchmark measurements. The raw results for every run are in the repo. We publish that as a floor, not a trophy (though we are optimizing for performance, so stay tuned). But a pass rate cannot tell you whether you trusted the diff, and the diff is the part that actually matters. One thing that differentiates us from the "skill" packs: Dex is also a Python package. The engine under the three commands is on PyPI as exmergo-dex-core, with a real programmatic API, so you can drive the same loop from your own code instead of shelling out to a CLI and parsing JSON. https://pypi.org/project/exmergo... Apache 2.0, free, no account. Read the SKILL.md files in the repo before you run anything. It touches your warehouse, and you should know exactly what it does first. We currently support these data warehouses and databases: Snowflake, Databricks, Google BigQuery, AWS Redshift, DuckDB, Postgres On our roadmap: Trino, ClickHouse, and Microsoft data warehouses. And the thing I would most like from you. If you run dbt, tell me where /dex:maintain would have saved you, and where it would have gotten it wrong. Drift detection is both the most valuable and the trickiest part to nail down, given the breadth of issues that can come up. And please, open an issue on GitHub for any bugs or enhancements!