Law tells a developer what the organisation must do and must show. It does not tell a senior developer whether to build the feature that product management has specified and counsel has cleared, what to write in a pull request when an assistant produced most of it, or what to do when a colleague's generated change reaches production without anyone having read it. Chapter 24 mapped the duties that the instruments place on named parties. This chapter starts where that map ends: at the decisions that nobody has regulated and that somebody still has to take. It concerns three of the five developer functions. D1 Frame is where a value first meets a requirement, because the problem a team chooses to solve and the people it chooses to count are fixed there. D2 Design is where a value becomes a constraint that every later change, generated or typed, must respect. D5 Steward is where the developer who owns the software answers for it, and where the authority to stop, to decline and to report is used or is not.
The chapter ends with an artefact that turns three of an organisation's values into engineering rules that a pipeline, an oracle or a reviewer can check, with evidence that expires.
Four conclusions of the earlier volumes carry this chapter. Architecture as Code (Chapter 20) concluded that some decisions stay with people whatever the agents propose, and that every decision is linked to a commit, a pull request and an accountable individual (F13) (161, Nordqvist, 2025). AI Governance, Chapter 17, concluded that in a public authority legality comes before capability, that the line between decision support and automated decision is drawn in the data model and the audit log, and that every case has a reasons log (F31) (162, Nordqvist, 2026). AI Boss concluded that contestability and transparency are designed in, and that the quiet harms of algorithmic management, to autonomy, dignity and the willingness to speak, deserve attention before the loud ones (F85 and F89, Chapters 11, 13, 14, 27 and 28) (167, Nordqvist, 2026). AI Leader, Chapter 25, concluded that law states a floor and a process, that four values recur in the decisions of a leader (fairness, dignity, honesty and care), that they conflict without a fixed solution, and that the delegation ladder gains a question: which value does a decision put at stake, and can the test run outside the system? Where it cannot, the ceiling is lowered (F178) (174, Nordqvist, 2026).
Primary topics explored
- What the series has already settled
- Beyond compliance
- Professional codes
- Refusing to build harm
- Accessibility and inclusion as engineering rules
- Honesty about provenance
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.
Continue with the full chapter
Chapter 25: Ethics, Professional Responsibility and the Developer's Judgement in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Regulation, Ethics and Responsibility” and is one of 37 drawn from the manuscript.