Research, Pillar 01
AI in Software Engineering
AI is changing software development. Whether it is changing it in the ways the conversation assumes is an empirical question.
Most commentary on AI in software engineering moves faster than the evidence. This research programme slows that down: measuring what is actually happening in engineering teams, tracking adoption over time, and applying the same analytical standards used across the rest of this work. The findings are more nuanced than the headlines suggest, and more useful for that reason.
Adoption Dynamics
The most common assumption in AI tool rollouts is that adoption follows perceived usefulness: if engineers believe a tool helps, they will use it. The empirical record qualifies this significantly.
Workflow compatibility is the stronger predictor. Engineers adopt AI tools that integrate into how they already work. Tools that require changes to established practices face sustained resistance, regardless of how capable they appear on paper. An organisation introducing AI coding assistants should map integration points to existing workflows before measuring uptake, and should not interpret early resistance as evidence of permanent rejection.
A second finding: social proof within the team matters as much as the tool’s inherent qualities. Engineers who initially resist AI tools become high adopters when a trusted colleague demonstrates integration into a shared working context. Adoption is partly a social process, not only a capability evaluation.
Studying Disruptive Technology
Studying an emerging technology while it is still emerging is methodologically difficult. The common mistake is to study only what is new while ignoring the trajectory of what came before.
This research addresses that problem with a structured playbook that combines retrospective analysis of how past technologies, mobile, cloud, open source, changed software engineering, with prospective studies of current AI tools. The result is a more complete picture of technological impact, one that is less vulnerable to the hype cycles that distort most coverage of emerging tools.
The practical implication for technology leaders: distinguish between adoption signals that reflect genuine workflow value and those that reflect novelty. The retrospective lens helps make that distinction.
Creativity and Generative AI
When routine coding tasks are automated, developers gain time. What they do with that time is not automatic.
Early findings from this work suggest that the quality of non-routine creative work after AI adoption depends heavily on team structure and explicit expectations, not on the AI tool’s capabilities alone. Teams that restructure around the time freed by AI show different outcomes from teams that simply add the tool to an unchanged workflow.
This complicates simple productivity narratives. The question is not whether AI makes engineers faster. It is whether AI makes engineering teams better, and under what conditions that happens.
The Copenhagen Manifesto
The Copenhagen Manifesto articulates four principles for responsible AI integration: responsibility, transparency, inclusivity, and sustainability. These are not values statements. They are design constraints that teams can apply to specific decisions about how to introduce and govern AI tools in production environments.
Responsibility means specifying who is accountable for AI-generated outputs. Transparency means making the AI’s role in a given output visible to the people affected by it. Inclusivity means ensuring that AI adoption does not systematically advantage some team members over others. Sustainability means building for the long-term health of the team, not only current productivity metrics.