The $600 Slack Ping: What Happens When You Point a Coding Agent at Your Warehouse

It is 9:00 AM on a Monday, and your Slack is already on fire.

Your VP of Finance has sent a screenshot of the GCP billing dashboard. There is a clean vertical spike in your BigQuery spend. One query, executed late yesterday afternoon, cost exactly $620.25.

You open the query logs expecting to find a junior developer and an unindexed full-table scan. You find neither. It was your brand new autonomous coding agent. You asked it to "analyze yesterday's sign-up spikes and write a quick report," and the agent, eager to please, did what a naive developer does on day one:

SELECT * FROM `production_logs.raw_app_events` LIMIT 100;

On a 100 TB table holding years of history, that harmless-looking line triggered a full-table scan. LIMIT 100 capped the rows returned, not the bytes read. BigQuery still scanned every column across every partition to hand back 100 rows.

BigQuery's on-demand tier bills on data volume, at $6.25 per TiB scanned. So the agent lit roughly $600 on fire in under two minutes, and it had no idea it did anything wrong.

As agents like Claude Code, Cursor, Codex, and Devin become standard in engineering workflows, this stops being a funny anecdote and starts being a line item. Here is why coding agents are uniquely dangerous next to a data warehouse, and how we fixed it.

The human buffer is gone

When a person uses AI to help write SQL, the person is the safety layer. They copy the query, glance at the estimator, notice it wants to scan 100 TB, and rewrite it before it ever runs.

Give an agent terminal access and that buffer disappears. The agent writes the SQL, opens a shell, runs bq query, and parses stdout. If the query errors, it does not stop to think. It rewrites, reruns, errors again, and loops. Now you are paying two meters at once.

The token meter. Every loop, the agent re-fetches giant schemas, floods its own context window, and runs up your Anthropic or OpenAI bill. One unguarded schema dump can cost more than the query it was meant to plan.

The warehouse meter. Every loop, raw un-optimized SQL hits your serverless warehouse and bills you again. Snowflake and Databricks are among the most expensive consumption-billed software on the planet. An agent left to explore freely explores on your credit card.

Coding agents are built to write code, not to defend your infrastructure. They have no model of warehouse billing, they do not know which columns are partitioned, and they will happily pull raw customer PII into their context without a second thought.

What is missing is a layer that sits between the agent and the warehouse and holds both meters down.

We built that layer. It's called Dex.

This is the exact problem my team at Exmergo built Dex to solve. It is open source, Apache 2.0.

Dex is an agent-native analytics engineering toolkit. Instead of letting your agent talk to the database directly, you drop Dex into your workspace. When the agent needs to explore a warehouse, author dbt models, or inspect a schema, it routes through Dex's guardrailed commands rather than raw bash.

┌────────────────────────┐

│ AI Coding Agent │ (Claude Code, Cursor, Codex)

└───────────┬────────────┘

│ calls guarded tools

▼

┌───────────────────────────────────┐

│ EXMERGO DEX │

│ │

│ Dry-runs and cost caps │ the guardrail layer

│ Read-only, aggregates not rows │

│ PII flagged, never surfaced │

│ Local schema map and spend ledger│

└────────────────┬─────────────────┘

│ sends guarded SQL

▼

┌────────────────────────┐

│ Cloud Data Warehouse │ (BigQuery, Snowflake, Databricks)

└────────────────────────┘

Installed as a skill or plugin, Dex gives the agent three commands: /dex:explore, /dex:transform, and /dex:maintain. Here is how it keeps that $620 query from ever running.

1. The dry-run gatekeeper

When you ask the agent to find something, it runs /dex:explore, and Dex intercepts the query before the warehouse ever touches it.

It forces a dry-run estimate first, calculating the exact scan volume up front. It checks that estimate against a per-warehouse cost guard: bytes scanned on BigQuery, compute time on Snowflake, DBUs on Databricks. If the query is too expensive, Dex halts it, blocks the spend, and hands the agent an error it can act on, something like: Query blocked. Attempted to scan 100 TB. Filter by the partition key `event_date`. Every scan that does run is recorded in a local ledger, so the spend is auditable instead of a surprise at month end.

That is the difference between an agent that loops on errors and an agent that gets told exactly how to fix its query.

2. A local schema map, so tokens stop bleeding

To stop the agent from re-querying the warehouse every time it needs to remember what a table looks like, Dex profiles columns, infers the relationships between tables, and caches a draft map locally in .dex/. The agent reads that offline map for free instead of paying to relearn your schema on every turn. The warehouse meter and the token meter both go quiet.

3. PII that never reaches the model

You do not want raw customer emails and IP addresses leaving your warehouse for an external LLM API. Dex is built so they cannot.

Dex is read-only, and it builds its understanding from SQL aggregates, never from raw rows. Nothing sensitive is copied out, so PII never enters the model's context in the first place. Suspected PII columns are flagged automatically and left unsurfaced. Your warehouse credentials connect Dex to the database directly and never reach the LLM either. Security here is architectural, not a checkbox you remember to tick.

Equipping your agent takes about 24 seconds

Cursor, Codex, Gemini CLI, and all agents. One command wires Dex into your project via AGENTS.md:

npx skills add exmergo/dex

The next time your agent indexes the repo, it sees it has a safe database toolkit and starts routing data work through Dex.

Claude Code. Install it as a native plugin, running each line on its own:

/plugin marketplace add exmergo/exmergo-agent-plugins
/plugin install dex@exmergo

Claude then gets the /dex:explore, /dex:transform, and /dex:maintain commands directly.

The guardrails are not a tax on quality

The obvious worry is that wrapping an agent in cost guards makes it dumber. It does not. Dex scores 76% on dbt Labs' ADE-bench with Claude Sonnet 5, and runs about 2.5x cheaper than Claude Fable 5 on the same work. You get the safety and the results.

Giving an agent raw bash access to a production warehouse with no middleware is a financial time bomb with a slow fuse. You do not have to choose between speed and safety. Let your agents explore unfamiliar schemas, build dbt models, and debug pipelines on their own, and keep your cloud bill exactly where it belongs.