Cloud as a Story - Vunvulea Radu

 When we discuss AI in IT delivery, the main point isn’t that AI will take over everyone’s jobs. The bigger shift is that AI will cut down on the number of handovers between people. Right now, a feature might go from a Business Analyst to a Product Owner, then to a developer, tester, DevOps, and finally support. Each step adds meetings, tickets, explanations, and sometimes delays. With AI, many of these tasks won’t go away completely, but they’ll be combined into broader roles. Teams might get smaller in some areas, but more importantly, the way teams are structured will change. Before going into more details, you can find below a possible mapping of new roles, covering the full SDLC. Before With AI BA + PO + Process Analyst + Data Analyst Product Discovery Lead Scrum Master + PMO + Project Coordinator Delivery Manager Developer + QA Automation + Basic Tester AI Product Engineer Ma...

Many executive teams ask: How quickly should we expand our AI capabilities? The typical response is to hire more AI/ML engineers, data scientists, or establish a dedicated AI department. While important, this addresses only part of the challenge. AI does not generate business value simply by increasing headcount. Value arises when models, data, applications, platforms, security, testing, and business processes are integrated. The key question is not just, “ How many AI engineers do we need? ” but rather, “ What organisational structure will turn AI ideas into production business outcomes? ” In many AI initiatives, AI/ML work accounts for only 20–40% of the total effort. The rest of the effort is in data engineering, cloud and platform engineering, automation, software development, QA, security, compliance, monitoring, cost management and business adoption. If an organisation grows AI talent without growing the surrounding capabilities, the bottleneck does not disappear. It only moves ...

 Today, most AI-generated platform engineering work still relies on classical prompt engineering: describe the outcome, add context and constraints, then iterate until the pipelines, infrastructure, and operational assets are “good enough.” More structured methods and tools (such as BMAD or SpecKit) are still relatively uncommon for tasks like DevOps pipelines, infrastructure-as-code, operational documentation, and production-readiness controls. That’s why I ran this comparison: I wanted to see whether structured approaches can materially outperform normal prompting on a realistic platform engineering task. I compared four approaches to generate pipelines, cloud infrastructure, and an operational layer for an existing application running on Azure App Service: SpecKit used with normal prompting, classical prompt engineering, SpecKit (method-driven), and BMAD. The goal wasn’t just “does it compile?”—it was whether the output looked like something a real platform team could run ...