I Think I Was Wrong About AI Coding | Enterprise Vibe Coding Explained For a long time, I've been sceptical about claims that AI can replace software developers. I've argued that software development is about far more than writing code. It involves design thinking, stakeholder management, architecture, quality assurance, security, accountability, and understanding complex business problems. But after sitting down with digital transformation and AI specialist Mark Strefford, I'm beginning to think I may have underestimated just how quickly AI software development is evolving. In this episode of The Common Sense CTO Podcast, we explore what happens when AI moves beyond being a coding assistant and starts acting like an entire software engineering team. We discuss: ✅ Enterprise Vibe Coding – is it real? ✅ Can AI agents replace parts of a software development team? ✅ AI-generated code without developers reading the codebase ✅ AI software delivery lifecycles and agentic engineering teams ✅ Testing, quality assurance and accountability in AI-built systems ✅ Why critical thinking may become the most important engineering skill ✅ The future of junior developers and software engineering careers ✅ AI code reviews, security reviews and automated testing ✅ Enterprise legacy modernisation using AI ✅ Local LLMs vs cloud AI models ✅ The economics of AI development and the true cost of tokens ✅ Agentic customers, autonomous buying behaviour and the future of digital products Mark shares practical examples of: • Building software almost entirely through AI • Using multiple AI agents to perform engineering activities • AI identifying defects humans had missed • Orchestrating specialised models for different tasks • Enterprise-scale software development with AI augmentation • Where humans remain essential in the loop Whether you're a CTO, software engineer, architect, technology leader, founder, business leader or simply curious about the future of software development, this conversation explores one of the biggest questions facing the industry: Are we approaching a world where AI doesn't just help developers, but becomes the software team itself? In the interest of balance I should say that I still believe we're some way away from losing your development team altogether, but I am more convinced than I was before this conversation that team augmentation is a reality now (as opposed to just assistance). Some of what Mark has been doing is publicly available at this GitHub address... https://github.com/markstrefford/claude-skills

In this first episode of The Common Sense CTO Podcast, I'm joined by John Nolan. John is a true Agile Pioneer, a contemporary of Kent Beck, and co-founder of Connextra, the "XP from the ground up" business that introduced the "As a... I want.. So that..." form of User Story. He and I have known each other for a quarter of a century through our involvement in an innovative Software Practice conference series either side of the turn of the Century, and we reconnected recently after a hiatus of a couple of decades, to have some really interesting chats about those early days of agile, the evolution of software development over in the intervening two decades and the state of the art now around the opportunities and fears around AI in our space. www.commonsensecto.com www.stepthinking.com

Achieving transformation success isn't about delivering technology. It's about delivering tangible business value. In this video, I share five specific examples of business outcomes delivered through transformation programmes I've led, demonstrating why the real measure of digital transformation isn't the technology itself, but what the business can achieve as a result. Transformation should deliver real, tangible and sustainable business results, leaving the organisation stronger, faster, more scalable and more predictable. matt@stepthinking.com

Are you a business leader who wonders why the tech team always seems so busy, but progress is slower than you need it to be? There's lots of reasons why that can happen, and not always to do with the technology teams themselves. Three very common reasons are: 1. Constantly changing priorities 2. Unclear ownership leading to slow decision-making 3. Excessive governance and reporting overlaid on top of work in an attempt to speed it up when things aren't going as fast as you want them to, which just ultimately results in slowing it down further. Most technology teams don't suddenly get faster just by being asked to work harder. They become faster when the business creates the conditions for better delivery. If you recognise yourself or your business in that scenario, ask yourself some searching questions. Is your technology team not up to the job, or actually, do you just need to create better conditions for them to succeed