AI can now build systems.
That fact itself is no longer surprising.
It can write code.
It can build screens.
It can connect APIs.
It can generate database definitions.
It can write test code.
It can draft documentation.
Tasks that once required experience and time can now be shaped into something functional in a very short period of time.
That is convenient.
And it is undeniably powerful.
But there is something we must not overlook.
A system does not end the moment it is built.
In fact, that is when it begins.
It will be used.
It will be modified.
It will break.
It will receive specification changes.
Its maintainers will change.
Its environment will change.
External services will change.
Laws and business rules will change.
And still, it will be expected to keep running.
A system is not something you simply build.
A system is something you carry.
The real problem exposed by the AI era is not:
Can AI build a system?
The problem is:
Who will carry the system built by AI?
AI produces clean-looking artifacts.
A polished screen.
Plausible code.
A convincing design explanation.
A readable README.
A structure that appears coherent at first glance.
It has the face of something complete.
But a clean face is not the same as maintainability.
Code that runs is not the same as design intent being preserved.
A screen that displays is not the same as business specifications being organized.
A README is not the same as operational responsibility being clear.
Test code is not the same as resilience to change.
Systems built with AI often leave behind only the fact that they were built.
Why was this structure chosen?
Why this data model?
Why this exception handling?
What was specification, and what was AI completion?
Who reviewed it?
Who approved it?
What must not be broken when the system changes in the future?
When these judgment records are missing, only the artifact remains.
A clean face, but broken underneath.
That is the entrance to AI Legacy.
The term “legacy system” usually refers to old systems.
Old programming languages.
Old frameworks.
Old operating systems.
Old databases.
Old design assumptions.
Code made complex by years of modification.
But AI Legacy is different.
AI Legacy does not become a problem because it is old.
It becomes a problem because it is new, yet already impossible to carry.
At the time it is built, it is new.
The technology is new.
The screen looks modern.
The code may even look clean.
And yet, a few months later, or a year later, the problem surfaces.
It cannot be changed.
It cannot be fixed.
The cause of failure cannot be traced.
The specifications are unclear.
No one knows the safe range of testing.
The person who built it cannot explain it.
No one knows what assumptions the AI used when generating it.
In other words, the system has not aged, but it is already unmaintainable.
That is the major difference from traditional legacy systems.
Traditional legacy was created by the passage of time.
AI Legacy is created by the absence of responsibility.
The main cause of AI Legacy is not simply a lack of technical skill.
The essence of the problem is the absence of judgment.
Having AI write code is not itself the problem.
Having AI propose designs, draft documentation, or generate test perspectives is not itself the problem.
The problem is who evaluated the output.
Under what assumptions was it adopted?
What risks were accepted?
What did humans verify?
What was left as-is from AI output?
What alternatives were rejected?
Why were they rejected?
If those judgments are not preserved, artifacts may remain, but design does not.
In the AI era, judgment logs become more valuable than code itself.
Who adopted which AI output, and why?
Where was uncertainty present, and where did a human approve it?
When a future maintainer reads the system, what can they trust?
If these things are not recorded, the system is already legacy, even if it looks new.
AI Legacy appears in several forms.
The first is the specification-reconstruction failure type.
The system runs.
But no one knows why it behaves the way it does.
Is it a business requirement?
Is it a temporary workaround?
Is it behavior AI filled in on its own?
Did it simply happen to pass a test?
No one can tell.
When maintainers are asked to “preserve current behavior” in this state, they are thrown into hell.
They must reproduce behavior without knowing whether that behavior is correct.
The second is the unknown technical health type.
The code runs.
But no one knows whether the structure is healthy.
Responsibilities are blurred.
Exception handling is thin.
Logging is weak.
Security boundaries are unclear.
The data model is ad hoc.
Tests are superficial.
No one knows why certain dependencies were chosen.
AI can create plausible form.
But humans must determine whether that form can survive long-term operation.
The third is the unclear rights and licensing type.
It is usually impossible to directly trace what training data or references influenced AI-generated code or text.
In addition, when libraries, sample code, or architecture patterns suggested by AI are adopted as-is, licensing and intellectual property checks may become ambiguous.
“AI generated it, so it must be fine” is not a valid position.
AI does not carry legal responsibility.
Humans and organizations must verify.
The fourth is the contractually unmanageable type.
A system built with AI is later handed to a systems integrator or maintenance vendor.
But from the receiving side, there is too much uncertainty.
The specifications are unclear.
The design intent is unclear.
The test coverage is unclear.
The volume of latent defects is unknown.
The level of risk to price into the work is unknown.
In this state, accepting it as a normal maintenance contract is difficult.
If it is accepted at all, the work must be divided into an investigation phase, a specification-reconstruction phase, and a risk-diagnosis phase.
A risk premium becomes necessary.
In some cases, it may need to be treated as a near-rebuild project.
A system that was supposedly built cheaply with AI may become expensive during cleanup.
This is entirely plausible.
The fifth is the low customer maturity type.
The side that built the system with AI does not understand the responsibility of owning a system.
If it can be built, it should be cheap.
If it is running, it should be fine.
If AI built it, maintenance should be easy.
If something happens, experts can be brought in later.
That is the mindset.
But a system is not merely an artifact.
It is a continuing responsibility.
The moment business operations depend on it, operation, maintenance, change management, incident response, and accountability all begin.
If a system is built with AI without that recognition, the problem is simply pushed into the future.
Someone in the future will have to carry it.
The frightening thing about AI Legacy is that it looks like success at first.
It was built quickly.
It cost less.
The screen worked.
The documents were prepared.
Stakeholders accepted it at least once.
As a project, it appears successful.
But the real evaluation begins only after it enters operation.
When a specification change arrives.
When an incident occurs.
When the responsible person changes.
When an external integration changes.
When a security response is required.
When an audit asks for an explanation.
Only then do the judgments that were not recorded during development become a problem.
Why is it this way?
Who decided this?
What assumptions were used?
How far was it verified?
Can it be changed?
What must not be broken?
No one can answer.
That is AI Legacy.
Avoiding AI Legacy does not require banning AI.
Rather, if we use AI, we must strengthen human design responsibility even more.
Before having AI build something, define the requirements.
After AI writes something, have humans review it.
Make explicit the assumptions AI filled in.
Record the outputs that were adopted and the outputs that were rejected.
Preserve design decisions.
Have humans verify test perspectives.
Decide who owns operation.
Check maintainability.
Prepare the system so it can be handed over.
In other words, the more we use AI, the more we need judgment logs.
Because AI builds quickly, humans must verify slowly.
Because AI makes things look plausible, humans must look for the rough edges.
Because AI fills blanks, humans must record where the blanks were filled.
In the AI era, the valuable person is not simply the one who can build.
It is the one who can evaluate what has been built.
And the one who can transform what has been built into something that can be carried.
AI Legacy is not a problem that will suddenly appear somewhere in the future.
The conditions are already forming.
No-code.
Low-code.
Generative AI.
Automatic code generation.
Internal tool development.
Shadow AI.
Personal automation of business tasks.
All of these can be useful when used well.
But if they multiply while responsibility lines remain unclear, they become future unmaintainable assets.
The problem is not as simple as saying that the person who built it was bad.
Convenience blurs responsibility.
Speed skips verification.
Low cost dulls the perception of maintenance cost.
The fluency of AI creates the illusion that judgment has already been made.
The accumulation of these things creates AI Legacy.
There was someone who built it.
But no one who took responsibility for it.
This sentence captures the essence of AI Legacy.
In the AI era, artifacts will multiply.
Code will multiply.
Documents will multiply.
Proposals will multiply.
Prototypes will multiply.
Small business applications will multiply.
But responsibility will not automatically inhabit all of them.
Responsibility is not auto-generated.
Judgment is not auto-generated.
Maintainability is not auto-generated.
Operational ownership is not auto-generated.
Humans must take them on.
Now that AI can build, the exposed problem is no longer the inability to build.
It is the inability to carry.
That is AI Legacy.
And this problem cannot be solved as a purely technical issue.
It is also an organizational issue, a contractual issue, an operational issue, and an issue of responsibility.
Before building with AI, there is only one question that needs to be asked:
Who will carry this?
A system that cannot answer that question is already legacy, even if it was built today.
