Last week, I wrote about uncomfortable truths concerning the imminent crash of the AI bubble. One of those uncomfortable truths is that software quality is likely never going to get back up to pre-AI standards. I want to dwell a bit on this insight, because I believe that we are losing a lot of quality and amazement through this change.
This article is partially a response to two opinion pieces, one by John Gruber, and one by Jason Snell (because the former quoted the latter). I feel compelled to write these lines, because I value the opinion of Gruber, but I feel that he is starting to lose the plot. And the original piece by Snell which he quotes, makes some good points, but also suffers from a few fatal misconceptions. Also, this is a general trend that I am observing, and which I find worrying.
To set the stage, I believe there are three core pieces to how we perceive a piece of software: its aesthetics, its functionality, and its user experience. And all three of them are affected by vibe coding. I believe that we are witnessing the rise of what I want to call “slopware;” a form of software that works and is maintained, but that has a certain lack to it.
Slopware can be distinguished from a bunch of other categories of software. First, it is not “abandonware” — software that is still available but hasn’t seen an update in about a decade. Such software will at some point typically just fail, but it is not slopware. Second, it is also not the classical “open source” software, such as LibreOffice or Gimp. Such software either looks bad or is notoriously difficult to use, but when it works, it works flawlessly. We all probably have a love-hate relationship with such software in that we tend to use it from time to time, and it will do what we need it to perfectly, but we will yell at it for being so cumbersome to use. Third, it is also not “corporateware” (I don’t know if this is even a word) which is primarily defined as being developed and marketed towards companies. These are not programs intended for personal use, but rather for use in companies. Think CRMs (Customer Relationship Managers), or Microsoft’s Active Directory. Those pieces of software are horrible to use, but again, this has nothing to do with slopware.
No, slopware is a piece of software that is actively maintained, targeted towards average people, looks amazing, and does what it says. But barely so.
Vibe Coding Native Apps
Slopware has only become possible thanks to AI coding agents. It is the antonym of vibe coding. It is what happens if someone with no understanding of software development makes an app. Slopware is the creation of an artist that has been told by too many sycophants that they can become anything if they just try hard enough.
I’ve seen an argument being used more and more often in the past months: the ability of AI to help people with no coding-experience make apps is great. This argument has been beautifully condensed by Snell: “We now live in an era where, if you can dream an app, you can probably build it.” But while Snell and, by extension, Gruber, think that this is a great thing, I believe that they are horribly, horribly wrong.
Snell’s argument goes like this: When someone who does not know how to code use an AI agent to have it write a piece of software, they essentially become a “product manager.” They don’t know how the app works, but they know what it should do, and they start iterating with their agent until the app works and does what they want. And then they release it to the public. He does confine this argument particularly to utility functions; small programs that all should just do a single thing, and nothing more. He believes that this is fine, because it still requires human brain power to envision the app and describe it to the agent. It includes discovering that some piece of the functionality is more difficult than anticipated, and having to think about how the feature should work in detail. After a few days of such back-and-forth, however, a fully working app is born. The “product manager” can then go through all the formal steps of making the app available to the public.
What is lacking from this argument is maintenance. Sure, AI agents can write an app, and it will work. But what happens in, say, six months from now? A year? Where is this software in a decade? Of course, if a user describes a bug, you can just throw the bug report at your AI agent, and wait until it has found and fixed it. Then you test it out, see that it works, and release an update. If someone wants a new feature, you again throw this at the agent, elaborate on particularities, and wait until that is implemented. Then you release another update. But here’s the issue: none of this is maintenance.
Vibe Coding is not Maintaining Software
If you haven’t consistently maintained any piece of software used by more people than your friends for at least a couple of years, you do not know how software development works. Period. I’m not going to argue on that. If LLMs allow you to write a piece of code, that’s cool. But unless you maintain it successfully for a few years, you don’t know what it is like to maintain software.
Because here’s the thing that Snell ignores: The rat tail of maintenance. All the arguments I have seen online in favor of more vibe coding, and the “empowerment of non-coders to write code” stop after the first iteration. They do not think about the needs for ongoing maintenance of tools. A lot of vibe coding tutorials walk you through how to set everything up, and how to interact with your agent, and give you step-by-step instructions until the app is ready for release. And then they stop.
Nobody talks about the countless hours of boring, frustrating maintenance work that follow the initial release. Who should use your app? How can they tell you if they found a bug? What if they have an idea for a feature? What do you do if someone emails you with a zero-day exploit in your app? What happens if your website goes down? Or, worse, what happens if your website or repository becomes target of malware? How can you ensure that existing features do not break? How can you reduce the amount of work to do for every individual release? And the list goes on.
Maintaining software is hard, and no coding tool will be able to help you with that. Because maintenance has little to do with code. Many senior software developers are laughing whenever someone tries to sell them the benefits of vibe coding. Because they know that 90% of the work of software developers is not actually coding. The stuff that your little coding agent does is only 10% of the total work required for a great app. All these chores are conveniently left out of the equation when someone tries to sell you generative AI.
This is the first big fallacy that both Gruber, Snell, and many other vibe coding enthusiasts make. They focus on what works (the initial prototype), and leave out what makes the work actually annoying, but the user experience great.
Empowering people with little understanding of the organic growth of an app into a big maintenance project to “just start coding” will lead to many, many small tools that all are simply dissatisfactory to work with. They won’t work well on computers other than the one the creator uses (a typical “works on my machine” fallacy), they will have odd bugs to work around, and while they generally work, they leave you with a feeling of “meh.”
However, there is a second, even bigger problem with Slopware. It’s not just that it essentially just serves as the minimum viable product with no aspirations to become great. Such software also lacks in terms of User eXperience, or UX.
Vibe Coding Is Not UX Design
If you haven’t heard this term before, don’t worry. UX is a bit like salt in your food: you only realize that it’s important if it is missing from one of your dishes. As long as the salt is adequate, we don’t think about the fact that there’s salt in our food very often.
And the people who do UX — UX designers — are a bit like drummers in bands. They are essential, but extremely rare creatures required for any band project. And if you happen to find one, they are typically already overcommitted with four other band projects.
UX designers’ task is neither to make sure that an app is bug free, nor that its basic functionality works. Their task is to ensure that people who use the software can actually use it; that its layout and buttons make sense. User experience is the craft of understanding who uses a program, how they use it, and how to ensure that the tool works as frictionless as possible. That’s why it’s easy to overlook UX: If it’s done properly, we don’t even think about it. Only in those instances where it is missing do we actually realize that someone should have probably thought about it.
Just one egregious personal example: Last week I had to get in touch with the folks at Mistral AI, because we needed a quote for API access for a research project, and I was tasked to contact them. So I went onto their website and saw a contact form. However, that was only limited to 500 characters, and my use-case was a bit bigger. So I started searching for an email address. In the footer, there were a bunch of links to their privacy policy, help center, and others.
So I clicked those links. But one after another led to a 404 error. Privacy page? Not found. Imprint? No luck. I was shocked to see that half of the links on the page simply didn’t work — especially those that are mandated by law. But alright, I’m not a police officer, I just need to email them. So I headed back to the contact form. I inserted my name, email address, subject, and a short message.
Again, as I mentioned, the message was limited to 500 characters. Fine, so I’ll be brief. With the character counter sitting at 495/500 characters, I hit send.
“Message is too long. Please type at most 500 characters.”
What?!
I hit send again.
“Message is too long.”
Okay? Maybe the character counter excludes spaces, but the form includes spaces in its validation? Mh, let’s delete a few.
Now, the character count was at 450/500 characters, and I hit send.
“Message is too long.”
Is this a joke?!
So I remove more text, condense everything even more, rephrase sentences, search for shorter words, and do a lot of gymnastics to reduce the message length. It was an iterative process: Remove some characters, hit send, get an error, remove some more, until, after a dozen attempts or so, it finally went through. The “official” character count was about 250 at that point.
My current theory is that they intended for the form to allow a 500 character body, but that they accidentally added a validation function that concatenates everything and then checks the entire text length.
I am mentioning this experience — even though it was with a website, not an app — because this is the epitome of what I mean with slopware. This is exactly what will happen more frequently going forward. It kind of works — you can contact them — but the signals are all messed up, the website is lying to you, and you have to trial-and-error your way through trying to get to them.
And that’s in a case where I actively wanted to give them money. Ten years ago, we would have said “Well, apparently you don’t want my money bad enough. I’ll go to a competitor.”
But there are no competitors. I mean, there are, but if you want to keep data inside the European Union, there are none. Same with coding. If you want a beefy coding agent, you go to Claude Code. There are no worthy competitors.
Market consolidation and monopolization are fun, aren’t they?
Unfortunately, this is something that we will see more and more often. Because even if AI coding agents can write functional code. What they don’t have is hands, eyes, and an intent. They cannot account for the experience of users using the app. They cannot use the app like a human, because they lack our bodily experience. Agents have no eyes to see if the buttons are placed correctly, and they have no hands that move a mouse and see if they can do their task efficiently with the app.
When someone cares about an app, they will try everything out themselves, and initiate changes where necessary. But if you didn’t write code yourself, how are you supposed to know which new buttons have appeared after the last iteration? It is very easy to miss a new button that your AI has added, not test it, and see your users struggling to use the app.
Why I am Disappointed By Gruber
This leads me to a final, somewhat related point I want to make, because I had been thinking about this for two weeks at this point. When Gruber linked Snell’s article, he added his own thoughts. To quote:
I’ve been concerned for years that the biggest problem the Mac faces is that so many new apps for the platform weren’t Mac apps. The Mac has never faced a decline in popularity, but truly native Mac application development (and the skills) did. Now it’s turning around. Mac users are thirsty for Mac apps, and with AI, they can quench their own thirst and tell the dullards promulgating Electron bundles to pound sand.
This shows an overly simplistic idea of software development from Gruber. Essentially, he assumes that anyone who vibe codes a Mac app is caring and wants to improve their apps. This is a very optimistic picture of the average vibe coder. I mean, good for him, but nothing could be further from reality.
And, even if we assume for a moment that every vibe coder vowed to work tirelessly until their app is great, there is still maintenance and UX design. It will be very hard to secure such apps against malicious actors. They simply don’t know what to look out for. And even though SwiftUI makes it very hard to deliver gruesome UX, we can see with some first-party apps from Apple themselves that this is not an automatism. Remember when Apple redesigned macOS’s system preferences to align more with iOS, and everybody hated it? I believe even Gruber mocked Apple for that.
Neither maintenance nor UX design will come automatically from vibe coders. You cannot just be a product manager. You do need to get your hands dirty with a lot of very boring tasks to ensure your app thrives.
Which brings me to Gruber’s obnoxious hate for Electron. To be clear, I agree with him. Almost to the day five years ago, I commented on a post from Gruber from 2018 and agreed that a lot of Electron apps do not care about Mac-native UX. They are big, bloated, and less efficient than they should be.
But Gruber’s thoughts on Electron seem to stop there. Currently, his opinion on the Electron vs. Swift debate appears to be “Electron bad, Swift good” — completely detached from any context. This makes it a good hot take (see how long I’m commenting on it!), but a hot take is typically not a good one.
So I emphatically disagree with him. Because it is indeed possible to write an Electron app with a better overall UX than some “native” Mac apps. And back in my article five years ago, I outlined a lot of relevant reasons for why to consider using Electron, rather than Swift. Just because an app is written in Swift does not make it good. And we will see an avalanche of very bad, vibe coded apps in the next few years. Let’s see what Gruber thinks about “native” apps then.
Final Thoughts
Slopware is going to have a very bad influence on the general perception of software. It will take the generally bad UX typically reserved for enterprise software, and make it available to the masses. And I think that more vibe coded native Mac apps can easily backfire for the popularity of the ecosystem. Because most regular users don’t care if an app is written in Swift or Electron. They care if it works.
Apple has been known for well-polished software, and with the current announcements for macOS 27, it seems that the company agrees. And good user experiences requires a lot of human thought. But if most of the software that people interact with on Apple devices is mass-produced slopware, what will users think of Apple? A UX-focused company, or a swamp full of mediocre apps?
I do hope that slopware will not drown out carefully designed apps, but I am not too optimistic. We’ll see in five years.
- Gruber is concerned with apps that seamlessly integrated into the Mac platform, but at the same time confuses form with function.
- While I agree in principle with the fact that Electron apps are less-than-desirable, he ignores any type of context of surrounding reason for why developers might sometimes have no choice.
- Writing a native Mac app ≠ writing a good Mac app.
A few years ago, Gruber complained about the rise of Electron apps all around. And I agreed with him. Electron is big, bloated, and if you have Google Chrome, Discord, and Slack installed on your computer, you have the same web browser installed three times. That’s not really efficient. And Electron apps have the reputation of being bloated and sluggish. I have outlined my arguments towards Gruber’s disdain with Electron elsewhere. And again, I agree that a lot of Electron apps do live up to their reputation.
But here’s the thing: Just because something is based on Electron doesn’t mean it’s bad. I have made damn sure that Zettlr is as fast as it can get, as small as it can get, and feels as native as it can get. Because that is easier than writing a Mac-native app. If you’re a free-time open-source developer with a regular day job, such as me, you simply cannot write an app using Swift. Because that would leave out about 70% of your user base. It is impossible for me to maintain three separate code bases, and offering an app exclusively on one platform is just not feasible.
Gruber apparently has started to base his opinion exclusively on the form of an app, not its function. For him, it doesn’t matter if an app tries its best to be lean, fast, and well-working. It only matters if it’s written in Swift or Electron. But writing a native Mac-app does not imply that the app works well. Slopware can be in perfect native Swift, and still work atrociously bad. Just because your app uses Liquid Glass does not mean that it does its job. But at the same time, just because the framework your app uses is a bit overengineered doesn’t mean you can’t make great apps with it.
And this is the overarching problem I see with this type of argument: It confuses form with function. The form of an app (native vs. Electron, simple vs. complex) does not matter, if its fundamental functions are just broken.
But again, I do believe that slopware that focuses on form, and not on function, will slowly become the norm. Our tasks will become less efficient, and we will spend more time in front of computers because the goal of slopware is not to go out of your way to enable you to perform your tasks. Its goal is to look shiny and provide some clout to some tech enthusiast with a Claude Max subscription.
Final Thoughts
Now, this article was very heavy-handed in its arguments. If you are a software developer who uses AI tools, none of this was directed against you. If you are someone who cannot code but who deeply cares not about publishing an app, but to be helpful to other people by providing a genuinely useful function, none of this was directed against you.
But the problem with human society is that there are so many people (likely none of which will read this article) that don’t care about any of this. Who don’t think UX is relevant, that maintaining software is irrelevant, and that all that matters is that they have done something they could not have done before.
We are entering a new age of software, in which the functionality of software will slowly degrade to a degree that it works just above the absolute minimum, but where we will have hundreds of well-looking apps. We will have more and more, smaller and smaller apps installed on our computers, that all do something slightly different. Instead of focusing on what we need to do, we will focus on what app will have the least amount of bugs for the task we need to do.
Slopware will slowly lead to the death of function, and usher in the age of form. Recommended reading after this: Guy Debord’s Society of the Spectacle.