ETL or ELT? How about ETM

For the past decade, the debate has been ETL vs ELT. Extract Transform Load, or Extract Load Transform?

With modern data warehouses and lakehouses, the industry has moved decisively toward ELT. You load the data into your platform, then you start transforming. But analytics engineering, and data engineering as a whole, doesn't stop there. Fivetran, Databricks, and Snowflake have solved extraction and loading. An engineer's real job starts at transformation.

And transformation is an entire labor-intensive industry of its own. We believe the debate shouldn't stop at "where does transformation happen." We believe the whole conversation should shift to where the real work is being done, by real people.

That's where ETM comes in. The modern data workflow federates into three distinct verticals: Exploration, Transformation, and Maintenance.

1. Exploration

This is sense-making. Where is the raw data I need to solve a business problem? Can I lean on existing pipelines to get there? What is the grain? Which columns can I aggregate on? Engineers and scientists tackle this with notebooks, their code editors, and CLI tools.

2. Transformation

Transformation happens after sense-making. The industry standard for building transformation pipelines in enterprise data platforms is dbt. Semantic models have since emerged as the ultimate gold layer.

3. Maintenance

This is where engineers spend most of their day-to-day. Raw data changes, usually without warning. Schemas drift, volume drops unexpectedly, grain changes. Metrics and definitions change as the enterprise evolves.

Maintenance is the tax you pay on everything you built in the first two steps. And nobody budgets for it.

So how do we perform at our best across the full ETM flow?

Agents are the ultimate ETM partner

I've burned through around 500 words in this post without mentioning AI or agents. But now I will.

Your coding agent can connect to your warehouse, run queries, and inspect metadata. It can author transformation pipelines. And a week later, it can help you maintain those same pipelines and semantic models. Explore, transform, maintain. The full loop, with a partner that was there when the pipeline was written and remembers why.

So we built the best analytics engineering toolkit for agents: Dex.

/dex:explore

Point it at your warehouse and stop running SELECT * LIMIT 10 by hand a hundred times. Dex profiles your columns, infers the relationships between your tables, and builds a comprehensive draft map of your schema, cached locally in .dex/. It stays read-only and builds its understanding from SQL aggregates, never from raw rows, so nothing sensitive is copied out. PII is flagged automatically and never surfaced. Exploration is also where an unsupervised agent can quietly run up a fortune in scanned bytes, so every query clears a cost guard before it runs.

/dex:transform

Once you know the landscape, you build. Ask Dex for a metric and it hands you a reviewable diff, not a black box. It authors dependency-aware dbt SQL models, schema tests, and full MetricFlow YAML for your semantic layer. Everything validates against a dev target, behind the same cost guards, before a single line touches production.

/dex:maintain

This is the part nobody else builds for, and it's where you actually live. Run /dex:maintain against your .dex/ snapshot and it catches drift before it breaks a dashboard: schema drift when a column gets renamed or dropped, volume drift when a load comes in 95% light, grain drift when a new join fans out and silently duplicates your fact table. It proposes the exact edits to reconcile your project, on top of flagging the problem.

Get started

Dex drops into any agent with a single command in your terminal:

npx skills add exmergo/dex

If you're running Claude Code, run these two commands, one at a time:

/plugin marketplace add exmergo/exmergo-agent-plugins

/plugin install dex@exmergo

It's open source, Apache 2.0, and it scores 76% on dbt Labs' ADE-bench. Full context at exmergo.com/dex.