There are two things almost nobody says in the same breath about AI in data engineering. The first is that it works. The productivity gains are real, and I have watched them happen on real systems, not in demos. The second is that those gains arrive on a meter, and the meter does not stop just because you are impressed.
Most of the writing on this topic picks one. The hype crowd talks about the multiplier and ignores the bill. The skeptics talk about the bill and miss what is actually being delivered. The engineers who come out of this era ahead, especially the ones moving from senior IC toward leading teams, are the ones holding both ideas at once. AI multiplies your output, and left unchecked, it just as quietly multiplies your cost and obscures who actually did the work.
Let me take those in order.
1. The multiplier is real
I will start with something concrete, because the abstractions are cheap.
An engineer I coach had been staring at a tangle of ORM-generated SQL, the kind of machine-emitted query nobody writes by hand and nobody fully understands later. The question was not “is this slow.” It was the more basic one: where is this data even coming from, and what is this query actually doing? Tracing that by hand, jumping across repos and generated layers, is the kind of work that eats days and produces nothing you can show anyone.
He pointed Claude at the repositories and used it to trace the logic. The manual version of that investigation would have taken days. With AI doing the legwork, it collapsed into a fraction of that, and it surfaced something worth surfacing: a query running redundant joins to return data that lived entirely in the base table. The joins were not doing anything. They were complexity that had been hiding the fact that only base-table data was ever coming back.
That is the part I want to be precise about. The win was not speed. The win was legibility. AI turned an opaque, over-joined query into something a human could finally reason about and simplify. Speed was a side effect.
In a separate piece of work, the same pattern showed up against production infrastructure. An AI-generated Python script profiled a single table, surfaced a set of unused indexes quietly eating storage, and then benchmarked the before-and-after across their production fleet. That is not a toy. That is a measurable footprint on real systems.
And here is the line I would put in bold if this were a slide. He is the first to say AI is wrong often enough that you check everything. That caveat is not a weakness in the story. It is the whole point. The multiplier only works in the hands of someone who can tell when the output is wrong.
This is also where the market is pointing, if you read the job descriptions honestly. Data engineering fundamentals are still the floor, but the postings increasingly assume you can pair them with AI-assisted workflows, cloud, and CI/CD as table stakes rather than differentiators. The skill being priced is not “uses AI.” It is “uses AI and knows when to overrule it.”
2. The meter is running
Here is the part the multiplier stories leave out.
Agentic AI does not bill like the software you are used to buying. For two decades, enterprise tools billed like SaaS: a flat seat fee, the same whether your team hammered the tool all day or forgot it existed. AI bills like the electric company. Every prompt, every long document pulled into context, every autonomous agent looping through a multi-step task draws metered compute, and you pay by the micro-unit. Inc. made exactly this comparison in its recent coverage, and it is the right one.
The cautionary tale in that same reporting: a company reportedly burned through roughly half a billion dollars in a single month after rolling Claude out to its workforce with no usage caps. People ran long queries and complex agent workflows, and the tab piled up before finance understood the meter was even on. That figure deserves the honesty caveat. It traces back to a single consultant’s account of one client, and Inc. framed it as a canary, not a verified statistic. But you do not need the number to be precise for the lesson to be true.
The flat-rate era is ending, and the vendors are telling you so
If the half-billion-dollar story feels too far away to matter, look at what is happening to the tools on your own desk. The flat-rate subscription, the model that trained all of us to treat software cost as a fixed line item, is being dismantled in plain sight.
GitHub Copilot moved its plans to usage-based billing in 2026, replacing fixed request units with credits tied to token consumption. GitHub’s own product leadership was blunt about why: Copilot stopped being an in-editor autocomplete and became an agentic platform that runs long, multi-step sessions across entire repos, and per-seat pricing cannot absorb that. Microsoft 365 Copilot is following with pay-as-you-go billing. The developer reaction was immediate, with many arguing they will get less for the same money, since base prices hold while token-heavy work such as chat, agentic coding, and code review gets more cost-sensitive.
Then there is Anthropic, which is worth dwelling on, because it is the clearest version of the pattern. Anthropic shifted Claude Enterprise away from a flat fee of up to roughly $200 per user per month that included a bundle of tokens, and toward a usage-based model: a smaller seat fee around $20 per user, with metered compute charged on top (as reported by The Information). On the subscription side, programmatic and agent usage, the Agent SDK, scripted command-line calls, Claude Code running in CI pipelines, is being split off from the interactive chat pool and onto a separate monthly credit. That credit is capped, sized roughly $20 for Pro, $100 for Max 5x, and $200 for Max 20x, and it is metered at full API list rates with no rollover. When the credit runs out, the automated work simply stops unless you have opted into overflow billing.
Read that mechanic again, because it is the shape of where everything is heading. You get a capped allowance, and past the cap, you are on consumption-based billing at full rates. Anthropic’s own guidance even points teams running shared production automation toward pay-as-you-go API billing rather than subscription credentials. The structural reason is honest and unsurprising: agents consume compute at a rate flat-rate subscriptions were never designed to sustain, and demand has been growing faster than supply.
The takeaway for an engineer is not which vendor changed what on which date. It is that the era where you could ignore consumption is over, at every layer, from the IDE assistant to the enterprise platform to the API.
The price card can hold steady while your cost climbs
There is a motif worth naming once and reusing. The headline price can stay flat while your actual cost rises. Copilot’s base prices did not move, but token-heavy work got more expensive. The same thing happens at the model layer, where a new tokenizer can generate materially more tokens for the same input text, so your spend rises even though the per-token rate on the rate card never changed. The meter spins faster without anyone raising the price.
Here is the rough shape of that meter across the frontier tools, so you have a feel for the order of magnitude:
Tier Rough rate (input / output, per million tokens) Flagship (Claude Opus, GPT-5.5) ~$5 / $25 to $30 Mid (Claude Sonnet, Gemini Pro) ~$2 to $3 / $12 to $15 Workhorse (Haiku, Gemini Flash-Lite, GPT Mini) ~$0.10 to $1 / $0.40 to $5
Two structural facts hide in that table, and they are where the discipline lives.
First, output costs roughly five times what input does. The expensive thing is not your prompt. It is how much the model says back. Verbose, let-it-ramble usage is where budgets bleed quietly.
Second, the workhorse models are ten to twenty-five times cheaper than the flagships, and most of your workload does not need a flagship. Defaulting every call to the most powerful model is the AI equivalent of running every job on an over-provisioned cluster because requesting the right size felt like effort.
You can put a number on it before you spend it
One of the more useful developments is that the vendors now ship estimators, which means you can model the bill before you commit to it. Microsoft publishes an official Copilot Credit Estimator where you select agent types and features and see projected monthly credit consumption, with one credit priced at a cent. The numbers it surfaces are instructive on their own. By Microsoft’s own example, a grounded agent response costs around 12 credits, but flip on reasoning and the same response can cost 112 or more, roughly nine times the price for a single toggle. Microsoft even advises adding a 10 to 20 percent buffer to any estimate, because you cannot fully predict how many calls an agent will make to finish a task.
Sit with the reasoning multiplier, because it generalizes. Across providers, “think harder” is a spend decision. A single high-effort call on a long prompt can burn tens of thousands of reasoning tokens before you get one line of answer. Reasoning is a feature, not a default. Turn it on where it earns its keep and leave it off where it does not.
Do not throw money at the fire
This brings me to the mindset I actually want you to take from this section.
I sat in with a team debugging a reporting slowdown, and the tempting fix was on the table: throw more compute at it. They declined. They fixed the inefficient logic instead. That is exactly the instinct token spend demands. Do not brute-force inefficiency with more resources. Find the inefficiency and remove it. Another team I work with is bumping against hard memory ceilings and cannot simply allocate their way out, and that constraint is part of what is pushing them toward a Rust migration. Same lesson from the other direction: you get good when you are forced to optimize under a ceiling you cannot raise.
The concrete levers map almost one-to-one onto disciplines you already practice:
Prompt caching cuts repeated-input cost by up to about 90 percent. It is not recomputing what you already have, the same logic as a materialized view or an incremental load.
Batch processing runs roughly half price for anything that does not need an answer this second. It is scheduling non-urgent jobs off-peak.
Model routing sends the easy 80 percent to a cheap model and reserves the flagship for what genuinely needs it. It is right-sizing compute.
Concise prompting directly cuts the expensive side of the bill. It is the difference between
SELECT *and selecting the columns you actually need.Reasoning effort, as above, is a spend decision rather than a default setting.
None of this is exotic. It is the cost-conscious engineering you would apply to any metered resource. AI is just the newest line item that bills like one, and right now it is one of the least-governed line items in most engineering budgets. Being early to that discipline is a real edge.
The exercise I run with teams
Here is a thought experiment I have started giving the people I work with, and it does more to build cost intuition than any dashboard.
I ask them one question: if you were told you could only use one third of the tokens you currently use, what would you change about how you work?
The first reaction is usually mild panic, which is the point. Then the real answers come, and they are almost always good engineering. People say they would stop dumping entire repositories into context and start being deliberate about what the model actually needs to see. They would cache the system prompt and the reference material instead of resending it on every call. They would draft and iterate on a cheap model and only escalate to the flagship for the final, hard step. They would turn reasoning off for the routine work. They would batch the overnight jobs. They would write tighter prompts and ask for tighter answers.
Notice what just happened. Every one of those answers is something they could do today, at full budget, and the only reason they were not doing it is that nobody made them think about the meter. The constraint did not make them worse engineers. It made them deliberate ones. That is the entire game. The cap is hypothetical, but the waste it exposes is not.
If you lead a team, this is a better forcing function than a spending alert, because it changes behavior before the bill arrives instead of after. And if you are an individual contributor, run it on yourself. You will find a third of your spend you did not need.
3. The ethics layer
Cost is the part people are starting to talk about. Authorship is the part they are still avoiding, and it is the one that will quietly make or break careers.
When AI multiplies your output, it also blurs the line between what you did and what the tool did. The dishonest move, and it is everywhere, is to let that blur work in your favor. Ship the AI’s output, take the credit, hope nobody asks how the sausage was made.
The advice I give every coaching student is the opposite, and it has two halves that have to go together.
First, understand the foundations before you reach for the accelerant. You need a real grasp of what AI is and what it is not, because the multiplier only works for someone who can judge the output. Use AI to speed up delivery, absolutely, but speeding up delivery of work you could not evaluate is just shipping risk faster.
Second, be brutally honest about the tool’s role. In your README, in your write-up, in how you talk about the project, separate three things explicitly:
This is what I used AI to do.
This is what I had to make decisions on.
This is how it sped up my time to market.
That is not a confession. It is a credential. Step back and think about what a hiring manager actually wants to see. Using tools to work more efficiently has always been the job. That part is not new and not interesting. What they are really screening for is whether you can do that and bring enough foundation and experience to think critically about the output: to adjust it, to make logical calls, to recognize when the model has handed you an anti-pattern and push back toward the right one.
You cannot demonstrate that judgment by hiding the AI. You demonstrate it by showing exactly where you applied it and where you overrode it.
This connects to something I keep coming back to with the people I mentor. Show your work. The most valuable thing you can document is not the clean, happy-path result. It is the actual problem-solving path, including the wrong turns and the decisions. A tutorial that only shows the version that worked teaches almost nothing. A write-up that shows how you got there, where AI helped, and where your own judgment redirected it proves the one thing an employer cannot get from a polished repo alone: that there is an engineer in there doing the thinking.
The ethical use of AI was never about hiding it. It is about showing the reasoning AI helped you reach, and owning which parts of that reasoning were yours.
The throughline
AI multiplies output. Left unchecked, it multiplies cost and obscures authorship just as efficiently.
The engineers who win this era treat tokens like a compute budget, because that is exactly what they are, and treat attribution like a professional obligation, because that is exactly what it is. The multiplier is real. So is the meter. And the person standing between the two, deciding what is worth spending and honestly accounting for what got built, is still you.
I coach engineers on exactly this kind of judgment, the foundations underneath the tools and how to demonstrate them, through The Gambill Data Coaching Program. A companion piece is coming for the leadership and executive side of this question, how to govern AI spend and authorship at the team and org level, in the Data With Direction blog for leaders on the Gambill Data website. If that is your seat, watch for it.