AI Developer · Whitepaper

Chapter 6 · The Craft of Developing

Design: Architecture, Decisions and Constraints with AI

Key insights from Chapter 6 of "AI Developer"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 11 November 2026
Build number 2026.11
software-development stewardship ai-governance architecture-as-code ai-agents
Figure 6.1: A design decision: options, challenge, a named decision-maker and a record with a review date.
Figure 6.1: A design decision: options, challenge, a named decision-maker and a record with a review date.

Design is the point at which a developer chooses what the code that follows may and may not do. This chapter treats that choice: the constraints that a design sets, the records that keep the reasons for it, what AI contributes as a generator of options and a reviewer of drafts, what is known about the drift of generated codebases away from their intended design, and where the developer's design work ends and the architect's begins. It concerns D2 Design, the developer function of choosing the constraints: architecture, interfaces, data, security by design, decisions and their records. It leans on D1 Frame, which supplies the need and the quality attributes that a design must satisfy (Chapter 5), and it hands over to D3 Build (Chapters 7 and 8), where the constraints meet code, and to D4 Prove (Chapter 9), where conformance to them is checked.

The chapter describes design without AI first, because the question of what changes cannot be answered without a baseline. It then asks where an assistant helps, where it flatters, and what an organisation has to write down so that a design decision can still be explained when the people and the tools that took part have changed. The delegation ladder is simple for this function. In both organisations of this book, design is at Level 0 Advisory for every tool: an assistant may propose, critique and draft, and a named developer decides. The reasons are the book's own conclusion from the evidence below, and the chapter ends with what would change them.

The figure shows one decision from need to review date. The need and the constraints come from the specification and from law and data class. An assistant drafts options and challenges them. The developer adds the options the tool did not offer, and a pre-mortem and recorded dissent follow. A named developer decides and gives reasons. A decision that is hard to reverse or that crosses a boundary goes to the architect or the design forum. The Architecture Decision Record (ADR) states the AI contribution, the dissent and the review date, and a rule derived from it is checked in the pipeline by something other than the generator. A drift finding returns to the pre-mortem, and the review date reopens the need.

Primary topics explored

  1. Design as the choice of constraints
  2. Decision records
  3. AI as option generator and design reviewer
  4. Architectural drift
  5. The boundary to the architect
  6. A worked decision: Nordvik Region's status interface

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.

Who should read this

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.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 6: Design: Architecture, Decisions and Constraints with AI 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.