A few months ago, one of DVT’s AI Build Teams ran an experiment on a greenfield build for a DVT client in the UK. The team worked fully remotely throughout, and every person on the project used AI tools to do their job, with the whole build run on AI spec-driven development. It turned into the clearest proof I’ve seen that this isn’t a “nice to have” anymore.
This is the final article in a three-part series about the Flow Master role in AI Build teams. The first explained why AI-enabled delivery requires more than traditional Scrum facilitation. The second examined the skills Flow Masters need to manage specifications, validation, governance, priorities and decisions.
As AI raises expectations for real-time customer engagement, CIOs need to address the data architecture, governance and duplication issues that keep personalisation from scaling.
The first article in this series highlighted a shift in AI Build teams: creating code, documentation, and tests is no longer the hard part. AI has significantly reduced the effort needed for these tasks, allowing small teams to deliver at speeds that were unimaginable just a few years ago.
Software development is changing. AI engineering tools, agentic environments, automated testing, AI-generated documentation and spec-driven development are reshaping how teams are structured, how decisions are made and what leadership looks like in a delivery team.
In a recent DVT Insights Webinar, Dael Williamson outlined why the next phase of enterprise AI will depend less on chatbots and productivity gains, and more on data, governance, organisational design and new ways of working.
Back in 1979, an IBM training manual included a warning that feels strangely fitting today: "A computer can never be held accountable, therefore a computer must never make a management decision." In software engineering, every line of code is a decision. The architecture you choose, the edge cases you handle and the way you structure your data are all choices that decide whether a system succeeds or fails. With generative AI now part of our toolkit, there's one question worth asking: who is making those decisions in your codebase?
There is a conversation happening in the boardrooms of South Africa's mining houses, chemical companies, and manufacturers right now. It usually starts with a frustrated CIO or COO pointing at a list: the mobile application for field maintenance crews that has been in development for eighteen months. The plant operations dashboard that went live missing half its integrations. The AI-powered scheduling tool that is still a pilot, twelve months after the pilot was supposed to end. The digital platform that works in the demo environment and nowhere else.
As organisations deploy AI at scale, leaders need to confront a critical question: who owns the decisions of the machines?