Login
You're viewing the linuxhotel.social public feed.
  • Oct 17, 2026, 8:08 AM

    The term "single use software" currently lives rent free in my head.

    People use LLMs to create software specific for their needs. But neither can other people use it (hardcoded variables, no rights management, too specific), nor do they use it again (too specific, easier to produce a new one).

    Single use software is not maintained. Nobody understands it or has an interest in keeping it working.

    The creation of single use software feels cheap, but isn't. It takes time to create the software, it needs infrastructure and power. The time is experienced as short compared to how long it takes to create maintainable and reusable software. But once you take into account how many people benefit from reusable software, the single use software takes way more time to create than what it saves. The infrastructure and power costs are hidden because the data center isn't visible. The costs are subsidized by venture capital.

    Like other single use items, single use software brings risks of unforeseen consequences. From data loss or leaks to issues for maintainers of reusable software (eg. verbal abuse, less motivation and lost income).

    As an example of single use software is a German LinkedIn post of a person who slopcoded a HEMS (home energy management system). It took them more than a week. While open source projects like evcc.io/ already provide the same functionality. They could have used it for free or paid 100€ and got support for some additional devices. But they decided that they know better how it should work and now have a single use software. If it breaks there is nobody they can ask. There won't be updates and no community to discuss and develop new features. No organization will ever be interested in officially supporting it. And even if it works, it only benefits that one person.

    (This doesn't mean people shouldn't build things that only they use. But they should enjoy doing so.)

    Mit 21 habe ich Webse en weiteren Unternehmen habe ich Back up now beitet und mich auf Konzeption, Skalierung und technische Machbarkeit von Geschäftsmodellen fokussiert.

In den letzten Wochen habe ich mir bewusst viel Zeit genommen, mich tiefergehend mit ChatGPT Codex und Claude Code auseinanderzusetzen. Mit Codex habe ich ein Plugin für mein Smart-Home-System gebaut, um mein Energiemanagement (HEMS) an unsere Anforderungen anzupassen.

Die Software basiert ausschließlich auf Open Source: Python, PostgreSQL und Flutter für das Frontend. Das Plugin liest via Modbus TCP den Wechselrichter aus, verbindet sich mit der Wallbox, der Batterie, mit Solcast für die PV-Prognose und meinen direkt ansteuerbaren Verbrauchern.

Vierzehn Stunden Entwicklung, fünf Stunden Testing, dann eine Woche Optimierung und Bugfixing - und nun automatisiert mein individuelles HEMS alles eigenständig.

Früher wurden dafür hohe fünfstellige Beträge ausgegeben. Jetzt ist es einen Prompt entfernt. Individualentwicklung boomt und die Möglichkeiten wirken grenzenlos.

Was mich daran am meisten beschäftigt, ist nicht die Technik. Es ist die Tatsache, dass Softwareentwicklung viel dynamischer wird und einem breiteren Publikum zugänglich wird.

Natürlich bedeutet das (noch) nicht, dass sichere und performante Software einen Prompt entfernt ist. Aber man benötigt keine hohe Vorstellungskraft, um zu sehen, dass KI sehr bald bei Security- und Architekturfragen vollautomatisch leistungsfähige Systeme konzeptioniert und baut.

Die Frage ist somit nicht mehr, ob man etwas bauen kann. Die Frage ist, ob es jemand benötigt und man einen Bedarf decken kann.

Eines ist aber klar: Menschen mit viel Kreativität haben nun ein Tool an der Hand, das ihnen dabei hilft, technische Hürden schneller zu überwinden.
    💬 39🔄 5⭐ 0

Replies

  • 💬 2🔄 1⭐ 0
  • Oct 17, 2026, 9:02 AM

    @tante @luca I live in fear of the coming maintenocalypse where AI vendors take in half their income from needlessly expensive maintenance of vibed up in house tools

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:27 PM

    @tante @luca "Fashion" is an apt description for software development, and "fast fashion" fits the slop coding. I've often referred to software development as a popularity contest due to the lack of measurement. Developers will follow trends without asking why or to what benefit; just look at all the misuse of Python these days. From the reports of slop projects, I'm sure that actual measurement would put slop use in the avoid column of the process spreadsheet.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 8:31 AM

    @luca I honestly understand the urge for a new setup if he's paying tens of thousands for the old one (that's what the "fünfstellige" bit is, right? My German's poor to say the least), but I really don't understand why he chose a week+ of slopping instead of a week of research to see if there already was a cheap/free and maintainable solution available.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 9:11 AM

    @luca and in the act of having a slop machine extrude a piece of single use software, that person gained no experience, no domain knowledge, etc.

    Even if that specific problem is niche, you never know where some of the acquired know-how could become handy.

    Maybe researching opensource tools and duck-taping a couple of them would turn out useful.

    Instead, that person just wasted time arguing with a word extruder software.

    [...]

    💬 0🔄 1⭐ 1
  • Oct 17, 2026, 9:12 AM

    @luca
    This guy spent more than a week slopcoding something I managed to install in 2 hours using an existing foss project (evcc).

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 9:13 AM

    @luca I was thinking about the parallel with visual basic apps and excel / access databases of the 90s/00s, that was a popular way to build throw away / bespoke software, and over time, a lot of that was replaced by more professionally developed apps, sometime after great pain, but also, a lot was just forgotten as soon as they outlived their usefulness.

    I think the current wave of bespoke LLM software, is interesting, and the usefulness and quality is certainly superior to what people could cobble together with limited understanding with these tools, but if we mistake the apparent polish, for quality, and give too much responsibility for this software, outside of more professional audit/support/management, there will indeed be great pain.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 9:42 AM

    @luca There is a problem with this analysis. There is nothing wrong with single use applications, and time is valuable too. If it is faster for the end user to vibe code up a single use thing for their specific need, that is time spent getting the thing done, using it what it is to be used for, and moving on. It saves the most precious resource humans have, time.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 10:31 AM

    @luca yeh it's so real holy shit. i'm seeing it happen all over the place now

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 10:51 AM

    @luca Once Upon A Time we had a concept of "temporary" software, which didn't have to be built according to our normal engineering standards / quality rules.

    Typically this would be a tool for a one-off data conversion, something like that. It had a lifetime of 24 or 48 hours, forget which, after which anybody could delete it / throw the paper tape away / whatever.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 11:26 AM

    @luca I understand your line of reasoning, and you do make some valid points. Nevertheless, I would like to partially disagree. In my own experience, my software needs often fall into the "long tail"—meaning that the software I require would never be economically viable because the concept doesn't scale. Under a conventional paradigm, such software would likely never be built in the first place. With AI, however, I can tailor solutions to my specific needs, which represents a huge step forward for me.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 12:02 PM

    @luca I think we are looking at it from the wrong angle. "A system already exists for this" is a projection of "Why didn't the guy just use <$my_thing>" which makes us all feel bad, but we haven't really checked "why is contributing to $project seen as a drag by commoners". OSS has created a very elitist attitude towards either newbie users or driveby-contributors, and it is chock-full of design decisions which are - let's call it for what it is - bad. One natural way out is vibe.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 12:15 PM

    @luca I mean yes, but also no. The term “maintainable” is a never-fulfilled promise of IT. Ever. One gets incompatible upgrades. One gets vendors breaking their APIs. One has to monkey patch an integration because who would expect anyone to follow any standards? Etc.
    So while I do agree that the Single Use Software is *mostly* for one user, it also allows something we’ve never had before: Maintenance-less systems. Assuming the human is out of the loop. Completely.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 12:55 PM

    @luca I was gonna start arguing with you, but your last paragraph took the wind out of my sails.

    Because I did the same thing, built my own HEMS integration, with about the same effort, but I did it with my own brain, and I learned *a lot* (and I am not a professional programmer, although I've been coding on and off for 4 decades).

    But going from "works well for my environment" to something that could be reused by others is a lot of effort, needs cleaning up, abstracting things, documenting /

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 12:59 PM

    @luca Some people have to learn things the hard way. They're unable to look and reason around them, and see how things will turn out.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:17 PM

    @luca "Single use software" is a good observation, also known as "throw-away code" (which never gets thrown away). Capers Jones has expressed excitement about slop, because of the "potential for reuse". I wonder if he's started measuring any slop coding efforts. I think he's going to change his mind. He should know better than to jump the measurement step.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:18 PM

    @luca Vibing your own solution is also a way to never have to think about whether your workflow makes sense. Say, you want a customer relationship database. If you look at existing software, none might fit the way you have been working so far with just Excel sheets or whatever. But maybe your workflow was inefficient and you've just entrenched it.
    Existing software might work differently because people with more experience have concluded that it makes more sense to do things in a certain way...

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • EvoScaleEvoScale@c.im
    Oct 17, 2026, 1:30 PM

    @luca Copyright issues are now accelerating, considering the next level hacking available to #AI and #TechBros #AbuseOfPower.

    Just because your average coder and end user sets aside a smaller, simpler code set, doesn't mean it's not easily archived and quickly (read: at the speed of the fastest AI available) aggregated into newer agency, outside of any human intervention.

    So does that leave any equitable accountability, solely up to the most powerful AI, while the .01% wealthiest remain greedily, and blissfully, ignorant?

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:32 PM

    @luca This is quite a weak take, seen from my perspective.
    I regularly develop one-shot tools and often it took me ages, but I enjoyed (point given) the learning process.
    What I experience: The vibe-coding era brings a bigger pile of shame when it comes to maintenance and doc. But that's a well-known cultural challenge and AI helps a lot with that overall, too.

    I generally refuse the conclusion AI erodes our mindful processing; it happens a lot now, but I'm confident our habits will evolve.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:50 PM

    @luca Single use software has existed before, think scripts and patches and hacks. But indeed now time to prototype is 30 mins, so lots of software ideas can be realized quickly (and then either developed further properly or forgotten). Nothing wrong with that, on the opposite. But indeed vibe coders without programming experience forget the maintenance debt. Programmers on the other hand can be more efficient in architecting systems and not getting buried in the details.

    💬 0🔄 0⭐ 0
  • Seth Mosdatabeestje@noc.social
    Oct 17, 2026, 2:10 PM

    @luca I think of different software, with a single registration code unique per PC and you get to buy it again.

    I despise that software

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 2:54 PM

    @luca Single use software isn't new to LLMs. It's been around since the dawn of computing and remains extremely prevalent in forms like spreadsheets and shell scripts, whether prepared by hand or with LLMs.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Oct 17, 2026, 8:04 PM

    @luca A habit that would have saved that week: before an agent builds anything, ask it to list existing open source projects that already do this and why they don't fit. Often the most useful prompt of the session.

    💬 0🔄 0⭐ 0
  • Oct 18, 2026, 7:03 AM

    @luca "single-use software" back in my day it was a script I threw together in half an hour

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • Oct 20, 2026, 7:37 AM

    @KuestenKeks @luca Nicht nur ein wenig. Das ist ziemlich genau meine Befürchtung. Da die Menschheit aber doch ganz gut darin ist Lösungen für Probleme zu suchen - ahne ich, dass uns ein neuer Mechanismus einfallen wird, wie wir solche „Gravitation“ von Projekten wieder herstellen. Ich habe da auch schon ein paar vage Ideen.

    💬 0🔄 0⭐ 0