Cloud as a Story - Vunvulea Radu

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

Cloud partner audits can look simple from the outside. You receive a checklist, find some projects, collect evidence, join the audit call, and hope to pass. Reality, is much more different. These audits are not only about having good cloud engineers or successful projects. They are about proving, with clear evidence, that your organization has a repeatable capability. A company can deliver a very good migration project and still struggle during an audit. Not because the delivery was bad, but because the evidence is missing, hard to find, or not mapped to the audit requirements. The auditor needs proof. The real question is not only whether we did the work. The real question is whether we can prove that we did the required activity, for a real customer, with clear and verifiable evidence. Start with candidate projects, not all projects In a large organization, it is not realistic to track every cloud migration and modernization project for audit purposes. There are too many proj...

AI-Enabled Operating Model In previous articles, I looked at how AI may change IT roles and how this can affect team size throughout the SDLC. But after these discussions, I think the next question is even more important: how can an organisation actually move from today’s delivery model to an AI-enabled operating model? In real life, transformation isn’t just about changing job titles. You can rename a Business Analyst to Product Discovery Lead or a developer to AI Product Engineer, but if the process stays the same, the result will not be very different. The real change happens when the way of working changes. Many IT organisations are still built around handovers. Requirements are prepared by one group, delivery is handled by another, testing is done by another, release is managed by another team, and support is involved in the last stage of the flow. This model is common. It worked for many years, it helped enterprises to scale delivery, create structure and manage complex programme...

  Whenever AI and IT teams come up in conversation, I notice the discussion quickly moves to jobs and headcount. How many people will be replaced? Which roles will disappear first? Personally, I think that discussion misses the bigger point. From what I’ve seen, the biggest impact of AI isn’t just task automation. What really changes things is the way it cuts down handovers, reduces repetitive coordination, and removes a lot of the delays that teams have learned to live with. If we look at a typical software delivery organization, work is often split across many specialized roles. Business analysts gather requirements, product owners manage backlogs, developers write code, testers validate functionality, DevOps engineers prepare releases, infrastructure teams manage environments, and support teams handle incidents. There’s nothing fundamentally wrong with that model. But in practice, every handoff creates overhead. Meetings need to happen, tickets get opened, documents get wr...

 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...