There’s something in the air that reminds me of the early days of the internet.
Back then we found ourselves with the possibility and opportunities to make things that we couldn’t do before, to have something of ourselves present on the world wide web. Most of it was rough and ugly, certainly. Nonetheless, it was there for people. GeoCities pages with weirdly tiled backgrounds, flashy animated gifs (horrible flashbacks to the dancing baby aside), and hand-coded HTML were common. People were spinning up Angelfire sites, creating journal pages and blogs that barely had any visitors. But people were building their own space on the internet, whether anyone else wanted it or not or thought it was necessary.
The creation was the fun and exciting part, and the chaos of it all was part of the appeal. Looking back, albeit tentatively with rose-tinted glasses, there was something truly exciting about that time. The barriers for entry to create something, perhaps a bit messy and personal, were lowered.
Something similar seems to be happening now. Not for publishing but for software. Those same barriers to building something have been lowered in a different way. More significant and harder to categorise. Some of it is noise, some others are interesting, but a good chunk of it is also causing real damage to the wider ecosystems of the web. Parts of those were already fragile and some of the damage is already done in irreparable ways.
But the parallel only goes so far, and where it breaks down is the part worth thinking about and discussing.
Without AI lowering the barrier to creating software and tools, whether you want to call it AI-assisted code or vibe-coding, many people including me wouldn’t be able to build many of the things that we’ve built in recent times. Even going back just a few years ago, if i wanted to automate a repetitive task in my role i’d often have to create a ticket to my IT team or developers and hope that they think it’s within their bandwidth or is worth building. Now, i can simply fix this myself or create workarounds using something like Claude or Codex.
In just the last year alone, i’ve built tools like a Raycast extension for Lunatask, a tool built just for myself but was encouraged to add to Raycast. I also released a media plugin for Thymer after being requested to do so by other early adopters of Thymer, and many more tools specific to my job from dashboards to userscripts. Even Wayward, this site, has been created with the help of AI. I’ve even written about using Cursor as a non-developer.
The truth of it all though is that none of these things are clean from a coding perspective. It would be an understatement to say that they wouldn’t survive two seconds in the hands of a real developer. But these things do what i need and fit my requirements. There’s no blog theme, framework, or template out there that could incorporate everything that this site alone does and in the ways that i wanted it to.
What i keep noticing is the difference between software that fits and software that almost fits. Almost-fitting software works — after all you can use it and get things done with it. But there are always bits and bobs that you wish worked differently, that could work in this other way but just aren’t built that way. You instead build habits around working around those things. But building something for yourself means less of those things and more of the ways that things work for you.
There’s a principle espoused by the IndieWeb folks:
Back when the IndieWeb was starting to take off in the early 2010s this was a great idea, but a limited one. Realistically, this was only available to people who could code — actual developers. These days that’s all changed.
Now you have apps such as the recently launched Glaze by Raycast, which lets anyone build a macOS app by describing what they want in natural language. Apple introduced natural language Shortcuts creation through Apple Intelligence at WWDC this month. Not to be outdone, Google’s Android equivalent lets you build custom home screen widgets the same way.
The landscape and tooling is changing. It’s moving from “people who can code can now work faster” to “anyone with a clear idea of what they want can build something.” Now, more than ever, that IndieWeb principle is reachable for so many people.
Fabien Girardin traces the underlying idea back to Ivan Illich’s 1973 concept of “tools for conviviality” — namely that it is meant to empower individuals to shape their own technological environment.
For the longest time in software, you were beholden to commercial software. You adapted yourself to the tool. Your workflows, processes and habits moulded by rigid software. Now though, the direction of this relationship is changing and it feels like a watershed moment.
The same freedom and opportunities to build things and create code that AI has opened up has also created real collateral damage in shared spaces.
Daniel Stenberg, who maintains curl, for example has shut down his own bug bounty program after seeing a wave of vibe-coded bounty submissions.
That’s not to mention the multitudes of other open-source software and projects that have been inundated with AI-coded pull requests, often submitted by people who come with good intentions but do not understand the code that the AI has written. In the self-hosting communities that i often lurk around this has become more and more of a problem, and it seems the solutions are for the time being just bandaids to the larger problem.
For example, GitHub is now building rate-limiting tools specifically to help maintainers throttle the volume of outside contributions, which is quite the thing to have to build into a platform that hosts most of the world’s open source software.
The larger problem is one of imbalance. While the cost of creating code and building software is easier and cheaper than ever before, it has become an excessively expensive burden for developers and maintainers.
The AI-assisted code being pushed in PRs can look right — plausible structure, the right language, the right variables — but may just not do the thing it is meant to do. The person who submits it often doesn’t know that. For all they know, the AI generated the code and it worked on their side, and that’s that. A maintainer going through a backlog of AI-generated PRs can’t afford to carefully work through all of them to figure out what the submitter meant to do. The vast majority of the time the submitter can’t even answer the questions needed to figure out the code.
You can look at the mass PRs that some users are submitting to a myriad of open-source projects and look at it cynically — they’re just interested in filling their GitHub contributions graph. After all, it does look good for recruiters, especially if it’s notable open-source projects. The AI makes it supremely easy to generate these PRs across all those projects at once.
But it is the maintainers that get hit the hardest. The cost of producing a contribution has dropped to near zero. The cost of evaluating it has stayed exactly the same as it always was.
There are arguments for making a distinction between the different styles, or methods, of AI-assisted coding. Simon Willison, who published his own thoughts on vibe-coding, also wrote about what he considers to be vibe-engineering — where experienced people use AI as an accelerant while staying accountable for what ships. The difference is know-how and ownership.
The PRs and submissions in the open-source community are clearly on the other side of that spectrum — vibe-coded solutions sent in by people who don’t understand them, to projects they don’t really understand either, trying to fix problems they barely understand or verified exist.
The distinction that matters, for me personally at least, is the one between building for yourself and sending something into a shared space. When your AI-generated code stays only on your computer, works for your specific workflows, solves your problems, and you’re the only person who has to use it or maintain it, the quality of that code is set entirely by you. If it works, it works. If the building blocks of this AI-generated mess make sense to you, that’s fine. There is no consequence to any of this except between you and whatever it is you have built. That’s the spirit of the IndieWeb, and a great one at that.
It has also been my experience in recent times. Some, if not most, that i’ve built have been entirely personal. Specific tools i use and workflows that only i need. Solutions that i created, however messy, for my own needs. Others though ended up being shared because people asked for them. The Thymer media plugin for example exists because it was an early plugin created for Thymer in its alpha testing stage and others wanted to see how it could work. Releasing it publicly was never the goal, and i made it clear it was not something that would be maintained.
For solutions i create for myself though, there is no need to consider any maintenance. Either i update it when and as needed or it stays as is. There are no bug reports or feature requests to entertain. Therefore i don’t feel the weight of having to fully understand what every part of the code does or know what parts work. What i won’t do is release something into a shared space and then go silent when it doesn’t work, or be unable to explain what it was supposed to do. It’s not a high bar to clear. But it’s a bar.
The moment you commit that PR or push a package to a shared space, you’re asking someone else to look at and go through your output, and spend the time to understand it, even if you don’t. When you can’t explain what the code does, debug a problem someone else found with it, or can’t truly own the output, then you’re pushing the cost of dealing with this on to someone who didn’t choose to take it on.
Eric Ma wrote about this earlier in the year, having spent weeks undoing and untangling the AI-assisted work he had created in just 48 hours of vibe-coding.
His arguments ring true — the whole situation was able to be resolved because he understood the architecture, how to refactor, and how to truly test it. For personal projects, you can skip some of these things. When it’s something that goes to a shared space though, you can’t, or you’re asking others to pay the cost of fixing the issues you’re introducing.
That comparison to the early web though? This is where it breaks down, hard. In the late 90s and early 2000s, the barriers that were lowered were publishing. Building your own Geocities page was entirely self-contained, it only really affected the person who built the site. Nobody’s machine crashed because your GeoCities page had over 50 animated fire gifs.
Software is different though, because software has dependencies, needs code-reviews, has shared spaces, and side effects. When you lower the barrier to publishing a webpage, the damage is near zero. But when you lower the barriers to producing code and submitting it somewhere, that’s when the damage has a blast radius. It’s now transferred onto others who have to go through it in their review queue, go through tests, and take up their time. None of this happened with your GeoCities page though.
The chaos of the early web was contained by design. This isn’t.
In the end, despite my perhaps seemingly gloomy take on the woes of AI-generated code, i am still excited about where things currently are and where they’ll be going. The early days of the web managed to resolve itself. Perhaps not as we all wished it would, but it did. Web standards became a thing, platforms emerged and consolidated, and some of those Angelfire pages became real longstanding websites while others just quietly disappeared.
I don’t imagine this will be any different when the dust settles on this AI revolution.
The personal software angle is still what piques my curiosity and excitement. The IndieWeb principle i mentioned at the top isn’t new but remains ever so relevant, and for so many more people than ever before. But i think it’s important to always keep considering what you do with it.
My thoughts still linger around this topic, particularly on the notion of what to do when you’ve published or released your AI-generated projects. We’ve had abandonware and vaporware in the past, but the proliferation of AI-generated software is unleashing an altogether different problem — one that i’m still getting to grips with, and perhaps worth a different write-up.
For now though i’m still going to build things for the perfect audience: me, myself, and i.