AI Adoption Needs Change Management

I’m running a four-day workshop. A team of around 10 technically savvy people, system administrators and software developers. And a managing director who is himself very closely involved in the development process. There’s a desire to venture into the world of AI-assisted software development, but also plenty of questions. What about our intellectual property and data protection? Are we making ourselves redundant here? And how do we ensure that the output isn’t complete rubbish?

The tempting fallacy

In this case, the managing director deliberately took a different approach. He realised that it wasn’t enough simply to give the developers a licence for Claude Code and expect the rest to sort itself out. Unfortunately, I often hear this kind of thing in both my professional and private circles.

Many, especially large companies, lay off hundreds or thousands of developers, hoping that AI will make up for it (or cite this as the reason). Then comes the harsh reality: rehiring at higher costs, bugs and loss of customers, damage to the brand. The aim should be to use AI to improve quality and fill gaps… not to get rid of the most important resource: the people with the knowledge.

What we did

First of all, we spent a day getting everyone on the same page. How does it all actually work, even behind the UI or the CLI? For some, this might just have been a refresher, but having a common language and filling in knowledge gaps are the foundation for developing something sustainable.

On the second day, it became clear to many that AI isn’t actually the main issue. We discussed processes, scrutinised meetings and looked at how to write tickets. How are things currently run, what is the ideal, what is the goal? And rather than dictating the whole thing, we aimed to foster an understanding that there are reasons why agile project management approaches such as Scrum or Kanban have become established in the industry.

Day 3 brought both aspects together, using a technique that has been mentioned more and more frequently of late: Spec-Driven Development. Instead of generating code straight away, the specification is first developed collaboratively and refined iteratively. Only then does the AI take over the actual implementation. We also looked back at the previous days, discussing why we maintain the ‘human in the loop’ here – that whilst workloads may shift, software development is about more than just generating code.

The final day then took another look at trends, token-efficient use of AI, and unresolved questions from the previous days. And, very importantly, a rough plan for the next two weeks, which, as a pilot sprint, is intended to put what we’ve learnt into practice.

What have we learnt?

Perhaps there was a widespread expectation here and there that, straight after the workshop week, we would be able to start using AI to implement the first features.

However, it became clear to everyone on the very first day that there are still quite a few hurdles to overcome. How do we ensure we comply with data protection regulations and keep customer and employee data clearly separate from the LLM? Equally important, what about intellectual property? How do we protect business-critical algorithms, and do we even need to? Is the codebase free of credentials, and what about the Git history? This discussion needs to take place; facts must be established and decisions made. A commitment from the team is essential, based on an understanding of the technology and its potential consequences.

Nor can processes continue unchanged. Whether new slots for AI topics are created in meetings or the ticket structure is adapted to an upcoming spec-driven development approach – this won’t happen by itself; it must be decided by the team and supported by everyone.

Spec-Driven Development, in particular, felt like the biggest ‘aha’ moment; during the practical session, in several teams working on a similar task, all participants sensed that this approach provides control, produces comparable output, and ensures the path to that output is documented and adjustable – but above all, it avoids ‘vibe coding’.

The Pilot Sprint

It becomes clear right from the first meetings that much of what was learnt in the workshop is still a long way from being put into daily practice and becoming second nature. Every ticket is different – sometimes a feature, sometimes a bug. Questions need to be asked and answered, ideally by everyone, so that people don’t just learn for themselves.

This is about change management – it’s people work that no AI can do for you. Facilitation is essential here, and that requires time and an understanding of the individuals involved in the change. There are sceptics, there are early adopters and a whole spectrum in between, and everyone must be included and listened to. The theory and the technical possibilities must be integrated into the team and the processes; there is no one-size-fits-all template, only precise tailoring and constant adaptation of what has been learnt.

The work is only just beginning

Knowledge has been shared, concerns have been taken seriously and discussed, and in many areas these have certainly been addressed. Practical application has served as a source of motivation, demonstrating that opportunities are emerging which did not exist before. Problems have been uncovered which were not initially the main focus, but a planned change often highlights these more clearly than pointing them out directly.

The pilot sprint is still underway, and this is a deliberate initial experiment in which we must listen carefully and observe where the snags lie in order to find solutions. Afterwards, however, it will still take some time before everything becomes second nature and everyone feels confident in applying the processes correctly. And in today’s AI-driven world, where established standards have been completely replaced after just a few weeks, it is all the more important to recognise this as a lasting change that continually impacts everyday life and cannot be ignored.