In 1983 Lisanne Bainbridge wrote a short paper called Ironies of Automation. The irony she cared most about was that the more capable the automation, the less practice the human operator gets, and the more important it becomes that the human can take over when the automation fails. A job that’s mostly monitoring, she wrote, is “very boring but very responsible”.

She was writing about chemical plants and cockpits. Annie Vella has spent this year arguing that she was also writing about us.

Vella’s post on supervisory engineering work is worth reading in full. It’s the clearest framing I’ve read of what has changed in software engineering since agents started writing code. Her research found what she calls a creation-to-verification shift, with engineers spending less time producing code and more time testing and reviewing it. She boils the new job down to three verbs: directing the agent, evaluating what it produced, and correcting it when it’s wrong.

I’ve been reading that post with a specific question in mind: what changes when the thing being supervised isn’t an application but a pipeline, and when the supervisor is also the manager who signs off on it?


The shift happened faster than the job descriptions


An engineer picks up a ticket: add a new source to the ingestion layer, model it into a dimension, wire up the tests. Eighteen months ago that was two or three days of writing SQL and dbt YAML and arguing with the orchestrator. Now a reasonable chunk of it is a prompt and a pattern pulled from the pattern bank, and an agent turns that into a pull request that is, on first read, pretty good.

I recently sat through what happens when nobody gets past the first read. Someone was given a task, and the instructions looked like they’d been pasted into an AI prompt word for word. The output was never tested against the ask, and it wasn’t what we expected.

That led to several (yes, several) follow-up meetings to agree on what we actually wanted, how it worked, and how we’d know it was working. Most of it came down to testing the output. The frustrating part is that we did that testing in review meetings, because none of it was baked into the work itself.

I’m seeing this more and more with AI. Anyone can write a prompt. The job is checking that the output actually behaves correctly, and if you’re not doing that, you’re pushing the burden onto everyone else to do it for you.

Whether people have noticed or not, the engineer’s day has moved from the left of the feedback loop to the right of it. Less time with a blank editor, more time with a diff. And the diff is longer than anything they’d have written themselves in the same time, which means the review is larger than any review they’d have done before. Call it the review burden.

Vella cites a 1995 study by Endsley and Kiris where workload didn’t appear to drop even at full automation, possibly because monitoring load went up (“sound familiar?” she asks). And she’s blunt that “what an AI agent says it did and what it actually did may not be the same thing.” You can’t skip the check.

I wrote in July that data engineers should just do code reviews, because the evidence says reading code finds roughly twice as many defects per hour as testing does. I stand by it. But that post assumed the author was a person who could be asked why they’d done something. The author is now, often, a process that will confidently answer any question you ask it, including the ones where it’s wrong.


Pipelines fail differently, and that changes the supervision


Vella’s framework comes from human factors research: Sheridan’s supervisory control, Endsley’s situation awareness, the aviation studies that moved the blame from “pilot error” to “design error”. It transfers to data work well, but there’s one property of pipelines that makes the supervision harder than it is for application code.

A pipeline’s output is data, and data doesn’t crash.

If an agent writes a web handler with a bug, something usually goes red, like a failing test or a 500 in production. If an agent writes a dbt model with a subtly wrong join, typically nothing goes red. The model builds. The tests pass, because the tests were written by the same agent against the same misunderstanding. The row count looks plausible. The number then lands in a dashboard, and the first signal that anything is wrong is an analyst three weeks later asking why a metric doubled.

That’s the same failure as the drift I described in The Broken Window. Plausible output is the enemy. And an agent is a machine for producing plausible output.

So when Vella writes about situation awareness, about the operator perceiving what changed but understanding its meaning less well, I think about a reviewer looking at forty lines of generated SQL that reads cleanly and still can’t tell you whether the fan-out on that left join is intended. Reading is more passive than writing. You can approve a diff you don’t actually understand, and the pipeline will still run.

Here’s how those three verbs play out on a data team.

Directing. This is where most of the payoff is, and it’s where teams tend to under-invest. Directing an agent well on data work means giving it the grain, the keys, the known traps of the source, and the house pattern for the thing it’s building. If that context lives in people’s heads, the agent guesses, and the guess is usually generic.

The reason I built Ghost Skills was that I was tired of re-explaining the same six things about SCD2 to every agent session. The pattern bank is the same idea for humans. Directing is mostly context engineering, and context engineering is mostly writing down what your team already knows. A lot of the MCP integration work happening now can help here too (MCP is the protocol that lets an agent pull in your docs and tools directly), but only if the documentation behind it is actually maintained.

If you’re taking a data team down the AI path, get these principles written down and hardened first. They’re your primer.

Evaluating. For pipelines, evaluation can’t stop at reading the code. It has to include running the reconciliation: does the target tie out to source, do the row counts and the sums and the distinct keys match, is the overlap test on the dimension clean. I’ve started treating a reconciliation query as the mandatory second half of any agent-produced PR, and I’d rather see a short reconciliation than a long explanation. The agent can write the reconciliation too, which is fine, as long as a human reads the result and not just the code.

Linus Torvalds showed the limits of agent-written tests recently. He used Claude Code on a page-cache problem that kernel developers had been stuck on for about two and a half years. He directed the work and ran the benchmarks on his own machine, but the agent wrote the code and the tests. Four hours after the patches went out, another kernel developer found a race condition those tests had missed. Torvalds hadn’t caught it either.

Correcting. Correcting an agent is easy; you tell it what’s wrong and it fixes it. Correcting the pattern that produced the error is the manager’s job, and it means feeding the correction back into the skill, the template, the pre-mortem checklist, so the next session doesn’t make the same mistake. If you only correct the output, you’re on a treadmill. It’s the difference between fixing a pipeline and fixing the factory that makes pipelines.


The manager’s version of Bainbridge’s irony


Vella’s piece is addressed to engineers. There’s a second audience she doesn’t quite address, which is the people accountable for the engineers’ work, and that’s where Bainbridge’s irony hits hardest.

As a manager, I was already a supervisor. I didn’t write most of the code my team shipped before agents turned up either. What I had was a chain of accountability I understood: an engineer wrote it, a second engineer reviewed it, both could explain it, and if something went wrong I knew who’d learned what.

That chain now has a link in it that can’t be held accountable, doesn’t remember last week, and will produce a thorough-sounding justification for anything it did. The engineer who directed it is accountable. But as Vella asks, “what does it really mean to hold engineers accountable for code they’re less and less likely to have written, or even read?”

Here’s what’s helped on my team.

The reviewer must be able to explain the change without the agent. Not re-derive it, just explain it: what it does, what it assumes, what would break it. If they can’t, the PR isn’t ready, regardless of what the tests say. This is the situation-awareness test, and it’s the one I’d keep if I could only keep one.

A method that works for me is to draw it. Diagram the process step by step and explode out what each step is doing. Seeing the change from a different angle makes problems in the logic or the sequence much easier to spot.

Decide the automation level per kind of work, deliberately. Vella’s first recommendation, and the one I’d underline. Exploratory analysis and boilerplate ingestion: let the agent run, review the output. Dimension logic, anything touching money or compliance, migrations: agent drafts, human owns every line. We’ve written that mapping down, and it changes which PRs get a thirty-second glance and which get a sit-down.

Keep people practising. Bainbridge’s point was that the best automation needs the most-trained operators, because interventions are rare and high-stakes. For us that means the occasional piece of work done without an agent, on purpose, especially for juniors. Not as a hazing ritual. Because when the agent produces something wrong in a way nobody’s seen before, the only person who’ll catch it is one who has built the thing by hand at least once.


The tradeoff


I’m not nostalgic about this. I’m seeing teams move faster than they ever have, and the engineers I’d most want to keep have taken to directing agents with the same instincts they’d use directing a junior. More than ever, the skills that matter are leadership and testing.

But the human factors people saw this coming more than forty years ago. Supervision looks like less work and is actually different work: more responsibility, less feedback, and a skill that atrophies quietly if nobody tends it. The managers who come out of this well are going to be the ones who treat the review burden as the job rather than the overhead, and who keep deliberately rebuilding the manual skill in a team that no longer needs it on an ordinary Tuesday.

Vella says this work needs new definitions of what good looks like. Here’s a modest start for data teams. A good supervisor is someone who can tell you what a pipeline does, why it’s right, and how they’d know if it stopped being right. That was always the standard. It’s just that for a while, writing the code did most of the proving for us.