Rise of the Citizen Coder: The Other Side of the Agentic Revolution
Part II — Death of a Craftsman
Gartner estimates that by 2026, citizen developers at large enterprises will outnumber professional software developers four to one. Four to one. Not because companies suddenly stopped needing engineers; because the backlog of things that needed building was always bigger than the engineering team could handle, and now people are finding ways to build without them.
In Part 1, I wrote about what we stand to lose as agentic coding becomes the norm. The erosion of craft. The abstraction debt. The knowledge gap that compounds over generations. I meant every word of it.
The software industry I'm part of and built a career in also failed a lot of people. If we're going to critique the new wave of "vibe coding," we have to be equally critical of the industry that created the barriers in the first place. This is the other side.
The Backlog
The same scene plays out in every company, every week.
A product manager walks into a planning meeting with a simple request: an internal tool to track customer feedback. Nothing fancy. A form, a database, some basic reporting. Maybe two weeks of work for someone who knows what they're doing.
Engineering estimates six months. Not because the tool is complex—it isn't. But the backlog is full. Three major features sit ahead of it, two critical bugs need fixing, and a migration has been pushed back twice. The PM's little tool isn't a priority. It goes to the bottom of the list, where it will sit until someone forgets why they wanted it in the first place.
The PM is frustrated. The engineers are frustrated too—they're not trying to be difficult; they're just drowning. Everyone agrees the tool would be useful. Nobody has bandwidth to build it.
This is the bottleneck that agentic coding is breaking open.
I've been on both sides of this conversation. I've been the engineer explaining why we can't get to something for months; I've been the person with a simple idea watching it die in backlog purgatory. The system we built—the one that requires specialized skills to create even basic software—created a chokepoint that serves nobody well.
The average enterprise IT backlog runs three to twelve months. That's three to twelve months where someone with a real problem waits for someone with the right skills to have time for them. Sometimes the wait is justified; the work is genuinely complex. But often it's not. Often it's just that we created a system where building anything requires specialized skills, and the people with those skills don't have bandwidth for everyone's problems.
The Gatekeeping Problem
I don't think most programmers set out to create barriers. It just happened. The skills take years to acquire. The tools resist simplification. The failure modes can take down production systems. All of that is true.
But the effect—intended or not—was a bottleneck that locked people out.
Think about what "learn to code" meant as advice. It meant: spend months or years acquiring foundational skills before you can build anything useful. Take courses. Do tutorials. Learn syntax, then frameworks, then deployment, then debugging. By the time you're competent enough to build that simple feedback tracking tool, you've invested hundreds of hours. Maybe thousands.
That's fine if you want to be a programmer. It's absurd if you're a marketing director who just needs a reporting dashboard; a founder with deep domain expertise who wants to test an idea before hiring engineers; an operations manager who could automate half their job if they could just write a little code.
"Learn to code" was never realistic advice for these people. They have jobs. They have expertise in their own domains. They don't have time for a CS curriculum, and they shouldn't need one.
The craftsman in me wants to say: but the complexity is real. You can't just skip the fundamentals. The shortcuts will catch up with you.
And that's true. But it's also true that we built a system where a simple tool requires a complex skill set, where domain experts can't build domain-specific solutions, where ideas die because they're stuck behind people who don't have time to implement them.
That was a failure too. We just didn't call it one because it was our failure, and we were on the winning side of it.
The Other Tribe
In Part 1, I talked about the two tribes of programmers: those who love the craft of coding, and those who see code as transportation to building things. I was clear about which tribe I belong to.
I undersold the other tribe's position. Their argument deserves a fairer hearing.
A comment stuck with me—the inverse of the one that opened Part 1:
"I'm happy for all coding to be AI. I prefer delivery over the craft of writing software."
My first reaction was dismissal. The attitude that leads to vibe coding disasters, right? People who don't care about quality; who just want to ship fast and let someone else deal with the consequences.
That's uncharitable. The real picture is different.
These are people who learned programming because it was the only way to build software. They didn't fall in love with syntax; they fell in love with products. The code was never the point—the code was the obstacle between their idea and a working thing. They put in the years because they had to, not because they wanted to.
For them, AI coding tools aren't a shortcut around craft; they're the removal of an artificial barrier. The barrier was always the implementation, not the thinking. They know what they want to build. They understand the problem domain. They have taste about what makes a good product. The only thing they lacked was the ability to translate that into syntax a computer could execute.
Now they have that. And they're asking: why should I care about the elegance of the implementation if the product works?
I don't fully agree with this position. I think there are real risks they're underweighting. But I can't pretend it's incoherent. It's a legitimate philosophy, not just laziness dressed up as productivity.
