Who's Driving?

I rode in a Tesla the other day while the driver showed me what its self-driving could do. My first thought was that I could take a nap on the way home. My second thought came a few seconds later. If it hit someone, whose fault would that be?

Ask anyone what makes them nervous about self-driving cars and you'll hear the same question within a minute.

Most people take for granted that the car can stay in its lane on a clear day. What worries them is the half second when it can't, and who answers for it afterward. The person in the driver's seat who wasn't driving? The company that wrote the software? The engineer who approved the release?

Carmakers actually grade this on a scale from 0 to 5. At 0 you do all the driving. At 5 the car doesn't need a steering wheel. The middle is where it gets interesting. At Level 2 the car steers and brakes, but you're supposed to watch every second. At Level 3 the car drives and calls you back when it gets confused. The handoff is the dangerous part. Someone who has been watching the scenery for twenty minutes doesn't become an alert driver the moment a chime goes off.

Lisanne Bainbridge saw this coming in 1983. In a short paper called "Ironies of Automation," she pointed out that the more you automate, the more you depend on the human who's left. And the less practice that human gets at the very thing you'll suddenly need them to do. Her examples came from industrial control rooms. Pull request queues didn't exist yet, but the pattern fits.

Look at where a lot of engineering teams are right now. Code arrives faster than anyone planned for. Claude, Codex and Cursor write it, often test it, and then a person is asked to approve it. That person is usually one of your best engineers, and they're looking at their fortieth PR of the week. They know they should read it carefully. They also know there are thirty-nine more to review.

So what happens? I think we all know. The approval becomes a formality. The reviewer turns into the person in the driver's seat, watching the scenery. The industry calls this Human in the Loop. Most days it's closer to Human on the Side.

And when it breaks, whose fault is it? The AI didn't sign anything. The engineer approved it in four minutes. The CTO is the one explaining the outage. We put out a guide on this called You Didn't Write That Code. You Still Own It. The title says it.

So where should the human actually be? What does Human in the Loop mean?

Jason Arbon and I have been trying to answer that for our own work first. We ended up with a grid. Down the side is the kind of quality work: quick checks, high-volume work, judgments, and investigation. Across the top is who leads, moving from AI to the expert:

• Autonomous. A link that goes nowhere. A required field that accepts an empty value. An API response that breaks its schema. The rules are written down, so let AI run these checks and stop spending expert time on them.
• Light guidance. Someone sets the expectations and AI does the work. Regression suites with a defined setup. Deciding which of fifty AI-flagged issues actually matter.
• Deep guidance. AI still does the work, but an expert steers it toward bugs it would never find alone, or tunes a test agent to a codebase over weeks. This is the column teams tend to skip.
• Expert-driven. Deciding what correct even means. The unwritten business exception everyone on the team knows and nobody documented. The fifteen seconds when a tester looks at a screen and says this feels wrong. Release sign-off.

The graphic shows one square from each column. Follow them from the top left corner to the bottom right, and you can watch the person go from passenger to driver.

When we tried to put rough numbers on it, our working split came out to about 79 percent AI on its own, 13 percent shared, and 8 percent that needs an expert. Jason was careful to call that a working number, and it will move as the tools get better. But look at what it says. Most of the testing your people do by hand today shouldn't be done by hand. A small slice can't be done any other way. And that small slice is the part you'll answer for when something breaks.

In driving terms, most teams I see run in one of two modes. Either a human reviews everything, which doesn't survive the volume of AI-written code, or AI handles it and someone glances at the result, which is the car calling for help while the driver dozes. The useful work happens in the two middle columns, and it needs someone who knows the product and the tools well enough to steer.

Bainbridge's irony shows up here too. If your testers spend their days in the first column, clicking through checks a machine could run, will they have the eye ready when the fourth column needs it?

That's the work we do at IcebergQA. We add AI testing capacity with QA experts who know how to run it, steer it, and decide when a person needs to step in. You can turn it on for a release and turn it off afterward.

When your AI flags something in tomorrow’s release, who looks at it? Someone in the loop who knows within seconds whether it matters, or someone on the side, clicking approve on PR number forty?