Cloud as a Story - Vunvulea Radu

 Last week, I was working around seven in the evening when I ran out of tokens. I was working on a system built entirely with AI. For a system build with AI, it is impossible to work on this system without AI, so when the tokens were gone, I had to stop. It reminded me of ten or eleven years ago, when the electricity went off at the office. The computers stopped, and everyone went outside because there was not much else to do inside. Back then, our work depended on electricity. Now, more and more, it depends on AI too. Tokens can seem like a small technical detail, just a limit you check from time to time. But when they are gone, you feel what they mean. They can be the difference between continuing your work and having to stop. I wonder if we are starting to depend on AI in the same way. We use it to write, analyse things, find solutions, and move projects forward. Maybe, after some time, working without it will become much harder. Not because we have forgotten how to do the...

 Moving an application to the cloud is not the same as making it ready for AI. AI workloads need data that is available when they need it, systems that can scale, and good automation and governance. If we only move an old application as it is, we may end up with the same limitations in a different place. That’s why I think it helps to separate migration from modernisation. Migration changes where an application runs. Modernisation changes how it is built, operated and improved over time. Before AI agents entered the picture, the modernisation journey already had a familiar shape: discover and analyse the application, decide what to do, migrate it, and decommission what is no longer needed. Those steps still matter. What changes is how much of the repeatable work we can now accelerate. An agent can help explore a codebase, identify dependencies, review configuration and suggest possible modernisation paths. It can also help draft a plan or prepare code changes. That’s useful, ...

  I’ve been using ChatGPT and Codex a lot lately - for research, analysis, writing, and the many small tasks that make up a working day. One thing I’ve started doing is saving the prompt and context behind a document, so I can come back to it later. It began as a practical habit. Then I realised it pointed to something bigger.  I noticed this while working on a proposal for new AI capabilities. When it was time for review, the proposal itself wasn’t the whole story. People also needed to understand how we had got there: what information we’d considered, what assumptions we’d made, and what might happen next. I’ve run into a similar thing with client proposals. Work can start in an early conversation, before there’s a formal project space or an agreed way to share context. Later, I, or someone else, might need to pick it up and carry it forward. The conversation may be hard to find, or the reasoning behind the document may never have been written down. Then the final proposal i...

 I don’t think Microsoft is bringing Copilot together just to make its product catalogue easier to understand. The new Home, Code and Autopilot capabilities connect everyday work, building solutions and persistent agents, with a staged rollout. But this is not one unlimited licence for everything. GitHub Copilot, for example, still has separate plans. Think about preparing a customer proposal. You need documents, customer information, a cost model and perhaps a small automation. You want to finish the proposal, not decide which Copilot should handle each step. For me, this explains part of the change. The more interesting part is why Microsoft wants to do it now. If another AI assistant becomes the place where we start our work, Microsoft’s applications could become tools running in the background. Microsoft would still provide the software, but another platform would have the direct relationship with the user. I see this move as a way to protect that relationship. There ...

Many organisations know how to create a service offer. They identify a market need, define the value proposition, describe the scope and create a presentation for clients. Sometimes they also add a delivery approach, a pricing model and a few case studies. This is useful work. It gives sales teams a clear story and helps start client conversations. But it does not automatically mean that the organisation is ready to deliver the service. I learned this while working on cloud migration. What started as the creation of a service offer became something much bigger: building the capability behind the offer, from the commercial proposition to the people who could deliver it. The main question changed from: "Can we sell cloud migration?" to: " Can we deliver cloud migration repeatedly, with different teams and client environments, while keeping a predictable level of quality?" - that second question changes the entire approach. A standard service offer normally includes:...

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