The Outsourced Developer Disappeared... Can Stagnant Services Be Maintained or Revived Using AI Like Google Antigravity?

To start with the conclusion,if the conditions are met, 'partial revival' is possible, but a complete restoration using only AI is not realistic.

Let me break this down step by step.

First, as a premise, services whose developers have disappeared face three major hurdles.

・Unclear specifications
・Lack of documentation
・Operational environment has become a black box

AI can be a strong ally here, but it is not a panacea.

What AI can do

With current advanced code-based AI, you can:

・Analyze existing code and explain its structure
・Identify dependencies
・Suggest refactoring for unorganized code
・Generate test code
・Detect common vulnerabilities
・Assist with library updates

These tasks are quite practical. It is especially effective for visualizing a state where 'you don't know what is running or how.'

Difficult areas

However, the following issues still require human judgment.

・What were the original specifications?
・Determining whether a behavior is intentional or a bug
・Redefining business logic
・Ensuring consistency with customer requirements
・Handling production-specific settings and infrastructure dependencies

AI can make inferences from code, but it cannot determine the 'correct specifications' unless they are provided.

A realistic revival model

The most realistic approach is a collaborative model where:

1. AI analyzes and visualizes the entire codebase

2. Humans redefine the specifications

3. AI generates improvement plans and tests

4. Humans review and deploy to production

With this structure, revival is possible with far fewer people than before.

Conditions That Determine Success Rate

The difficulty of revival changes significantly based on the following:

Is the source code completely intact?
Is the build environment reproducible?
Are external APIs still active?
Can the database structure be understood?

If the source code remains, there is hope. If you only have binaries and the specifications are unknown, the difficulty level increases dramatically.

How far can you go with tools like Google Antigravity?

Large-scale models are highly effective for:

Reading legacy languages
Modernizing code
Gradual migration to other languages
Identifying security holes

However, they have not yet reached the point of being an 'autonomous entity that continues maintenance.'

Conclusion

For the maintenance and revival of stagnant services:

Using AI significantly lowers the difficulty
However, the ultimate responsibility and specification decisions must be handled by humans
Complete automatic revival is currently impossible

This is the realistic assessment.

Yes, if the source code remains, grasping the current situation is possible with high accuracy for the most part. However, it is important to note that this is slightly different from 'complete understanding'.

I will explain in order.

1. What can be done through analysis

Using AI, it is highly probable that you can grasp the following:

・Organizing the structure of the entire system
・Visualizing dependencies between modules
・Identifying major entry points
・Extracting API and DB access points
・Identifying connection points with external services
・Detecting unused code
・Pointing out potential bugs and vulnerabilities

AI is particularly adept at the task of "creating a map" for legacy code.

2. However, there are limitations

Parts such as the following may be based on speculation:

・The intent behind why a specification was made that way
・Whether it is a temporary fix or an official specification
・The relationship with customer requirements
・Past incident response history

You can read the "behavior" from the code, but you cannot read the "background".

3. Factors that influence accuracy

Analysis accuracy varies significantly based on the following:

・Presence of comments
・Quality of naming
・Existence of test code
・Consistency of design patterns
・Whether it is in a buildable state

The more organized the code is, the more accurately AI can structure it.

4. Realistic assessment

In practical terms, using AI in combination is overwhelmingly faster than a human reading it from scratch is certain. Even for a scale of tens of thousands of lines,

・Summarizing the overall picture
・Verbalizing dependency maps
・Decomposing into functional units

are sufficiently realistic.

5. Conclusion

Yes, if you have the source code, understanding the current situation is possible. Moreover, it is far more efficient than a human alone. However, it is important to note that this is

• an "understanding of the operational structure"

• and not a "complete restoration of business intent"

.

Yes, I would say that their importance has increased in terms of quality. However, this is not a matter of simply increasing the quantity.

Let me clarify this a bit.

1. Why are comments important even though AI can read code?

Modern AI can analyze syntax, control flow, and dependencies quite accurately. However,

・Why was that design chosen?
・What constraints are assumed?
・What was intentionally left undone?

These "design intentions" cannot be fully read from the code alone. This is where the value of comments lies.

2. What is important in the AI era are "explanatory comments"

Simple descriptions of processes, such as

・"Loop here"
・"Add here"

are redundant for both AI and humans. However, the following information is extremely valuable:

・Correspondence with external specifications
・Assumptions that are planned to change in the future
・Known limitations
・Bugs being avoided or historical context
・Security reasons

These greatly improve the inference accuracy of AI.

3. Comments influence the quality of AI output

AI depends heavily on the provided context. With high-quality comments,

・Incorrect optimizations can be prevented
・Refactoring that differs from the intent can be avoided
・Destructive changes due to misunderstandings of specifications can be reduced

In other words, comments act as part of the prompt for the AI.

4. Especially Important for Legacy Revival

In cases like projects where the outsourced developer has disappeared, the fewer comments there are, the more likely the following will occur:

・Misinterpretation
・Specification breakage
・Unexpected side effects

Conversely, if the minimum design intent remains, reconstruction by AI becomes significantly safer.

5. Practical Conclusion for the Future

What is important in the AI era is:

・Writing design intent rather than process explanations
・Writing constraints and assumptions
・Writing the "why"
・Writing about future changeability

This is comment design.

Conclusion

Yes, in the AI era, source code comments have become even more important. However, this does not mean "increasing" them, but rather,

improving the quality of comments as a tool for sharing intent so that both AI and humans do not misunderstand

is what is important.

To give you the conclusion first, the principle is "not to write them everywhere," but "to write them where misunderstandings might arise".

Whether in the AI era or the human era, this core principle remains unchanged.

First, the fundamental principles

Comments should:

・Not state what is already obvious from the code
・State the intent, constraints, and reasons
・State external contracts

These three are the basics.

1. What to write for classes

Since classes are design units, this is important. At a minimum, it is worth leaving the following:

・Responsibilities (what this class is in charge of)
・Domain concepts handled
・Relationships with external entities
・State preconditions
・Thread safety status
・Lifecycle assumptions

The "responsibilities" are especially critical. Both AI and humans rely on this to determine if the Single Responsibility Principle is being followed.

2. What to write for public methods

Methods exposed to the outside are "contracts." Here, it is worth writing:

・Meaning and constraints of arguments
・Guarantees of return values
・Exception conditions
・Presence of side effects
・Presence of state changes
・Performance characteristics

Side effects, in particular, should be explicitly stated.

3. What about private methods?

They are unnecessary if the process is short and obvious. However, you should write them in cases such as:

・Non-intuitive algorithms
・Mathematical processing
・Reasons for optimization
・"Why this order?"
・Implementations due to historical circumstances

What is important here is "why this implementation?"

4. Examples of what not to write

・Getters / setters
・Obvious conditional branching
・Processes that are clear from the name alone
・Simple data conversions

Writing explanations for these becomes noise.

5. Perspectives unique to the AI era

AI can read code, but

• Design philosophy
• Domain constraints
• Business rule priorities

will be incorrectly guessed if not explicitly documented. In other words, comments are design specifications not just for future humans, but for future AI as well.

Practical guidelines

When in doubt, you can decide based on the following question:

“If I look at this code a year from now, will I misunderstand its intent?”

If there is a possibility of misunderstanding, it is worth writing.

Conclusion

• Write responsibilities and prerequisites for classes
• Write contracts for public methods
• Write reasons for non-intuitive logic
• Do not write for self-evident processes

Quality over quantity, intent over explanation. This is the most practical approach.

As you say, the content just mentioned does not differ significantly from the principles of 'human-to-human optimization'.

So, let's organize what changes specifically for AI.

1. AI 'fills in the gaps with ambiguity'

Humans can stop when they 'don't understand.' However, AI will fill in the gaps with plausible guesses even if it is ambiguous. Therefore, for AI, you must explicitly state:

• Implicit assumptions
• Priorities
• Exception cases
• Parts that must not be changed

The value of explicitly stating this increases. In particular,

"This implementation is provisional"
"This is the specification, but it is scheduled to change in the future"
"Do not delete under any circumstances"

Meta-information such as this is important.

2. "Explicit statement of constraints" is uniquely important for AI

AI tends to suggest optimizations and simplifications. Therefore,

・Performance constraints
・Memory limits
・Maintaining compatibility
・External contracts

If these are not clearly stated, it may propose destructive improvements. In other words,

Constraints may be deleted if they are not explicitly documented

is a characteristic of the AI era.

3. Business rules must be verbalized

AI calculates intent from logic, but it cannot perfectly infer priorities. For example,

・Safety priority
・Speed priority
・Readability priority
・Backward compatibility priority

Such value judgments are worth writing in comments. Things that can be handled verbally with humans become necessary for AI.

4. Explicit statement of boundary conditions

AI is good at generalization. Therefore,

・This function is used only in this context
・Prohibited for other uses
・This data is not intended for external input

Writing down the "scope of application" like this can reduce misuse.

5. Explicit statement of the "scope that can be changed"

AI makes modification proposals over a wide range. Therefore,

・This module is a stable area
・This part is experimental
・This part is scheduled for future replacement

Writing it down this way makes safe modifications possible. This is a part that is more important for AI than for humans.

6. In summary

What is unique and important for AI is:

・Explicitly stating implicit assumptions
・Clarifying constraints
・Verbalizing priorities
・Limiting the scope of application
・Declaring what can and cannot be changed

is what it comes down to.

Conclusion

The basic principles are the same as for humans. However, in the AI era,

the idea that 'they should understand even if I don't write it' is unlikely to work

is a major difference.

To give you the conclusion first,'there is no need to write all the background,' but 'it is safer to write down the background that would be problematic if destroyed' in the AI erais the answer.

Let me break it down and explain.

1. Why was the background not written down in the past?

The conventional assumptions were as follows:

・Shared in design meetings
・Maintained continuously by the same team
・Tacit knowledge exists
・Humans stop if they are about to break something

In other words, the context was shared.

2. What Changes When AI Is Introduced

AI:

- Does not know about meetings
- Does not know the history
- Does not know internal company circumstances
- Does not know that 'changing this will cause political trouble'

Nevertheless, it proposes the most rational-looking fixes. In this case, if the background is not written down,

'This is a better implementation, let's make it concise'

it may break things with good intentions.

3. So, Should Everything Be Written Down?

No, that is not necessary. The practical criteria are as follows.

Backgrounds that do not need to be written

- Mere historical anecdotes
- Past circumstances that have already been invalidated
- Who suggested it

Backgrounds that should be written

- Reasons for maintaining compatibility
- Legal regulations or contractual constraints
- Special specifications due to customer requirements
- Compromised implementations due to performance constraints
- Circumstances where deletion would cause an accident

In other words, writing only the background of the constraints that bind the design is rational.

4. Differences Unique to AI

Humans feel a sense of discomfort. AI does not. Humans think, 'Is it okay to change this?' AI immediately proposes, 'It can be optimized.' That is precisely why information such as:

- This part is intentionally redundant
- This is maintained for consistency with past specifications
- This behavior is a specification, not a bug

is particularly effective for AI.

5. Practical Compromise

The recommendation is to briefly write the 'premises that bind this design' only at the beginning of classes or for public APIs.

Long historical accounts are unnecessary, but a single line of constraint explanation is powerful.

Conclusion

You do not need to write out the entire background for the AI. However,

it is worth writing down at least the reasons why you do not want the design to be broken

is a realistic balance in the AI era.

[PR] Tales of Berseria Remaster - PS5

AI-generated, for reference only.