Two weeks ago, our team was at JSNation and React Summit 2026 in Amsterdam.
Across 33 sessions, engineers from companies like Netflix, monday.com, and Meta described what AI is already doing to enterprise software right now, not what it might do someday. The pattern that emerged across nearly every talk had very little to do with which model performed best. It had to do with which organizations had built the business process to use AI safely, and which ones were still treating it as a tool you hand an engineering team and hope for the best.
That distinction is the point of this blog. Because the gap it's creating between enterprises isn't theoretical, and it isn't slow. It is already showing up in how quickly companies can modernize old systems, how safely they can adopt AI internally, and how prepared they are for a world where customers may no longer reach them through the same digital channels they built the last decade around.
What is this blog about?
This blog breaks down three shifts in enterprise software that surfaced repeatedly across JSNation and React Summit 2026: the new economics of legacy systems, the operational risk most companies are carrying without realizing it, and a structural shift in how customers and partners will reach digital products at all. Each one is a business risk before it's a technical one, which is exactly why it tends to get missed.
The common thread across all three is that AI is not creating the same advantage for every organization. The companies that treat it as another tool in the developer stack may get some productivity gains. The companies that treat it as a business process change are the ones starting to open a much larger gap.
Trying to figure out where your organization actually stands on AI adoption? Book a FREE call.
AI Is Changing the Economics of Enterprise Technical Debt
The clearest data point from JSNation came from monday.com, who described a client-side migration that had been quoted at eight years of manual work, a timeline that, for most businesses, simply means "we will never fix this." Using a custom AI orchestration engine, they're migrating production code daily, on a six-month timeline, at a projected cost of roughly $200,000.
That is not just a development story. It is an economic one.
For years, many companies have treated major migrations as something they know they should do, but cannot justify. The system is too entangled. The internal knowledge is too spread out. The roadmap is already full. The migration would take too long, cost too much, and create too much operational risk while the business is still trying to run.
AI changes that calculation for the companies that know how to use it properly.
Why does AI-assisted legacy migration matter to enterprises?
Every organization with a codebase older than a few years has a system everyone has agreed not to touch, because touching it has always been too expensive to justify. That calculation just changed for companies that know how to run this kind of migration responsibly. It hasn't changed for companies that don't.
That last part matters. AI does not automatically make legacy systems cheaper to fix. It makes them cheaper to fix for organizations that can break the work down, control the risk, and validate the output as they go. For everyone else, the migration is still just as dangerous as it was before, only now competitors may have a way to move past the same blockers faster.
What made monday.com's result possible wasn't a more powerful model. It was a structured process: mapping the full dependency graph before touching anything, migrating from the safest, least-connected files inward, and breaking every change into narrow, well-scoped steps rather than one large rewrite. That structure is what kept 40,000 file changes from turning into 40,000 new problems.
This is the part enterprises should pay attention to. The AI was not trusted because it was AI. It was trusted because the work around it was designed carefully enough to make each step small, checkable, and recoverable. That is the difference between using AI to accelerate a risky rewrite and using AI to make a rewrite operationally possible.
Why does technical debt matter for AI adoption?
This is a window, not a permanent advantage. The enterprises that build this orchestration capability now get to revisit architecture decisions their competitors have written off as too risky to attempt. The ones that don't are stuck paying the slow, compounding tax that old systems have always charged, while their competitors quietly stop paying it.
That tax shows up everywhere. It shows up when a feature takes three months because the old system was not designed for it. It shows up when integrations are avoided because the architecture is too fragile. It shows up when teams keep building workarounds instead of fixing the underlying problem. It shows up when the business wants to move faster, but the software cannot follow.
AI-assisted migration does not remove the need for technical judgment. It makes that judgment more valuable, because the companies that know where to apply AI, where to constrain it, and where to validate it can start turning previously impossible modernization work into a practical business decision.
Curious whether a legacy system you've written off is actually more fixable than you think?
Talk to Calda about your migration
Unmanaged Enterprise AI Adoption Is Becoming a Business Risk
Here's the uncomfortable finding underneath nearly every talk at both conferences, stated by completely unrelated speakers, in completely unrelated contexts:
AI generates. Deterministic systems validate.
The organizations getting real results from AI were not the ones with the most advanced prompting techniques. They were the ones who had already built the infrastructure to catch AI when it gets something wrong, things like dependency graphs, automated test coverage, design system conventions, and structured review pipelines. Netflix's engineering team made the point directly during their talk on internal standardization: the hard part was never the framework. It was adoption, meaning the documentation, playbooks, and support structure that make a standard actually stick across an organization.
That is the part most enterprise AI conversations skip over. The visible part of AI adoption is the tool. The invisible part is the system that determines whether the tool can be trusted. Without that system, more output does not necessarily mean more progress. It can just mean more things being produced faster than the organization can properly understand, review, or maintain.
Why does unmanaged AI adoption happen?
Most enterprises right now are in an unmanaged middle state. Individual teams are adopting AI tools independently, without shared conventions, without a validation process, and without a clear answer to what AI is allowed to touch unsupervised versus what requires human review. It looks like progress because output is increasing. What's actually happening underneath is that velocity is increasing while institutional understanding of what's being shipped is quietly decreasing.
This happens naturally. Teams are under pressure to move faster, AI tools are easy to access, and early results often look impressive. A developer can produce a working draft faster. A product team can create a specification faster. A support team can generate answers faster. None of that is wrong by itself.
The problem starts when every team creates its own AI habits without the company defining what safe usage actually means. One team may let AI write production code with light review. Another may use it only for drafts. Another may connect it to internal data. Another may forbid it entirely. From the outside, the company looks like it is adopting AI. Internally, it may be creating a patchwork of practices nobody fully owns.
Why does AI validation matter in enterprise software?
Engineers at the conference described this gap plainly: companies are getting faster at producing code without getting better at understanding it. That isn't a productivity win. It is deferred risk, and most organizations do not currently have a clear way to track it. It tends to surface at the worst possible moment, six months in, when nobody on the team can explain why a system behaves the way it does.
This is especially dangerous because AI output often looks complete. It can be well-formatted, plausible, and technically fluent, even when the underlying assumption is wrong. That makes it easy for teams to move past the review step too quickly, especially when the pressure is to ship.
In enterprise software, the cost of being wrong is rarely isolated to one file or one feature. A bad assumption can affect customer experience, reporting, operations, permissions, compliance, or internal decision-making. The risk is not that AI makes mistakes. The risk is that the organization does not have the process to notice those mistakes before they become part of the system.
How do enterprises prevent AI risk?
The fix isn't slowing down AI adoption. It's building the same kind of structure monday.com built for their migration: clear conventions, automated validation, and a defined line between what AI can do unsupervised and what needs a human in the loop before it ships. This is precisely the layer most internal engineering teams are not resourced to build while also shipping their regular roadmap, and it's the layer that determines whether AI adoption compounds into capability or compounds into risk.
That layer does not need to be overcomplicated, but it does need to exist. Companies need to define which AI uses are low risk, which ones need review, which ones require testing, and which ones should not happen without a stronger governance model. They need shared standards for documentation, code review, acceptance criteria, and validation. They need a way to turn successful AI usage into repeatable practice instead of one-off team experiments.
The goal is not to make AI slower. The goal is to make the speed usable.
Not sure whether your team's current AI usage is creating more risk than value?
Book a FREE call with Calda and we'll help you find out.
AI Agents Are Changing How Customers Reach Enterprise Products
The third shift is the one fewest enterprise roadmaps currently account for, and it came from a talk on a protocol called MCP (Model Context Protocol), an open standard originally published by Anthropic and increasingly adopted across the industry for how AI assistants connect to external services.
The thesis presented at JSNation was direct: the web is going "nearly headless." Autonomous agents are increasingly handling interactions through structured protocols rather than a person clicking through a browser. A "last mile" of human-required moments still remains, confirming a purchase, reviewing something high-stakes, but the default path to a service is starting to route through an AI agent acting on someone's behalf, not a homepage.
For most enterprises, this is still a strange idea because digital strategy has been built around the assumption that a human comes to your website, opens your app, reads your interface, and clicks through your flow. That assumption is not disappearing tomorrow, but it is starting to weaken. If an assistant can understand the user's intent, interact with services directly, and only show the person what they need to approve or decide, the shape of the customer journey changes.
Why does agent-ready software matter?
This same idea surfaced independently at React Summit, in a completely separate talk about generative interfaces, where the UI itself is composed by a model at the moment of the request rather than built ahead of time by a developer. Two unrelated parts of the industry arrived at the same architectural shift from different directions. That's usually a signal worth paying attention to.
The implication is not that every enterprise app will disappear. It is that the interface may stop being the primary entry point in every interaction. In some workflows, the agent may become the first user. The human may only appear when judgment, confirmation, comparison, or trust is required.
That changes how companies need to think about access, structure, data, permissions, and product design. If your systems are only built for humans clicking through screens, they may be harder for AI assistants to understand and use. If your services are exposed in a structured and controlled way, they become easier to participate in agent-driven workflows.
Enterprises whose digital strategy assumes a human is always the one driving the browser are building on an assumption that's actively eroding. The organizations already exposing their tools, data, and services in a structured, agent-readable way are better positioned for a future where AI assistants help customers decide who to interact with, buy from, or work with. The ones that aren't are betting their entire digital channel stays exactly the shape it is today.
This will not affect every industry at the same speed. But the direction matters. If customers, employees, and partners begin delegating more digital work to assistants, companies will need to make sure their products and services can be understood, accessed, and trusted in that environment. Agent-readiness will not just be a technical upgrade. It will become part of how a business stays reachable.
Wondering what it would take for your business to be agent-ready? Talk to Calda about what this shift means for your roadmap.
Where Calda Fits in Enterprise AI Strategy
This is exactly why we were at JSNation and React Summit in the first place, and it's worth being direct about it. Calda's business isn't writing code. It's helping enterprises make the right decisions before, during, and after that code gets written, which is precisely the layer every talk at both conferences kept circling back to.
The pattern is consistent across every example in this blog. monday.com didn't get an 8-year migration down to 6 months by having a better model than everyone else. They got there by having the orchestration discipline to map the dependency graph first, sequence the work safely, and validate every step. Netflix didn't make standardization work by writing a better framework. They made it work by investing in adoption, playbooks, documentation, and support structure. In every case, the technology was available to everyone. The differentiator was the business process wrapped around it.
That is the layer most enterprises do not have in-house. Not because their engineering teams are not capable, but because those teams are usually measured on shipping the roadmap, not redesigning the operating model around AI. Building that layer requires stepping back from immediate delivery pressure to ask harder questions: What should AI touch unsupervised in your organization, and what shouldn't it? Which of your legacy systems just became economically viable to fix? Is your business ready to be found and transacted with by an AI agent, not just a person on a browser?
Those aren't engineering questions first. They're business questions with engineering consequences, and answering them is what we do.
Want an honest read on where your organization stands, and what the next right move actually is? Book a FREE call.
Enterprise AI Adoption FAQ
1. What does "agent-ready" actually mean for an enterprise?
It means your tools, data, and services can be discovered and used by AI assistants acting on a customer's or partner's behalf, not just by a person navigating your website or app manually. Practically, this involves exposing structured access through protocols like MCP rather than assuming every interaction starts with a human clicking through a traditional interface. Enterprises that get ahead of this are positioning themselves for a future where AI agents help customers and partners decide who to interact with.
2. How do we know if our current AI adoption is creating risk instead of value?
The clearest warning sign is velocity without understanding, meaning your teams are shipping AI-generated output faster than anyone can explain or validate what it's actually doing. If AI tools are being adopted independently across teams without shared conventions, without a defined validation process, and without clarity on what requires human review, the volume of output you're seeing is not a reliable signal of progress. It's worth an honest audit before that gap widens further.
3. Is the kind of migration monday.com described realistic for a mid-sized enterprise, or only companies at that scale?
The scale of the migration changes, but the underlying approach doesn't. The discipline that made their result possible, mapping dependencies before touching anything, sequencing changes from safest to riskiest, and validating every step with deterministic checks rather than trusting AI output blindly, applies regardless of whether you're migrating 40,000 files or 4,000. What matters is whether the process is structured, not how large the codebase is.
4. We already have an engineering team. Why would we need outside help with this?
Most internal engineering teams are resourced to ship the roadmap, not to step back and build the governance, validation, and orchestration layer that makes AI adoption safe at scale. That's a different skill set, and often a different kind of bandwidth, than maintaining a product roadmap. It's also easier to get right with outside perspective, since the teams closest to a codebase are often the ones least likely to notice where unmanaged AI use has already introduced risk.
5. Where should we actually start?
Start with an honest look at where AI is already being used across your organization, formally or informally, and what oversight currently exists around it. From there, the highest-leverage starting points are usually the legacy systems that have been written off as too expensive to touch, and the customer-facing or partner-facing systems where being agent-ready will matter soonest. That's also exactly the conversation worth having with us before deciding where to invest first.