Back in 2021, when I had made the leap from being a Dynamics 365 CRM consultant into a Power Platform entrepreneur, I wrote about the bigger picture of what was happening with low-code. The topic of the blog post was “Democratizing code”. Given what has happened to the concept of code in the past year, thanks to LLMs and coding agents, it was now time for the 2026 me to read and reflect on the thoughts of my past self.
The post-ChatGPT world is different in a way that I could not have imagined five years ago, but I’m not going to hold that against me. Practically no one saw what was coming and how that would affect the way apps are built today. Honestly, I expected there to be roughly a decade of the Power Apps era low-code development ahead of us. Yet things changed gradually, then suddenly, and now 2031 has arrived in half the time I assumed.
This one paragraph from my original post feels pretty accurate, though:
Be it the creation of content or apps, any model of manual governance and control that relies on A) the creators to follow specific rules and policies, and B) human editors/gatekeepers to enforce them, isn’t going to scale very far. Algorithms must be put into use. AI needs to be given the opportunity to help us in everything that goes into developing and maintaining great business apps.
Even at times when the Copilot fanfare from Microsoft has triggered my snark cannon, resulting in some mighty critical posts, I have remained optimistic that AI is going to be hugely useful for makers. I’m less sure about how well the autonomous AI agents meant for replacing humans in the operation of business processes will live up to market expectations. But when it comes to building new tools, LLMs are the tool I’ve always wanted.
The arrival of coding agents and the resulting generic information worker tools like Cowork are truly doing what was the prophecy of my article: they are democratizing code. In the recent Platformer newsletter issue, there was an interview with Boris Cherny, the creator of Claude Code. He talked about what the impact from his work has been on the non-programmers in the team:
The Platformer: Claude Code's creator on the end of the software engineer
“Everyone on the team codes.” This isn’t just about cutting away managerial layers that don’t add value. Or pushing designers to create working prototype apps instead of mock UIs. I see the shift being about the usefulness of code expanding to new areas of work. Because of the fluency that LLMs have on written instructions like software code, we no longer have to hide it away behind protective layers like cloud SaaS app GUIs.
Creating apps is easier and faster than ever. Yet simultaneously, having things locked behind a GUI is becoming increasingly harmful for the usefulness of data. Precisely because it’s an experience designed for humans and not an ideal interaction pattern for LLMs. Chat boxes and terminals have many similarities in how the human is expected to interact with them. Thanks to the power of local compute resources and tools, that is where an AI agent is at its happy place — resulting in a surprising resurrection of the 80s style terminal UIs (here’s a gift link to my earlier premium issue about TUIs).
For an LLM, it doesn’t matter if the files being worked on are TypeScript or Markdown. As for humans, there’s probably 100x more people out there who could read and write .md files compared to .tsx files. Once information workers become brave enough to touch something that looks a bit like code, rather than a traditional Office document, the barrier to introducing scripts to automate .md file creation and processing is no longer that high. And once you get to generating scripts via talking to your LLM buddy, it will soon suggest generating more and more advanced tools for helping you achieve your expressed goals quicker.
Then, all of a sudden, you are coding. But you aren’t exactly a programmer. This gets us to the same dilemma that my 2021 article talked about: what exactly do we call these people? With the rise of Power Platform apps and automations, it was becoming obvious how the term “citizen developer” wasn’t a fair description of the new roles forming around low-code solutions:
The amount of low-code business applications that organizations of all sizes in every industry will soon have in their hands means that we’ll see a growing number of employees working 100% on these. If low-code becomes your full-time job, you’re not just a citizen or a hobbyist. You’re a professional working with advanced technologies and complex processes. The only thing that separates you from the “classic” definition of a Professional Developer is that you don’t write much code (aside from things like Power Fx).
The only clear distinction I saw back then was “you don’t write much code”. Well, that’s not very helpful in the year 2026 anymore. Like Boris Cherny says, “everyone who's not an engineer is going to code a little more, and engineers like me are going to code less”. Direct review and writing of code might remain reserved for those with an engineering background. The other 95% of people working with code will use the abstraction layer of coding agents to do it. But the professional developers will be using that layer far more and burning tokens at a much higher rate.
So, we can’t simply look at the activities anymore. Code work is becoming something more like driving: knowing that you were driving a car today doesn’t help me deduce whether your profession is a taxi driver or an office worker that just did their daily commute on the highway. We travel on the same roads, even if our roles in the grand logistical scheme of things is pretty different.
The risks of vibe coding are similar to those introduced by features like Tesla’s “Full Self-Driving.” In theory, you could ride in the car while drunk, sleeping, or incapable of steering the vehicle, and still get to your destination safely. If things go wrong, though, the car manufacturer is not going to be paying for the damages.
Join over 4 million professionals who start their day with Morning Brew — a free daily newsletter on business, finance, and tech that's actually fun to read. Try it for free.
This leads us to the topic of whether the profession of software engineering is going away. I find it hard to believe that the total number of people doing software engineering would decrease anytime soon. Vibe-coding is a bad idea for probably most of the existing software systems we have in the world today. While you maybe could prompt your way to a small B2B sales CRM system today with no understanding of software architecture, doing something similar with an accounting system sounds a bit dangerous.
I feel the right point of comparison is not the existing software, though. Just like low-code wasn’t about replacing the Dynamics 365 systems with canvas apps built on SharePoint lists, the disruptive power of AI-generated code is not in eliminating SaaS subscriptions entirely. Low-code was often applied for replacing Excel workbooks. Vibe-code extends those same powers to scenarios far greater than 2D sheets of text and numbers on a digital Office canvas.
So far, the most interesting session from Build 2026 that I’ve watched has been from the creator of OpenClaw. “Build the thing that builds the thing” is a no-slides presentation of Peter Steinberger describing how he has addressed the explosive popularity of his project and what strategies have helped the small open-source team thrive.
Peter Steinberger, “the Clawfather”, presenting at Microsoft Build 2026.
“I find being annoyed is the very best way to solve problems.” Wow! I didn’t know Peter and I have so much in common. In case you haven’t noticed it from my community contributions, the vast majority of them are powered by sheer annoyance. There’s nothing quite like being frustrated with how things work (or fail to work) to give you an energy boost to do something about it. In the past, I could mostly just solve things via writing. These days, I can also create a repo full of code to solve a problem for me and others.
What fuels the vibe-code movement is not so much the efficiency gains of how to ship more software faster. Existing software projects and products will undoubtedly look very different in a few years time, yet it will still be about doing what was already being done. I believe the truly transformative powers are how AI helps democratize code that solves net-new problems. To build tools for problems that would have never been feasible to solve with code done in the classic way.
The creator of OpenClaw doesn’t just create more claws. In fact, the Build 2026 session was a demonstration of the incredible array of vibe-coded tools that Peter Steinberger and his team had created to help them focus on building their main tool (OpenClaw). His core claim is that the bottleneck is no longer just writing application code. It is building the surrounding loops, context, review, testing, triage, and UI automation that let coding agents work faster with less human babysitting.
Crabbox: remote software testing and execution control plane built around short-lived test boxes.
In the context of OpenClaw, the ways to reduce annoying manual work range from throwaway remote testboxes (Crabbox) to Discord user feedback aggregation (Discrawl) to capturing developer AI agent chat logs alongside code commits (Entire), all the way to building your own Slack clone for AI-friendly messaging (ClickClack). All of these have naturally been built purely with vibes and some AI agent prompting. Quite literally by just describing the problem in a prompt, letting the coding agents work on it, putting other agents in place to review it, and then the human comes back to see the final product.
This sort of hands-off development doesn’t suit each and every software project, of course. It doesn’t have to — because custom software no longer needs to be a project. Sometimes you are merely solving a problem for yourself. What used to be limited to personal productivity canvas apps or cloud flows can now be applied to almost any form of output. If you’re annoyed enough and you can work with code (not read or write it), today there’s not much stopping you from generating a solution you personally like. It may be software for the audience of one, for your team, or for anyone who finds your repo on GitHub.
As an example, I have been very much annoyed with the experience of sharing slides online. Ever since LinkedIn bought SlideShare, then Microsoft bought LinkedIn, and then they sold SlideShare to Scribd, there’s been no decent alternative to the enshittified experience of the original site. I wanted to migrate my deck history away from there, so I built ShareSlides:
“Annoyance-Driven Development” presentation on my ShareSlides site.
It’s simply a place where .pptx and .pdf decks can be published as more than just raw downloads on GitHub. Now, the actual site does run on GitHub Pages, so technically the files are there. This vibe-coded app of mine just offers the viewing, sharing and embedding features that we learned to expect from online presentations, thanks to what SlideShare launched 20 years ago.
Slides aren’t what they used to be, of course. Today, we can easily generate interesting visual summaries from any online content, using services like Google’s NotebookLM. As an example, this Annoyance-Driven Development deck is based on what Peter Steinberger presented at Build. I picked the .vtt transcript file and asked my Codex to summarize it, then handed it over to NotebookLM to focus on that key concept that I found so compelling. And now it is shared on a site running on software built from sheer annoyance.