June 21, 2026
No One Gets to Be Wrong Anymore
This post is part of my Medium blog.
Here is what I have started to notice.
When I talk to developers around my age — early fifties, twenty-plus years of production work behind them, systems that have failed on them in ways that permanently changed how they think — the conversation about multi-agent pipelines gets fast and enthusiastic. Connecting agents for code generation, automated builds, continuous deployment: there is a shared vocabulary, a shorthand that develops quickly. There is also a shared excitement that I recognize immediately.
When I talk to a developer who just graduated from college, something different happens. I describe what these tools can do, and the first question is usually: "But do you trust it?"
Not how does it work. Not what are the failure modes. Just that question, with a skepticism that sounds almost protective.
I was talking recently to someone I used to work with — someone who pays close attention to how their teams actually function — and they mentioned that junior developers were avoiding the AI coding tools more than the senior ones were. Not struggling with them. Avoiding them. This is July 2026, and we are apparently watching a cohort of developers decide, consciously or not, that generative AI is not for them.
The narrative that swept through the industry was that less experienced developers would adapt naturally while the senior hands resisted. They're earlier in their careers, they're comfortable with technology, they'll just get it. The senior engineers will cling to their grep and their grumpiness. That's the story that circulated, and it was wrong.
It is backward.
The people I know who are most comfortable handing off entire subsystems to agents, most fluent in navigating where the tools can be trusted and where they require supervision — they're the people who spent years getting beaten up by systems. They have the scar tissue.
The developers who are hesitating, who keep asking whether you trust it — they are, frequently, the ones who haven't yet taken that beating.
To understand why, you have to go back to what a bug actually teaches you.
You're debugging. Something breaks, you paste the error into Claude, and half a minute later you get a fix that seems plausible enough to try. You apply it. It works. You move on.
That is productive. I mean that. The bug is gone, you didn't burn half a day, and nobody is going to give you a medal for suffering through a stack trace unaided.
But you may have fixed the issue while skipping the part that would have taught you how the system actually works. Before these tools existed, debugging was frequently how you discovered that your assumptions about a technology were wrong. What we called needless trial was, in the absence of anything better, how people learned.
Debugging was never just error correction. A compiler does error correction. A decent type system catches whole categories of foolishness before you embarrass yourself in production.
Debugging is how you build a mental model of a system by discovering, usually the hard way, where your model is wrong.
Maybe your assumption about state was wrong. Maybe the order of operations wasn't what you thought. Maybe the data was dirtier than the happy-path tests. Maybe some library had a sharp edge hidden behind cheerful documentation and you had to clone the repo and read the code to find it. Whatever it was, the failure was the moment the system stopped cooperating and forced you to understand the detail.
For junior developers, that opportunity is disappearing.
If you paste the error in too quickly, get back a repair, and move on without understanding why the code broke or why the fix worked — you have output. What you may not have is understanding. And over time that gap becomes expensive.
The developer who has gone through the failure loop enough times builds pattern recognition that looks like intuition from the outside. It isn't magic. It is a scar tissue library. At 2 a.m., during an incident, they can form a decent hypothesis quickly not because they have seen this exact failure before, but because they have spent years watching systems break in adjacent ways.
That's the thing about the senior developers who are excited about agent pipelines. They are not outsourcing their judgment. They already built it. When they hand a task to an agent, they can evaluate the output because they know what failure looks like from the inside.
They're not handing over the part of the job that made them competent. They completed that part. Now they're automating execution.
To be clear: I don't trust these systems unconditionally either. I've watched agents make genuinely bad decisions — code that looked plausible and failed in production, pipelines that drifted somewhere wrong without any obvious signal, architectural suggestions that a less experienced eye would have accepted without question. These tools get things wrong. Sometimes confidently, cheerfully wrong.
The difference is not that I trust the output more. The difference is that I have enough failure experience to catch it when the output is bad. When an agent produces something heading somewhere wrong, I can usually feel the shape of it. Not because I've seen that exact mistake, but because I've spent enough years being wrong that wrong has a texture I recognize.
That's what lets you orchestrate rather than just run.
The concern here is not that junior developers are lazy or deficient. The real issue is simpler: if a tool consistently removes the experience of wrestling with why something failed, it may also remove the conditions under which the judgment to evaluate that tool ever develops.
Here is the part nobody is being direct about: what we're going to be short of, going forward, is failure. Not the pointless kind. The kind that teaches. The next generation of developers will ship more, faster, with less friction, and accumulate far fewer of the formative incidents that built the mental models their predecessors use to supervise these tools. That's the gap that's opening. Not intelligence, not work ethic. Just accumulated contact with reality from spending years being wrong without a shortcut available.
The question is not whether you trust the tool.
The question is whether you've done enough work yet to trust your own judgment about when the tool is wrong.
In Redundant, the first book in The Condition Set trilogy, Rob Coleman runs the FinOps review that names the waste nobody wants to hear about. The numbers don't change. The question is who they get used against.