Software Areas
Shopify Areas
Information
Technologies
Risk and Cost · AI Development Series
Technical debt you took on without knowing it. Security exposure. The cost of scale failures. Why cheap to build becomes expensive to own. The business case for doing it properly.
Imagine you can build a house in two days using an automated system that generates it from your description. The house looks perfect. The rooms are the right sizes. The kitchen is where you wanted it. The curtains are exactly right.
What the system did not do: dig foundations. Check the soil. Size the structural beams. Ensure the wiring meets safety standards. Build the drainage properly. These things are invisible. You cannot see them when you walk around the house. They will not matter for a while.
This is what AI app generation produces. The curtains are exactly right. The foundations are a guess.
The most common serious failure in AI-generated applications is missing access controls: users can see data that belongs to other accounts. This is not a theoretical risk. We have seen it in production applications, discovered by a client who noticed something that should not have been visible.
The costs of a data breach: notification to affected users (legally required under GDPR), notification to the ICO, potential regulatory investigation, reputational damage with existing customers, the cost of the remediation itself, and the conversation with prospective customers who heard about it.
AI-generated database schemas have no indexes because the tool does not know what queries will be run frequently, what columns will be searched, or what relationships need to be traversable quickly. The schema works with small data and degrades predictably as data accumulates.
The cost appears as degraded performance first. Reports that ran in two seconds now take thirty. User-facing pages that loaded instantly now have a visible delay. The options at that point: expensive infrastructure scaling that masks rather than fixes the problem, or restructuring a live production database, which is significantly more complex and risky than building the structure correctly from the start.
AI-generated codebases accumulate technical debt at a rate that non-AI codebases do not, because no human ever designed the structure. Each feature added is generated in a session disconnected from the previous ones. The result is business logic scattered across the codebase without consistent structure, functions that do multiple unrelated things, and no clear separation between what the application knows and what it does.
The cost is not visible on day one. It is visible on the day you need to add a feature that touches multiple parts of the system and nobody can confidently predict what else will change. Features that should take a day take a week. Bugs introduced by changes take longer to find because the relationships between components are not clear.
Concurrency failures in AI-generated applications produce intermittent bugs: duplicate records, incorrect totals, actions that occasionally produce the wrong result. These are hard to reproduce because they only occur when two users happen to perform the same operation simultaneously. They erode user trust slowly. They are time-consuming to investigate. And they are expensive to fix in a codebase where nobody understands the structure well enough to identify all the places the pattern appears.
Most AI-built applications are fixable rather than write-offs. But fixing them involves a developer spending time understanding code they did not write, which takes longer than it would with code that was designed by a human. When the accumulated technical debt reaches a certain point, a rebuild from scratch on a proper engineering foundation becomes cheaper than continuing to maintain what exists.
That rebuild uses the product knowledge that has been developed through operating the original application. The domain understanding, the user feedback, the edge cases discovered in production: all valuable. But the code itself is often not worth carrying forward. The rebuild cost is the price of not doing it properly the first time.
Not always, and not immediately. Single-user applications or prototypes with small data volumes may run indefinitely without serious problems. The failure modes emerge under conditions that AI tools did not test for: concurrent users, real data volumes, and access across multiple accounts. If none of those conditions apply, the risk is lower. If any of them apply, the risk is real and grows over time.
It depends on what is found and how complex the application is. Critical security issues can often be addressed in a few days. A full structural remediation covering database, concurrency, and code quality typically takes four to eight weeks. The AI Code Audit gives you a scoped picture of what is needed before you commit to remediation. Most rescue engagements cost significantly less than the rebuild they prevent.
If it is a single-user tool or a prototype and the data it handles is not sensitive, probably not urgently. If it has multiple users, handles data that belongs to different accounts, or is being used for anything business-critical, the question is not whether it works fine right now, but whether there are problems that have not presented yet. An audit will tell you which.
Security exposure, database scalability, technical debt, maintainability: a written report in five working days. Better to know than to find out in production.
We reply within one working day.
