Vibe check: AI may replace SaaS (but not for a while)

Vibe check: AI may replace SaaS (but not for a while) If ‘vibe coding’ disrupts the software market like SaaS did 20 years ago, what does this mean for cyber security? Andriy Onufriyenko via Getty Images February 2026 saw a billion-dollar wobble in the value of US tech companies over investors' fears that AI will destroy the Software-as-a-Service (SaaS) business model. This quickly became known as ‘the SaaSpocalypse’, leading to further market movements, sell-offs and significant debate online. This blog post does not predict that organisations will suddenly vibe code a replacement for their customer relationship management tool (or other corporate platform), nor will I argue today’s AI-written code is consistently good, safe, or maintainable - but that recent events have indicated that the cost/effort curve for ‘bespoke enough’ software is shifting. As such, over the coming years, we will see organisations make different choices about buy vs build vs ‘go without’. The security question then becomes: what technology, guardrails, platforms and assurance do we need so this future is safer than the status quo? Before the SaaSpocalypse…. There is a slightly simplistic idea that everything a business does is either a ‘profit centre’ (something that makes money for the business) or a ‘cost centre’ (something that’s accounted as the cost of doing business). Organisations are generally happy to invest and develop systems that are parts of delivering core business (that is, profit centres), but want as little outlay as possible in running IT systems that are more ancillary or supportive (that is, cost centres). If we wind back to the late 2000s, running a non-core business application was a considerable cost centre, and a pain for the average organisation. The application needed purchasing, then installing and configuring on servers that you also had to purchase (and house somewhere). But the real pain was maintenance. IT teams needed to patch, manage redundancy, plan capacity upgrades and secure the application and servers. Even a relatively simple, non-core business application required huge cost and effort. Then came ‘the cloud’ and SaaS. The attraction was clear; for most non-bespoke software and systems, organisations paid a predictable per-user fee, and all of the maintenance aspects were managed on your behalf. No hardware to administer. No patches to apply. And generally better security defaults. Whilst this was generally an improvement on the state of on-prem software, security folk predictably fretted, their main concerns being: - ‘You have to trust the provider to be secure’. - ‘If the provider is compromised, all their clients’ data gets compromised'. - ‘What about sovereignty issues?’ In the 2010s, as SaaS and cloud pervaded nearly every sector, I remember thinking at the time that these issues weren’t being really mitigated. However, the business benefits were so clear that the world slowly transitioned to SaaS, starting with small startups and eventually huge established organisations (and governments) following. Nearly 20 years later, we are only now revisiting some of the above concerns with approaches like confidential computing and regional guarantees. SaaS isn't perfect Despite all the benefits over the classic on-prem approach, SaaS isn't perfect. Firstly, SaaS can end up being expensive. All those subscriptions add up, particularly when you factor in the additional features you might need above and beyond the basic functionality. Furthermore, the business model adopted by many SaaS companies is built upon double-digit growth. This ‘breakout growth’ was possible in the early days of SaaS, but once the market was saturated, vendors started to monetise their offering by separating features into higher pricing tiers. Increasingly, security has become a means for vendors to create a price-differential, with expensive ‘enterprise’ tiers frequently required for organisations wishing to implement even relatively basic security features such as logging, monitoring, single sign-on and multi-factor authentication. Secondly, SaaS is always an imperfect solution, by which I mean the customer must choose from the providers' services that are trying to meet the requirements of many customers. No SaaS product can reasonably cover everything a single customer wants from it. This tends to result in the closest (affordable) SaaS service being chosen, and the customer then adapting their internal processes accordingly. The promise of vibe coding Using AI to write code, often without human review, has become known as ‘vibe coding’. It’s showing the glimpses of a new paradigm: experienced developers are discovering that vibe coding can massively increase their productivity, and can be used to write entire stacks in an afternoon rather than weeks. Currently, the code produced is far from perfect and there's a lot for the developer to improve, but the promise is there. It can be easy to dismiss the value of vibe coding, as the benefits will depend upon the seniority and experience of the person who is ‘vibe coding’. For example, someone with little or no technical experience tends to find it creates code they never could, but it’s often unreliable, hard to maintain, or has critical issues. Experienced coders who pride themselves on effective and elegant code observe that the code AI produces is way below the quality they require. Managers responsible for development teams' efforts also report concerns about the quality and the maintainability of code. Who wants to reverse engineer thousands of lines of AI generated code to realise it has an off-by-one error? And how will it affect the career pipeline for developers? However, people who are experienced coders (or experienced in assigning tasks to more junior staff) are already telling me that they are seeing huge increases in their productivity. I recently spoke with a startup that had received a SaaS renewal quote that was twice the current price, as an increase in user numbers pushed them into a higher-priced tier. Instead of renewing, one of their engineering leads ‘vibe coded’ a replacement with the core functionality they needed within a couple of hours. And this trend isn’t limited to risk-tolerant startups; large organisations I talk to are now seeing developer and admin teams using AI when creating and maintaining internal tools to support their work. Bill Gates’ frequently-cited quote from 1996 reads: "most people overestimate what they can do in one year and underestimate what they can do in 10 years”. With this in mind, let's look at how some thought leaders have predicted how vibe coding might mature: - Dan Shapiro’s blog ‘Spicy autocomplete to dark factory’ takes inspiration from the standards used to assess autonomous driving to assess the stages of how vibe coding might integrate in an organisation. - Steve Yegge’s blog ‘Welcome to Gas Town' captured imaginations by proposing a maturity model and architecture based on a multi-agent 'town’, and also by trying to build it. Both of the above envisage different stages for the same core idea; vibe coding will evolve from being an aid to humans, to a point where no human has even looked at the code being run. This process will take time and won’t necessarily arrive evenly. I argue that it will spread mainly along 3 dimensions: - how complex the service is - how important the service is - how risk averse the organisation is Don't get me wrong, there are MANY issues today with vibe coding. Social media and blogs are awash with examples of rubbish code, horrific security, ‘slopsquatting' and other new types of attack. But as was the case with SaaS a decade or two ago, the business benefits on the table will be too strong to resist. I strongly suspect we'll see broad migration towards vibe coding along the above 3 axes, regardless of the security concerns. A mitigation that’s sometimes suggested is that organisations will simply say 'all code written by AI must be reviewed by a human’. But already that guidance is creaking at the seams for organisations that want to build aggressively. Over the next 5 years it will become increasingly common to see AI-written code in production systems that a human has never reviewed or even looked at. Getting security a seat at the table Some security professionals may be horrified by all this, but there is an opportunity here for us to shape the future. There is real excitement in organisations around vibe coding, but also a lot of nervousness. Even the name ‘vibe coding’ suggests it’s more suited to whimsical (rather than serious) applications. I think a challenge the security community will face is that no one yet knows exactly what we need to introduce to ensure the ‘vibe coded future’ is a safer one. There is a call to action here for the security community on research, and broad opportunities for new companies to emerge around this. If we face this challenge head on from the start, we have a chance to introduce some strong security fundamentals. More worryingly, if security professionals don’t lean in from the start, the landscape will evolve without this crucial input, as was arguably the case in the early years of cloud adoption. Some safeguards are obvious: - We need models to write code that is secure by default. - We need to be able to have confidence in the model provenance, and be able to trust and verify that it has not been developed in a way to maliciously introduce issues in code it produces. - We need to think about how we can use AI to review code, both existing human-written code, and that which will be written by AI. But there are also more nuanced considerations: - How do we use a deterministic architecture (that is, known controls implemented in rules and code, rather than expecting an AI to limit another AI) to limit what code can do even if it is malicious, compromised, or unsafe? - What platforms for hosting AI-generated services (and even human-generated ones) can we design to implement the controls above and protect the organisation and its data even if the code running is of poor quality? - How could we use AI to do the security hygiene we demand of critical services (such as documentation, test cases, fuzzing, permanently updating threat models), but for all software? Encouragingly, I know of one large organisation that has embraced vibe coding, and is already making sure that even the smallest project now has comparable test case coverage, automated security testing, and documentation, as they do for critical software they manually maintain. AI could also help with: - smaller tasks, like maintaining the allow-list of URLs an application is allowed to talk to - taking on the time-consuming hygiene at all development steps, such as refactoring for readability and full testing - huge tasks like rewriting critical components in a framework that protects from common security issues by default, or in a memory safe language There is a possible future where AI code ends up far more restricted (and locked down by default) than the best on-prem product or SaaS service ever was. Ironically, it may even present a solution to organisations still worried about the old concerns with cloud services, who have avoided migrating in all these years. The vibe future? Some of these ideas discussed here can be developed and made useful without waiting 5 years for the vibe future. As just one example, the ability to use AI to harden the hosting or code of a legacy (even end-of-life) critical application would pay off a lot of technical and security debt carried by an organisation. We are already seeing smaller, risk-tolerant startups vibe coding non-core SaaS replacements that do relatively simple things. We also see larger, more risk-averse organisations building tools that a single person or team uses, that might have once been just a feature in a SaaS. As the tech (and comfort with the tech) develops, I wager we’ll see ever more complex services, providing ever more important services, being developed by ever more risk-averse organisations. But as with cloud, this transition will take years rather than months. In 5-10 years, we can easily imagine that the SaaS services that will survive are those that have an inherent moat. That is, those services that can’t be easily replaced with a vibe-coded alternative, perhaps because their services have themselves become critical to a business, the service they provide is genuinely difficult to recreate, there are regulatory requirements they meet, or they simply have a critical mass of data across customers. Infrastructure-as-a-Service and Platform-as-a-Service are less likely to be affected because organisations will need somewhere to run their new vibe-coded applications (that preferably doesn’t involve racking servers). To clarify, this blog post is not advocating that we should all start vibe coding, or that there is no risk if organisations want to start doing it. Currently, there are risks that are likely far outside most organisations' risk tolerances. I think a lot of things will change over the next decade, but I also think that security folk need to start understanding the risks - and exploring the opportunities - now. I believe there is a future on the table where software at large is more secure than it is today. Vibe coding is following a similar pattern to cloud adoption 20 years ago, and will likely reshape how software is developed, deployed, and maintained. This presents the security community with an opportunity. We can either block it, as some tried (and failed to do) with the cloud, or we can get behind it and seize the benefits of a more productive and more secure future. With thanks to Alex Howells for discussions on this topic David Chismon CTO for Architecture Share and print this article Written by CTO for Architecture