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.
The Uncomfortable Successes
Something complicates the skepticism I laid out in Part 1. Some of this is working.
Not the hype. Not the demos. The results.
Twenty-five percent of Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. These aren't weekend projects; they're funded startups that passed YC's filter—and every one of those founders, according to YC managing partner Jared Friedman, was technical enough to build the product from scratch. They chose not to. Collins Dictionary named "vibe coding" their word of the year for 2025. This isn't a fringe phenomenon anymore.
And when I talk to the people doing it—not the evangelists, the practitioners—I hear stories that are hard to dismiss:
A founder with fifteen years of logistics expertise built a supply chain MVP in two weeks that would have taken months with traditional development. Not because the AI wrote perfect code, but because she could iterate on ideas in hours instead of waiting for engineering sprints.
A business analyst tired of waiting nine months for IT built the reporting tool his team needed. It's not elegant. He'd be the first to admit he doesn't fully understand how it works under the hood. But it works, and it shipped, and his team uses it every day.
A product designer prototyped an interface that functions—not just a mockup. She could test real interactions with real users before involving engineering at all.
These aren't hypotheticals. These are people building things that wouldn't have existed otherwise—not because the ideas weren't good, but because the implementation barrier was too high.
The obvious objections surface immediately: maintenance, edge cases, security. Those are fair questions. I asked them in Part 1. But for some of these projects, the questions might not matter that much. A throwaway prototype doesn't need to be maintainable; an internal tool with fifty users doesn't need enterprise-grade security; a startup testing product-market fit might not survive long enough for maintenance debt to matter.
Not every piece of software needs to be built like it's going to run for twenty years. Some software is disposable, and that's fine. The craft-obsessed approach I advocated in Part 1 might be overkill for a significant portion of what gets built.
That's uncomfortable to admit. But I think it's true.
The Risks are Real
I'm not going to relitigate Part 1. The risks I outlined are real: abstraction debt, debugging nightmares, the knowledge gap, the quality illusion. I stand by all of it.
One thing I didn't emphasize enough in Part 1: the thoughtful practitioners already know the limits.
There's a prototype phase, where vibe coding is useful—rapid iteration, exploring ideas, testing concepts. And there's a production phase, where engineering discipline matters—reliability, security, maintainability. The problem isn't that vibe coding exists; it's that the boundary between phases isn't always clear, and the people crossing it often don't realize they're crossing it.
A business analyst building an internal tool is probably fine. A startup founder building an MVP to test an idea is probably fine. Someone shipping a financial system that processes millions of transactions is not fine. The tool doesn't know the difference. The user has to.
The other risk worth naming: we're going to see a lot of "almost right" code. Output that's close but not quite. Almost right works until it doesn't. Edge cases. Security holes. Performance issues that only manifest under load. Research on AI-generated code already suggests that roughly 40% of AI-generated code snippets contain vulnerabilities; "almost right" at scale is a liability, not a shortcut.
Who fixes it when the person who built it doesn't understand it?
In a lot of cases, the answer is: a craftsman programmer, cleaning up after someone else's vibe-coded creation. That's already happening. Some are calling it "rescue engineering"—the maintenance burden that lands on engineering teams after citizen developers ship something that works until it doesn't. The "vibe coding hangover" is real.
This might be the new division of labor. Citizen coders generate; engineers audit and maintain. Builders move fast; craftsmen clean up.
Is that sustainable? I honestly don't know. But it's happening whether we think it's a good idea or not.
Where to Draw the Line
If you're a CTO watching this unfold, the question isn't whether citizen coding is coming to your organization. It's already there—or it will be by next quarter.
The questions worth asking:
How much of your current backlog is genuinely complex engineering work, and how much is queued simply because nobody with the right skills has bandwidth? Where in your organization are people already building things without engineering oversight—and what happens when those things break? If a business team built an internal tool with AI tomorrow, would your engineering org know about it? Would they need to?
The boundary between "fine to vibe-code" and "needs engineering discipline" isn't a bright line. It's a gradient, and your job is to figure out where your organization falls on it. Prototype vs. production. Internal vs. customer-facing. Fifty users vs. fifty thousand. Disposable vs. durable.
What I'm Doing
While I still reserve a lot of skepticism for vibe-coding and AI-first trends, in 2026 I'm launching a few experiments by building micro-SaaS products alone using teams of agents to handle the end-to-end building and operation of the business. You can follow them:
StructPR — Code review, reorganized
ShipLog — Feedback board, changelog, and embeddable widget for solo SaaS founders
AuroraGRC — Compliance management for Canadian regulations (partially)
This isn't a contradiction. It's a test. If agentic coding can build and operate real businesses that serve real users, I want to see it work—or fail—with my own codebase. Maybe the quality problems will materialize. Maybe they won't. But I'd rather find out by building than by speculating.
I'm ready to fully let go of the wheel and let AI take control, the first micro-saas in this list is specially about code review and organization, because it's a problem that's been bothering me for a long time; and that is being exacerbated by the rise of vibe coding.
The Tension That Doesn't Resolve
I tried to come up with a neat conclusion, but I don't have one.
The craftsmen are right that comprehension debt is real. That the junior developer pipeline is collapsing. That we're building systems nobody fully understands and calling it progress.
The citizen coders are right that the system failed them. That the backlogs were absurd. That gatekeeping kept good ideas from getting built. That not every piece of software needs to be a cathedral.
Both things are true.
What we're watching is a profession fragmenting in real time. Not dying—fragmenting. There will still be craftsmen, working on the systems where deep understanding matters; there will be citizen coders, building things that would have died in backlog purgatory; there will be a lot of mess in the middle, where the boundaries aren't clear and the failures teach us where they should have been.
The question isn't which side wins. It's whether we can capture the benefits of democratization—more people building, more ideas tested, fewer bottlenecks—without drowning in the maintenance debt that Part 1 warned about.
Nobody has figured that out yet. The answer probably looks different for a weekend project than for financial infrastructure. The boundaries will be learned the hard way, through failures that teach us where vibe coding breaks.
The craftsmen will say "I told you so." The builders will point to the successes and ask why the craftsmen are still complaining. And both will be partially right, which is the most frustrating kind of disagreement—the kind that doesn't end.
I started this series by quoting a programmer who said he never knew there was "an entire subclass of people in my field who don't want to write code." Writing this piece surfaced something I hadn't seen clearly before. They never wanted to be in our field in the first place. They just didn't have another way to build things.
Now they do.
The craft isn't dead. But it's no longer the only way to build. That changes everything about who we are as engineers—and what we're for.