Every chapter of this book so far has asked something of the developer: state the intent before opening the draft, read the change before approving it, write the oracle from the specification, know the delegation profile, be able to revert what you merged. This chapter asks what the developer must be able to do in order to meet those demands, how an organisation can know that the developer can do it, and how developers are developed when the work that once developed them is changing. It concerns all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because competence is the condition of each of them. A developer who cannot turn a vague request into testable criteria cannot frame; one who cannot read a generated change cannot prove; one who has never reverted a release cannot steward.
The claim of the chapter is narrow and meant to be tested. The competence of a developer is a claim that needs evidence (Chapter 4), and the evidence that serves is a record of judgement exercised, assessed by someone outside the developer's line, dated and with an expiry, not a record of attendance or of tool use. The chapter sets out six groups of competence, the AI literacy duty of the AI Act and what an organisation can reasonably record to meet it, the kinds of evidence that support a statement about each group, the frameworks that can carry the baseline, the career ladder that rests on the evidence, the hiring practice that uses the same groups, and a competence record for a mid-level developer at Nordvik Region.
The chapter takes over five conclusions. Architecture as Code (Chapter 18) managed competence as a skills matrix by level, Foundation to Expert, and held that practical demonstration on real delivery shows capability (161, Nordqvist, 2025). AI Governance, Chapter 14, held that careers need a path between building and verifying and that assessment results are personal data whose use is agreed with employee representatives (162, Nordqvist, 2026). The Transformed Security Architect, Chapters 15, 21 and 22, held that keeping a craft is a design decision and that competence is evidenced by records of judgement exercised (166, Nordqvist, 2026). AI Operations, Chapter 26, gave the manual-practice interval of 90 days, the rule that the lower of the assisted and the unaided result governs, and the rule that a Level 3 class drops to Level 2 when fewer than two people hold current evidence (170, Nordqvist, 2026). AI Leader, Chapter 27, set out the competence record assessed by a second leader (174, Nordqvist, 2026).
Primary topics explored
- What this chapter builds on
- The competence profile
- AI literacy under Article 4
- Evidence of competence
- Frameworks
- Career ladders
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 27: Competences and Developing the Developer in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Developer as a Person” and is one of 37 drawn from the manuscript.