Technical Debt: AI System vs Engineer — A Fair Comparison

The question is deceptively simple: if you take an AI-created engineering solution and an engineer-created engineering solution, both solving the same problem, how do you identify the technical debt in each?

Most discussions of technical debt treat it as a synonym for old, messy or poorly documented code. That framing is not useful here. For this comparison, technical debt is better understood as the accumulated future effort, uncertainty and risk created by decisions embedded in a technical solution. That definition works equally for both approaches and doesn't assume either is inherently superior.

The comparison has to be like-for-like

The starting point is a common requirement delivered two ways. Solution A produced by an AI system. Solution B produced by an engineer using traditional software tools. The comparison should not begin with speed, cost or volume of documentation. It should begin with the technical state left behind by each solution — because that is where the debt actually lives.

1. Requirement debt

The first question is whether you can establish what requirements the solution actually satisfies. Can you trace an explicit requirement to its implementation? Has it been verified? Are there requirements with no identifiable implementation — places where a future engineer must rediscover intent from the output alone?

Both AI and human engineering can be remarkably poor here. Requirement debt is not a failure mode unique to either approach. But the manifestation differs. An AI solution may produce apparently complete outputs without ever representing which requirement drove which decision. An engineer's solution may scatter requirements across emails, meeting notes and memory.

Same debt. Different hiding place.

2. Assumption debt

Every engineering solution contains assumptions. The question is whether you can find them. For each solution, the test is whether assumptions are explicitly declared, evidence-supported, embedded in a calculation, or simply hidden.

An AI solution may carry enormous hidden assumption debt if the system generated coherent-looking outputs without preserving the reasoning behind particular choices. A traditional engineering solution may distribute its assumptions across spreadsheets, calculation notes, emails, experience and undocumented professional judgement. Both are forms of assumption debt. The engineer's version is at least familiar in its messiness. The AI version may look clean while being structurally opaque.

3. Decision debt — probably the most important

Ask one question of every significant decision in the solution: why is it this way?

For a traditional engineering solution, a pump sized at 1,200 kW may be traceable to a specific calculation version, a spreadsheet, a supplier discussion, an email, and a design meeting. The lineage is messy, fragmented and partially undocumented. But it exists in a form that an experienced engineer can reconstruct.

For an AI solution, the same pump size may appear as a clean, confident output. The reasoning that produced it may not exist anywhere that a human can inspect or reproduce. The documentation may describe the answer without representing the generative path. That is a profound difference.

You can get an illusion of understanding. The explanation itself may also be generated. Documentation may describe the answer without representing the actual reasoning.

4. Dependency debt

Traditional solutions accumulate dependency debt through obsolete software, proprietary file formats, undocumented macros, vendor tools, internal standards, and one person's knowledge. This debt is visible, familiar and ugly. Engineers know it exists.

AI solutions accumulate dependency debt differently. The solution may depend on a specific model version, specific prompts, specific tools, specific context states, and a specific execution environment. Technical debt appears when the model changes, prompts are lost, tools become unavailable, context cannot be reconstructed, or system behaviour changes between versions.

My blunt view is this: traditional systems usually carry visible technical debt. AI-created systems risk carrying invisible epistemic debt. The question isn't just whether you can run it. It becomes whether you know enough about why it exists to safely change it.

5. Reproducibility debt

This is the cleanest measurable comparison. Ask whether an independent competent person can reproduce the solution. Test at each boundary: are the inputs available and identifiable? Is the method versioned and documented? Are the transformations reproducible? Can the output be independently regenerated?

For a traditional engineer, the inputs and calculation model may be solid, but software versions, macros and engineering judgement may introduce gaps. For an AI solution, the inputs and model may be documented, but model version, prompt state, tool execution and context state may not. Each unresolved gap is evidence of technical debt. Each question mark in the reproducibility chain is a cost that the next engineer will pay.

6. Modification debt

This may be the most commercially meaningful test. Give both solutions a change: increase the load by 15%. Then measure how long it takes to locate affected components, how many dependencies change, how much must be recalculated, how much requires expert interpretation, and whether unintended effects can be detected.

The traditional solution may be slow but understandable. A familiar process — find the calculation model, understand dependencies, change inputs, recalculate, check outputs, update drawings. For the AI solution, the risk is different. The system might produce a different solution rather than a controlled modification of the previous one. You may not know whether the new output represents the old design plus 15%, or a completely new design with subtle differences everywhere.

That is a serious form of technical debt. Not the complexity of the change, but the inability to bound its consequences.

7. Verification debt

Ask what has to be manually rechecked every time the solution changes. A traditional solution typically verifies through peer review, independent calculation, standards compliance and professional judgement. The weakness is cost. You don't verify everything continuously because continuous verification is expensive.

An AI solution can potentially verify everything continuously — but only if the verification is sufficiently independent from generation. An AI system that generates a solution and then checks it against its own output is not providing strong assurance. Strong assurance requires deterministic independent calculation, rules-based standards testing and simulation that operates separately from the generative process. The distinction matters enormously.

An AI solution can potentially have less technical debt than a traditional solution — if it leaves behind deterministic, independently verifiable engineering. If it doesn't, it may have considerably more.

The debt comparison framework

Applied to both solutions, the comparison looks like this:

The real-world test

The fairest comparison is not theoretical. It is a technical debt recovery test. After both solutions are delivered, remove the original engineer from one and the AI system from the other. Remove selected tools and undocumented context. Give both to independent engineers with the same brief: understand this solution, change it, verify it.

Then measure: time to understand, time to locate assumptions, time to identify dependencies, time to make the change, time to verify the change, and number of unresolved uncertainties that remain.

That is the comparison. Not which system was faster to create. Not which produced more documentation. But what the next competent person had to pay to understand, change and trust it.

The long-term risk profiles

The actual conclusion

I would not trust either method by default. The traditional solution is probably easier to inherit — an experienced engineer understands the ecosystem even if the implementation is messy. The AI-created solution is potentially much more efficient. But it has to prove that it has not simply moved complexity into a place humans cannot inspect.

The winning solution is not AI-created or engineer-created. It is the one that leaves behind the smallest burden for the next engineer: the combined cost of understanding it, verifying it, modifying it, reusing it and defending it in front of someone who had nothing to do with building it.

My suspicion — not a conclusion until tested — is that current AI solutions could be dramatically better at creating systems but dramatically worse at leaving behind human-understandable continuity, unless continuity and verification are deliberately engineered into the delivery process.

The question for the industry is whether anyone is requiring that deliberate engineering, or whether we are accepting the speed benefit while quietly absorbing a new category of debt we do not yet have good tools to measure.