AI
- Who can release open-source software (OSS)?
- What do we require from someone releasing OSS?
- What can the OSS developer expect from others?
- Vincent Ritter put together neat API documentation for Micro.blog at microblog.dev. I’ve been working on my own client so this came in at a very good time. I’ll report on my new client some time in the future.
- The new client I’ve been working on has been vibe-coded, which brings me to this new site for the Outcome Engineering Manifesto. It lays down some very sensible ground rules for deliberate coding with agents, emphasizing techniques such as measuring, prioritizing, and risk management.
- Matt Web which may be hyper-specific to the creators' needs. I think that’s a great point, for I certainly wouldn’t have started creating my own blog client without agents, but now I can customize my writing experience just the way I want. It would indeed also be just nice to get a picture of what people are building, by following a single source.
- Finally, the comic relief: OpenAI reports how their models became overly fascinated with goblins. 👺
- My former colleague Robert turned out to be quite a penman. He wrote a cool short sci-fi story called Null and void and published it in his blog. Check it out!
- Darwin Awards collects events where people have removed themselves from the gene pool by doing something stupid. The history of the site goes back to the 1990s, so you may have heard about it already, but this year they’ve got a new category for AI Darwin Awards. This new category honours the visionaries who looked at AI and thought “You know what this needs? Less safety testing and more venture capital!".
- Finally, you thought you knew what an email address looks like? The E-mail.wtf quiz is here to prove you wrong! I scored 14/21…
Re: Re: Most slopcode projects are abandoned and deleted within months of release
Michael Harley recently commented on Thom Holwerda’s post commenting on Evangelos (Evan) “GeopJr” Paterakis’s post:
Evangelos “GeopJr” Paterakis:
⤷ Thom Holwerda:
⤷⤷ Michael Harley:
Michael wrote:
Building is fun and interesting but maintaining? Not so much. My takeaway from this is that we should beware of single developer projects, especially ones a developer coded with LLM coding agents.
I’m certain there are successful single developer projects that are around for the long term, but a single developer who used AI to develop their project seems very likely to abandon it when they get bored and are ready to move on.
So, maybe give a new project a year of releases before you start using it for anything important.
For starters, yes, do give new projects a year before you start using them for anything serious. This goes for basically any new and unproven project, single developer or not, AI-generated or not. For just playing around, use whatever you want.
In general, however, I think this is very much a multifaceted issue:
For point one, I think the obvious answer is that anyone can release open-source software. To say otherwise would be gatekeeping.
It gets more interesting at point two: what can we require from someone releasing OSS? Michael seems to suggest that we should expect them to maintain their software, but I would have to disagree. As someone who publishes OSS, you’re not in debt to anyone unless you’ve actually made some binding contract with them. GitHub is full of abandoned projects that only ever received their initial commit, and this was already the case long before the introduction of coding agents.
Point three is probably the most interesting one: what can the OSS developer expect from others? Evan’s original post stemmed from the fact that Flathub banned AI-generated submissions. Flathub is like an app store for Linux, and they have strict standards on the apps included there, as they should. My take here is that no matter how you produce the code, you still need to own it. If you haven’t reviewed the code yourself, you cannot expect anyone else to put in that effort for you either. We’ve been through this conversation with my team at work as well and, after some initial struggles, reached a consensus that this is how it ought to be. If you’re working in a team, AI doesn’t necessarily speed you up that much because you still need to own your code and be able to explain to others why something is done the way it is. “I don’t know, the AI made it” is not a valid excuse at all.
Thom quoted this part from Evan’s original post, saying it’s “absolutely soul-crushing”:
Of the 120 unique repos, 32 were maintained and 88 were abandoned. No seriously, a big portion of them was completely deleted, nowhere to be found, others stopped 6 months ago, right after submitting to Flathub.
Now, I don’t know, is that? Those are just plain numbers that are rather meaningless without a baseline for comparison.
I reached out to Evan, but as he had manually checked all 120 repos and there were some 500 submissions in total during the same time period, it’s understandable that he didn’t check the repos not marked as “AI slop”. We could, for example, find the number of archived Flathub packaging repositories easily (it’s 10 for apps both published and archived in 2025), but that tells us nothing about their actual upstream repositories. In other words, there doesn’t seem to be an easy baseline available.
So, this little piece of research still isn’t very scientific, as Evan indicated in the disclaimer of his original post, and we should bear this in mind:
It’s important to note that this is not 100% accurate. It’s impossible to know for sure if something is still maintained based on the amount of commits per time period, unless it has been declared as such. Software sometimes is “done” and needs no further changes, other times the maintainers are taking a break.
Anyway, I’m now tempted to quote Evan for the last time:
What do we get out of these results? Honestly, not much.
Vibe-coding is all nice and fun and IMO should be encouraged – as long as you don’t expect others to review your code for you. It’d also be nice if you clearly disclosed that your repository was vibe-coded. For a friendly approach to vibe-coded apps, consider something like the Tiny Tool Town that I wrote about earlier.
Tiny Tool Town
In my I linked to Matt Web’s article where he called for better discoverability of vibe-coded apps. A few days ago I learned that my favorite podcaster Scott Hanselman had created a site called Tiny Tool Town exactly for that purpose! A quote from the About page of Tiny Tool Town:
Remember GeoCities? That glorious, chaotic, beautiful mess of personal websites? Everyone had one. Most of them were terrible. All of them were wonderful.
We’re living in that moment again. AI tools have made it possible for anyone to build software. People are creating tiny, weird, wonderful tools — not because there’s a market for them, but because they want them to exist.
Tiny Tool Town is a place to celebrate those creations.
I find this admirable and delightful. You’re nowadays constantly being told how AI wastes water and makes people dumb and entertainment mediocre, but this site just proudly celebrates everyone’s creations; you can be judgmental elsewhere.
I even contributed my recent app, GPX Comparer, to the directory. Go check it out and submit your pet projects too! 📍🚴
Vibing a wardriving visualizer
A while ago someone was showing off their LEGO creation in my social media feed: a brick-built QR-code containing the credentials to their WiFi network. People rushed to tell them that they shouldn’t share this info publicly, but they appeared unconcerned, for who would actually even know where their network was physically located, right? Can’t do any harm to it if you can’t find it. But could you? Surely there are databases of networks available online?
It turns out there are indeed services like WiGLE that catalogue WiFi access points, Bluetooth devices, and cellphone towers around the world. It relies on people using their Android app and submitting the found networks to the site’s database. Out of curiosity I installed the app and did a bike ride of some 25 km around the city, and much to my surprise logged a whopping 5000 WiFi networks and some 10000 Bluetooth devices! It was a revealing moment when I stopped on a bridge over a highway and looked at the app, and it showed Bluetooth devices with names like Audi, BMW, and Toyota. Almost all new cars can be seen as Bluetooth devices!
Now, I had collected some sample of networks, but how would I view it? The WiGLE app itself does not provide a map view, so I did what anyone would do these days and vibe-coded my own app. I started by typing a stream of thoughts to ChatGPT: I want it to be a web page, not an app you need to install, and I want it to work fully in the user’s browser, not uploading the data to any servers. The app should provide a map with my route and the network observations, along with some playback controls, etc. Chad then turned all this into a proper requirements document that I handed out to the ChatGPT Codex coding agent after creating an empty GitHub repository for the project. Codex crunched the assignment for five minutes and burped out a pull request. I then set GitHub up to automatically publish the project in GitHub Pages and merged the PR, and lo and behold, it actually worked immediately! After exporting my observations out of the WiGLE app I could follow my route and see all the observations on the map.
Random Things Sunday #15: Vibe coding
This week’s main topic is vibe coding, but there’s an aasinsilta,, “donkey’s bridge” as we say in Finnish, to it first:
Bluesky bot to report speeding buses
The people in my neighborhood Facebook group are often worried about cars speeding on the main road that goes through the area. While I can’t do much about that, I realized that I can at least monitor how fast the buses are going and make that visible, thanks to a realtime high-frequency positioning API provided by HSL that runs the public transport system here. This was around June 2020. I implemented a simple Java application to monitor those buses on the street, but the MQTT library I used proved unreliable, so I put the project to slow backburner. My idea was to eventually make it into a Twitter bot, but I never got that far back then.
Fast forward a couple of years to September 2022, two months before ChatGPT was launched. TypeScript was all the rage back then but I had not had the opportunity to use it at work yet, so it clicked to me that I could retry my old bus speed tracker with TypeScript.
Using AI at work
Random Things Sunday #10
Some random findings from the internets, this time catering to programmer-minded people:
A light exercise in vibe coding
A few months ago I tried vibe coding an ant colony simulator, but in the end it didn’t work out. I did mention that I had had successes in vibe coding, and lately I had one of those again.
For my previous post I needed to embed several YouTube videos. That, however, is very cumbersome when you’re blogging with your phone, as the mobile version of YouTube does not have the option to easily just copy the embed code, unlike the desktop version, so it was about to turn into an exercise in frustration.
But lo and behold, ChatGPT to the rescue. I gave it this prompt:
Are you really using AI?
Yesterday I was scrolling through my feed when I came across a short video by Allie K. Miller, who’s something of a thought leader in the AI business space. She mentioned that you probably use AI already, but asked if you’re really using it? AI can enable so many novel use cases that merely enhancing your old processes is kind of wasting its full potential.
It made me stop and think. Like many, I’ve been using AI tools here and there - asking ChatGPT to help with writing, generating some ideas, maybe summarizing content. But am I actually reimagining how I work?
Allie mentioned how after 10 years of creating AI content (7 of those without AI tools), she completely rebuilt her workflow. Now she dictates to Otter AI while walking, runs her content through multiple AI systems, and formats everything in Beehiiv with auto-links. More steps, but apparently 80% time saved. That’s not just enhancement.
I wonder if most of us are in that “scratching the surface” phase with AI that Allie mentions. We’re asking AI to help with tasks we already do, rather than rethinking what tasks we should be doing in the first place.
I’m obviously not using AI to its fullest potential either. My current workflows still look pretty much like they did a couple of years ago, with some AI assistance sprinkled in rather than built around them. There’s something to think about there.
(By the way, I don’t often subscribe to newsletters, but I do follow Allie’s work. If any of this piqued your interest, you might want to check out her newsletter at AI with Allie.)
Vibe coding an ant colony simulator
When it comes to household chores, ironing is one of my favorites as it often allows me to shorten my “Watch later” playlist (771 videos there as of writing this…) in YouTube. Last time I did ironing I watched this cool video of an ant colony simulator:
The fun thing is that it creates fascinating emergent behavior from a few simple rules. The ants walk around randomly, leaving behind a trail of pheromones like breadcrumbs pointing back home, and when they encounter food, they pick some up and follow the pheromone trail back to the nest. While carrying food they leave behind another type of pheromone that point the ants to the food source.
This seemed like an interesting exercise in vibe coding where you just describe your need in your own words and let an AI do the actual programming for you. Vibe coding seems to split the opinions sharply: some find that it makes coding more equal and available to anyone, others loathe the idea of an influx of AI-generated trash.