All these articles seem to think people will vibe code by prompting:
make me my own Stripe
make me my own Salesforce
make me my own Shopify
It will be more like:
Look at how Lago, an open-source Stripe layer, works and make it work with Authorized.net directly
Look at Twenty, an open-source CRM, and make it work in our tech stack for our sales needs
Look at how Medusa, an open-source e-commerce platform, works and what features we would need and bring into our website
When doing the latter, getting a good enough alternative will reduce the need for commercial SaaS. On top of that, these commercial SaaS are bloated with features in their attempt to work with as many use cases as possible and configuring them is “coding” by another name. Throw in Enshittification and the above seems to the next logical move by companies looking to move off these apps.
Velocity or one-shot capability isn't the move. It's making stuff that used to be traumatic just...normal now.
Google fucking vibe-coded their x86 -> ARM ISA changeover. It never would have been done without agents. Not like "google did it X% faster." Google would have let that sit forever because the labor economics of the problem were backwards.
That doesn't MATTER anymore. If you have some scratch, some halfway decent engineers, and a clear idea, you can build stuff that was just infeasible or impossible. all it takes is time and care.
Some people have figured this out and are moving now.
I think something like an x86 -> ARM change is perfect example of something where LLM assisted coding shines. lots of busywork (i.e. smaller tasks that don't require lots of context of the other existing tasks), nothing totally novel to do (they don't have to write another borg or spanner), easy to verify, and 'translation'. LLMs are quite good at human language translation, why should they be bad at translating from one inline assembly language to another?
Yeah. Lots of busywork where if you had to assign it to a human you would need to find someone with deep technical expertise plus inordinate, unflagging attention to detail. You couldn’t pass it off to a batch of summer interns. It would have needed to be done by an engineer with some real experience. And there is no way in the world you could hire enough to do it, for almost any money.
I’m not worried about the personal character of diligence. I’m interested in what the technology unlocked and how things made with it are materially different in terms of labor configurations.
If you're trying to automate all coding activity, writing tests is coding activity. Arguably the greater fraction of effort between implementation, and verifying said implementation. If the only thing making your problem space tractable for the automation to be able to replace the lesser half of coding activity is an authored test suite you couldn't generate via your automation, then you really need to admit that.
"Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles. Spent quite a few years as a dedicated tester once I developed the knack for it. Everybody gangsta til it's time to prove the damn thing works.
> "Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles.
Here it’s a climb-down. Writing tests to validate translation is orders of magnitude less work (and less likely to fail or be too dull to do properly) than the alternative available prior to 2025.
The fact that they wrote tests and clearly established operational control is not some kinda gotcha! It’s how they managed to get this piece of technology to allow them to do the IMPOSSIBLE.
I am just really struggling to understand someone who reads that paper and thinks “yup, everything is still the same and we don’t need to re-evaluate any ideas” Like, if you want to say that they still need engineering discipline in order to do ISA transitions at scale then…ok? That’s true? But Gemini meant that this formerly impossible thing was now not only within reach but done.
Exactly, if the engineers know where to look for the solution in open-source code and point the AI there, it will get them there. Even if the language or the tech stack are different, AI is excellent at finding the seams, those spots where a feature connects to the underlying tech stack, and figuring out how the feature is really implemented, and bringing that over.
The value in enterprise SaaS offerings isn't just the application functionality but the IaaS substrate underneath. The vendor handles server operations, storage, scalability, backups, security, compliance, etc. It might be easier for companies to vibe code their own custom applications now but LLMs don't help nearly as much with keeping those applications running. Most companies are terrible at technical operations. I predict we'll see a new wave of IaaS startups that sell to those enterprise vibe coders and undercut the legacy SaaS vendors.
I've been confronting this truth personally. For years I had a backlog of projects that I always put off because I didn't have the capacity. Now I have the capacity but without the know how to sell it. It turns out that everything comes back to sales and building human relationships. Sort of a prerequisite to having operations.
First, a vendor will have the best context on the inner workings and best practices of extending the current state of their software. The pressure on vendors to make this accessible and digestable to agents/ LLMs will increase, though.
Secondly, if you have coded with LLM assistance (not vibe coding), you will have experienced the limited ability of one shot stochastic approaches to build out well architected solutions that go beyond immediate functionality encapsulated in a prompt.
Thirdly, as the article mentions, opportunity cost will never make this a favorable term - unless the SaaS vendor was extorting prices before. The direct cost of mental overhead and time of an internal team member to hand-hold an agent/ write specs/ debug/ firefight some LLM assisted/ vibe coded solution will not outweigh the upside potential of expanding your core business unless you're a stagnant enterprise product on life support.
Sensible people would do that (asking for just the features they need), but look at us, are we sensible?
Most of us* are working for places whose analytics software transitively asks the user for permission to be tracked by more "trusted" partners than the number of people in a typical high school, which transitively includes more bytes of code than the total size of DOOM including assets, with a performance hit so bad that it would be an improvement for everyone if the visitor remote desktop-ed into a VM running Win95 on the server.
And people were complaining about how wasteful software was when Win95 was new.
* Possibly an exaggeration, I don't know what business software is like; but websites and, in my experience at least, mobile apps do this.
So maybe the saas will pivot to just sell some barebone agents that include their real IP? The rest (UI, dashboards and connectivity) will be tailored made by LLMs
make me my own Stripe
make me my own Salesforce
make me my own Shopify
It will be more like:
Look at how Lago, an open-source Stripe layer, works and make it work with Authorized.net directly
Look at Twenty, an open-source CRM, and make it work in our tech stack for our sales needs
Look at how Medusa, an open-source e-commerce platform, works and what features we would need and bring into our website
When doing the latter, getting a good enough alternative will reduce the need for commercial SaaS. On top of that, these commercial SaaS are bloated with features in their attempt to work with as many use cases as possible and configuring them is “coding” by another name. Throw in Enshittification and the above seems to the next logical move by companies looking to move off these apps.