June 2026 · 7 min read
Agents Don't Replace Your Data Engineers. They Deskill Them.
Agents won't replace your data engineers. They'll deskill them, quietly eroding the one skill you need most: catching the confident, silent, wrong answer the automation hands back. Aviation already ran this experiment, and paid for the lesson.
Every quarter a new vendor deck lands with the same conclusion. Agents will write your pipelines. Agents will wire your connectors, generate your transformations, author your tests. So you won’t need data engineers anymore.
That’s the wrong failure mode to worry about.
Agents are not going to replace your data engineers. They are going to deskill them. The danger isn’t that the machine does the job. It’s that the machine does it well enough, for long enough, that the people who were supposed to catch its mistakes forget how. Replacement is loud and you’d see it coming. Deskilling is silent, and by the time it bites, the skill is already gone.
Aviation already named this
In 1997 an American Airlines training captain named Warren Vanderburgh recorded a lecture called “Children of the Magenta Line.” Glass cockpits and flight management computers had arrived. Pilots had learned to program the magenta course line on the display and let the automation fly. The lecture wasn’t anti-automation. It was anti-passivity. Vanderburgh’s point was that the cockpit had quietly shifted from flying the airplane to managing a system that flies the airplane, and that pilots were losing the judgment of when to drop down a level and take the controls back. American Airlines’ own review of its incidents put automation mismanagement behind 68% of them.
The accident that proves it
This is not an abstract worry. On June 1, 2009, Air France 447 was cruising over the Atlantic when its airspeed sensors iced over and fed the computers bad data. The autopilot did the correct thing and handed control back to the humans. The crew, who had flown almost their entire careers on automation, did not recognize that they had a recoverable stall on their hands. They held the nose up for four minutes until the airplane hit the ocean. 228 people died.
The machine didn’t fail them. It worked exactly as designed, right up to the moment it gave them a problem they had lost the proficiency to solve. The lecture warning about this had been in circulation for nine years.
Now run it on your data stack
The agent builds the pipeline, runs it, handles the routine failures it has seen a thousand times. It does this well, which is the point and also the trap. Then one day it hits something off the edge of what it knows. A model won’t run because a join is dropping rows it shouldn’t. The agent, told to make the thing green, resolves it the way a confident system does. It filters out the unmatched rows and the pipeline goes through.
Every test passes, because every row that’s left is valid. The totals look plausible. They are also wrong, understated by exactly the rows that quietly fell out. No alert fires. Freshness is fine. Schema is fine. Volume is within range. The number is just wrong, in a way you can only catch if you know what the number is supposed to mean and why those rows should have matched.
That is the moment that needs a human with current, hands-on proficiency. Not because humans spot anomalies better than machines. They don’t, and that gap is closing fast. The durable edge is narrower and harder to automate: reasoning about a failure no one has seen before, deciding whether the plausible answer is the correct one, and being accountable for the call. The agent has no stake in whether finance makes a bad decision on a wrong number. The engineer does. But that engineer can only do the job if they have kept their hands deep enough in the machine to know where to look. And the agentic workflow, left alone, is busy taking that away.
“Every abstraction layer scared us like this”
The obvious pushback. Every layer of abstraction triggered the same panic and we were fine. If compilers write the assembly, who debugs the assembly. If nobody manages memory by hand, who fixes the leaks. Mostly the profession adapted and moved on. True.
But two things make this one different. A compiler is deterministic. It produces the same output the same way every time, and when it’s solid you can stop thinking about the layer beneath it, because that layer does not surprise you. An agent is probabilistic. It can be confidently, fluently wrong, and it fails in novel ways that don’t repeat. You cannot stop thinking about the layer beneath it, because that layer will occasionally lie to you with total confidence.
The second thing: aviation is proof that this worry is not always unfounded. Sometimes the skill atrophies faster than the automation matures to cover for it, and the gap in between is where people get hurt. The history is not a clean record of “it always works out.” Sometimes it works out only after a reckoning and a deliberate fix.
What aviation actually did about it
The move is not to ban the agents or hand-fly every pipeline out of nostalgia. Aviation didn’t do that either. It didn’t rip out the autopilot. It calibrated. It decided which skills were non-negotiable given the cost of losing them, and it mandated that pilots keep those skills sharp, hand-flying on a schedule even when the automation could have done it.
Do the same with your data. Sort your pipelines by one question: what does a confident, silent, wrong answer cost here? For the pipeline feeding the board deck, the regulatory filing, the revenue number the company steers by, the answer is “too much.” That is where you keep engineers in the build, reviewing what the agent produces closely enough to catch the dropped rows, designing the tests themselves instead of letting the agent grade its own work. For the internal dashboard nobody bets the quarter on, let the agent run it unsupervised and don’t think twice.
The cost of proficiency is real. You pay it where the downside justifies it, and nowhere else.
Two roles, two ways to lose the thread
That failure needs two kinds of knowledge, and on a healthy team they live in two different people.
The data platform engineer owns the machine. The orchestration, the warehouse, the lineage and freshness checks and the runbook that tell you where a job actually broke. This is the person who knows where to look when the agent hands back a problem, because they built the substrate the agent runs on and have kept it alive. Let the agent operate that substrate unattended for a year and the mental map goes stale. The hands come off the machine, and the instinct for where to look leaves with them.
The data product engineer owns the meaning. The semantic model, the entity definitions, what the number is supposed to be, why those rows should have matched. This is the person who can tell a plausible total from a correct one, because they know the business the data describes. Let the agent author the transformations and grade its own tests, and the product engineer slides from owning the meaning to approving the agent’s account of it. That drift is the more dangerous one, because nothing on the dashboard shows it. The tests are green either way.
I have argued before that these roles get more valuable as the systems get smarter, not less, because the judgment layer is the last thing to automate. This is the mechanism underneath that claim. The agent absorbs the building. What is left for the human is the judgment: is this the right answer, and where do I look when it is not. Deskilling is what happens when you let the agent absorb that part too, one green checkmark at a time.
Don’t get trained to stop flying
The job title will drift. “Data engineer” becomes “data reliability” or “analytics platform owner” or whatever the next vendor deck decides. The work underneath is the one aviation already mapped. Know the machine well enough to take the controls when it hands them back. Keep that skill alive deliberately, because it does not maintain itself, and the automation will be happy to let it fade.
The pilots who followed the magenta line into the ground were not bad pilots. They were good ones who had been trained, slowly and invisibly, to stop flying. Don’t let your data team be trained the same way.