A coding assistant arrives in an organisation as a licence, a plug-in or a vendor update, and it leaves behind something that no other tool of the developer's trade has left: a record of how each developer works. Acceptance rates, prompts, completions, agent runs and review comments are all data about people, and in most of Europe the law gives the people concerned a body that speaks for them before such a tool is introduced. This chapter sets out what must be informed, consulted or agreed before developer tooling and its telemetry are used, where the monitoring of developers ends, what employment terms the change touches, who owns what a developer produces with AI, and what a collective agreement on developer tooling contains. It concerns D3 Build, because the telemetry is generated by the act of writing and directing code, and D5 Steward, because stewardship needs named owners and records, which is exactly where it meets the limits on monitoring.
The chapter argues that the two requirements are compatible if they are kept apart by design. Stewardship needs a record that says which named person owns a change and can explain and revert it (the tests Name, Understand and Revert of Chapter 4). Employee representation and data protection forbid turning the by-products of that record into a score of the person. The same field can serve both only when purpose, grain and access are written down and agreed. The chapter describes obligations and good practice. It does not describe any way of avoiding or defeating the rights of representatives, and it is not legal advice.
Five conclusions of the earlier volumes carry this chapter, and each is summarised so that the chapter stands alone.
Primary topics explored
- What the earlier volumes settle
- Information, consultation and co-determination
- Telemetry and monitoring of developers
- Employment terms
- Ownership of output
- Collective agreements
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 22: Developers, Works Councils and Employment: Telemetry, Rights and Intellectual Property 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.