A developer in a public authority writes software that carries law into action. The case system applies a statute to a resident, the portal is the only door some residents can use, and the code that sits behind both is, in most countries, a public document that anyone may ask to read. This chapter concerns three of the five developer functions. D1 Frame is the task of turning a legal rule and a public need into intent that can be built and tested. D2 Design is the choice between building and buying, and the constraints that procurement, accessibility and public access place on the design. D5 Steward is the duty to own software that the public has paid for, that others may reuse and that must be kept as a record. D3 Build and D4 Prove appear where the toolchain and its evidence are part of the argument.
The chapter works through Nordvik Region and one tender, NR-2030-041, for development assistants in Applications and Integration. It asks how AI coding tools are procured under public procurement law, what public code and open source ask of an authority, how accessibility, archives and transparency bind development, how public-law accountability reaches the developer, and when in-house development is better than a supplier. Nordvik's administrative law follows the Swedish pattern, as in the earlier volumes; the chapter marks where a statement concerns Swedish texts and where it concerns EU law that applies in every member state. Every legal point is an organisational and architectural implication and not legal advice. Hansa Mutual, a private insurer under financial-sector supervision, appears for contrast.
The previous chapters described the developer role in general. This chapter describes the setting in which the role carries the most borrowed authority. Three features distinguish it.
Primary topics explored
- Why the public authority is a different place to develop
- Procurement of AI coding tools
- Public code and open source
- Accessibility
- Archives and transparency
- Accountability under public law
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 18: Developers in the Public Authority: Procurement, Public Code and Legitimacy 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.