Every organisation is being told some version of the same thing: use AI to move faster.
That instruction is not wrong. AI coding tools can now turn a prompt into a working application with the kind of speed that would have looked absurd a few years ago. For executives, that makes the pitch almost irresistible: more internal tools, more workflow automation, more customer-facing apps, and more experiments that actually run.
The problem is that "it runs" is not the same thing as "it is safe to run inside a business."
A working demo is the start of the obligation, not the end of it. The moment an application touches customers, employees, operational data, health data, financial data, bookings, orders, approvals, or compliance evidence, it becomes part of the organisation's software estate. It has to be secured, tested, patched, documented, upgraded, integrated, monitored, supported, handed over, audited, and changed.
AI made the app easier to create. It did not make the app disappear from the maintenance ledger.
That is the core argument of our new whitepaper, The Hidden Cost of AI Application Delivery. We built the same application two ways: once as raw AI-generated code, and once using Buzzy's semantic application platform. Then we looked past the first working version and asked the question that matters more: what does the organisation have to maintain afterwards?
The answer was not subtle.
The benchmark: an Airbnb-style app, two ways
The test application was ShortStay, an Airbnb-style short-stay marketplace. It was deliberately not a toy CRUD app. It included guest discovery and search, property detail pages, maps, booking flows, availability calendars, host listing management, and administrative workflows.
The raw AI-generated version worked. That is important. This is not an argument that AI coding tools cannot produce useful software. They can.
But the raw-code build reached feature parity at roughly 5,200 lines of application code, or about 6,200 lines including tests. It also brought along 50+ direct and transitive dependencies, a database lifecycle, infrastructure obligations, a custom security surface, a test suite, and the usual operational chores that make software expensive long after the first demo.
An independent audit of the hardened raw-code build found one critical vulnerability and seven additional issues. A routine dependency check also found a high-severity issue in the build toolchain that required a breaking upgrade. In other words, the app had barely been born before it already had a maintenance calendar.
This is not unusual. This is software.
Now scale that pattern. One generated application with 5,200 lines is manageable. Ten similar apps is roughly 52,000 lines of customer-maintained application code. Fifty similar apps becomes about 260,000 lines, plus dependencies, tests, security reviews, handovers, patch cycles, and framework upgrades.
Even if a Buzzy app still needs some custom extension code for backend integrations, bespoke widgets, or genuinely unique business logic, the footprint is much smaller. In the whitepaper's conservative modelling, we use a 5% custom-extension assumption. That means a ShortStay-like app would carry around 260 lines of app-specific extension code, not 5,200 lines of generated application code.
At 50 apps, that is the difference between roughly 260,000 lines and 13,000 lines of app-specific custom code.
The claim is not that custom code vanishes. It is that the custom-code surface becomes smaller, more explicit, and easier to govern. That distinction matters.
Technical debt has become a management category
For years, "technical debt" was treated as something engineering teams complained about when they wanted more refactoring time. That framing is obsolete.
Gartner now has a Magic Quadrant for Technical Debt Management Tools. More importantly, Gartner expects architectural technical debt to account for a large share of all technical debt by 2027 and estimates the technical debt management tools market will reach $1.2 billion in annual revenue by the end of 2026. Technical debt is no longer just a developer productivity issue. It is becoming a board-level operating risk.
The whitepaper uses a simple Technical Debt Index to describe where the liability accumulates:
Structural debt is the code quality, architecture, and data model problem.
Operational debt is the test coverage, CI/CD, release, security, vulnerability, and uptime problem.
Organisational debt is the documentation, handover, vendor dependency, developer friction, and product lifecycle problem.
Raw AI-generated applications can increase all three.
They can create structural debt because each app gets its own generated architecture, naming conventions, dependency choices, data model decisions, and edge-case logic. They can create operational debt because every app needs its own testing, patching, security review, release pipeline, monitoring, and incident response. They can create organisational debt because understanding often lives inside generated code, supplier habits, or developer-specific decisions rather than in an explicit application model.
This is why "we outsource development" does not solve the problem. Outsourcing changes who writes the software. It does not change who is accountable for security, uptime, compliance, data protection, user experience, or the cost of future change.
You can outsource development effort. You cannot outsource the consequences of the system existing.
The alternative: stop generating the common parts
The Buzzy model starts from a different premise.
Instead of generating a fresh bespoke codebase for every application, Buzzy creates a semantic application definition: a structured model of the app's brief, flows, blueprint, data model, theme/design system, screens, permissions, tests, integrations, APIs, and agentic flows.
That definition runs on a maintained core engine.
The practical difference is that common application capabilities do not need to be regenerated for every project. Forms, lists, dashboards, calendars, bookings, maps, search, permissions, data handling, security patterns, compliance assessment, testing capability, APIs, and MCP or agentic flows can be handled as platform capabilities rather than scattered across dozens of bespoke codebases.
This is the architectural move that matters: separate application intent from implementation burden.
The application definition becomes the control plane. It contains the documentation, requirements, data model, workflows, security assumptions, design system, and behavioural intent in a form that humans and AI can inspect without spelunking through thousands of lines of generated code.
That also changes how security, compliance, and testing work. Because Buzzy has deeper knowledge of the application definition, it can reason about the intended flows, permissions, data model, and behaviours directly. Security and compliance assessment are not just after-the-fact scans over an opaque codebase. Testing is not merely a test suite bolted on after the app exists. The system has the app's intent as part of the application model.
That is a very different maintenance posture.
The real portfolio problem
The mistake is to evaluate AI-generated apps one at a time.
For one app, almost anything can look fine. A small team can nurse the codebase along. A developer can patch dependencies. A vendor can write documentation. A security issue can be triaged. A test suite can be expanded.
But AI adoption is not going to create one app. It is going to create many.
A sales ops team wants a workflow app. Finance wants a compliance tracker. HR wants onboarding automation. Operations wants fleet visibility. Customer success wants a portal. A partner wants an integration layer. A business unit wants something that looks suspiciously like a SaaS product.
AI lowers the activation energy for all of it.
That is the opportunity. It is also the trap.
If every one of those apps becomes a separate codebase, then the organisation has not just adopted AI. It has created an accidental software portfolio with inconsistent architecture, uneven documentation, different dependency trees, duplicated logic, fragmented controls, and a maintenance burden that grows with every successful experiment.
Buzzy's argument is not "never write code." That would be unserious.
There are still cases where raw code is exactly the right answer: genuinely novel systems, deep algorithmic IP, infrastructure-level products, or anything where the implementation itself is the differentiated asset.
But most business applications are not that. They are workflows, data models, permissions, forms, dashboards, integrations, mobile experiences, and operational rules. The business value is in the workflow and the speed of adaptation, not in hand-maintaining another custom implementation of a calendar, booking engine, search view, permissions model, or API layer.
For those applications, the goal should be simple: build more capability while maintaining less bespoke code.
The production evidence matters
The benchmark is useful because it gives us a controlled comparison. But real systems matter more.
Buzzy has already been used in production contexts that look a lot like the problem the whitepaper describes. A healthcare coordination platform moved from 100+ Figma screens to a base product in about four days, using one foundation across web, iOS, and Android, with single-tenant deployment for compliance needs and more than 30 patches plus three major releases in six weeks.
Another production system, OneTap, supports offline-capable customer feedback for multi-site restaurants. It has processed more than 1 million surveys, integrated with Tableau, absorbed 20+ major React Native releases, and avoided an estimated 350-650 developer hours on mobile maintenance alone.
These are the kinds of signals that matter. Not just "could it be built?" but "could it keep evolving without turning into a maintenance swamp?"
The useful question
The AI app-delivery debate is often framed badly.
It is not: Can AI build software? It can.
It is not: Will people use AI to build more software? They will.
The useful question is: How much software liability should the organisation accept every time someone turns an idea into an app?
That is the difference between time-to-demo and time-to-value.
AI has made creation cheap. The winning organisations will not be the ones that generate the most code. They will be the ones that use AI to create more business capability while keeping the software estate governable, secure, testable, documented, and maintainable.
Or put more bluntly: build the app. Do not accidentally build the department that keeps a hundred generated apps alive.