alt Hacker News> In my workplace, we're going to decline to renew some software subscriptions because a non-programmer vibe-coded their replacement in a week. The impacts are here, they're just not evenly distributed yet.
Interesting to see the impact in the long term when battle tested software gets replaced with vibecoded variants by non-programmers. Does it increase data breaches or quality actually goes up?
Replies
One of the upside I can foresee is the return of single payment software. No one is going to be paying subscriptions when they can LLM themselves, but paying someone else to LLM for them would let them shrug off accountability for malfunctions
The other day, i was fed up with my mac webcam software. I just needed to fix being washed out. Every piece of software I found cost money, several were a monthly subscription.
Over lunch, Claude made a minimal toolbar app that lets me adjust down the brightness.
Often, you don't need battle tested. And you don't need a bunch of features.
The ai could have shipped my video feed somewhere I suppose, if I were unable to read its code.
To me, this is inline w the book BULLSHIT JOBS, and that class of job that was really like a few hours a week but 40 hrs pay. That type of job should be automated and the person removed. The exception is going to the person who complained to management that it’s a 2 hr a week job…. Give me more work.
I think Sturgeon's law would tell us that everything will stay about the same.
But in reality, a lot of corporate software exists just because there are plenty of companies who are afraid of owning code. They don't want to maintain any in-house coding skills, and therefore are willing to buy literally any vaguely-relevant CRUD app that the manager heard about at the conference. I don't think replacing that class of software with vibe coded alternatives will be any worse, because the bar is starting on the floor.
There are entire software categories that consist entirely of code that is only one or two evolutionary steps away from some engineer's spreadsheet originally written in 1995. One fine example I work with has changed its backend database 3 times in the past 4 years. Their most recent decision to use mongodb came with the questionable decision to store json as a raw string literals complete with bizarre escaping inside a database literally designed to store json-shaped-objects.
I don't think Opus could store data that poorly, even if the end user prompting it didn't know what they were doing.