Technical debt doesn't depend on who wrote the code, but on how much it costs to change it. A perfectly correct module that no one on the team understands is technical debt, even if it doesn't have a single bug, because every future modification will require rebuilding the reasoning that no one created.
This matters now more than ever because a fast track to accumulating correct but misunderstood code has emerged: accepting what a model generates without understanding why it is the way it is.
When a team modifies a system, the real work isn't writing new lines of code. It's answering three questions before writing them: what does this do now, why is it done this way, and what will break if I change it.
That work is called understanding, and it consumes most of the time involved in any change to a mature system. If no one understood the code when it was first introduced, that bill doesn't disappear: it's postponed and paid with interest, because whoever pays it won't even have the context of the original discussion.
There is an uncomfortable asymmetry: Generating is faster than understanding.. A model can produce in seconds something that takes a person twenty minutes to understand. When generation accelerates and understanding doesn't, the imbalance accumulates in the repository.
Nobody knows if a part is being used. Code appears that may or may not be necessary, and when in doubt, it's kept. The system grows bloated with material that no one dares to delete.
Reviews become superficial. When major changes occur frequently, the review process shifts from "I understand this and I agree" to "this seems reasonable." It's a quiet but decisive change.
The same problems are solved twice. Three functions appear that do almost the same thing, because nobody knew that the others existed.
Mistakes are corrected by wrapping, not fixing. A condition is added on top of the problem instead of solving it, because touching the original is scary.
GitClear quantified the third symptom: duplicate code blocks increased eightfold in 2024, and their subsequent report indicated that duplication continued to grow. Duplication is the statistical signature of misunderstanding: people copy what they don't understand well enough to reuse effectively.
We propose just one, and it's easy to defend in any team:
Nobody merges code they couldn't explain on a whiteboard.
It doesn't require understanding every detail of implementation. It requires being able to answer three things: what problem it solves, why it was solved this way and not another, and what would happen if it ceased to exist.
When properly applied, this rule doesn't slow down the process; it reorders it. Generating the 80% code with assistance remains valid. What is no longer valid is incorporating it without having read it.
|
Practice |
Before |
With assisted generation |
|---|---|---|
|
Size of change |
Limited by the time available to write it |
It can grow without natural limit. |
|
Focus of the review |
Find errors |
Check understanding and fit |
|
Main risk |
A specific failure |
Accepting a structure that no one decided on |
|
Effective control |
Peer review |
Change size limit and mandatory testing |
The row size explains DORA's 2024 finding: as AI adoption increased, delivery stability fell by 7.2%. The cause isn't the quality of the generated code, but rather the disappearance of the natural deterrent of writing it. A thousand-line change isn't reviewed the same way as a fifty-line one, no matter how good the reviewer is.
Therefore, the most effective control is not a tool, but a process standard: limit the size of the changes. It's unsophisticated and it works.
Tests written by one person. It's reasonable for the model to generate the implementation; it's reasonable for it to also generate the test that validates that implementation, thus closing the loop. The test must express what the business expects, and that's something only a person knows.
Documentation of the decision, not the code. There's no need to comment on every line. What's needed is a paragraph explaining why this approach was chosen and what alternative was discarded. This allows someone to change it within a year without having to repeat the analysis.
A size limit per change. Any reasonable limit works. Its value lies not in the number itself, but in the fact that it forces the work to be broken down into understandable units.
All three are inexpensive and none require new tools. It's the same underlying logic that underpins the engineering standards we apply to every delivery: explicit contracts, isolated environments, and documentation transferred to the client, because The code and its documentation are the property of whoever pays for them.
In an audit, there is one question that guides the diagnosis faster than any metric: Choose a module at random and ask someone on the team to explain why it's made that way..
If an explanation is provided and is coherent, the system is maintainable despite its flaws. If the answer is that it works and no one quite knows why, the cost of each future change will be higher than any estimate indicates, and that difference will only grow.
That is the true indicator of technical debt. Not the lines, not the age, not the tool with which it was written: the gap between what the system does and what the organization understands about it.
It's the additional cost incurred with each future change as a consequence of decisions made to expedite the process at the time. It's not measured by the code's age or who wrote it, but by the cost of modifying it securely.
Not because of its intrinsic quality, but because the natural restraint of writing it disappears: changes grow in size, revisions become superficial, and duplication increases. GitClear documented that duplicate blocks increased eightfold in 2024.
With one simple rule: no one merges code they couldn't explain on a whiteboard, answering what problem it solves, why it was solved that way, and what would happen if it ceased to exist. It doesn't require understanding every implementation detail.
Three: written evidence from one person expressing what the business expects, documentation of the decision and the discarded alternative, and a size limit per change that forces the work to be broken down into understandable units.
Because copying is the usual response when you don't understand what already exists well enough to reuse it. Each copy multiplies the number of places where the same fix will have to be applied in the future.
Asking someone on the team to explain why a randomly chosen module is built the way it is. If the explanation is coherent, the system is maintainable despite its flaws; if the answer is that it works and nobody knows why, each change will cost more than estimated.
How much of your system does your team understand today? We audit architecture, code, debt, and security, and deliver the written diagnosis within 10 business days, at a fixed price. Request the audit →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
