The Platform Bet You Made Three Years Ago Is Now Your AI Problem

Earlier this year, a private equity firm we work with walked away from an acquisition it had spent months on. The target was a healthy business by the usual measures. What killed the deal was a judgment about its software: the firm decided the platform underneath it was too exposed to AI disruption to underwrite at the price on the table.

It sounds dramatic when you first say it out loud (we thought so too). But this isn't just the legacy software you bought or built twenty years ago. It's the bet you made three years ago, and it is now deciding how much you get out of AI, and potentially whether your business is worth buying. AI has simply exposed the problems that were already there. The cost of ignoring shows up later as AI projects stall, valuations slip, and competitors ship the feature you couldn't.

The bet sits on two layers

Let's break down the statement into two parts since there are a number of perspectives from which the statement can be considered true, and they lie on different layers.

The first is infrastructure and platform. These decisions made a few years ago now determine how quickly you can meaningfully adopt AI. Companies running on platforms like Salesforce, hyperscalers such as AWS, GCP, Azure, and using data tools like Snowflake or Databricks have data that's accessible and connectable. We can pipe that data into Data 360, and Agentforce can query it directly or run RAG across it. Companies running less connected systems and point solutions hit a wall the moment AI use cases are considered. The data is often there; getting to it isn't always so straightforward.

Heroku is another cautionary example. Salesforce acquired Heroku in 2010 and never really found a home for it; we watched the investment rise and fall over the years. A key Heroku proposition was cutting out the mundane work that running a solution on AWS, Azure, or GCP demands: reduced infrastructure management, smaller DevOps functions, and faster deployments. By cutting out that work, the pitch was that headcount and overhead costs would reduce, too. But in a world where AI can automate the mundane on our behalf, the moat around Heroku begins to erode. The End of Sale is not a surprise to those following closely. The questions now are for the companies that invested in it three, five, or ten years ago: what do they do next? What is their strategy for getting off Heroku without the move becoming its own multi-year project? And how do they get the same outcomes that Heroku promised, from a new generation of agentic tools?

Config-first may now be a handicap

The second layer is how things are built: the application layer. Three years ago, depending on your platform of choice, you probably had two options: an internal tool or an external service. The visual, declarative route: point-and-click low code builders like Flow in the Salesforce world, or Power Automate in Microsoft's. The other option is the programmatic route: Apex and Lightning Web Components, .NET, or Java. Frequently, the vendors steer builders toward the declarative route. Indeed, Salesforce's architecture documents describe Flow as "the preferred solution for low automation density."

The challenge we're beginning to recognize with this automation posture is that today's coding agents are far more proficient at writing code than at building a visual artifact like Flow, and they understand and interpret code much better than they understand and interpret a Flow. We know this first-hand, and we've experienced it anecdotally. When faced with proofs of concept and demos, many of us would much sooner lean on a coded approach, because the AI tools we're using simply appear to be better at it.

But the research also backs up these findings. We didn't want to rest on instinct, so we went looking. A paper from 2024 reached exactly the conclusion our experiences pointed to: "We find that metaprogramming results in more semantically correct generated code, given that the code is well-formed (i.e., is syntactically correct and runs)" (Zhang et al., 2024). Further research found analogous GUI tools "force LLMs to decompose high-level goals into lengthy, error-prone sequences of fine-grained actions, resulting in low success rates and an excessive number of LLM calls" (Wang, Li and Chen, 2025). The authors instead propose an abstraction layer through which an LLM conducts the high-level semantic planning, where it excels. These findings highlight what's abundantly clear: that we are experiencing a moment of massive technical evolution, and while one tool may be more effective today, this might not be true tomorrow.

So the honest read is not that the declarative is finished. It is that if you bet on triggers, classes, LWCs, all the codified areas of the platform, you are probably better placed to adopt coding agents today than if you had followed the point-and-click administrative path in years gone by. If your team leaned into Flow, Power Automate, or similar tools, that's worth an honest look now: which processes are locked into declarative tools an agent can't easily read or extend?

The clearest tell of a good bet is an API

The infrastructure layer has its own version of this, and the strongest signal of a good bet is something Salesforce has been saying from the very beginning. Both of us worked at Salesforce before the word ChatGPT existed in our vocabularies, and it was already in the marketing collateral: Salesforce is an API-first platform. The data, the metadata, and the functionality are exposed through (in most cases) well-documented APIs, which is exactly what an agent needs. Benioff has taken to saying that the API is your new UI, and the direction is headless: you never need to log in to Salesforce again. The companies that invested years ago in API-first, event-driven architecture are the leaders today, because tools like Claude and Codex can reach in and use what is there.

We see the inverse working with a global enterprise client where the APIs are not developed and/or documented well, and that is exactly where the work gets slow and expensive. AI did not make those APIs poor. It exposed how poor and undocumented they already were. On a separate project, we proved we can 'agentify' any API and stand up a working way for an agent to use it. As long as you have that API and the documentation, the rest is quick.

What this looks like to an investor

Investors are pricing this in already. One recent Forbes article, describing how AI upended the economics of legacy software modernization, cited the numbers: 75% reduction in modernization lead times, roughly 80% of legacy code consists of simple CRUD operations that AI can reliably auto-transpile. AI tools have matured to the point where they can accelerate modernization by 40% to 50% or more. These numbers have played out in our projects not as projections but as reality. Working with product companies, we keep observing time and time again how changing code becomes easy, and implementing that change across the customer base of hundreds can be a nightmare.

Another recent Forbes article, explaining how AI disrupted the investment map for tech investments, made the implication clear: new competitors can leverage foundation models, synthetic data generation, and rapid iteration to beat incumbents at their own game, and the investor's task is to distinguish structural resilience from structural fragility, as they say. What took ten years to build may erode in just two to three. The same math applies inside a company, not just to whoever's evaluating it: the gap between you and a faster-moving competitor comes down to how quickly you can act on what you already have.

The risks nobody should wave away

None of this is a clean story, and we wouldn't trust anyone who sold it as one. The obvious risk is hype versus reality. It is really easy to prototype something now with AI, and relatively easy to build a fully functional version. It is still hard to build something scalable that you can maintain and add to, and that is the part the demos skip. Yes, it has become easier to build software. The harder question is the strategy for what comes next: adding new features and maintaining the solution after it ships.

But the thing that matters more than scalability is security. It's easier than ever to release a solution that works, and it's equally easy to release something that is inherently dangerous without people being aware of it. Once the building task gets delegated to an entity that generates thousands of lines of code not written by you, it can't be ensured that everyone stops to ask themselves at each point all of the questions that a good developer should have asked: is field-level security used here, is this JWT token actually being verified or just decoded, is this query safe from SOQL injection? Those inside the Salesforce ecosystem will be all too familiar with cases of vulnerabilities this year: hundreds of org vulnerabilities traced back to missing field-level security, over-broad sharing, and Apex that never enforced authorization checks.

The third risk is slower and easier to ignore. The same agents that produce text slop across the internet can produce slop that lives as technical debt in your application. One prediction making the rounds is that services organizations like Aquiva, specializing in clean code and scalable solutions, will soon be asked to help untangle the mess created by AI. We are convinced the debt is real and that it gets built in fastest wherever agentic development is used irresponsibly. This is the work we do with clients before it becomes an incident: auditing what agentic development has already shipped, and fixing what it got wrong.

What comes next will keep moving the target. Today, the work might run through a CLI. Tomorrow may be MCP, and after that, some version of headless we're yet to experience. The flaw in thinking is assuming that the interface is what you are betting on. Interfaces are changing. What remains constant is the underlying technology: your data and functionalities available through an API, with code that is readable by your agents, and the security and maintenance of this technology. There is one question that remains open and relevant, and that is one that vendors like Salesforce, ServiceNow, or SAP themselves are now answering: whether the agentic layer on top of all of this will end up belonging to them, or will belong to some players that emerged out of thin air in the last two years. We do not know just yet. Teams that will survive either way are the ones that are paying close attention to the agentic evolution and are making the necessary business and technology changes right now.

If you're not sure whether your platform bet from three years ago is helping or hurting your AI plans, that's worth figuring out before you make the next one.

Talk to Aquiva about a platform and architecture review →