The Citizen Developer is Evolving

For years, the idea of a citizen developer was tied closely to no-code and low-code.

The premise was simple: people who understood the business could build useful software without becoming traditional software developers. They could connect systems with Zapier, build lightweight apps with tools like Glide, create internal workflows, and solve problems that would otherwise have sat in an IT backlog.

That was already a meaningful shift, but I think the definition is changing again.

At ZapConnect this year, Zapier showed off a next-generation builder that can generate TypeScript, a programming language, while also representing an automation visually. Tools like Zite are taking a similar idea into application development: you describe what you want to build, and the platform generates the code needed to make it work.

The interesting part is that the person building the solution may never need to write, or even read, most of that code.

So are they still a citizen developer? I think so.

In fact, I think we're entering a new phase of citizen development where "no-code" is no longer the defining characteristic. What defines it now is that someone who understands a business problem can turn that understanding into working software without needing to be a traditional programmer.

The term has been around much longer than the current wave of generative AI.

Gartner is widely credited with popularizing the concept. Its definition has shifted over time, but the core idea has held: a citizen developer is someone outside a traditional IT development role who creates or extends technology capabilities for themselves or others.

That distinction matters. Citizen development was never really about avoiding code for its own sake. It was about moving the ability to create technology closer to the people who understood the problem.

No-code and low-code tools made that possible by abstracting away much of the technical complexity. Instead of writing API calls, you selected an app and an action. Instead of writing conditional logic, you created a path. Instead of building a database from scratch, you created a table. Instead of deploying a web application, you published an interface.

For a generation of builders, tools like Zapier became a visual programming language.

A traditional developer might tell a computer exactly how to accomplish something using a programming language. A no-code builder might configure the same logic using visual components. Increasingly, a citizen developer can simply describe what should happen, and the system can generate the implementation.

Zapier's next-generation builder, announced at ZapConnect this year as Next Gen Zaps, is a useful example.

It isn't simply generating a prettier Zap. It can generate TypeScript underneath the workflow, and that opens up things that have historically been difficult, or sometimes impossible, to express in a purely visual builder: combining branches back together, continuing execution after loops, supporting multiple triggers, and building more sophisticated logic.

The user may still be building through an accessible interface, but code is very much involved. What's changing is who's responsible for producing it. Increasingly, it's the platform.

This connects to a much larger conversation happening across software right now.

AI-assisted development has dramatically cut the cost and effort of producing code. That doesn't mean software engineering has become trivial, and it certainly doesn't mean every piece of software should be generated by prompting a model. But it does change where the scarce skill lives.

If producing the implementation becomes easier, more value moves upstream:

• What problem are we actually solving?
• What should happen when something goes wrong?
• Which system should own the data?
• What information needs to move between systems?
• Which exceptions matter?
• What should require human approval?
• What needs to be deterministic?
• How will we know whether the result is correct?

Those aren't primarily coding questions. They're systems-thinking and domain-expertise questions.

That's why I don't think the citizen developer of the future is necessarily the person who knows the most tools. It may be the person who understands the business deeply enough to describe what should exist, and who has enough technical literacy to guide, test, and improve what gets generated.

One of the more interesting sessions I attended at ZapConnect wasn't really about development at all. It was about hiring in the age of AI.

Zapier's talent team described an AI fluency rubric built around four areas: mindset, strategy, builder skills, and accountability and judgment. They also talked about learning agility, whether someone can learn hard things fast, because the tools people are using today may not be the tools they're using three months from now.

That resonated with me. I've hired for roles in the promo industry myself, and those are exactly the traits I've looked for. Knowing Zapier is useful. Knowing APIs is useful. Knowing how a loop works is useful. But those skills sit underneath more durable traits: curiosity, experimentation, judgment, an ability to understand systems, and a willingness to rethink how work gets done.

The panel also made the point that AI actually increases the importance of expertise and judgment. If a system can generate a large amount of work quickly, someone still needs to determine whether that work is any good. The future isn't just about being able to generate software. It's about being able to recognize good software, good automation, and good process design when you see it.

The panel's take on hiring backed this up: nonlinear career paths, the kind that might once have looked messy on a résumé, often show exactly the adaptability employers need now. The tools will change. The ability to learn, question, build, evaluate, and adapt is a lot more durable.

It's easy for every technology conversation right now to turn into an AI conversation, but AI doesn't need to be everywhere.

Zapier recently looked at how leading companies were actually using AI inside automated workflows. Even among strong adopters, AI accounted for only 18% of the steps in AI-powered workflows. The remaining 82% relied on conventional automation: rules, logic, app connections, and data movement. That's a useful reality check.

If a workflow needs to move a customer ID from one system to another, you probably don't need a language model. If it needs to determine whether an incoming email represents a sales opportunity, a customer complaint, or an invoice request, AI may be useful. One requires execution; the other requires interpretation. A capable citizen developer needs to know the difference, and to treat AI as another tool in the toolbox, not the toolbox itself.

Zapier's own Next Gen Zaps builder is built around this same idea, under a name they call fluid determinism: each step in a workflow can shift between AI reasoning and predictable if-then logic depending on what that step actually needs. The steps that just move data or apply a fixed rule stay deterministic, cheap and consistent. The steps that need to interpret something ambiguous get handed to the model. It's a useful way to think about where AI belongs in an automation, not as a layer poured over the whole workflow, but as a mode individual steps can switch into when the task calls for interpretation instead of execution.

There's an obvious tension in citizen development: if you make it easier for more people to create software, you also make it easier for more people to create badly governed software.

That doesn't mean organizations should lock everything down and send every automation request back through IT. That would eliminate much of the value citizen development creates. It means the role of IT changes. Instead of being the only group allowed to build, IT increasingly becomes responsible for establishing the environment in which everyone else can build safely: identity and access controls, role-based permissions, approved applications and connections, audit logs, version history, data-retention policies, testing standards, documentation, and ownership and continuity.

This was another theme running through ZapConnect and Zapier's broader enterprise strategy. Zapier's enterprise platform now includes controls for application access, user provisioning, role-based permissions, an expanded audit log, security policies, and centralized administration. That's not separate from the citizen-development story. It's what makes citizen development viable at larger scale.

The goal isn't unrestricted building. It's distributed building inside sensible guardrails.

I think our industry is unusually well suited for this next generation of citizen developer.

Print and promo businesses are full of workflows that cross multiple systems and organizations. A salesperson builds a project, a presentation becomes an order, artwork has to be collected and approved, purchase orders go out to suppliers and decorators, inventory may come from one company while decoration happens at another, tracking data needs to come back, invoices need to reconcile, and exceptions happen everywhere. Every distributor, supplier, decorator, and technology provider seems to run a slightly different version of the process.

Historically, someone could understand that workflow incredibly well and still have very little ability to change the technology supporting it. They had to explain the process to a developer, submit a request to IT, wait for a software vendor, or simply live with the manual work.

No-code changed that. AI-assisted development expands it further. Someone who understands promotional products operations can increasingly build the connective tissue themselves. They don't need to become TypeScript developers so much as understand the process, the systems, the data, and the outcome they're trying to create. That's a much more accessible skill set, and in many cases, the people with that knowledge are already sitting inside the business.

We've seen this firsthand. We've built order-hold logic for a couple of company stores on the same commerce platform: one flags orders that go over a buyer's credit limit, another holds an order until a purchase order gets approved and uploaded, then releases it to fulfillment. Neither project was really a coding problem. The hard part was deciding what "on hold" should actually mean and which exceptions needed a human. We've done similar work on the reporting side, reconciling order and invoice data between a client's sales platform and their CRM so the numbers they report internally actually tie out. None of that required a computer science degree. It required knowing exactly how orders, invoices, and fulfillment are supposed to work in this industry, and where they usually don't.

For a long time, citizen development was closely associated with the phrase "no-code." I'm not sure that will remain true.

The next generation of citizen developers may generate quite a lot of code. They just won't necessarily write it themselves. Their job will increasingly be to understand the business, architect the solution, give technology the right instructions, test the result, recognize when something is wrong, and continuously improve the system.

In other words, the technical barrier is moving. The valuable skill is no longer simply knowing how to tell a computer how to do something. It's knowing what should happen, why it should happen, and whether what was built actually works.

I'll admit some of this makes me uneasy. Composing Zaps step by step has been a big part of how I've made a living. But that was never really the point of starting PromoPilot. I started it to be a voice in an industry that doesn't hear this enough: there are people at your company right now who can do very cool things with Zapier, and you don't have to be a coder to do it. That's the idea behind our coaching and the courses we run in our Aviators community. If AI makes that even truer, if more people who understand this industry can build the connective tissue themselves without a computer science degree, that's not competition for the mission. It is the mission, arriving faster than I expected.

And that potentially opens the door to a much larger pool of people capable of building the software that moves our businesses forward.