The development organisation has never been the only place where software is written. Case handlers build trackers, claims teams build dashboards, product owners build prototypes, and since generative AI arrived each of them can describe an application in a sentence and receive one. This chapter concerns D1 Frame, D3 Build and D5 Steward for the person who is not a developer and builds anyway: who that person is, which tools they use, what goes wrong when nobody knows the tool exists, how governance works when prohibition does not, where a prototype becomes production and who owns the result when its builder moves on. It matters to developers because the platform team, the tech lead and the architect are the people the rest of the organisation will call when a citizen-built tool fails.
The terms are used as follows. A citizen developer is an employee outside the development organisation who builds software for work, with a spreadsheet, a form or workflow builder, a low-code platform or a natural-language app builder. The research literature calls the wider group end-user programmers. A low-code platform provides visual building blocks, connectors to data and a hosting environment so that an application can be assembled with little or no hand-written code. A natural-language app builder generates the application, and often its database and hosting, from a description in ordinary language; the practice of building by conversation with an AI coding system is called vibe coding in Chapter 7. Shadow IT is software or a service that the organisation's IT function does not know about or has not approved. A maker is the platform vocabulary for a citizen developer inside a low-code product.
The argument has five steps. More people build, and AI lowers the barrier of syntax without lowering the barrier of knowing whether the result is right. The risks fall into data, access and continuity. Governance without prohibition rests on a register, templates and sandboxes, because bans do not appear to stop what they target. The line between prototype and production is drawn by use and by data and crossed through gates that the stewardship tests supply. Every tool has an owner who can leave, so support and sunset are decided at registration. A register entry with promotion criteria makes the steps reviewable.
Primary topics explored
- When anyone can build
- Shadow IT and its risks
- Governance without prohibition
- Prototype and production
- Support and sunset
- A build-your-own-tool register
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 19: Citizen Developers, Low-Code and the Non-Developer Who Builds in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Developer Roles Across the Organisation” and is one of 37 drawn from the manuscript.