Technical debt is the invisible tax on AI

The stated figures

44 per cent: AI code tasks with security flaws
41 per cent: Increase in code complexity

One team points a coding assistant at a renewals spreadsheet before lunch and has a working tracker in front of the sales floor by Friday; a second team spends the same afternoon writing a specification, pinning the model version, testing the discount rule and naming the person accountable, and has nothing to demonstrate until the following Monday. The first course yields a demo and a maintenance obligation nobody has priced. The second yields a short delay and a system that a new engineer can change without reconstructing a prompt history. Neither course escapes the debt. They differ in when it is recognised, who can see it, and whether the organisation has a mechanism for paying it down.

What the renewals tracker costs after Friday

The Business Times carries the precedent: a colleague at the article author's previous employer assembled over two hundred applications on a low-code platform. When that colleague moved to another unit, the IT department inherited a portfolio that stored private employee data across several locations with no register of where it sat, and in which several applications performed overlapping work. The inheritance took months to untangle. The AI demo is the same artefact with a better interface and a shorter build time.

The article does not argue against cheap tools. It argues that build time is a poor proxy for the obligation. Veracode's 2026 tests, as The Business Times reports, found a security flaw in roughly 44 per cent of the AI code-generation tasks it tested. That figure describes tested tasks rather than deployed business applications, and it still makes a successful run on the builder's laptop the opening of a safety question rather than the close of one.

The finance definition problem follows. Your tracker counts customers who have agreed to renew; finance counts only signed agreements. Both figures can be correct, and they measure different things. Before anyone asks a model to change the calculation, someone has to decide what the dashboard is for. The article states the point exactly: "The bill, however, includes years of decisions about what happens next."

Those decisions have names. They are:

the owner who answers when finance disputes the figure;
the data map that survives a staff transfer;
the maintenance budget that funds a schema change;
the security review that arrives before the first customer record;
the model-version record that explains why the JSON shape changed;
the retention schedule that decides which records move and which are deleted;
the retirement plan that stops the application becoming a museum piece with a login screen.

The ledger has more entries than duplication

AI technical debt is a portfolio of liabilities, and each entry has a different repayment mechanism. Tembo cites GitClear's analysis of 211 million changed lines: duplicated code blocks rose eightfold, refactoring fell from 25 per cent to under 10 per cent, and copy-paste rose from 8.3 to 12.3 per cent. The same business rule now lives in several files, and every future change has to find all of them.

Augment Code reports that He et al. measured about a 41 per cent increase in code complexity after teams adopted Cursor. The code passes tests and takes longer to understand, which is the expensive half of the transaction.

The remaining entries in the ledger:

Dependency creep. A model suggests a package because the package was popular in its training data, not because it fits the repository's existing tree. Every added library is a maintenance commitment and a vulnerability surface.
Model drift. Vendors retrain and redeploy. The same prompt returns a different JSON shape in a quarter the team did not choose, and the application that depended on the old shape fails at the boundary.
Data without a map. The application writes employee records to a second store. The second store exists in the memory of the person who accepted the pull request and nowhere in the repository.
Security after the fact. A generated function can look clean and still omit input validation, error handling or authorisation checks. The review has to test for the absence of a decision, which is harder than spotting a syntax error.
Ownership without authority. The application has a name in a wiki and no budget, no maintenance window and no person empowered to close it.
Retirement without a plan. The application outlives the process it replaced. The records it holds have retention requirements, and nobody has decided which records move and which are deleted.

The Forbes Technology Council's summary separates this from deliberate debt: the model chooses the architecture, the reviewer sees a clean diff, and no person records a trade-off. Deliberate debt has an author. AI-generated debt has a diff.

Review is not a substitute for a theory of the system

Margaret-Anne Storey calls the residue cognitive debt: the loss of a shared theory of what the program does and how it can change. A team can pass every test and still lose the ability to explain why the approval threshold sits where it does. The code may be readable. The reasoning has left the building.

CIO frames the same failure at enterprise scale: technical debt is the tax that is killing AI ambition, because every tactical model deployment lands on an estate already carrying platform and data debt. The model does not remove that debt. It consumes the estate's capacity to absorb change.

The tooling consequence is direct. A merge gate that checks formatting and unit tests catches syntax and regressions. It does not catch a missing business rule, a duplicated abstraction, a model version that changed under the application, or an owner who has left. Those require a specification, a data map, a dependency record and a named person with the authority to say no. Code review remains useful. It is not the control that makes those four things exist.

The productivity gain is real, and so is the drift

MIT Sloan Management Review reports that technical debt costs the United States $2.41 trillion a year and that companies well positioned for change set aside about 15 per cent of IT budgets for remediation. That is not an argument against assistants. It is an argument against measuring only the assistant's output.

The Forbes Technology Council reports that a 25 per cent rise in AI usage lines up with a 7.2 per cent fall in delivery stability. The direction is the point. More generation can raise throughput while lowering the system's tolerance for change, and the dashboard that celebrates the first number rarely carries the second.

A team that tracks only merged pull requests is measuring the wrong side of the invoice. It needs:

review time per AI-assisted change;
churn within the first weeks after merge;
rollback frequency;
duplication counts;
the share of applications with a named owner;
the share with a retirement date;
the number of model versions pinned and documented.

Those measures are unglamorous. They are also the ones that tell you whether the assistant is buying speed or borrowing it.

Ownership is the control that makes the rest auditable

The Business Times reports that the team that gains from an application must help steer and pay for what comes after it. The division is not a governance formality. IT can work out how to change a system; sales has to explain how a new contract should behave. Forwarding an application to IT does not forward that knowledge, however many senior managers are copied into the email.

An owner needs three things: time, budget and the authority to close the application. The owner also needs a record of where the data lives and who can reach it, so that a change of owner does not set off a hunt for undocumented stores of personal data. That record is the difference between an asset and a liability with a password reset. It is the only way a later engineer can tell whether a table is a system of record or a temporary copy that nobody has agreed to delete.

Proportionality decides the scrutiny, and the decision after launch

Not every application deserves the same process. A throwaway script that reformats a file deserves lighter review than a system that records promises to customers. The useful questions are who depends on the application and what happens if it gets something wrong. An afternoon of coding can create years of obligations, so how long the build took says little about how much responsibility it carries.

The article offers a practical test: whether a colleague's working week improves. Cutting three spreadsheets and a weekly meeting looks like a gain. If the new tool saves five minutes of data entry and adds an hour of Friday reconciliation, the team finishes the week with more work than before. That means mapping the whole process before declaring a saving.

Then comes the decision the article puts at the centre. The decision to retain, improve or shut down an application deserves the same management attention as the decision to approve a new one. Continual evolution can mean removing features and closing applications, especially as the team learns which tools people actually use. The budget should cover retirement as well as change, including moving the records that must survive and cleaning up the rest. Without that line item, the portfolio becomes a museum of promising ideas, every one of them requiring a password reset.

Sources

Source: The long bill for cheap software and AI apps, The Business Times