The Quiet End of Software as a Service
My co-founder Toby recently published a piece on LinkedIn arguing that vibe coding is quietly creating an IP crisis most companies haven't recognised yet - you can read it here. I agree with him, and I want to take the argument one layer deeper, into the part I spend most of my time in: what it actually takes to turn a vibe-coded product into something a business can depend on, sell, license and defend.
For two decades the default answer to 'we need software' has been the same: buy a SaaS subscription, log in through a browser, accept the roadmap somebody else controls. That model is quietly ending. When Toby builds a CRM in a few weeks using vibe coding tools and ends up with something a commercial CRM cannot do - because every screen, field and automation reflects exactly how he works - he runs into the same wall every founder is about to hit. He can't really sell it as SaaS. What he can do is hand the source over to another company, let them remix it, and charge a licensing fee or a share of the value it manages. That's not SaaS. That's IP.
One Core, A Million Versions
The pattern we're going to see across every industry is the same: one well-built core product, then a million private forks of it inside the companies that adopt it. Six months after a customer takes the code, maybe 50% of the features still overlap with the original. A year later it might be 20%. At what point is it still 'your' product? What licensing model survives when 80% of the source has been rewritten by the customer's own team?
These aren't theoretical questions. They are the contracts, the IP clauses and the deal structures that buyers and vendors will be arguing about by the end of this year. And they land squarely on engineering, because the answers depend on how the code is structured, segmented and instrumented from day one.
The 'No More Developers' Myth
There's a loud narrative that AI-assisted development means companies won't need developers anymore. From where I sit - shipping this into production with real clients - the opposite is true: every organisation will need more developers, not fewer - just doing very different work.
The shift is from greenfield development to *taking over* a working vibe-coded product and equipping it with the safety mechanisms, stability and production hardening it never had. Customising it. Integrating it. Defending it against scope creep and silent security regressions. That is not a job AI does on its own. I've written about why this still needs real engineering discipline in Vibe Coding Done Right, and about the recurring patterns we see when we're called in to fix what AI-accelerated teams shipped too fast in The Rescue Squad Playbook.
Most companies don't have that team in-house. They will either build one or partner with one.
The New Roles Inside Every Software-Buying Company
If you accept the premise that buyers will increasingly own the source code of the products they use, four roles inside their organisation change shape almost overnight:
- ▹Programmers become security guards. Their job is to guard the codebase against the natural entropy of vibe coding - infinite feature requests, scalability landmines, silent security regressions, dependencies that drift. Less typing, more vigilance.
- ▹Testers become the heroes. When code is generated in minutes, the bottleneck moves to verification. The people who can prove a release is safe to ship are the ones who unlock the speed advantage of AI in the first place.
- ▹Procurement and supply-chain managers become quasi-lawyers. They suddenly have to reason about source-code licensing, derivative-work clauses, IP ownership of AI-generated code, and revenue-share structures that didn't exist in the SaaS playbook.
- ▹Users become the innovators. When any user can describe a feature and watch it appear, the centre of product gravity moves out of the vendor's roadmap and into the customer's daily workflow.
The 'testers become heroes' shift is the one I see most clearly in our delivery teams. The bottleneck is no longer typing speed; it's the confidence to ship. That's where senior engineering judgement starts to pay back hard.
Why This Plays To Engineering Partners, Not Sales Teams
This shift is uncomfortable for traditional software vendors and outsourcing shops. It is genuinely good news for the kind of engineering partner AMT has been since 2003. If you're a company adopting a vibe-coded product - whether you bought it, licensed it or built the first version yourself - you need partners who can do three things well:
- ▹Read someone else's codebase like it's their own. Pick up a vibe-generated core, understand it in days, and start shipping safe changes.
- ▹Add the production layer the original build skipped. Authentication, authorisation, audit logging, observability, rate limits, test coverage, CI/CD, disaster recovery - all the unglamorous engineering that keeps systems alive at scale.
- ▹Structure the IP correctly. Help you reason about what you own, what you license, what you can resell, and how to track derivative work as your fork diverges from the original core.
Those three sit at the intersection of senior engineering, enterprise architecture and IP-aware product thinking. That's an unusual combination, and it's the one we've been quietly building at AMT for over twenty years. A lot of it now flows through the integration layer between existing systems and AI - which is why I keep coming back to MCP servers as the missing layer between your software and AI and to the practical work of bridging legacy APIs with modern AI. Those are the seams where IP value gets created or quietly destroyed.
What This Means If You're Planning Your Next Build
If you're a founder, a product owner or an enterprise buyer thinking about your next platform, the practical implications are:
- ▹Stop assuming SaaS is the only delivery model. A source-licensed, customer-hosted, remix-friendly product may give you a stronger moat and a healthier margin than a crowded SaaS category.
- ▹Plan for source-code ownership from day one. Your contracts, your repos and your deployment topology should assume the customer will eventually want the keys.
- ▹Hire (or partner for) engineers who can guard, not just generate. The scarce skill in 2026 is the ability to see what's wrong with AI-generated code, not the ability to produce more of it.
- ▹Treat IP, licensing and revenue-share design as a core product decision. It's no longer a footnote in a Master Services Agreement.
Where AMT Fits
At AMT we sit on exactly this seam: senior engineers who have been hardening enterprise software since 2003, now working day-in-day-out with AI-assisted development, MCP servers, AI agents and the IP questions that come with them. We take over vibe-coded prototypes and make them production-ready. We build the security, testing and architectural discipline that turns a clever demo into a system a board is comfortable depending on. And we help our clients think clearly about who owns what, who can change what, and how that gets priced.
If you're somewhere on this curve - excited about what vibe coding can do for your business, but unsure how to make it safe, scalable and defensible - that's the conversation we'd like to have. Not a sales pitch. A technical discovery call, the way we've always done it.