As agents take over execution tasks in analytics engineering, the practitioner’s role shifts from producing analytical work to directing it — from programmer to manager. One practitioner described working with OpenClaw as: “It replaced the me that used to write code, truly stepping into the programmer role and freeing me to act as a manager.” This shift happens faster with agents than it did when senior engineers moved to tech lead roles; the agent takes on execution tasks almost immediately.
From Producer to Supervisor
Before agents, an hour might go toward writing SQL — understanding the requirement, translating it to code, testing it, fixing errors, documenting it. With an agent, that same hour goes toward reviewing generated SQL, catching errors the agent could not catch, and providing judgment the agent does not have. Addy Osmani from Google described it as being “the director of the show”: the agent handles execution while the practitioner sets direction and makes judgment calls.
An agent can run dbt test across your entire project at 3 AM and have results waiting in Slack by 7 AM. It cannot decide whether a test failure represents a data quality bug, expected behavior for a new edge case, or a false positive from a recently updated upstream schema. That decision requires context the agent doesn’t have and can’t acquire from a schema definition.
An agent can write a column description for subscription_start_at. It cannot write a column description that says “the moment a subscription becomes active, which may differ from order__created_at for enterprise clients with custom onboarding flows” — because knowing that distinction requires understanding the business deeply enough to know what the next person reading the schema actually needs.
This is the structure of the director role: you define the work, review the output, and make the calls that require knowing things the agent can’t know.
What Stays Human
The Recce case study on AI-generated dbt projects documents this boundary. Claude Code, given a full dbt project end-to-end, followed naming conventions, used CTEs, and made tables incremental without prompting. But it used inner joins where left joins were needed, rebuilt a date dimension that already existed, and silently filtered null values without flagging whether they were bugs or expected behavior. The study’s conclusion: “AI-assisted analytics engineering isn’t a prompting problem. It’s an infrastructure problem.”
The AI writes valid SQL; what it lacks is the context that makes SQL decisions correct for a specific business. Human-territory items from that failure pattern:
Business context and domain knowledge. An agent can calculate churn rate. It cannot tell you that this particular client’s definition of churn excludes seasonal pauses because their customer success team handles those separately, or that the 90-day lookback was chosen because of a specific contract negotiation two years ago. That institutional knowledge doesn’t live in any schema.
Data quality judgment calls. When 15% of records are missing org_id, is that a data quality bug, expected behavior for free-tier users, or a new edge case from a recent product change? The answer requires knowing the product, the data, and the history. The agent sees the gap; you understand what it means.
Semantic modeling. The gap between “timestamp of creation” and a column description that actually tells the next engineer what they need to know is the gap between an agent and a domain expert. Good semantic modeling requires knowing what people who read the schema will be confused about, which requires knowing the business well enough to anticipate confusion.
Stakeholder communication. Designing what analytics should measure is a collaborative process. Which KPIs matter for this quarter’s board deck. What level of granularity the marketing team actually needs. How to present a metric that went down without triggering panic. That kind of work requires reading people, not just data.
Governance and trust. Ensuring data products are reliable, documented, and compliant with regulations. When an agent’s cron job processes personal data, the accountability for that data handling can’t be delegated to the autonomous process. Someone human has to be responsible. In European consulting where GDPR touches almost every pipeline, that accountability is operational, not theoretical.
Strategic orchestration. Deciding what to build, for whom, when, and why. Backlog prioritization, trade-offs between speed and correctness, the judgment about which client project needs attention this week — these are director-level calls.
The Democratization Question
Analytics engineers add value by designing workflows rather than executing them, deciding what should be tested rather than writing each test, and governing pipeline quality rather than building every pipeline. As Tristan Handy (dbt Labs CEO) noted, data engineers will be pushed in three directions: toward the business domain, toward automation, or toward the underlying platform. Teams where analytics engineers handle domain work — stakeholder conversations, data quality judgment, semantic modeling — while agents handle execution are better positioned than teams where analytics engineers were primarily doing execution work.
Practical Implications
Spend more time on specifications. The CLAUDE.md file, the skill definitions, the test expectations are the director’s primary output. A well-specified system with clear guardrails produces better agent output than a vaguely specified system with a capable agent.
Develop a critical review practice. The failure modes of AI-generated SQL are predictable — wrong join types, inconsistent temporal filters, silent data filtering. Reviewing agent output requires checking semantic correctness (“is this SQL correct for what we actually need?”), not just syntactic validity.
Invest in domain expertise. As agents handle more mechanical work, the value a practitioner provides is understanding the business well enough to make the decisions agents cannot. Documenting tribal knowledge that makes pipelines correct for a specific business serves both agent performance and institutional continuity.
Govern agent access actively. The trust gradient runs from observer (read-only, report results) to deployer (merge and deploy to production). Most agents should operate at the lower end of that gradient. Security Posture for AI Agents covers the mechanics.
Career Stage Implications
- Early career: Learn fundamentals deeply first — SQL, data modeling, business logic, warehouse mechanics. AI amplifies existing skill; it does not compensate for gaps. Being able to evaluate whether AI-generated SQL is correct requires a foundation to check it against.
- Mid-career: Building AI orchestration skills now — workflows that combine human judgment with agent execution — is the highest-leverage investment. Enough experience to evaluate AI output critically makes this stage the most productive entry point.
- Senior and lead roles: Define how agents fit into team workflow, build the guardrails and review processes, establish the governance frameworks that prevent silent data quality decisions. This includes deciding what gets automated and what does not.