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?
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.
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.
That's gonna turn out well :-)
Maybe they only need it to work for the next 6 months of enhancements...
But I think it is most productive to assume that it does not.
I am a very capable developer, and I convince myself anymore.
And there probably always will be.
When the choices are "hand all of our highly sensitive internal data over to one of several other companies, all of which have questionable financials and very cozy relationships with adtech" or "invest in a whole bunch of expensive GPU servers plus internal talent to run our own models", vs "keep on doing what we've been doing, which is still working just fine", why would a non-tech Fortune 500 company choose either of the former options?
This is curious to me, as at my workplace we never had such subscriptions for small- to mid-size stuff and always built the corresponding tooling in-house.
Yeah, sure you are. Report back when it happens.
(Replacing overpriced garbageware with something I scraped together in 3 days is my jam. But the specifics matter a lot.)
Is instrument spec sheet management focused on storage and presentation, and occasionally updating values such as service interval, calibration dates etc ? If so I also find this plausible.
Both use cases are focused in terms of use case complexity (especially if your company is focusing on your requirements only as opposed to software vendors covering variations), low in complexity in terms of involved parties, and inter-system boundary crossings.
Very interesting. The spec management is probably the higher risk use case, but I assume you have proper engineering review and a tight test strategy to control this aspect.