AI agents are starting to eat SaaS

Probably because Microsoft knows vibe coding is _not_ an actual viable way to build production ready code and does not want to deal with the liability issues of prompting customers to move from a working Excel sheet to a broken piece of software that looks like it works.

In my experience, it's actually quite hard to move a business from an excel sheet to software. Because an excel sheet allows the end user to easily handle every edge case and they likely don't even think in terms of "edge cases"

I miss MSAccess, but for the modern age. It has been replaced by basic CRUD using your platform of choice, but it's not as easy.

That would be similar to your solution, so either one would work.

I think that there might be some similar alternatives (maybe Airtable? probably using Lovable or Firebase counts) but nothing that is available for me for now.

You can use something like Salesforce as an app platform if you want. It lets you create "Custom Objects", which are basically tables, write queries, and so on.

It's just that the hassle of dealing with that platform tends to be similar to the hassle of setting up an app yourself, and now you're paying a per-user license cost.

Are you calling out Microsoft specifically or just in general any big tech company? Because Google can do this with Google sheets using Apps Script.

https://developers.google.com/apps-script/guides/web

Microsoft PowerApps has similar workflows for at least 2 years now. The professional development experience is lacking, however enterprise users can create many applications based on Excel files.

It’s possible to do this with excel cia azure or even tying it into power bi first.

I might be missing something but live edits in production and banking? Doesn't that violate all kinds of compliance controls?

> "we'll just build it internally" or "we can just throw it into an LLM" all of the time.

Is that a bluff used to negotiate the price?

> (3) an SLA/support that's more than "random dev isn't on PTO"

Why do they have an internal engineering org at all if they can't manage the most basic maintenance of a software product?

The OSS point doesn't apply to every vertical. Open source applications come about when developers scratch their own itch. Developer tools, infrastructure, general purpose CRMs, project management get OSS alternatives because developers use them and want to build them.

Nobody is building open source software for [niche professional vertical] in their spare time. It's not mass market. It's not something a developer encounters in their daily work and thinks "I could do this better." The domain knowledge required to even understand the problem space takes months to acquire, and there's no personal payoff for doing so.

The "OSS will appear" prediction works for horizontal tools. For deep vertical SaaS, the threat model is different: it's other funded startups or internal enterprise clones (both of which we've already faced and won against).

Yes. This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature.

It's an ugly truth product owners never wanted to hear, and are now being forced to: nobody wants software products or services. No one really wants another Widgetify of DoodlyD.oo.io or another basic software tool packaged into bespoke UI and trying to make itself a command center of work in their entire domain. All those products and services are just standing between the user and the thing the user actually wants. The promise of AI agents for end-users is that of having a personal secretary, that deals with all the product UI/UX bullshit so the user doesn't have to, ultimately turning these products into tool calls.

The president of a company I work with is a youngish guy who has no technical skills, but is resourceful. He wanted updated analytic dashboards, but there’s no dev capacity for that right now. So he decided he was going to try his hand at building his own dashboard using Lovable, which is one of these AI app making outfits. I sent him a copy of the dev database and a few markdown files with explanations regarding certain trickier elements of the data structure and told him to give them to the AI, it will know what they mean. No updates yet, but I have every confidence he’ll figure it out.

Think about all the cycles this will save. The CEO codes his own dashboards. The OP has a point.

The Excel holy grail. Dashboard are an abstraction, SaaS is an abstraction of an abstraction from the pov of customers suffering from a one size fits all. Shell scripts generated by LLMs that send automated a customized reports via email will make a lot of corporate heros. No need to login, learn and use the SaaS in many instances for decisions makers.

Also, for many larger companies, access to internal data and systems is only granted to authorized human users and approved applications/agents. Each approval is a separate request.

This means for any "manual" or existing workflow requiring a access to several systems, that requires multiple IT permissions with defined scopes. Even something as simple as a sales rep sending a DocuSign might need:

- CRM access

- DocuSign access

- Possibly access to ERP (if CRM isn't configured to pass signed contract status and value across)

- Possibly access to SharePoint / Power Automate (if finance/legal/someone else has created internal policy or process, e.g. saving a DocuSign PDF to a folder, inputting details for handover to fulfilment or client success, or submitting ticket to finance so invoicing can be set up)

Skills seem to be promising.

I never understood the evolvement around agents, they just appeared to me as Python scripts initially (Crewai 2-3 years ago).

The question is can people see that agents will evolve? Similar to how software evolves to handle the right depth of granularity.

There are plenty of HN posts where I only read the comments because the discussion around that topic is the most interesting part.

Agreed. I've been on HN for 15 years, and IME maybe 90% of the value has come directly from comments (another 5% from links in commenters' profiles, and 5% from TFAs).

As a solo grumpy senior, I've been pumping out features over the past 6 months and am now expanding into new markets.

I've also eliminated some third party SaaS integrations by creating slimmer and better integrated services directly into my platform. Which is an example of using AI to bring some features in-house, not primarily to save money (generally not worth the effort if that's the goal), but because it's simply better integrated and less frustrating than dealing with crappy third-party APIs.

> Which I don't think can be replaced by AI in a lot of cases

Yes. I try to visit my customers as often as I can, to learn how they work and to see the production processes on site. I consider it to be one of the most valuable things I can do for the future of my business.

I would include this in the "spreadsheet" metaphor. I do not know your use case, so please don't take this as addressed to you specifically, but I found that there is a learning/complexity problem: many people do not realize there is much more to inventory and production management than it seems. It might seem easy to AI-code something, only to find out later that things could have been done much better.

This is actually a serious problem for me: my SaaS has a lot of very complex functionality under the hood, but it is not easily visible, and importantly it isn't necessarily appreciated when making a buying decision. Lot control is a good example: most people think it is only needed for coding batches of expiring products. In reality, it's an essential feature that pretty much everyone needs, because it lets you treat some inventory of the same part (e.g. a reel) differently from other inventory of this part (e.g. cut tape) and track those separately.

AI-coding will help people get the features they know they need, but it won't guide them to the features they don't know they could use.

First, I'll second that I've applied agentic LLMs to an open source project to fix bugs and forcibly coerce it to act in ways that the maintainer may or may not approve of. It has been remarkablely effective, so long as I'm willing to apply patches or maintain a fork of the project (trivial, since this particular open-source project is abandoned anyway).

That said, the act of doing this- using LLMs to dominate somebody's legitimately intelligent and unique work- feels not only discourteous, but worse, like it's a short-term solution.

I'm convinced that it's a short-term solution NOT because I don't think that LLMs can continuously maintain these projects, but because open-source itself is going to be clawed back. The raison d'être of open-source is personal pride, hiring, collaboration, enjoyment, trust, etc. These motivations make less sense in an LLM-fueled world.

My prediction is that useful and well maintained open-source projects like we're hijacking will become fewer and far between.

Won't this breakdown if you need to pull new changes from the original project?

Clojure is just better than CL in pretty much every respect. Excellent and well designed standard library, great concurrency primitives, core.async, built-in transducers (CL has SERIES which does a kind-of similar thing, but isn't as well designed and integrated) and the dominant immutability all let me write more maintainable code. Also, I can re-use model code on the client side (ClojureScript), so there is lots of code sharing, and I don't have to serialize to a crippled format (JSON), my data can pass from server to client and back intact (with sets, keywords, and other rich data types).

I used to love CL and wrote quite a bit of code in it, but since Clojure came along I can't really see any reason to go back.

> So the simpler problem is that your product now becomes merely a tool call for AI agents. That's what users want.

This is a big assumption, and not one I've seen in product testing. Open-ended human language is not a good interface for highly detailed technical work, at least not with the current state of LLMs.

> It's the same reason why API access to SaaS is usually restricted or not available for the users except biggest customers.

I don't... think this is true? Of the top of my head, aside from cloud providers like AWS/GCP/Azure which obviously provide APIs: Salesforce, Hubspot, Jira all provide APIs either alongside basic plans or as a small upsell. Certainly not just for the biggest customers. You're probably thinking of social media where Twitter/Reddit/FB/etc don't really give API access, but those aren't really B2B SaaS products.

Hmm. I think none of what you wrote is applicable to my specific SaaS.

> Many (most, I imagine) users would prefer to hire an assistant to operate that UI for them, since UI is not the actual value your service provides

That's ridiculous. A good ui will improve on assistant in every way.

Do assistants have some use? Sure—querying.

I don't think that's entirely correct. You can do TDD style development with AI and it leads to better results.

It's just that messing with a company's core manufacturing is something they don't do lightly. They work with multiple shifts of staff that are supposed to work in these environments. People generally don't have a lot of computer skills, so things need to be simple, repeatable, and easy to explain. Any issues with production means cost increases, delays happen, and money is lost.

That being said, these companies are always looking for better ways to do stuff, to eliminate work that is not needed, etc. That's your way in. If there's a demonstrable ROI, most companies get a lot less risk averse.

That used to involve bespoke software integrations. Those are developed at great cost and with some non trivial risk by expensive software agencies. Some of these projects fail and failure is expensive. AI potentially reduces cost and risk here. E.g. a generic SAP integration isn't rocket science to vibe code. We're talking well documented and widely used APIs here. You'd want some oversight and testing here obviously. But it's the type of low level plumbing that traditionally gets outsourced to low wages countries. Using AI here is probably already happening at a large scale.

"Wake me up when we see swaths of companies AI-coding internal Jira".

This shouldnt be the goal. The goal should be to build an AI that can tell you what is done and what needs to be done i.e. replace jira with natural interactions. An AI that can "see" and "understand" your project. An AI that can see it, understand it, build it and modify it. I know this is not happening for the next few decades or so.

Analytics like what?! Sentry? See, i'm the first one to waste 15+ hours of my own time claude vibing some barely working analytics in order to save 15 dollars for not paying a proven solution to professionals who really understand that problem domain - but we all agree how dumb this is. But if i really can vibe code that analytics in 5 minutes, that thing was never a proven SaaS business in the first place and my use case with certainty a toy app with zero users..

The value proposition of SaaS is ultimately just that it's not a hack.

Most SaaS products could be replaced by a form + spreadsheet + email workflow, and the reason they aren't is that people don't want to be dealing with a hacky solution. Devs can hack together a nice little webapp instead of a network of spreadsheets, but it's still a hack. Factoring in AI assistance, perhaps SaaS is now competing with "something I hacked together in a week" as opposed to "something I hacked together in a month," but it's a hack either way.

I am absolutely going to pay for analytics and dashboards, because I don't want the operational concerns of my Elasticsearch analytics cluster getting in the way of the alarm that goes off when my primary database catches fire. Ops visibility is too important to be a hack, regardless of how quickly I could implement that hack.

Yes, because then I know the code is properly engineering, tested, maintained and supported.

Generating code is one part of software engineering is a small part of SaaS.

In my experience, SaaS is also fragile. It's real software, with real bugs. Most complex solutions offer an extensible API/scripting support with tons of switchable/pluggable modules to integrate with your company's infra. This complexity most often means that your particulary combination of features is almost wholly unique, and chances are your SaaS has much less open mindshare/open source support than any free solution.

We often ended up discarding large chunks of these poorly tested features, instead of trying to get them to work, and wrote our own. This got to a point where only the core platform was used, and replacing that seemed to be totally feasible.

SaaS often doesn't solve issues but replaces them - you substitute general engineering knowledge and open-source knowhow with proprietary one, and end up with experts in configuring commercial software - a skill that has very little value on the market where said software is not used, and chains you to a given vendor.

> Everything was a little bit fragile in subtle ways.

Maybe write some tests and have great software development practices and most importantly people who care about getting the details right. Honestly there’s no reason for software to be like this is there? I don’t know how much off the shelf ERP software you have used but I wouldn’t exactly describe that as flawless and bug free either!

> The reality is that software license costs is a tiny fraction of total business costs

Yes and no. If someone is controlling the SaaS selection, then this is true.

But I've seen startup phase companies with multiple slightly overlapping SaaS subscriptions (Linear + Trello + Asana for example), just because one PM prefers one over the other.

Then people have bought full-ass SaaS costing 50-100€/month for a single task it does.

I'd describe the "Use AI to make bespoke software" as the solution you use to round out the sharp edges in software (and licensing).

The survey SaaS wants extra money to connect to service Y, but their API is free? Fire up Claude and write the connector ourselves. We don't want to build and support a full survey tool, but API glue is fine.

Or someone is doing manual work because vendor A wants their data in format X and vendor B only accepts format Y. Out comes Claude and we create a tool that provides both outputs at the same time. (This was actually written by a copywriter on their spare time, just because they got annoyed with extra busywork. Now it's used by a half-dozen people)

> Soon or later the CTO will be dictating which projects can be vibe coded which ones make sense to buy.

A lot of the SaaS target companies won't even have a CTO

Right, so totally cool to ignore the law but our TOS is a binding contract.

I bet companies are circumventing this in a way that allows them to derive almost all the benefit from your data, yet makes it very hard to build a case against them.

For example, in RL, you have a train set, and a test set, which the model never sees, but is used to validate it - why not put proprietary data in the test set?

I'm pretty sure 99% of ML engineers would say this would constitute training on your data, but this is an argument you could drag out in courts forever.

Or alternatively - it's easier to ask for forgiveness than permission.

I've recently had an apocalyptic vision, that one day we'll wake up, an find that AI companies have produced an AI copy of every piece of software in existence - AI Windows, AI Office, AI Photoshop etc.

Given the conduct we've seen to date, I'd trust them to follow the letter - but not the spirit - of IP law.

There may very well be clever techniques that don't require directly training on the users' data. Perhaps generating a parallel paraphrased corpus as they serve user queries - one which they CAN train on legally.

The amount of value unlocked by stealing practically ~everyone's lunch makes me not want to put that past anyone who's capable of implementing such a technology.

it is amazing in almost 2026 there is anyone believing this… amazing

I wonder how much wiggle there is for collect now (to provide service, context history, etc), then later anonymise (some how, to some level) and then train on it?

Also I wonder if the ToS covers "queries & interaction" vs "uploaded data" - I could imagine some tricky language in there that says we wont use your word document, but we may at some time use the queries you put against it, not as raw corpus but as a second layer examining what tools/workflows to expand/exploit.

Well, perhaps this is naive of me from the perspective of not fully understanding the training process. However, at some point, with all available training data having been exhausted, gains with synthetic data exhausted, and a large pool of publicly available AI generated code, at what point is it 'smart' to scrape codebases from what you identify as high quality code based, clean it up to remove identifiers, and use that for training a smaller model?

Do you have a source for this?

There are claims all through this thread that “AI companies” are probably doing bad things with enterprise customer data but nobody has provided a single source for the claim.

This has been a theme on HN. There was a thread a few weeks back where someone confidently claimed up and down the thread that Gemini’s terms of service allowed them to train on your company’s customer data, even though 30 seconds of searching leads to the exact docs that say otherwise. There is a lot of hearsay being spread as fact, but nobody actually linking to ToS or citing sections they’re talking about.

It could be a wide range of things depending on your field: highly particular materials, knowledge or processes that give your products or services a particular edge, and which a company has often incurred high R&D costs to discover.

Many businesses simply couldn't afford to operate without such an edge.

Companies have already shifting from not using customer data to giving them an option to opt out ex:

“How can I control whether my data is used for model training?

If you are logged into Copilot with a Microsoft Account or other third-party authentication, you can control whether your conversations are used for training the generative AI models used in Copilot. Opting out will exclude your past, present, and future conversations from being used for training these AI models, unless you choose to opt back in. If you opt out, that change will be reflected throughout our systems within 30 days.” https://support.microsoft.com/en-us/topic/privacy-faq-for-mi...

At this point suggesting it has never and will her happen is wildly optimistic.

> LLMs don’t “learn” from the information they operate on, contrary to what a lot of people assume.

Nothing is really preventing this though. AI companies have already proven they will ignore copyright and any other legal nuisance so they can train models.

Information about the way we interact with the data (RLHF) can be used to refine agent behaviour.

While this isn't used specifically for LLM training, it can involve aggregating insights from customer behaviour.

They are not directly ingesting the data into their trainning sets but they are in most cases collecting it and will be using it to train future models.

If they weren't, then why would enterprise level subscriptions include specific terms stating that they don't train on user provided data? There's no reason to believe that they don't, and if they don't now then there's no reason to believe that they won't later whenever it suits them.

Just read the ToS of the LLM products please

> You will find a lot of conspiracy theories claiming that companies are saying one thing but secretly stealing your data, of course.

It's not really a conspiracy when we have multiple examples of high profile companies doing exactly this. And it keeps happening. Granted I'm unaware of cases of this occuring currently with professional AI services but it's basic security 101 that you should never let anything even have the remote opportunity to ingest data unless you don't care about the data.

> It took me no more than 2 hours to put those together. We didn't renew our TeamRetro

Okay, so two hours with an LLM vs maybe 2.5 days without an LLM in the best-case scenario (i.e. LLMs gave you a 10x boost. I would expect it to be less than that though, like maybe a 2x boost) - it sounds like it was always pretty cheap to replace the SaaS, but the business didn't do it.

TBH, the arguments were never "It would take too long to do ourselves", it was always "but then we'd have to maintain it ourselves".

The place I am consulting at now just moved (i.e. a month ago) from their in-house built ticketing system ($0/m as it had not needed maintenance for over a year) to Jira (~$2k/m).

In this specific case, it was literally 0 hours to avoid paying the SaaS, and they still moved, because they wanted some modern features (billing for time on support calls, etc) and figured that rather than update their in-house system to add support hours costing (a day, at most) they may as well move to a system that already had it.

(Joke's on them though - the Jira solution for support hours costing is not near the level of granularity they need, even with multiple paid plugins).

Once again, companies aren't using SaaS because it's cheaper or quicker; they could already quickly replace their SaaS with in-house.

How is teamretro a product to begin with? I feel like these SaaS’s exploded like js libraries.

Or just don’t do retro and save even more time and money!

If you're a typical software engineer, that time probably cost your company more than $240.