Last quarter, I spent two weeks building an AI agent that could write SQL from natural language. It was impressive, genuinely impressive. I'd describe a metric in English, and it would come back with perfect queries, proper joins, even anticipated edge cases. My team thought it was magic. Then we pushed it to production and discovered it was writing SQL that was correct but wrong-queries that ran without errors but calculated metrics nobody had actually agreed on.
That's when I realized I'd been solving the wrong problem entirely.
The Seductive Promise (And Where It Breaks)
Agentic data engineering sounds like the answer to every data team's prayer: autonomous AI agents that write your entire data pipeline, from ingestion through transformation to serving, all from plain-English descriptions of what you need. No more sitting in standups explaining why the retention metric took two weeks to build. No more midnight debugging sessions because someone wrote SQL without documenting their assumptions.
The original vision is real. An agentic workflow lets you describe a business outcome ("build me a weekly cohort retention model") and have the agent figure out the steps, handle the edge cases, and ship it. That's fundamentally different from a Copilot suggesting the next line of code while you stay in control, this is the agent actually pursuing the goal and making decisions about how to get there.
But here's what nobody tells you: an AI that writes clean SQL is not an AI that writes trustworthy SQL.
Where The Real Work Actually Lives
The article makes a crucial distinction that I'm obsessed with: the bottleneck isn't the model's capability. It's the control layer. The grounding. The guardrails.
When I built my agent, I measured success by whether it produced runnable queries. Wrong metric. The real question is whether the query answers the question the business actually wanted answered, and whether anyone would stake their reputation on that answer.
This is where a semantic layer becomes non-negotiable. Not as a nice-to-have architectural pattern, but as the actual foundation that lets an agent work on your data without destroying trust. A semantic layer encodes what "active user" means, how you calculate LTV, what the attribution window is. Once that's locked in, you go from ~51% accuracy in text-to-SQL conversion to over 90%. Not because the AI got smarter. Because the context got tighter.
I've started thinking of it like this: an agent without a semantic layer is like giving someone the keys to your database and telling them to "make good business decisions." An agent with a governed semantic layer is like giving them a playbook and access to a specific set of approved operations.
The Workflow That Actually Prevents Disasters
The article's description of the workflow is the part that genuinely changed my thinking. The agent doesn't deploy directly. It ships a pull request. It runs tests. It passes CI. Then a human reviews the diff and decides whether to merge.
This is not a minor detail. This is the entire difference between "we have an AI tool" and "we have an AI tool we can actually live with."
In my production setup now, I'm implementing exactly this pattern:
# The agent proposes a dbt model and its tests
# It doesn't touch production until this runs:
class DataAgentWorkflow:
def propose_change(self, intent: str) -> PullRequest:
# Agent writes model, tests, and documentation
model = self.agent.write_model(intent)
tests = self.agent.write_tests(model)
# Create PR, don't merge yet
pr = self.repo.create_pull_request(
title=f"Auto: {intent}",
branch=f"agent/auto-{uuid4()}",
files=[model, tests]
)
# CI runs, this is where bad logic gets caught
if not self.ci.passes(pr):
self.agent.read_failures()
self.agent.iterate() # Loop until CI passes
return pr # Human reviews before merge
The key insight: let the agent fail at review time, not in production. Let tests catch the logic errors before a stakeholder asks why the numbers don't match reality.
My Take: Where I'd Push Back
I agree with almost everything in the article. But I'd argue the job description change, from "writing every transformation" to "defining intent and reviewing diffs"-is actually harder, not easier. You've traded "I know exactly what this query does" for "I need to deeply understand what the agent produced and why."
That requires more data expertise, not less. You can't just review diffs mechanically. You need to think about edge cases, data quality, whether the definitions make sense. Some teams will get this right. Others will rubber-stamp PR merges and end up with worse problems than before.
I'm also skeptical about the timeline. The article was written in 2026 (or written as if it's 2026). We're not there yet. The semantic layers aren't standardized. The agents still hallucinate. I'm not betting my data infrastructure on this being production-ready everywhere today.
What I'm Building Next
I'm going to pilot this properly. Start with one metric, one agent, one semantic layer that actually captures how my org defines key concepts. Let it propose changes for two weeks. Review every single diff. See what breaks.
Have you tried letting an AI tool touch your data infrastructure? What scared you most, and what actually went wrong?
Source: This post was inspired by "Agentic Data Engineering: How AI Agents Build Data You Can Trust" by Dev.to. Read the original article
