Why would it stop with just developer layoffs? When software companies rely on LLM providers to run their business, I’d argue we‘ll see a massive bust of these companies around the world - from on-prem products to SaaS.
Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.
> Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.
Already happening. I know of a few places that have gotten such large gains from LLMs that they know have their engineers working on creating homegrown ports of popular services (Docker etc.).
Why would you create a homegrown port of Docker? Docker the container software, or Dockerhub the image repository? This is just confusing. If you didn't want to use Docker there is a perfectly good well tested alternative called Podman with wide adoption.
Not sure about Docker (lol) but stakeholders are definitely more open to "building your own" now. It used to be that to be agile as a business you would seek out already built software and rent it, as it typically was cheaper than building and maintaining your own (I say typically due to stuff like vendor lock-in and such). But these days, and especially in 2026 with the widespread use of agents and harnesses, that formula has started to change. Even though the SOTA models are really good now, it's the harness and the "fluff" around the model that makes it a game changer. The developer is no longer the one writing or even gluing the code together, the harness does that. Pair that with context preserving mechanisms and tools that emerged (automatic context compaction, AGENTS, TOOLS, MCP...) and you can get to a state where you start a new thread in Codex and it knows your systems, your dbs, can smartly explore code it doesn't know and db data patterns etc., it can explain stuff to a new developer (and be correct most of the time and have time to spend on the developer)... all of which SIGNIFICANTLY reduces the risk you take on yourself as a company when you "build your own". What's $10k/year to any half-working semi-profitable company? Nothing. But in 2026, you can build and maintain A TON of software for that, much more than your "average IT needs" company may ever use.
I'm sure the very large (and very small) businesses will keep their absolute need for (or the lack of) inhouse developers, but everything in between will probably get compressed to one or two inhouse architects in direct contact with the stakeholders and the rest will be contractors working with Codex-like automation.
Homegrown ports of calendly or jira seem feasible, and arguably a good business decision. Homegrown versions of docker seem ridiculous as a starting point, even if its possible to do today there is much lower hanging fruit to go after first.
> I know of a few places that have gotten such large gains from LLMs that they know have their engineers working on creating homegrown ports of popular services (Docker etc.).
Sounds like a good way to eventually erase those gains.
This won't happen in most cases because the valuable thing is largely the knowledge encoded in the software, which the buyers of the software don't have and don't want to have since they're focused on their own business.
There's also, of course, the not insignificant value in the software itself actually working, being operated, being updated when necessary, all of that. Again just extra hassle no business will want to shoulder when they can just buy something that does it for them.
I have personally replaced multiple tools that cost me money every month and now cost me $0/mo. They are low stakes but they work and have near zero maintenance (only changes are me adding features or fixing the occasional bug I missed).
Why would I pay someone even $10/mo when I now have a $0/mo solution?
1. There is value in a tool that solves precisely your needs, in the way you want it solved.
I've repeatedly seen enterprise SaaS purchases where the company ends up wrapping/layering on top additional tooling, software, and infra to solve core needs that are absent (or misaligned) from the saas tooling, but required for their specific usage.
I've directly experienced this with: analytics tooling, customer survey tooling, feature flag tooling, and interview tooling.
If your going to dedicate a dev anyways - the numbers can change here.
Is this every SaaS product for every business? Fuck no - but there are products that might be adjacant to your core business where you have both strong preferences & experience, are already spending for customization, and now it makes sense to pull the whole thing in-house.
2. The 50k/m crm is competing with that 500/m crm. which realistically appears to soon be competing with that 50/m.
Even if we stick with your stated observation that end businesses don't benefit from building their own tooling (which is fair and often true, although I'd wager it's not as clear-cut as you imply) - you're dismissing competition that is absolutely willing to undercut the market because they can slip on quality (slop - as you say) but still serve a need to customers who place cost as the primary buying metric.
If the customer is better served by the 500/m crm, why stop there? Why not go for the 100/m crm? The 50/m crm? Why not chug on down to the lowest possible cost competition, which likely will be 2-5 guys with an llm they ask to go copy "[insert crm of choice]", and then bill just slightly over infra costs.
Or the other thing I'm seeing happen in a lot of spaces right now... the "do it all" SaaS companies, that are pumping out into adjacent verticals that previously would have been too expensive to develop. The bill stays the same, but now it's not just a crm, it's the original crm, plus a clone of all the adjacent market leaders... scheduling, billing & invoicing, marketing, SEO, site hosting and design, social engagement, etc...
One SaaS elbowing into other verticals but keeping the bill the same, which I consider functionally equivalent to the competing on price, just wrapped in a different flavor (it won't be 2 dudes in a basement, it'll be 2 dudes on the "crm" squad in a bigger eng dept).
Starter is the "under 10" seats, but they don't have most of the features companies actually want, and the next category is suddenly $266/seat/month. Which is what they really expect enterprises to be paying per seat.
But.... like I said, that leaves a TON of room for getting undercut by a copy-cat company if the only competing metric is "price".
Hell, there is a lot of really good open source software that fits most peoples needs already, that can be self hosted and costs nothing but the running of it. But people still pay for the SaaS product. Because you're not just paying for software. you're paying for support, uptime, compliance etc. These people think that SaaS is dead confuse me.
Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.