AI Technical Debt: What Robert Moses Can Teach Engineers
AI technical debt can grow as code becomes easier to produce. Robert Moses offers a useful analogy for dependencies, maintenance, and engineering judgment.
A software feature can become difficult to remove long before anyone decides it should be permanent.
It starts with a prototype. Then another service depends on it. A dashboard expects its data. Someone promises it to a customer. What began as an experiment becomes something people plan around.
That is a useful way to think about AI technical debt: cheap construction can create expensive commitments.
Robert Moses understood the power of getting started
Robert Moses reshaped New York through parks, roads, and bridges. As Robert Caro describes in his account of Moses’s power, construction was only part of the story. Planning, financing, political leverage, and institutional control mattered just as much.
One tactic often associated with Moses was “stake driving”: begin physical work before all the financing is settled.
Once work has started, the decision changes. Officials are no longer considering a project that exists only on paper. They are deciding whether to abandon something already underway.
Joe Cortright’s discussion of Caro’s biography describes how early construction and spending could create pressure to provide the money needed to finish the job. The project itself became part of the case for continuing it.
The broader lesson is not that momentum explains everything Moses accomplished. It is that starting something can change the conditions under which later decisions are made.
AI technical debt can begin with a useful feature
Software has its own version of that momentum.
Imagine a small team using an AI coding assistant to build a search feature. The first version works well enough for a demo. To support it, the team adds a new service, a library, a background task, and another copy of some data.
None of those choices is necessarily bad on its own. The problem appears when nobody steps back to look at what they add up to.
A dependency is simply something another part of the system needs in order to work. Once other components depend on a feature, removing it becomes more complicated. Deleting the code might be easy. Changing everything that has grown around it may not be.
Microsoft’s guide to N-tier architecture shows the trade-off clearly. Layers and tiers can create useful boundaries, but each additional connection can also increase coupling and complexity.
Technical debt is the future maintenance cost created by choices that make sense in the short term. Sometimes that debt is intentional. Sometimes nobody notices they are taking it on.
When code becomes cheaper to produce, both kinds can accumulate faster.
What research shows about AI-generated code
A 2026 arXiv preprint, Debt Behind the AI Boom, by Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, and David Lo examined roughly 302,600 AI-authored commits across 6,299 GitHub repositories.
The researchers compared static-analysis findings before and after those changes and tracked the issues introduced. In version 2 of the paper, they reported that 22.7% of the tracked AI-introduced issues were still present in the latest repository revision.
That does not prove that AI-generated code is universally worse than human-written code. It also does not capture every cost involved in maintaining software. The attribution depended on visible Git metadata, and static-analysis warnings are not the same thing as failures experienced by users.
What the study does show is simpler: some detectable maintenance problems introduced alongside AI-authored changes remained in the codebase.
That is enough reason to take maintenance seriously.
The Robert Moses comparison is a way of thinking about the consequences of momentum. It is not something the researchers themselves tested.
Removing one bottleneck exposes another
If producing an initial implementation takes less effort, the bottleneck does not necessarily disappear. It can move.
The scarce resource may become understanding requirements, reviewing changes, testing behavior, or deciding whether something should exist in the first place.
Grasply’s article on the forces behind AI’s system-level impact makes a useful distinction between what a tool can do directly and the constraints it changes around it.
Applied to software, cheaper production can expose a shortage of attention.
The telephone–skyscraper connection offers a related example. Technologies that make larger systems possible also create new coordination problems. The same idea applies to software: more components create more relationships to understand and manage, even when each component looks simple by itself.
So the important question is not only whether AI can build a feature.
It is whether the team can still explain the system after adding it.
Good engineering means keeping that explanation possible.
A prototype becomes infrastructure through ordinary decisions
Consider a study app that generates practice questions.
A developer creates a second question-generation pipeline to test a new model. During the experiment, another screen begins using its output. Then a scheduled job starts saving those questions. Later, an analytics report assumes the same format.
The experimental pipeline now has dependents.
Removing it may mean migrating saved questions, changing the report, and coordinating a release. Nothing physically prevents the team from deleting it. The pipeline may even be worth keeping.
The cost comes from the commitments that formed around it before anyone decided what its long-term role should be.
The team could keep it, merge it with the original pipeline, or remove it. Any of those decisions might be reasonable.
The important part is making the decision consciously.
A feature is cheap only until other things start depending on it.
Four questions before the next layer
The carousel’s questions work well as a simple review habit. They are not a checklist that guarantees a good system, but they force useful conversations before another layer becomes permanent.
What should be built?
Start with the user problem, not the implementation. Ask whether the feature really needs a new component or whether an existing part of the system can handle it.
What can be trusted?
Identify the behavior that matters and decide what evidence would make you confident it works. A good demo is useful, but it is not a substitute for tests and independent checks aimed at real failure modes.
What should be removed?
Give experiments an owner and a date or condition for deciding their future. Ask what else would need to change if the component disappeared. Dependencies are much easier to deal with when they are discovered early.
What will break later?
Imagine obvious changes: more users, a different data format, an external service disappearing, or a new engineer taking over the system. The point is not to predict every failure. It is to expose assumptions before they become expensive.
Architecture, standards, testing, verification, and judgment turn those questions into engineering practice.
AI can help with many parts of that work. But accepting an answer still requires reasons that another person can inspect and understand.
Understanding is the capacity worth protecting
There is a learning lesson here too.
When studying a system, use AI to help draft an explanation, then try to explain the important relationships yourself.
Which component depends on which? What assumption makes the design work? What happens if one part disappears?
Generated explanations can accumulate faster than your ability to evaluate them. At some point, another page of notes is less useful than a question that forces you to prove you understand what is already there.
The same principle applies to software.
As code becomes easier to generate, engineering judgment becomes more valuable. The limiting factor may no longer be how quickly a team can produce code, but how well it can decide what to accept, understand what it has built, and maintain it over time.
When code becomes abundant, good engineering becomes scarce.
The practical response is to protect the ability to decide what deserves to be built—and what deserves to stop.
Sources and further reading
- Robert A. Caro, “The Power Broker—III: How Robert Moses Got Things Done”: Moses’s institutional, planning, and financing power.
- Joe Cortright, “Driving stakes, selling bonds”: discussion quoting Caro on construction momentum.
- Liu and colleagues, Debt Behind the AI Boom, version 2: repository study of persistent static-analysis issues associated with AI-authored commits.
- Microsoft, “N-tier architecture style”: dependencies, coupling, and architectural trade-offs.