The Human in the Loop Isn't Overhead

An Experienced Developer's Case for Augmentation Over Automation

The study making rounds says experienced developers using AI tools take 19% longer on tasks. The kicker: those same developers believed AI had made them faster.

I want to talk about why that finding might be simultaneously true and completely misleading. And why the whole conversation around AI and development is asking the wrong questions anyway.

The Conversation We Should Be Having

When I talk about AI in development, I mean LLMs. Generative models. And I've become evangelical about a specific framing: augmentation, not automation.

The push toward fully autonomous AI systems strikes me as a recipe for disaster. Here's the math that keeps me up at night: a 0.0001% error rate sounds vanishingly small in human terms. But if you have an AI making a billion decisions, that tiny percentage means a lot of bad decisions at scale.

The standard pushback: humans make bad decisions too. Yes. But humans can have consequences for their bad decisions. There's accountability. There's a mechanism for fault. With AI, we haven't figured that out yet. Maybe the creator bears responsibility. I know how this plays out: actuarial tables, insurance policies, liability frameworks. But then somebody makes a mistake in the training or the coding, and that 0.0001% chance becomes 0.01%. Still tiny by human intuition. Enormous when scaled to humanity.

So that's why I'm writing and talking about this. We need to change the narrative. Humans augmented by this technology. Not replaced by it.

About That 19% Slower Study

I'd love to see the methodology.

I can see how those numbers get generated. But here's why it might not apply to how I work: I'm not prompting the AI and sitting there watching it turn. I prompt, let it work, and go do something else. When I come back, maybe the overall elapsed time was "longer." But the attention cost? Always less. I didn't have to think through all the details. I had to validate that the details the generative model came up with solve the problem.

If your pattern is: prompt the AI, sit there waiting for it to think, let it generate something, correct it, let it think some more, correct it again, and that's the only thing you're doing? An experienced developer working in a domain they know well is almost always going to be slower with that workflow.

But that's not the only pattern.

We've been working on a project with a legacy system originally written in Spanish. We're English-speaking developers, and mining out all the nuance is difficult. We use AI to direct us toward the right thing to look at, to guide us to different parts of the application when we need to make changes. I don't see how it could possibly be faster doing that by hand.

Now compare that to: users want the button to change colors. Users want a modal confirmation. Users want a back button for undo. These are well-defined problems that an experienced developer mows through. The AI is going to take longer because it has to rebuild context every single time. Eternal sunshine of the spotless mind. Every engagement, it's starting fresh.

Meanwhile, the experienced developer who's been in this codebase for two years already knows where to go. If not the exact line, then the right file. If not the right file, then the right directory. The process of figuring out where to go is going to be way slower for the generative model.

So yeah. I'd be interested in knowing the methodology of that study.

Missing the Forest for the Trees

The generative models do this thing constantly: they get sucked into tactical thinking and miss the strategic picture.

I'll be reviewing code where the model analyzed a feature change and wrote a convoluted solution. Five if-blocks for one case. And I'm looking at it thinking: with this feature change, couldn't we eliminate this whole section of code? We're doing it differently now. Can we get rid of that?

And the model, when prompted, will say: you know what, you're right.

But it didn't see it on its own. A junior developer following the model's lead would see five if-blocks and implement five if-blocks. The experience gives you the ability to think strategically, to move between levels of abstraction, to understand when something isn't at the right level.

What do I feel when I catch these things? Relief, mostly. Relief that I didn't push bad code. Relief that I'm still paying attention enough to catch issues before production. Maybe a little satisfaction. And yes, tongue-in-cheek: relief that it's not coming for my job yet.

I'm not reviewing every line by thinking through all permutations of every possible input. I'm relying on tests, on intuition, on my understanding of how the system works. So when I catch something the model missed, it feels like validation that the process is working.

What the Workflow Looks Like

When I say using Opus 4 feels like having a team of 10 junior developers for $200 a month, here's what that means in practice:

I read the story. I think through the questions that need answering. I answer them. I give that to the model and let it write the code. Then I review it.

I can do that on five or six problems simultaneously. While the model's working on one, I move to the next.

Research works the same way. I need to understand how an API works, how other people are solving a problem, what the documentation says. Hand that off to the generative model instead of a junior developer. Once I have the research, I architect a solution. Then I hand off the coding-by-numbers, the same way I would to a junior developer. Take the output, review it.

I'll even have the model review its own output. Clear the context, point it at the code it wrote, and it'll tell you what it did wrong. Eternal sunshine of the spotless mind works both ways. That's no substitute for my judgment, but it gets the low-hanging fruit.

Prompt it with the right things. Let it turn. That's the workflow.

The Hard Conversation About Junior Developers

This is going to hurt, and I'm not going to pretend otherwise.

Junior developers are going to have to accept that salaries will drop significantly. They can't add value at the same level they used to. The position is more like a pipeline for creating mid and senior level talent. Companies will invest in that pipeline if juniors are willing to take less.

Why do we still have interns? Because interns don't get paid much, or anything at all. Zero is not a living wage either. Maybe the path forward is 50 to 70% of what junior developers made relative to seniors five years ago. That's still better than zero. If someone wants to get into the field, that's what it's going to take.

Me, by myself, with a generative model? That's effectively me and a team of 10 junior developers for a $200 monthly subscription. The economics have fundamentally shifted.

If you're graduating from a coding bootcamp or with your CS degree, I'm sorry you've come into this situation. Here's what it is.

If you have another passion and got into this for the money, maybe it's time to reevaluate. A lot of people entered software engineering because it was lucrative. That created a boom. Now we're seeing the compound effect: big companies laying off tons of engineers while generative models make small teams of senior developers more productive than ever.

Here's my hot take: it's better to have a smart senior developer getting stuff done with a generative model than 10 overpaid junior and mid-level developers. It's not about years of experience. It's about how smart you are and how much effort and attention you're willing to put in.

Years help. There's no way around that. But software engineering is one of those jobs where raw problem-solving ability is always a major component. There's never a time where you've solved a problem a hundred times and you're done, because on the 101st time there's new technology, new considerations, new constraints, new regulatory environments.

This isn't like oil and gas, where regulations were predominantly written 50 to 75 years ago. In software, three years from now the new hotness on frameworks and patterns will be old news. The tried and true patterns persist, and a lot of the new hotness is recapitulation with a new face. But you still have to learn it.

There's never going to be a time where you make a lot of money without thinking hard, without being smart, without constantly learning and evolving your skill set. The engineers of the last 20 years who got a skill and applied it for 20 years with low cognitive overhead? That's not a pathway forward anymore.

Why Augmentation, Not Automation

The epiphany came gradually, then suddenly.

I'd been working with AI for a while. Co-pilot built into VS Code, playing with Cursor. And then it crystallized: the generative model has an epistemological problem. It can't recognize when it's wrong. It always thinks it's right.

Here's what I mean. If someone asks me the capital of Wyoming and I say Baltimore, I know that's wrong. I know the capital is Cheyenne. I can recognize Baltimore as an incorrect answer.

The LLM can't do this. If you give it incorrect information as a prompt, sure, it can identify that. But it can never recognize in the moment that it doesn't know something. Everything is embedded in its training, in its weights. It has complete confidence in everything it says.

That's not a bug. That's the nature of the technology. That's how generative models work.

Human beings can recognize when their knowledge base is shaky. That recognition is the clue that we need to do research, that we need to be cautious, that we need to figure things out. The generative model doesn't have that clue. It can't signal uncertainty about its own outputs.

And that's why we can't automate with it. That's why augmentation is the only responsible path. The human in the loop isn't overhead. The human in the loop is the only mechanism we have for catching the inevitable failures.

Being Skeptical Costs Almost Nothing

Some people worry about being too skeptical of AI outputs. I don't understand this concern.

It costs almost nothing to have the generative model check its own work. To ask it to point to sources. To verify claims independently. The upside to being skeptical is huge. The downside is that you're occasionally slower.

That math is obvious.

I never had a problem reading documentation. That hasn't changed. When code doesn't feel right, I dig in. When research seems off, I verify. The experience of knowing what code to write when, how clever to get, when to abstract and when to get something done: that requires judgment that comes from years of doing this. It's almost an art rather than a science, especially when you're dealing with business constraints.

You're not always writing the "best possible code" in a vacuum. You have time and money constraints. You have to think about who's going to maintain this. Will they understand it?

That kind of judgment doesn't come from the model. It comes from you.

The Path Forward

If you're an experienced developer wondering how to engage with AI-augmented workflows, here's what I've learned:

Prompt, then move on. Don't sit and watch. Run parallel workstreams.

Use the model for research, for exploration, for the first draft of code. Use your experience for architecture, for strategic decisions, for catching what the model misses.

Stay skeptical. Verify. Have the model review its own work with a fresh context.

And remember: the technology can't recognize when it's wrong. That's your job. That's why you're still essential.

The conversation around AI and development keeps framing this as replacement or resistance. Those aren't the only options. There's a third path: working with these tools in a way that amplifies human judgment rather than replacing it.

That's the path I'm on. It's where experienced developers have the most to offer, and where the technology works.