Chapter 20 asked how a leader measures adoption without mistaking use for value. This chapter turns to the team, because the evidence that decides whether AI helps or harms a piece of software is produced in daily routines: how people work with an assistant, how they review what it generated, how far they trust it, and whether they say so when it is wrong. It concerns D3 Build, because the way a developer directs and accepts generated code is a habit before it is a policy, and D4 Prove, because review, testing and the reporting of defects are carried by a team's culture as much as by its tools. The chapter treats pairing with an assistant, review culture, trust calibration, speaking up, the safety of juniors to ask, shadow AI and a team practice agreement short enough to be checked.
The argument has five parts. An assistant can be worked with in a pairing-like way but is not a second person, and the difference is the absence of someone who can be named, who understands and who can revert. Review culture decides whether review is a gate that is passed or a practice that finds things. Trust in generated code is calibrated against outcomes that the team records. Speaking up depends on what happens to the person who speaks, and an assistant changes what that risks at three points. Shadow AI and concealment are signals about all of this, and the response is an approved route, not a hunt.
The chapter takes five conclusions as its starting point. AI Leader, Chapter 21, concluded that trust in AI is calibrated and not maximised, that psychological safety is a property of teams, that an assistant changes what speaking up risks at three points, the record, the count and the draft, each a rule a named leader sets, and that shadow AI and concealment are signals about trust (174, Nordqvist, 2026). This chapter applies those points to a development team. AI Threat, Chapters 6 and 14, concluded that relying on AI reduces effort, recall and, among those who trust the tool, checking, and that the response is drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level (165, Nordqvist, 2026). AI Operations, Chapter 25, concluded that responsibility tends to land on the person nearest the system and that the design response is structural, a stop right without penalty and metrics about the rota, never the person (170, Nordqvist, 2026). AI Purple, Chapter 23, set out when a session is safe for the truth: roles and not people are named, no result enters an appraisal and anyone may pause (169, Nordqvist, 2026). AI Boss, Chapter 13, treated the chilling effect of monitoring (167, Nordqvist, 2026). Chapter 4 added the stewardship principle (Name, Understand, Revert) and the independent test oracle. Chapter 9 treats the mechanics of review and testing; this chapter treats the culture in which they happen.
Primary topics explored
- What the earlier volumes settle
- Pairing with an assistant
- Review culture
- Trust calibration
- Speaking up
- Safety to ask
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 21: Team Practice and Culture: Pairing, Review Culture, Trust and Psychological Safety in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Leading Change and Adoption” and is one of 37 drawn from the manuscript.