Agent Analytics Engineer

Build tools not agents

A data team I work with has the typical issue with their backlog of having many small to medium complexity tickets; not all the interesting kind like data modelling etc, but many requests from stakeholders for new fields etc that enhance their data exploration. The backlog is full of tickets like add region column to the accounts mart, expose this staging model to the reporting layer, update the description on that dimension. Bread-and-butter analytics engineering. The kind of work that’s genuinely valuable, unambiguously well-defined, and also somewhat tedious. The kind of work that would be better done by a machine if possible.

The team lead asked me: “Could AI do this?”

“Sure,” I said. “Maybe we could build an agent.”

---

Phase 1: The CLI Agent

In mid-December I sat down and built a CLI agent in Python. Tools included: Jira API, GitHub API, git operations, file reads and writes - all wrapped around Claude as the reasoning engine using the Claude SDK. The architecture was simple: deterministic scaffolding around an LLM. My code handled authentication, API calls, repository setup. Claude did the thinking.

It worked. The agent would read a Jira ticket, create a branch, explore the dbt project, write the SQL and YAML changes, open a pull request, and transition the Jira status. I named the project JiraDE¹.

I was writing the agentic loop myself… deciding tool order, handling errors, managing retries. Every edge case was my problem. The agent was capable but rigid, and I was spending more time on the scaffolding than on the domain logic that actually mattered.

Phase 2: The REPL

In January I added an interactive mode jirade chat, a conversational REPL with twenty-two tools. For the tickets where full autonomy was overkill, I could guide the agent through the work, nudging it past gotchas the fully autonomous mode would get stuck on. I integrated dbt Cloud CI so the agent could validate its own pull requests before human review.

The REPL was genuinely useful. However, I was still maintaining a bespoke agent runtime. Every new failure: rate limits, context window management, tool call validation… was mine to handle. I was building an agent from scratch when Claude Code, the tool I was using every day, already was one. The best one out there, too.

Phase 3: The MCP Server

Then it dawned on me.

In early February I stripped out the agent loop entirely and exposed Jirade’s tools via MCP directly to Claude Code. I replaced the dbt Cloud CI integration with something far more controllable: running a custom-built dbt CI locally against Databricks, with isolated schemas and metadata-only comparisons². It also produces a helpful diff report comparing the models built in CI with prod equivalents, explaining row count, nullness and schema changes.

Claude Code became the agent. It already had the reasoning, the error recovery, the context management, the ability to recover from mistakes and try alternative approaches. I just needed to give it the right tools: Jira search and transitions, GitHub PR management, dbt local CI on Databricks, deprecation impact analysis. The tool schemas are defined, Claude Code discovers them via MCP, and the rest is its problem rather than mine.

The message crystallised across the weeks working on this project: yes, you can build agents easily now… but you shouldn’t. Give agents better tools instead. It’s a powerful development loop; the agent uses and improves the tools it has as it experiences difficulty.

---

The Closed Loop

Here’s what Claude Code now does with Jirade’s tools, end to end, without intervention:

It reads the Jira ticket. It explores the dbt project to understand the codebase. It writes the SQL and YAML changes: new models, updated schemas, altered configurations. It creates a pull request. It triggers CI against Databricks, building the changed models in isolated schemas and comparing the results against production using only aggregated metadata: row counts, column types, null rates, value distributions.

It publishes the comparison with a structured diff report in the PR, so that human approvers can approve at a glance without having to run models themselves.

If CI fails or a reviewer leaves comments, it reads the feedback, fixes the code, and pushes again. When all checks pass and the PR is merged, it cleans up the CI schemas and closes the Jira ticket.

Simple to medium complexity tickets… the add-a-column, expose-this-table, fix-this-description variety, it handles with aplomb. Even when the Jira tickets are vague or poorly specified, it infers intent from the codebase context. The constraint that matters most isn’t the model’s reasoning ability; it’s the quality of the tools you give it.

Its only limitation I’ve seen so far, is that when data has to be parsed out of semi-structured data, it can need a few iterations of trying to get it right. One Jira ticket mentioned the names to parse out but stated them in snake_case rather than camelCase, and because the agent isn’t allowed to read raw data in Databricks, it tried them verbatim. Even in this case, it just iterated off the error messages until the local dbt CI run succeeded. So while it doesn’t one-shot these, it does succeed through iteration. The issue with semi-structured data is that it doesn’t have a directly available schema from the data warehouse. I’m sticking to the idea that it shouldn’t read the data to derive it for now, especially as it does eventually succeed here.

The Implications

I wrote previously about Jevons Inversion, the idea that when AI makes a category of work dramatically cheaper, demand for that work explodes while demand for the specialists who used to do it may not. I argued this would happen to software engineers. I didn’t expect to prove the thesis quite this quickly.

Analytics engineering routine work, the tasks that fill backlogs and consume sprints, is exactly what tool-equipped agents handle well. Well-defined inputs, structured outputs, deterministic validation. The work won’t disappear. If anything, organisations will do vastly more of it, because the marginal cost drops toward zero³.

The analytics engineers doing this work will increasingly be agents with good tools, supervised by a smaller number of humans who understand the domain deeply enough to build those tools and handle the genuinely hard problems. Even the hard problems will be gradually chipped away with every new model release, every improvement to the harness and every improvement to the tools given to or built by the agent.

It may no longer be a great time to become an analytics engineer for the first time⁴. For those already in the role, the ones who understand the stack deeply enough to build the tools that agents need… it’s never been better. The work will multiply. The workers may not.

We’ll have more analytics engineering than ever. We’ll have more analytics engineers than ever. They just won’t be the same engineers, and most of them will live in a terminal window. They won’t eat, they won’t sleep, they won’t dream, they won’t go to lunch, they won’t get coffee, they won’t want a promotion, they don’t need mid-year reviews… they will just crunch through ticket after ticket after ticket.

1. JiraDE = Jira + Data Engineer. Although people seem to call it Jirade like a soft drink.

2. Jirade’s Databricks CI doesn’t expose raw data to the LLM. All comparisons use aggregated metadata like row counts, column-level statistics, schema diffs... plus a query whitelist to prevent leakage. Raw data isn’t particularly useful to LLMs anyhow. The idea is to give it eyes to see the data in its context.

3. The Jevons bit, applied literally: coal consumption rose when steam engines got more efficient. Analytics engineering output will rise when agents make it cheaper. But James Watt didn’t hire more coal miners — he built better engines.

4. Unless, of course, you’re the kind of person who would build the tools. In which case, carry on.