On 12 December 2025 I went to a Microsoft Power Platform community afternoon with an unusual premise. The host, a Microsoft employee, framed it as people, process and technology: first a speaker on the people side of change, then a talk on vibe coding with Power Platform, then a customer talking about how they are ready to accept new technology. This post covers the first talk, because it was the one I recorded: Patrick Debois, whose name is on the slide (âEvolution from LLM to Agents - Patrick Deboisâ) and whom the host introduced as the person who started the people side of DevOps. At the end of his talk he said he writes for AI Native Dev and works at Tessl, as his last slide also showed. I cover the second talk briefly at the end.
I summarise from my recording in my own words. The product claims are the speakerâs, and I link official pages where I checked them.
Who wants to change?
The host opened with an AI-generated cartoon: ask a room who wants change and every hand goes up, ask who wants to change and nobody moves. He said the better question may be âwho wants to be changedâ, because everybody wants change but nobody wants to be pushed into it. His point was that people in the room were there because they see what AI could do for their development life cycle.
The opening slide: âNext-Level Development: Smart, Scalable, AI-Poweredâ.
From tab completion to a team of agents
Patrick began with a slide of his own, generated with AI, about unicorns versus âthe rest of us, the horsesâ: AI is for everyone now, not only the most innovative companies. He also said the talk was about people who still type code by hand, so the no-code people in the room had to switch mindset.
His history of the developer experience went in steps. First came very clever tab completion. Then ChatGPT pulled people out of the editor to paste code into a chat. Completion grew from a line to many lines, then to predicting your next edit, then to changing many files across a code base. AI then reached the terminal and the run-and-fix loop, then test writing, then tools such as a browser the agent can drive itself. Cognitionâs Devin, he said, showed that whole loop automated, and many people had thought its demo was a mock-up. Finally the IDE disappeared and agents run headless in a terminal.
âAI Tech evolutionâ: an LLM gains RAG, functions, reasoning and memory, becomes an agent, then a team of agents with shared knowledge.
He said he maintains a landscape page of AI-infused development tools: the slide showed 330, and he thought the count was nearer 600 by then. His observation was that every new technology starts by sprinkling the new thing on the old workflow (a chatbot here, âmove everything to the cloudâ there), and that being AI-native is still being discovered. Asked by engineering VPs whether AI means hiring fewer people, his answer was that tasks shift rather than vanish: some get easier, some disappear, new ones appear.
Patterns he walked through
From writing to reviewing. If you no longer write the code, your job is reviewing it, and multi-file diffs make that expensive. He mentioned experiments that reduce the load: AI annotating the change, diagrams instead of text diffs, even an audio summary of the dayâs changes, and the idea of an IDE that adapts itself to the task, such as reviewing a business flow. The far end is commit first and revert if you do not like it, which calls for checkpoints to roll back, and for access control: he does not want an agent that can change the tests so that its own code passes. Cost matters too, since he said $20 or $100 is fine but some people see bills of $1,000 a month from agents.
The manager role. With a DevOps background he compared it to the old wall between developers and operators: agents build, and you are asked to accept the deploy without having been involved. He expects developers to move towards an operator or manager role. His reminder from DevOps was that automation brings a need for tests, production monitoring and chaos engineering to keep skills sharp, so time saved in writing moves into verification, depending on your risk appetite. When something fails, he said, you still need to know which agent did what.
From prompts to specifications. Typing prompts one at a time is inefficient, so people move to reusable rules (naming conventions, directory layout) that work across tools, then to specification and requirements documents: a spec, a plan, then code. He cited GitHubâs Spec Kit, which describes itself as an open source toolkit for specification-driven development, and an AWS coding tool that offers a choice between vibe and spec; that is Kiro, which pitches spec-driven development. Specs can be extracted from existing code, so code and spec stay linked in both directions, which also helps migrations. A plan breaks a large requirement into smaller tasks, almost a backlog, because an agent cannot turn a Java app into a mobile app in one step.
His other point was that this is simply good engineering: consistent naming, documentation, tests and small changes with predictable feedback. Many companies, he said, are cleaning up conventions âfor the AIâ that they never fixed for humans. And a spec lets product owners and developers debate intent in a form that both humans and agents can read. He moved from prompt engineering to giving the right context, and then to specifying intent: for example, telling the agent which major version of an API you use, or providing the docs of a framework version the model has never seen. That is the same problem I covered in Context7 vs RAG for documentation retrieval.
Prototypes: where vibe coding does fit
This part was the most relevant to the room. Vibe coding has a bad reputation because you say yes to everything the agent does and cannot trust it, but he called it very good for product design: a product owner can build several variants, pick one, and learn from the result without waiting a month for a developer. The âyes, this one, no, not that oneâ review becomes a product decision. Users, security people and other agents could give feedback on the same prototype.
âFast working prototypesâ: the third step is modifying the generated app with Lovable.
He then described parallelism: several variations of one task, plus a backlog split into tasks that several agents run at once, with reviews on a phone, or an agent started from a ticket. His company uses Devin as an experiment; he does not see it used much for core logic, but developers gladly hand it documentation and extra tests. Another slide covered multi-agent observability, credited on the slide to the IndyDevDan channel.
Multi-agent observability, the slide for the point that you need to see what many agents are doing.
Knowledge as the last piece
The final theme was knowledge. Teams scatter it across code, docs, drives and tickets. He argued that agents see it differently from us, so structure matters, in the same way search optimisation shaped websites. Libraries could ship their usage knowledge as specs; production incidents and runbooks could feed back to agents and to new team members; and agents can save what they learned in a session and share it with other agents, which he called a flywheel. He said running ten agents with shared memory is possible but not production-ready, though already useful for exploring legacy code bases, as long as a human checks the answers.
On the future of the craft he stayed sceptical about full autonomy: he does not believe in auto-deploy to production with this technology, and expects that people want to understand what runs, at least for when it fails. Teams may not shrink to one person; solo working in small companies is partly freedom from dependencies, and bigger organisations still need collaboration. He closed with a Booking.com example, attributed to him: optimising not only lead time but how fast you can swap one technology for another. His advice to people entering the field was a choice: learn the basics deeply to know what good looks like, or learn to use the abstraction and build business value.
The next talk: Power Platform vibe coding
The second session was Albert-Jan Schot, with the title on the slide âPower Platform Vibe coding: Fusion Development in the AI eraâ. His slides said âLow-code (as we know it) is deadâ and âThe balance of expertise is shiftingâ, and charted low code sorted by technical expertise from âPro Devâ to âCitizen Devâ. I did not record this talk, so I have only the slides. Later slides were Microsoftâs: âUpgrading your operating systemâ with Copilot, apps and agents, and the line âReplace a patchwork of inefficient systems with intelligent apps and agentsâ. See the autumn roundup for the âAI bends the curveâ chart.
Low code sorted by technical expertise, from âPro Devâ to âCitizen Devâ.
My take
Patrickâs talk was aimed at developers and landed well with a low-code audience, because the two worlds are converging on the same bottleneck: review and governance rather than creation. The practical points I would act on are the same for a Power Platform team and a platform engineering team: write specs and conventions that agents can read, keep tests as the safety net, and put checkpoints, access control and cost visibility around agents before you hand them autonomy.
