What’s the point of low-code anymore when AI code-gen is now possible? That is the most burning question that was present in most of the discussions at the Update Days Power Platform 2026 conference in Prague this week. More specifically: how can the professional developer audience working with Power Platform tools and technologies answer that question when customers or developers outside this ecosystem ask about it?

This week’s newsletter issue is my travel report from the Czech Republic as I infiltrated the programmer crowd and tried to assume a code-first way of approaching Power Platform topics.

I had two sessions at UDPP26, one about licensing and the other about inventory. Traditionally, this would have meant a lot of intimate moments between me and PowerPoint. Given how I had recently explored the five ways to use Copilot in creating PowerPoint decks, I should have been well equipped to improve my efficiency with the latest AI tools from Microsoft.

I chose not to choose Copilot. I chose something else:

Slidev is what the software developer audience has been using to create presentations for some time now. Reasons for its popularity have been how slides can be created and edited as Markdown. Furthermore, since the presentation really is just a web app you run locally with a command like ‘npx slidev licensing-session.md’, you can embed HTML and all sorts of Vue components in your slides. Or even a live code editor.

As Markdown has become the universal language of LLMs, this made it very convenient to work on the presentation contents with the help of AI buddies like Codex Desktop or Claude Code CLI. Storing all my research and reference materials in a folder meant that I didn’t need to try and beg a Copilot chat to do rewrites of my PowerPoint presentation. Instead, I was able to iterate on the .md files in a near-seamless way. Obsidian was my UI for viewing and editing the files, Codex worked behind the scenes, and the browser showed what the deck is going to look like.

I didn't settle for launching my slides from VS Code. I also created a number of demos to show how API data sources related to Power Platform licensing or inventory can be used by a vibe-coder like me to create pretty nice reports and tools. I’ll need more time to unpack everything that my UDPP26 workspace consisted of since I had to run through them really fast to stick to the session schedules and it’s all a bit blurry even for me.😅

All of this would have been impossible for me one year ago. It’s not just about the models becoming more capable in agentic coding scenarios. I’ve personally had to invest quite a lot of time in experimenting with how they can be put into use — not to mention learning the bare minimum about all the pro-dev tooling that has not been relevant for me during my first two decades in the MS BizApps ecosystem.

If I think about the many power users with whom I’ve had the pleasure to work with during the past few years as Power Platform went mainstream and empowered citizen developers everywhere, the setup I’m now using isn’t necessarily ready for them yet. Despite being a low-coder myself, I am not a citizen in the sense that this would be a side gig for me. For people who want to replace Excel and email based business processes with better tools, doing things from pure custom code would be quite a leap.

Yet most of them surely are already exploring ways to escape the sandbox of canvas apps and cloud flows. The very same individuals who weren’t afraid to learn Power Apps will surely look at app builder tools like Lovable, or simply prompt ChatGPT to give them code to run that solves the problems Power Platform isn’t flexible enough to solve. Not to mention those who never tried Power Apps and only discovered the joys of building apps when the era of GenAI began.

You can’t stop the vibes. Just like low-code development became an official thing, generating new tools by prompting a large language model is what a growing number of people have experimented with. They’ve seen results from it that were previously in the category of “someone else has to build this”. Now they are building it themselves, and that’s where bottom-up movements like citizen development get their juice from.

Scott Durow took the lead in a panel discussion about the future of low code vs vibe coding where I joined Diana Birkelbach and Rami Mounla to talk about what’s actually happening out there. I was the only panelist without any formal education or experience on classic software development, which of course fits my natural tendency to challenge the existing norms and be vocal while doing so.😁😁

The power users of business technology must have often felt like an underdog, in comparison to those who worked on building the tools for the users. They knew roughly what should be done, yet there was a barrier of projects, funding, specification and all the drudgery that stood between their idea and the outcome. Often the end result from all the hard work didn’t live up to the original vision since a lot was lost in translation and scoped out as not fitting the budget or schedule.

DIY business tech no longer means sticking to Excel monstrosities or buying shadow IT SaaS apps with a credit card. On the surface, real software is becoming indistinguishable from vibe software. It will not only place mounting pressure on the solutions that are constructed by software development professionals through formal project work. It also leads to a mountain of disposable apps that has been built either to validate an idea or to address a one-off need.

The way I see it, and the way I expressed this in the panel was: most apps should NOT BE BUILT to begin with. We are already lacking proper conceptual separation between an app that is built as mobile forms over a SharePoint list or a full line-of-business CRM system. Calling them all “apps” is just plain stupid, yet somehow we’re stuck in the word presented in Apple’s commercial from 17 years ago that positioned “there’s an app for that” as a good thing. Shouldn’t this already be like “you’ve got mail” by now — as in a problem that needs a junk filter? Will AI-generated throwaway apps become the 2020 equivalent of spam pretty soon?

Every presenter and attendee that I had the pleasure of talking with at UDPP26 was fully aware of what risks there are with going all-in on AI-generated code and letting the LLMs run on autopilot. Professional software developers seem to not be under the illusion that just because Claude Code can work with code, it would be smart to just let it do all the work.

No one dares to say you should not use AI for anything code related, though. Because of the recent advancement in frontier model capabilities and the AI coding agent harnesses, many devs are coming to terms with the fact that LLMs are now better at many things they used to do by hand. The focus has therefore shifted to what kind of an environment and tooling is needed for making coding agents scalable and sustainable in the context of business applications development.

Every demo in tech conference sessions is now supercharged by the computer doing things on its own, based on guidance from its human master. This is what allows folks like me to not just talk about available APIs in theory but rather show how they are turned into tools and reports with a few simple prompts. It is the area in which using AI coding agents is relatively safe, too. Working in sandbox tenants, using demo data, running on throwaway cloud infrastructure. There’s no excuse anymore to not show real code in operation.

The risks are also greater than ever if we forget the simple fact that for LLMs, every payload is the same. There’s no separation between instructions and data, no matter how much the vendors build different kinds of shields and layers to hide this. AI coding agents go through massive amounts of text, code and data in the blink of an eye. When malware today is simply plain text that convinces the model to do something the user would not want it to, it can be found anywhere. It may already be in your inbox, or public websites, and you’ll only discover it when the agent ends up reading it.

Gullibility of LLMs is what makes prompt injections a serious threat. Yet another feature of modern GenAI that may be seen as positive, their persistence to solve problems, can turn into problems for especially software developers. The latest models are incredibly creative in searching for ways around locked doors, such as missing tools or authorization to perform the action driven by the original prompt and the thinking steps that AI put together in its planning phase. Where there’s a will, there’s a way. Unsupervised agents will attempt to escape their sandboxes, modify their own settings, snoop around for available keys, and in the lack of a specific tool build their own version of it on the spot — just to reach the goal they were given, or what they interpreted to be the implied goal.

The dev community, both in Power Platform and in general, is today at a point where there are very few proven patterns and practices available for safe and reliable agentic AI usage. This means there’s a huge demand for guidance and experiences that can be shared within the community, and events like UDPP26 are very much needed to provide a platform for critical thinking and real-life examples to offset the breathless AI hype in this industry.

As the act of building new apps from code becomes the easy part, the value of managed platforms needs to be found from other phases of the application lifecycle. Meaning, what happens around the app that has been generated with your AI tool of choice. Ultimately, that is where the right answer to the “why Power Platform” question has been found already before. People didn’t choose canvas apps and cloud flows because of their superior experience and flexibility in building new things. They always had other reasons.

I’ve been saying how all new software products, be it from Microsoft or others, always start with the “Create New” path. Sometimes they never even mature up to a point where the “Add To Existing” user story is completed. That means they’ve failed to reach a level where meaningful, lasting business value is realized. Because building net-new things with no legacy and no dependencies is always the fun part. The hard part is in fitting these new creations with everything that already exists. Or better yet: building up the missing capabilities that are needed before the technology can be taken into production use.

With the Power Platform, it’s all there already. The technology stack that has evolved from the early on-prem XRM days twenty years ago into the MS cloud services we see today when opening different portals is what makes the apps business ready. For any organization that needs to pass IT audits, for example, the answers are already in the platform. Not as something automatically applied and implemented without any customer effort, but rather as enterprise-grade tools that can address all the typical questions an auditor might have.

I started working on Power Platform governance topics on a daily basis six years ago. Back in 2020, there were plenty of gaps in the story that didn’t have an easy answer, let alone documented best practices. It all had to be built — and it was. The experience of how you work in the Power Apps canvas studio hasn’t radically changed since then, whereas the tooling and features for how you deploy, manage and secure the solutions has gone through a radical transformation. It has earned the trust of IT decision makers and professionals on the customer side, as well as an ecosystem of partners and the community of makers.

All of this doesn’t just magically become irrelevant the moment a chatbot learns to output the source code for a nice looking React app. Code on its own is just a liability, unless you have the processes, platforms and tools to make it operate safely and reliably in the context of an organization that the solution is designed for. Frontier labs like OpenAI and Anthropic will surely claim to have all sorts of programs and models for making their products ready for business use. We all know by now how easy it is to vibe-code a product concept and a fancy looking website, though. Talk is cheap, real governance capabilities ain’t. Especially when the majority of the value in Power Platform today comes not from software features but from how the people working with it have established processes and accumulated competence around it.

AI will force the low-code community and platform vendors to change their ways of working, of course. Not everything that we used to build makes sense anymore, and a lot of what is needed for AI coding agents to be productive with Power Platform is still either missing or WIP. The choices that Microsoft will make when trying to navigate between tech opportunities, customer demands and market pressure will undoubtedly result in a growing list of dead features that are technically not deprecated but in practice no longer developed (ever).

What surprised me the most after spending three days at UDPP26 was how I did not experience AI fatigue at all. Despite the tech being present in nearly every discussion, there was no one forcing an AI product on you. Even from the Microsoft representatives at the conference, you wouldn’t hear anyone push Copilot for the sake of Copilot. It was almost as if AI was becoming closer to just normal technology that exists in our lives, impacting what and how we do with our computers, yet not being a goal in itself. It made me increasingly optimistic about our industry moving beyond the hype phase and towards a more pragmatic discussion on what works, what doesn’t, and how to move forward together with AI without abandoning all that came before it.