Every piece of software starts as somebody's problem, and every defect that is not a coding slip starts as a gap between that problem and what was built. This chapter concerns D1 Frame, the first of the five developer functions defined in Chapter 4: understanding the problem, fixing intent as requirements and acceptance criteria, and keeping the specification that others can verify against. It treats framing without AI first, at some length, because the later question of what AI adds and what it distorts can only be answered against a clear picture of what a person does well when nobody helps. A reader who knows what a good specification looks like will see at once which part an assistant can draft, which part it must not own, and which part it quietly damages.
The argument has five steps. Understanding the problem comes before stating a requirement, and ambiguity is the cost that framing exists to remove. A requirement becomes useful when it can be checked, which is what an acceptance criterion is. The specification is the source of intent, and when code is generated cheaply it becomes the most valuable artefact in the repository. AI adds capacity to drafting, questioning and summarising, and the same properties produce failures that are specific to framing. A specification record, shown at the end with a worked example for Nordvik Region and a contrast from Hansa Mutual, makes the five steps reviewable.
The chapter builds on conclusions of the earlier volumes. Architecture as Code (Chapter 4) set the discipline of short, numbered, immutable decision records kept beside the code (161, Nordqvist, 2025), and the specification record of this chapter applies it to intent instead of design. AI Governance, Chapter 13, set the tiering of decisions: routine decisions at pipeline gates, exceptions at a design authority (162, Nordqvist, 2026); a specification that departs from policy is such an exception. AI Platform and Security, Chapter 5, set the rule that a record is validated against a schema and re-opened by evidence (163, Nordqvist, 2026). AI Red Team, Chapter 10, placed threat models in code beside the architecture (164, Nordqvist, 2026), which is where the security requirements of this chapter belong too. AI Leader, Chapter 6, showed that AI adds capacity to orientation and that the same properties produce homogenised advice, hallucinated evidence and sycophancy to the framing of the question, and that a briefing therefore carries provenance, a dissent field and independent sources (174, Nordqvist, 2026). Requirements work is orientation at the scale of one product, and this chapter reuses that conclusion. The stewardship principle of Chapter 4 reaches back to this chapter in one place: the test oracle must be independent of the generator, and the oracle starts life as the acceptance criteria written here.
Primary topics explored
- Understanding the problem
- Requirements and acceptance criteria
- Specification as the source of intent
- What AI adds
- Failure modes
- A specification record
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 5: Frame: Problems, Requirements and Intent in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft of Developing” and is one of 37 drawn from the manuscript.