The 'Citizen Developer' is Just Shadow IT With a Better Publicist

Let's call this what it actually is: a corporate euphemism.

For years, the business world has tried to dress up 'shadow IT'—the act of employees bypassing official channels to get work done—as something noble and empowering. As Cory O'Daniel first reported for Massdriver, the latest iteration of this fantasy is the "citizen developer." The pitch is that by empowering the non-technical workforce to build their own tools, companies can move faster and bypass the bureaucratic slog of the engineering organization.

But as a skeptic, I see the pattern. Whether it was the accounts payable clerk in the nineties buying software on a sales call and plugging a Dell server into an ethernet port, or the marketing team in the early 2000s using Dreamweaver to create sites that IT then had to figure out how to host on IIS 5, the result is always the same. The business gets a quick win, and the technical debt lands squarely in the lap of the people actually paid to keep the lights on.

As Cory O'Daniel notes in a piece for Massdriver, this isn't a new phenomenon. According to Gartner, as far back as 2021, 41% of employees were already creating analytics or technology capabilities from outside the IT department. The difference today is that the barrier to entry has vanished. With the advent of tools like Claude Code, a sales development representative (SDR) who is tired of waiting for a lead management tool to move through backlog grooming can now spin up a sloppy version of that tool in a single afternoon.

On the surface, this looks like efficiency. To a CEO, it looks like a win: why wait for a roadmap prioritization fight when an employee can just "will it into existence"? But this "autonomy" comes with a staggering price tag that the citizen developer never has to pay.

When an untrained employee uses AI to build an app, they aren't thinking about PII (personally identifiable information) storage or security protocols. They are thinking about their immediate task. As O'Daniel points out, this is effectively a security incident. When these rogue applications are eventually discovered, they are treated as such by CISOs and IT professionals. Yet, the corporate culture often views these individuals as heroes who are simply "moving the business forward."

This is where the "citizen developer" label becomes truly insidious. By granting a title to someone who has never seen a line of production code, companies are blurring the line between professional engineering and hobbyist experimentation. O'Daniel argues that there is a gradient between the expert and the citizen, and that the boundary was largely drawn because professional developers get paid more. While that may be true in terms of payroll, it is fundamentally false in terms of responsibility.

Professional developers are trained to understand the downstream effects of their choices. They understand stability, scalability, and the precarious nature of production systems. The citizen developer, by definition, operates outside their comfort zone and outside their means. Whether it is an operations manager at a regional insurance carrier turning twenty years of spreadsheet-based institutional knowledge into a makeshift app, or a sales rep using a LLM to automate a workflow, they are introducing changes to systems that must remain stable.

From the perspective of operations, there is no difference between a professional developer and a citizen developer; both are introducing changes to a production system. The difference is that the professional knows how to build the guardrails, while the citizen is the reason the guardrails are necessary in the first place.

We are seeing a shift where the "layer cake" of corporate production—where the business waits on the PM, the PM waits on the engineer, and the engineer waits on ops—is being bypassed. The person at the top of the stack has decided that "it can't be this hard." And for the person writing the prompt, it isn't. But for the engineer who eventually inherits that sloppy, AI-generated mess? It is incredibly hard.

By rebranding shadow IT as "citizen development," companies are essentially telling their technical staff: "Deal with the wreckage later." They are prioritizing immediate, sloppy output over long-term systemic health. It is a gamble where the business takes the reward and the IT department takes the risk.

If we continue to pretend that anyone who can prompt an AI is a "developer," we aren't democratizing technology; we are just accelerating the rate at which we break things. The citizen developer isn't a new role—they are just the same person from the nineties, now with a much more powerful set of tools to create a much larger mess.