Backlogs are the silent killer of innovation. I’ve seen it too many times—a simple internal tool that should take two weeks gets pushed to the bottom of a six-month backlog because engineers are drowning in higher priority work. The system we built demands specialized skills even for the smallest things, creating a bottleneck that frustrates everyone. This backlog isn’t just a scheduling problem; it’s a symptom of an industry that made building software unnecessarily hard for domain experts who actually need solutions.
And it gets worse. The gatekeeping problem is baked into our culture. “Learn to code” has meant years of grinding through syntax, frameworks, deployment, and debugging before you can build anything useful. That made sense if you wanted to be a programmer, but it was never realistic advice for a marketing director, operations manager, or founder who just wants to solve a problem in their area of expertise. We built a fortress of complexity around software creation, and it locked out the very people who had the best ideas for what to build.
But here’s the part nobody talks about: there’s another tribe in programming—people who don’t care about the craft of coding itself but see code as a tool to get things done. They didn’t fall in love with syntax; they fell in love with products. For them, AI and low-code tools aren’t shortcuts; they’re a way to tear down artificial barriers. They want to focus on delivering value, not on writing elegant code. I don’t fully agree with this philosophy, but it’s coherent and legitimate, and it forces us to rethink what “good software” really means.
And something surprising is happening: it’s working. Not just hype or demos, but real startups and teams shipping AI-generated codebases that are good enough to win funding and users. Founders with deep domain knowledge are building MVPs in weeks, business analysts are delivering internal tools without waiting months, and designers are prototyping real interactions without engineers. These aren’t fringe cases; this is mainstream now. Sure, the code isn’t perfect. It’s not elegant or maintainable in the traditional sense. But it works—and sometimes, that’s enough.
That said, the risks are very real. AI-generated code is often “almost right,” and almost right can quickly become a liability when it hits edge cases, security vulnerabilities, or performance bottlenecks. Maintenance falls on engineering teams who didn’t build the system in the first place, spawning what some call “rescue engineering.” The division of labor might be citizen coders generating and engineers cleaning up. Whether that’s sustainable is an open question, but it’s happening whether we like it or not.
As a CTO, the question isn’t if citizen coding is coming—it’s already here. The real challenge is figuring out where your organization draws the line between what’s fine for vibe coding and what demands engineering rigor. Is that internal tool for fifty users or fifty thousand? A prototype or a production system? Disposable or durable? Those boundaries aren’t clear, but they’re critical. Understanding where your backlog is truly complex work—and where it’s just waiting on bandwidth—can help you decide where to empower domain experts to build directly.
I’m putting my money where my mouth is. In 2026, I’m launching experiments with micro-SaaS products built end-to-end by agent teams. This isn’t a contradiction but a test. If agentic coding can build and operate real businesses, I want to see it firsthand. Maybe the quality problems will surface; maybe they won’t. But speculation only takes you so far—I’m ready to find out by building.
There’s no neat conclusion here. The craftsmanship side is right about the dangers of abstraction debt and knowledge gaps. The citizen coder side is right that the system failed many people and that not all software needs to be a cathedral. We’re witnessing a profession fragmenting in real time: craftsmen working on systems demanding deep expertise, citizen coders building things that otherwise never get built, and a messy middle where the boundaries blur and failures teach us where they should be drawn.
The question isn’t which side wins. It’s whether we can capture the benefits of democratizing software creation without drowning in the maintenance debt that worries the craftsmen. Nobody has figured that out yet. 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.
You can read the full article—with all the data and sources—on ThePragmaticCTO Substack.
Read the full article — with all the data and sources — on ThePragmaticCTO Substack.
