programming

    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: Democratizing Abandonware
    โคท Thom Holwerda: Most slopcode projects are abandoned and deleted within months of release
    โคทโคท Michael Harley: Re: Most slopcode projects are abandoned and deleted within months of release

    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:

    1. Who can release open-source software (OSS)?
    2. What do we require from someone releasing OSS?
    3. What can the OSS developer expect from others?

    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.

    Junited 2026

    Junited is a no-pressure blog post sharing event that takes place every June. It was invented in 2024 by Robert Birming, and here is his index page for 2026.

    While I usually consider my posts ready once published for the first time and only fix typos or such, this particular post I intend to update with new links throughout the month. To keep it light, I won’t be providing much context or commentary, but these will be posts that I have read and enjoyed. Without further ado, let’s get the list started!

    Read More โ†’

    Tiny Tool Town

    In my previous Random Things Sunday post 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.

    Read More โ†’

    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:

    • 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 calls for better discoverability of vibe-coded apps 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. ๐Ÿ‘บ

    Random Things Sunday #13

    Technically it isn’t Sunday yet where I am, but it’s already Sunday somewhere on Earth, and who’s going to stop me anyway? It’s been a while since the previous Random Things Sunday, so let’s get to it. I have a couple of recent articles, one timeless web site, and an interesting YouTube video about movies.

    Read More โ†’

    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.

    Read More โ†’

    Using AI at work

    Someone young not in the software business recently asked me if I use AI in my work. My knee-jerk reaction was “no”: I don’t trust the AI agents running amok in my codebase. I’ve tried it, and it often feels like herding cats, unless your prompt is perfect and you managed to take everything into account, which isn’t possible. But then I started backing off, as there are of course nuances to this: it’s not all-in or nothing.

    Read More โ†’

    Random Things Sunday #10

    Some random findings from the internets, this time catering to programmer-minded people:

    • 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…

    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:

    Read More โ†’

    Elevator Saga game

    What should happen if you’re on the tenth floor of a building and push the button to call an elevator? Obviously, the elevator should come to you. But what if it’s going up at the 11th floor at the moment, as someone told it to take them to the 15th floor? Well, do that first, then get to the tenth floor. But what if, meanwhile, someone calls it to the 14th floor, wanting to go down? Maybe pass that floor when going up, but stop there on the way down to the tenth floor. But what if you, on the tenth floor, want to get to the 16th floor? Maybe pass the person waiting the 14th floor after all. And what if there are multiple elevators in the lobby, which one should be dispatched and where?

    Read More โ†’

    Robot Battle, an old Windows game

    In the 1990s and early 2000s I played this great game called Robot Battle by Brad Schick. It’s an open-ended programming game where you use a programming language called Robot Scripting Language (RSL) to program battle bots to shoot at each other. The bots look like tanks, consisting of a tracked body, turret, and radar. The arena is viewed from top-down and, in addition to the robots, would also contain mines that you would want your robots to avoid, and cookies that give you more energy. The game relied heavily on its community, initially connected via the Robot Battle Mailing List (RBML), later via the Robot Battle Registry web forum.

    Read More โ†’

    Random Things Sunday #8

    A bit of Star Wars and some programming this week:

    • SC 38 Reimagined is a fan-made remake of the Obi-Wan vs Darth Vader fight in Star Wars Episode IV: A New Hope. The film is short but it has high production values. It makes the original Alec Guinness vs David Prowse battle look rather geriatric, following Vader’s aggressive fighting style seen in the prequel films and TV shows. This fan-film even has a Wikipedia article.
    • Google may have profiled me after my previous Random Things Sunday post, as that list contained a reference to a piece of game-making software, and then YouTube’s algorithm recommended me the Make tiny games video by Juniper Dev. The video is about retro game engines, such as PICO-8, that force you to be creative by limiting the resources you have at your disposal, but that can also be fully mastered due to their limited size. If one wants to make games, start small, and nothing is smaller than these engines!
    • Finally, Joshua Barretto did a great write-up Writing Toy Software Is A Joy, which I think is a good follow-up to the previous point about tiny games. The point of the post is that if you’re a programmer, you should have hobby projects too. You cannot know how, but they’ll pay you back when you’ll acquire knowledge you didn’t know you’d need. And it’s also just more fun to program 20% the work for 80% the results, rather than trying to account for every exceptional case like you’d do if you were writing production quality software, where the first 90% of functionality takes 90% of effort and the final 10% of polish takes the other 90% of work.

    Saalo's Law of Software Development

    When you’ve been long enough in the software development business you start to notice patterns. One of those patterns recently surfaced again when someone in my team floated the idea that our system should be able to read or write Excel files. I’ve seen and implemented this particular request so many times that I got inspired to write it down as an adage. I’ve dubbed it Saalo’s Law of Software Development and it goes as follows:

    Every piece of enterprise software eventually evolves into either reading or writing Excel files.

    I originally posted this just to the company Slack where my peers unanimously agreed that yes, this is exactly what happens. There’s something about spreadsheets that makes them the universal translator of the business world – no matter how sophisticated your system, someone always needs that Excel import or export function.

    So there you have my humble observation on how enterprise software works. My law may not be as well known (yet!) as Hofstadter’s, Brooks', or Parkinson’s laws, but maybe one day. ๐Ÿ˜