iTranslated by AI
Professional Integrity in the Age of AI Development: Taking Responsibility for AI-Generated Code
Introduction
Development using Generative AI has already reached a practical stage.
Nowadays, even those with little programming experience can obtain code with a reasonably complex structure.
This change itself is something to be welcomed.
There is no doubt that the barriers to entry have been lowered, and opportunities to experiment, learn, and create have expanded.
On the other hand, there are more situations where I feel like pausing to think.
Asking myself, "Is this really okay?"
The reason a beginner is a beginner isn't a lack of ability.
In many cases, it's simply that they lack experience.
The process of trial and error, failure, and rethinking is precisely what has nurtured developers.
However, when GAI becomes too helpful, it can feel like that process is being bypassed.
In exchange for convenience, hasn't the speed or quality of growth started to change?
This article is not intended to negate GAI-driven development.
Rather, it takes the stance of sincerely affirming its evolution.
Building on that, I want to organize what it means to be a developer in this era and which responsibilities one should undertake.
I hope that developers from beginners to seniors, regardless of their position or years of experience, will find this article useful as material for taking a moment to reflect.
Chapter 1: GAI Development is an Evolution to be Sincerely Commended
The emergence of Generative AI (GAI) has significantly changed the landscape of software development.
This change is not a fleeting trend; it is deep enough to alter the very feel of development.
The initial speed of implementation has increased dramatically.
The moment an idea comes to mind, working code appears at your fingertips.
Using that as a starting point, you rethink the design, test it, and rewrite it again.
This speed of iteration is clearly different from previous development experiences.
GAI is a tool that moves a developer's thinking forward.
It has made the act of "getting it running first" a daily occurrence rather than something special.
As a result, the allocation of time spent thinking versus time spent testing has changed.
This change is particularly notable in the world of personal development and OSS.
Time spent on environment setup and boilerplate implementation has decreased, allowing for concentration on the verification and improvement that was originally intended.
GAI has blurred the boundary between those who "can write" and those who "cannot."
It has lowered the walls that previously hindered entry, giving many people the opportunity to touch development.
That is a change that should be welcomed as a development culture.
Looking back, similar moments have occurred many times.
GUI IDEs, code completion, template generation, libraries, and frameworks.
Every time they appeared, development became easier, faster, and more accessible.
GAI is on that same continuum.
It has simply appeared as a more powerful and versatile tool.
Therefore, GAI development should be affirmed.
While there may be reasons to be cautious, there is no reason to start with negation.
GAI is not something that robs developers of their creativity; it is the driving force to move it forward.
This change is a clear "step forward" for software development.
First, I want to sincerely acknowledge that fact.
Ultimately, it is not the means that are questioned.
The responsibility to release the product is the only thing that remains unchanged.
Column: On the Distinction Between GAI and LLM
In this article, Generative AI is referred to as GAI.
This term refers to the "way of use" or "experience" of generating outputs such as code and text.
On the other hand, LLM (Large Language Model) is often used as the core technology of GAI.
LLM is strictly a technical term referring to internal implementation and model structures.
This article does not deal with the mechanism or performance of models, but rather with the stance of how to take ownership of code written using GAI.
Therefore, the terminology will be unified as GAI from here on.
Chapter 2: It is a Revolution, but Not a Disconnection
The advent of GAI is often described as a "revolution in development." This phrase is accurate as far as the experience goes.
Indeed, with GAI, drafts for API clients, DTOs, and configuration code appear in your hands with almost no time spent. You can even have it read existing code and suggest modifications.
This change is substantial. However, changes of the same nature have occurred many times in the past.
The appearance of GUI IDEs completely transformed the landscape of UI design. By simply dragging and dropping components onto a screen, a skeleton of an interface with input fields and buttons was ready.
It wasn't the final product. But "giving it a shape first" became overwhelmingly easier than ever before.
When code completion became widespread, development changed significantly as well. This wasn't just about saving keystrokes.
One no longer had to repeatedly replay and rewrite the same code patterns in their mind. While there was physical relief, the mental relief was even greater.
Developers could let go of the parts they didn't need to think about and focus on what truly mattered. This shift elevated the quality of the development experience itself.
The rise of template generation followed the same path. Rather than automatically producing high-quality implementations, it enabled anyone to easily obtain code that, for the moment, actually works.
Authentication, CRUD, configuration files, and structures—things that previously required research, copying, and manual adjustment—could now be ready from the start.
What is generated is merely a starting point. However, the significance of being able to "start from something that works" was immense.
The change brought by GAI is essentially an extension of this. In a more powerful and versatile way, it has leveled up the speed of "giving it shape first."
That's not all. GAI has also shortened the distance between implementation and verification.
By generating drafts for test code, listing expected inputs and failure patterns, and checking behavior.
As the initial speed of these tasks increased, the cycle of trying, breaking, and fixing became faster.
GAI is not a magic tool that performs implementation on your behalf. It is like a template: you provide a request of "what you want to do," and it returns it in a tangible form.
It is a revolution. But it is not a disconnection that shatters the foundations of development.
Only the speed of implementation and verification has been accelerated. It is still the human who decides what to do and what to verify, just as before.
As long as we don't lose sight of this continuity, the points we should discuss next will naturally become clear.
Chapter 3: Even as Development Tools Change, the Responsibility for Written Code Never Changed
Let’s confirm our footing once more.
Development tools have changed many times.
From the era centered on text editors to the era of IDEs specialized for specific languages and environments, represented by Visual Studio.
Furthermore, integrated development environments like Eclipse, which can handle multiple languages, emerged, and the breadth of development targets and technology stacks expanded significantly.
And today, the mainstream format is based on lightweight editors like VS Code, which are extended with functions as needed.
Snippets, templates, and completions were all mechanisms for offloading the parts that don’t require repetitive thinking. GAI has simply expanded that target from code to intention.
With each of these changes, the way we develop has certainly changed. Efficiency has increased, and the scope we can handle has broadened.
However,
the responsibility for the written code has never changed.
No matter which editor was used to write the code, the responsibility to adopt, run, and maintain it has always rested with the developer themselves.
Just because a tool has become highly functional doesn't mean the responsibility for bugs has shifted to the tool. Just because completion was effective doesn't mean you are exempt from explaining how the code operates.
Convenient tools have lightened the "task of writing."
However,
they have never changed the "stance of ownership."
GAI is no exception in this regard.
Even if it looks as though GAI wrote the code, it is a human who decided to use it, judged where to integrate it, and put it into production.
Just because the tools have changed doesn't mean the location of responsibility has become ambiguous. It has simply become harder to see.
Development tools are not entities that bear responsibility on behalf of developers. GAI is also nothing more than one of the tools in that lineage.
If we don't hold onto this premise, the discussion will quickly drift in a different direction.
By using GAI, code of a scale or structure that you couldn't have written before may appear in your hands.
While this is convenient, it also creates a vague sense of unease that you are handling something beyond your own understanding or experience.
"It can't be helped because the AI wrote it."
"It's impossible to grasp everything."
These words often stem from bewilderment at being able to handle things beyond one's ability, rather than from irresponsibility.
However, the moment you use that anxiety as an excuse, the problem shifts from a technical discussion to a discussion of one's stance.
What we should look at next is not the performance of the tool,
but who will take ownership of the results of using it.
Column: Key Support Features That Have Sustained Development
Development environments have provided various functions to assist with work.
Snippets are a function for registering and reusing frequently used code fragments. Templates are a mechanism for generating templates for projects or functions all at once. Code completion is a function that suggests candidates based on the code being written or the context.
GAI further extends these, serving as a mechanism that takes an intention like "I want to do this" as input and returns it in forms such as code or tests.
Chapter 4: You Can Complain to a Library, but the Developer is the One to Work Around It
Software development is rarely completed with only the code you have written yourself.
Frameworks, libraries, and SDKs. You build a single system by combining these.
Naturally, external products can contain defects. Specifications change. It is not uncommon for documentation to be insufficient.
In such situations, it is natural for developers to feel frustrated. Pointing out problems and speaking up is by no means a mistake.
However, there is one reality.
It was the developer themselves who decided to use that library.
Even if there is a bug in a library, if a problem occurs in the production environment, the users look at the provider of the system.
"The library was at fault."
"It was an external problem."
Even if those are facts, the operational responsibility does not shift to the outside.
That is why, in the field, developers think of workarounds even while complaining.
- Fix the version
- Apply a patch
- Replace it with another method
Systems have been maintained by accumulating such judgments.
What is important here is not the difference between whether it is paid or free.
Whether it is free OSS or a paid library, the moment you adopt it, you are in a position to take ownership of its behavior.
The presence or absence of contracts or support may broaden the options for response, but it does not take over the responsibility itself.
GAI is not outside this structure either.
Even if there is a problem with the code generated by GAI, it was a human who adopted and integrated it.
Here, I would like to consider this from the perspective of a fellow developer.
If there were a bug in an SDK or library you are using, and you were given the following explanation from the provider:
"Because the tool generated it."
"Because it was an external factor."
Even if it were true as a matter of fact, there aren't many situations where that would be acceptable.
At the very least, if they left it at those words without providing problem isolation or a workaround, you would likely feel a strong sense of dissonance.
What developers are looking for is not the shifting of blame for the cause, but the stance of how to face that situation, given that premise.
Chapter 5: Responsibility Arises for Code Written by AI
Even if it appears that Generative AI wrote the code,
it is a human who decided to use it, adopted it, and integrated it.
"I don't know because AI wrote it"
"It can't be helped because the AI made a mistake"
I can understand that there are situations where one feels this way.
But these are
not reasons to shift the location of responsibility.
The important thing is the point that
responsibility was not born the moment you used AI.
Responsibility has existed since before GAI.
It has simply become harder to see because of the phrase "AI wrote it."
This responsibility exists regardless of whether it is paid or free, or for work or a hobby.
If that code is used in a place where it could stop someone's work,
influence someone's judgment, or take away someone's time,
there, responsibility arises.
So, with what kind of attitude should we undertake this responsibility?
The answer is the "Pride" that will be covered in the next chapter.
Chapter 6: What is Pride in the Age of AI Development?
"Pride" in the age of AI development is the determination to continue taking ownership of one's own judgments, without being misled by the evolution of tools.
So, what is required when putting that determination into practice?
It is taking responsibility for the code you have AI write.
- Being able to give precise instructions
- Being able to explain the outputted code
- Being able to fix it yourself if necessary
- Being able to make the decision not to adopt it
This is neither exclusion nor a screening process. It is a minimum safety mechanism to avoid breaking business systems or OSS.
Approving of GAI development and taking ownership of responsibility are not in conflict.
In fact, if you are serious about promoting GAI development, you must not look away from responsibility.
Tools have evolved. However, as long as you are a developer, your position of taking ownership of "what you provide using those tools" has not changed at all.
To continue taking ownership of that.
That, I believe, is the pride of the AI development era.
Chapter 7: A Few Habits to Make Pride a Reality
Pride is not something you just "have."
If it is not translated into judgment and action in actual practice, it will easily waver.
No special rituals are required.
You just need to be mindful of the following habits.
First,
Visualize the results concretely and convey them in words.
GAI is not an entity that automatically grasps "what you want to do."
What you should seek is not just the implementation itself, but
what kind of result you expect.
If that vision remains vague,
the code returned will also be vague.
Next,
Understand the provided code and be able to explain it in your own words.
You don't need to memorize it line by line.
But you must be able to explain
what that code accepts as input, how it behaves,
and what it outputs.
The range of what you can explain is precisely the range you can guarantee as code.
Finally,
Demonstrate responsibility for the product through testing.
"It worked" or "It seems fine" is not enough to prove product responsibility.
Only after showing that the expected behavior
is met under the expected conditions in the form of tests
is it ready for the world.
These are not new habits born in the GAI era.
They are merely a slightly more conscious exercise of the judgments
that those in the position of releasing products
have always undertaken.
Conclusion
In system development, GAI is strictly a tool.
It will never be the protagonist.
No matter how much the form of development changes,
it is humans who ultimately take responsibility.
As long as we are developers,
we will continue to take responsibility for what we provide.
That premise alone will remain unchanged.
Discussion