"AI will make software engineers unnecessary."
Over the past few years, I've heard this more and more often.
Honestly, I'm one of the people who is afraid of it. AI really is evolving at a remarkable speed.
When ChatGPT first appeared, it felt like "Google search gets a little easier." Now, it builds whole applications, proposes designs, and even does code review.
Watching this change, it's natural that some people wonder whether "the profession of software engineer is coming to an end."
I work as a software engineer myself. I use AI almost every day when developing. Incidentally, I even consulted AI about this article.
That's exactly why this change isn't someone else's problem for me.
Every day I think about what will happen from here and how I should build my career. Fortunately, for now I still have work.
Or rather, in Japan there's still a sense of an engineer shortage, so it's fine, but I hear that in the United States engineering jobs are already decreasing.
But will there still be work like this ten years from now? What skills would let me at least get by? When I think about that, I feel anxious.
So I decided to look at past revolutions.
Looking back at history, humanity has greatly changed "the way we work" many times.
The agricultural revolution. The industrial revolution. The arrival of computers. The internet. The cloud.
Each of them must have been revolutionary in its time.
I'm writing this article as a way to organize my thoughts while researching them.
In this article, I'd like to think about the AI era from the broad perspective of "systematization."
What Has Humanity Built?
Humanity made stone tools, used fire, and invented the wheel. Seen as a history of technology, that would be the explanation.
But when I look at history from the standpoint of a software engineer, I see a slightly different landscape.
What humanity has built is not only tools.
We have also built "mechanisms."
More precisely, I think that for thousands of years we have kept building mechanisms that produce the same kind of result without people having to think it through every time.
Take law, for example.
Without laws, every time someone caused trouble, a judgment would have to be made on the spot.
With laws, in many situations we can decide by following the same rules.
The same goes for the tax system.
Every year, nobody is thinking "what should we do about taxes this time" for each individual.
It is handled by predetermined rules.
Companies are the same.
Roles are defined. Approval flows are defined. Areas of responsibility are defined.
They are set up so that the organization keeps running even when people change.
I think this is also a kind of system.
When we hear the word "system," we tend to picture web systems or business systems.
But thinking a bit more broadly, we could say that humanity had been systematizing society itself long before computers appeared.
Looking at History as a Software Engineer
Because of my job, I sometimes get requests like "please turn this business operation into a system."
For example, logistics, education, or healthcare.
I observe the work on the ground and look at what information people look at, who makes the decisions, what the exceptions are, and what the unwritten rules are.
Then I convert that work into a form that a computer can handle.
In other words, it is the work of translating the real world into software.
Doing this work, strangely enough, I start to see history the same way.
Law is a translation of society.
A factory is a translation of production.
A company is a translation of an organization.
And software is a translation of information processing.
Though the subjects differ, they all seem to do the same thing: "turning reality into a reproducible mechanism."
If that is so, perhaps AI is not something entirely new either.
Perhaps it is a new stage in the endeavor of systematization that humanity has continued.
Lately, this is how I've been thinking.
What I Want to Think About in This Text
Of course, this is just one way of looking at things.
It is not the established view in historical studies.
To check whether this way of thinking is really valid, I am also gradually reading literature in history, economics, management studies, software engineering, AI research, and other fields.
Having looked into it, it seems hard to say it is "completely correct."
On the other hand, some researchers appear to hold quite similar ideas.
In this text, I'll think from a software engineer's standpoint about:
- What is a system?
- What has humanity systematized?
- What is industrialization?
- What did computers change?
- What does a software engineer actually do?
- Where does AI fit in history?
I don't want to predict the future of AI accurately.
But I feel that if I place AI back within humanity's long history and look at it, it becomes a little easier to see where the profession of software engineer is heading.
Chapter 2: What Is a System?
The word "system" is very convenient.
It is used almost every day in the IT industry.
Business systems. Sales management systems. Reservation systems. Core systems.
But if you stop and think for a moment, what is a "system"?
Is it software?
Is it a server?
Is it a database?
Of course, those are all parts of a system.
But I think it's more than that.
Systems Are Much Older Than Software
The word "system" was not born together with computers.
Its etymology is said to go back to the ancient Greek systēma.
Its meaning is "multiple things combined to function as a single whole."
In other words, a system originally has nothing to do with computers.
It is a mechanism in which parts relate to one another and fulfill a single purpose.
This idea spread to biology, management studies, sociology, and more, and today it connects to a field called "systems theory."
Society is a system.
The economy is a system.
An organization is a system.
The human body is a system.
Thinking this way, software is merely one kind of system.
The System As I See It
In this article, I'll try to define it a bit more in my own way.
I consider a system to be "a mechanism that makes it possible to obtain a consistent result without a person having to make a judgment every time."
Of course, this is not an academically rigorous definition.
It is simply a definition for use within this text.
Take traffic lights, for example.
Red means stop. Green means go.
It isn't that a police officer directs traffic at the intersection every time.
Because there are rules and mechanisms, society runs in roughly the same way.
This is also a system.
Companies are the same.
The company runs even if the department head is out.
Work continues even when employees are replaced.
That is because everything doesn't depend solely on individual ability, but runs on a mechanism called the organization.
Software is the same.
Press a button and an order is registered.
Inventory decreases.
An invoice is issued.
Even if the person in charge changes, the result is basically the same.
That's why we call it a system, I think.
What Is Systematization?
So what is systematization?
I think it is
externalizing, as a mechanism, the judgments that humans used to make in their heads.
Consider a restaurant, for example.
While the owner runs the place alone,
"Let's give this customer a little extra."
"This regular can pay later."
"Let's make this dish slightly milder today."
He can make all of these judgments in his head.
But what if there are 100 stores?
There would be 100 store managers.
There would be 1,000 part-timers.
At that moment, it can no longer be run
"in your head."
You need manuals.
You need recipes.
You need a POS system.
You need attendance management.
In other words, it becomes necessary to
convert human judgment into a mechanism.
This is systematization.
Systematization Is Not Automation
Here is one point that is easy to misunderstand.
Systematization and automation are not the same.
Take a checklist, for example.
It is just written on paper.
No computer is used.
But
even a new employee can inspect with the same quality.
In other words, it has been systematized.
Conversely, a vending machine is automated.
Press a button and a product comes out.
But behind it there are
restocking,
sales management,
change,
handling breakdowns,
logistics.
All sorts of systems.
Automation is part of systematization.
And computerization is also part of that.
Computers Accelerated Systematization
Even before computers appeared, humanity was building systems.
Law.
Taxes.
Armies.
Factories.
Companies.
Schools.
All of these are systems.
So what did computers change?
It is that they
made it possible to execute information-handling systems at overwhelming speed.
Take banks, for example.
When they were managed on paper, people copied entries into ledgers.
With computers, calculation is instantaneous.
Logistics is the same.
Inventory management is the same.
Computers did not so much create new work as
serve as devices that run already-existing social systems at high speed.
The Work of a Software Engineer
At work I build business systems.
When I'm designing, there are times when I spend more time thinking about
"what is being decided on the ground"
than writing code.
What is delivery?
What is a reservation?
What is a cancellation?
What is a return?
You can't write code without understanding these.
In other words, before writing code, a software engineer
understands the rules of the real world
and translates them into a form a computer can handle.
From this perspective,
a software engineer is not a programmer but
a profession that carries out systematization.
Writing code is merely the last step.
To the Next Chapter
If the history of humanity has been a history of systematization,
what was the first system?
Was it the computer?
Was it the factory?
I think its beginning lies much further back.
In the next chapter,
I'd like to think about the "systematization of society itself": law, the state, and bureaucracy.
How has humanity built mechanisms since thousands of years before software?
And I'll look at whether a single line connects it all the way to AI.
Chapter 3: When Did Society Become a System?
In the previous chapter, I defined the "system" of this article as
"a mechanism that makes it possible to obtain a consistent result without a person having to make a judgment every time."
If this way of thinking is right, then humanity was building systems thousands of years before software.
So where did it begin?
I think one of those beginnings was the birth of the "state."
Small Societies Didn't Need Systems
In the hunter-gatherer era, humans are thought to have lived in small groups of a few dozen people.
At that scale, society can be maintained by personal relationships alone.
Who can be trusted.
Who is good at hunting.
Who is sick.
Who broke a promise.
Everyone knows everyone.
The rules aren't written on paper.
There are no laws.
There are no taxes.
Even so, society holds together.
This is a little like modern startups.
In a company with only five employees, things somehow work without detailed work rules.
Often a quick word on Slack is enough.
But what if it becomes a company of 5,000?
The same approach won't work.
Wasn't society the same?
The Agricultural Revolution Created Complexity
By starting agriculture, humans began to settle down.
Population grew.
Land came into being.
Property came into being.
People began to stockpile food.
Cities appeared.
And
strangers began to live in the same society.
Only then do questions arise like
"who owns what,"
"who collects taxes,"
"who judges disputes."
In other words,
society itself became complex.
Law Can Be Seen as a Giant Algorithm
Let's think about law.
Suppose someone steals another person's property.
If there were no laws,
the king or village chief would have to make a judgment every time.
Judgments might vary from person to person.
The standard might differ between yesterday and today.
But with law it's different.
Cases can be handled by following predetermined rules.
Of course, real law is complex and cannot be applied mechanically.
There are judges' judgments.
There are exceptions.
Even so,
in the sense of "moving judgment from individuals to rules,"
it seems to have been a major turning point.
From a software engineer's standpoint,
law looks like a giant collection of if statements.
Of course, real law is far more complex.
But
society as a whole sharing how to handle a case once conditions are met
is somewhat similar to modern programs.
Bureaucracy as Software
Another interesting thing is bureaucracy.
Take taxes, for example.
A single king cannot manage the taxes of the entire population.
So roles are divided.
People who collect taxes.
People who keep records.
People who audit.
People who report.
Roles are divided,
procedures are set,
and areas of responsibility are decided.
This lets the state keep running even when people are replaced.
This is very similar to modern corporate organizations.
Work continues even when the person in charge quits.
There are manuals.
There are approval flows.
There are roles.
In both cases, it is a state where the organization, not the person, does the work.
I think this too is a kind of systematization.
The State Was Also a Giant Information System
To run a state,
information is needed.
Population.
Land.
Harvest yields.
Tax revenue.
Soldiers.
Roads.
These are things we would manage in a database today.
Of course, there were no computers in ancient times.
They were managed on paper and clay tablets.
Though the media differ,
a state can be said to be a system that manages a vast amount of information.
Collecting information,
storing it,
updating it,
and using it for decision-making.
There were no computers,
but it also seems that the idea of an information system already existed.
Humanity Didn't Increase "People"; It Increased "Mechanisms"
Looking back at history this far,
there is one thing I notice.
Just because society grew larger,
it wasn't solved by increasing the number of excellent people.
The ability of a single human has not changed much in thousands of years.
Even so, the reason we could build states is
that we made laws,
that we made roles,
that we made organizations.
In other words,
because we made mechanisms.
I think this may have been humanity's greatest invention.
Not the steam engine.
Not the computer.
"Making it possible to handle, through mechanisms, complexity that humans alone cannot process."
I think this is what drove civilization forward.
The Next Revolution
But even after states were built, problems remained.
Society runs.
There are laws.
There are organizations.
Even so,
the speed of making things depended on the ability of a single person.
Something a craftsman could make only one of per day existed only one per day.
Here the next revolution occurs.
The Industrial Revolution.
Humanity succeeded in systematizing not only society but
work itself.
In the next chapter,
I'll look at how division of labor, standardization, and the factory changed the way humans work.
And I'd like to think about how surprisingly similar that history is to modern software development.
Chapter 4: The Industrial Revolution — Work Became a System
The state created mechanisms for running society.
Laws were made.
Tax systems were made.
Bureaucracy was made.
A society that had relied on human memory gradually began to run on "mechanisms."
But one big problem remained.
Manufacturing.
The Craftsman Was a System
Before the Industrial Revolution, many products were made by craftsmen.
Furniture.
Shoes.
Clothes.
Tools.
A single craftsman
selected materials,
processed them,
assembled them,
and finished them.
The knowledge needed to complete a product was in that person's head.
In other words,
a single craftsman was a single system.
Of course, there were technical books.
There were apprentices.
But in the end,
it depended heavily on
"experience,"
"intuition,"
and "mastery."
If an excellent craftsman quit, quality dropped.
If he died, the skill was lost.
It was a society that depended on people.
What Adam Smith Discovered
In the 18th century, Adam Smith introduced the famous "pin factory" example.
Rather than one person making everything,
dividing the process yields overwhelmingly higher productivity.
The person who cuts.
The person who stretches.
The person who sharpens.
The person who packages.
Merely by decomposing the work, output rose by tens of times.
This story is often told as a story of economics,
but I think there is another way to see it.
That is,
the work itself was decomposed into a system.
Work that had been in one person's head
is divided into processes.
Divided into roles.
Made so that the result is the same no matter who does it.
This is very similar to software design.
Splitting a huge function
into small functions.
Separating responsibilities.
Modularizing.
Making the work easier to understand.
Division of labor may have been
system design itself.
Taylor Tried to Turn Work into a Program
In the early 20th century,
Frederick Taylor went one step further.
He observed work exhaustively.
How do people walk?
How do they hold tools?
How many seconds does it take?
Are there any wasted motions?
And he
standardized "the most efficient way of working."
This is known as scientific management.
Today it is sometimes criticized.
Some point out that it treats humans like machines.
But from a software engineer's perspective,
what he was doing also looks like
creating an algorithm for work.
Observe the work.
Extract the decisions.
Reduce the exceptions.
Write the procedure.
Make it reproducible.
It is surprisingly similar to what we do when we design business systems.
Ford Built an Engine That Executes Work
Henry Ford
extended that mechanism to the whole factory.
The conveyor belt.
Until then,
people went to the product.
Ford did the opposite:
he carried the product to the person.
Workers
did only their assigned tasks.
Then,
the flow of work itself became a system.
What Ford did was not
the invention of the automobile.
It was that he
designed the flow of work.
In software terms,
it was like building a workflow engine.
Who is in charge?
In what order does it proceed?
What must be finished before moving to the next step?
These are things we design almost every day in modern business systems.
A Factory Was a Giant Program
When I tour a factory,
I always feel like I'm looking at a program.
Materials come in,
get processed,
get inspected,
and get shipped.
There are conditional branches along the way.
If it's defective, send it back.
If it passes, move on.
If inventory is short, stop.
When a process finishes, notify.
It is a flowchart itself.
Of course, a factory is not software.
But
in the sense of "a mechanism that processes work in sequence,"
it is surprisingly similar to a program.
So I think
industrialization was also
a history of systematizing manufacturing.
Software Development Followed the Same Path
What is interesting is that
software development has followed the same history.
In the old days, one person wrote everything.
Design.
Implementation.
Testing.
Release.
But as systems grew,
review.
CI.
Automated tests.
Docker.
Cloud.
Microservices.
Roles were divided,
responsibilities were separated,
and things came to run on mechanisms.
In other words,
software development itself has been systematized.
The work of building software
was no exception.
Humanity Has Been Fighting Complexity
Looking at it this far,
it seems humanity wasn't seeking only convenience.
The real enemy
may have been
complexity.
Society grows.
People increase.
Work increases.
Information increases.
Then
it can no longer be handled by a single person.
So we build mechanisms.
Divide roles.
Standardize.
In other words,
systematize.
For thousands of years, humanity seems to have kept building systems
to manage complexity.
The Next System
But factories had their limits too.
Things could now be made efficiently.
Even so,
ledgers were on paper.
Accounting was on paper.
Banking was on paper.
Only information
was still being processed by humans.
What humanity systematized next was not "things."
It was information.
The computer was
the giant system that humanity first built to process information itself.
And a new profession was born to design that system.
The software engineer.
Chapter 5: What Did Computers Systematize?
As we've seen so far, humanity has systematized society and systematized work.
Law.
Companies.
Factories.
All were inventions for handling, through mechanisms, complexity that humans alone could no longer process.
But in the 20th century, a new problem arose.
That was
information.
Factories Became Efficient. But Clerical Work Didn't Change
The Industrial Revolution changed factories dramatically.
Mass production became possible.
But outside the factory, things were different.
Orders were on paper.
Inventory was on paper.
Accounting was on paper.
Payroll was on paper.
Banking was on paper.
Government offices were on paper.
Logistics was on paper.
In other words,
while the mechanisms for handling goods developed, the work of handling information was still processed by humans.
The bigger a company got,
the more paper there was.
The more ledgers.
The more calculations.
The more verification work.
Factories got faster,
but information was still at human speed.
Here a new bottleneck emerged.
The Computer Was Not a "Calculator"
When you say computer,
the image is of a machine that speeds up calculation.
Of course, that isn't wrong.
But thinking about modern computers,
I feel their bigger role than calculation
was
managing information.
Take banks, for example.
What a bank wants to manage is not the money itself.
It's account information.
Balances.
Transfer history.
Loan information.
In other words, information.
Logistics companies are the same.
It's not the packages themselves.
It's where the packages are.
Whose it is.
When it will arrive.
It manages that kind of information.
Reservation systems are the same.
They don't manage the hotel itself.
They manage the information of vacancies.
The computer was
a machine that handles not reality itself but information that represents reality.
The Real World Has a Database
When you design business systems,
you notice something.
The real world
has had a database from the start.
Take logistics, for example.
There are packages.
There are delivery staff.
There are vehicles.
There are delivery destinations.
Each of them has relationships.
If you turn this into an ER diagram,
it becomes almost the real world itself.
We are not inventing databases.
We are simply
re-expressing the real world as data.
The same goes for accounting.
The same goes for education.
The same goes for healthcare.
The real world has rules.
It has relationships.
It has states.
A software engineer
translates them into a form a computer can understand.
The Software Engineer Was a Translator
Let me pause here and
think about the job of software engineer.
I think
a software engineer is not a profession of writing code.
Of course, we write code.
But
there are things we do before writing code.
Go to the site.
Hear about the work.
Look at the paper.
Listen to what's said on the phone.
Ask about exceptions.
Question the person in charge.
"What is a return?"
"What does delivery completion mean?"
"What is a cancellation?"
"Who makes the decision in this case?"
It is not unusual for this time
to be longer than implementation.
In other words,
we are not writing code;
we are
understanding the real world.
And in the end,
we convert that understanding into a program.
That's why I think
a software engineer is
a profession that translates the real world into computers.
Software Was a Copy of Society
If this way of thinking is right,
what is software?
I think it may be
a copy of society.
Accounting software.
This is a copy of the accounting system.
Attendance systems.
These are copies of labor management.
An e-commerce site is a copy of commercial transactions.
A shipping system is a copy of logistics.
Software isn't building a world from scratch.
It is merely moving an already-existing society
into the computer.
Of course, there are improvements in the process.
There is new value.
But the starting point
is the real world.
What Computers Changed
So what did computers change?
Rather than changing society itself,
I think they
changed the speed of information processing.
The time to write ledgers.
The time to search.
The time to calculate.
The time to tally.
The time to verify.
All of these became dramatically shorter.
Information systems themselves were accelerated.
That's why companies could become huge.
Businesses could operate worldwide.
Logistics and finance
can no longer function without computers.
And Software Development Will Change Too
But there is something interesting.
Thanks to computers,
society's information processing was systematized.
And yet,
the work of building software itself
still depended heavily on humans.
Writing code.
Thinking through specifications.
Finding bugs.
Designing.
Reviewing.
These were, for a long time,
human work.
Of course IDEs evolved.
Libraries increased.
Frameworks appeared.
Even so,
the act of "building software" itself
was carried out by humans.
But even that situation began to change little by little.
Google appeared,
Stack Overflow was born,
GitHub spread,
and OSS expanded around the world.
Human knowledge itself
began to be systematized bit by bit.
And on the extension of that line,
AI appears.
The work of building software itself
is about to become the target of the next systematization.
Was that a natural course of events from the standpoint of human history?
In the next chapter,
I'd like to look back at how software development has changed since Google
and think about where AI came from.
Chapter 6: Software Development Has Also Been Systematized
Looking back at the history we've seen so far, there is one thing in common.
We systematized society.
We systematized work.
We systematized information.
I think the turn that came next was
the work of building software itself.
Once, Programming Was a Craft
When software development began, programming was an extremely specialized job.
Learn the language specification.
Understand the OS.
Understand the compiler.
Understand memory management.
Understand the CPU.
And write your own algorithms.
Truly craftsmen.
The ability to write code itself was the value.
So the more excellent the programmer,
the more knowledge they held in their heads.
Which API to use.
Which algorithm to choose.
Which libraries exist.
It was all experience.
Programmers of that era
closely resemble the craftsmen before the Industrial Revolution.
Google Systematized Knowledge
When Google appeared,
the way of developing changed.
When you don't know something,
you search.
When an error appears,
you search.
Even how to use an API,
you search.
In the past, we opened technical books from the bookshelf.
That became the browser.
Was this merely more convenient?
I think it was an event in which
access to knowledge was systematized.
It was no longer
"the person who remembers everything"
but
"the person who can find the information they need"
who became strong.
It was the moment when dependence on human memory
decreased a little.
Stack Overflow Shared Experience
Next came Stack Overflow.
Errors.
Design.
Implementation.
Best practices.
Developers around the world write down their experience.
This is an interesting change.
Experience,
which originally existed only in people's heads,
began to accumulate on the internet.
In other words,
experience itself became a system.
"What someone struggled with in the past"
became something that people all over the world could use.
GitHub Shared Software
GitHub was an even bigger change.
Until then,
we had shared knowledge.
But GitHub shares
the software itself.
Libraries.
Frameworks.
OSS.
Developers around the world
can publish code,
improve it,
and reuse it.
An authentication feature that in the old days we would build from scratch
is now just a matter of installing a library.
HTTP servers,
ORMs,
UI libraries,
all of them are made by somebody.
This may be described as
the implementation itself being systematized.
Docker Shared Environments
The next thing that changed
was not code.
It was the environment.
In the old days,
conversations like this were common on development teams.
"It works on my machine."
Everyone has probably heard it at least once.
Different OS.
Different library versions.
Different Node.js versions.
Environment setup
depended heavily on people.
Docker made it possible to share
the environment itself.
Even environment setup, which depended on people, was systematized.
CI/CD Systematized Releases
Writing code isn't the end of it.
Review.
Test.
Build.
Deploy.
In the old days,
people did these too.
Now,
just by pushing to GitHub,
tests run,
builds run,
and deployment finishes.
In other words,
the work of releasing itself
became a system.
Software Development Moved from "People" to "Mechanisms"
Lining these up,
I notice something interesting.
Google.
Stack Overflow.
GitHub.
OSS.
Docker.
CI/CD.
At first glance,
they are completely different technologies.
But they share something.
All of them
turned work that humans used to do into mechanisms.
Knowledge.
Experience.
Code.
Environments.
Releases.
Little by little,
they reduced the dependence on humans.
Is AI the Only Special One?
Here I started thinking
about AI.
AI is certainly an amazing technology.
It writes code.
It reviews.
It thinks about design.
It writes tests.
But
did it really appear out of nowhere?
I couldn't
think so.
Google systematized knowledge.
Stack Overflow systematized experience.
GitHub shared code.
Docker systematized environments.
CI/CD systematized releases.
On the extension of that line,
AI
began to systematize the intellectual work of implementation.
Thinking of it this way,
AI doesn't look like a revolution that suddenly appeared.
It seems like
the next step in the systematization of software development
that humanity has continued for decades.
And the Value of Writing Code Will Change
If this flow is right,
will AI take away the work of writing code?
Probably,
in part, yes.
But
I feel that a bigger change will occur.
More important than writing code
will become
what to systematize.
Software that was too expensive to implement to build before
becomes buildable thanks to AI.
Then
I think the software engineer's work
will shift even more from writing code
toward designing systems.
So,
will AI make software engineers unnecessary?
Or is it
asking us anew
about the essence of the profession of software engineer?
In the next chapter,
I'd like to place AI back within the whole of history
and think about what the work of a software engineer fundamentally is.
Chapter 7: The Software Engineer in the AI Era
So far, we've looked back over a long history.
The state.
Law.
Factories.
Computers.
The internet.
Software.
And AI.
At first glance, they each look like completely separate events.
But I think
there is something common to all of them.
That is,
"humanity has built systems in order to endure complexity."
Is AI a Revolution?
Is AI a revolution?
To this question,
I answer both "yes" and "no."
As technology, it is a revolution.
Things unthinkable a few years ago
are now everyday.
Writing code.
Thinking about design.
Writing tests.
Compiling documentation.
AI has begun to take on part of the intellectual work
that humans used to do.
This is without doubt a revolution.
But when seen across all of history,
a slightly different landscape appears.
We systematized society.
We systematized work.
We systematized information.
And now
we are trying to systematize software development itself.
Thinking this way,
AI is a revolution,
and at the same time
it seems to lie on the extension of a long history.
Is Writing Code the Essence?
When AI is discussed,
people often say
"the work of writing code will disappear."
In a sense, that is probably right.
In fact,
I myself spend more time writing code with AI.
An implementation that once took an hour
can now be done in ten minutes.
But
here I have a question.
Was writing code ever the essence of a software engineer?
I think not.
In work building business systems,
before starting to write code,
we go to the site.
We talk to the people in charge.
We read paper forms.
We understand the business flow.
We identify the exceptions.
And then
we think about
"What is delivery?"
"What is a return?"
"What is an order?"
Without this time,
we couldn't write a single line of code.
In other words,
code is merely the deliverable that appears at the end.
The Software Engineer Was a Translator
I think of a software engineer
as a translator.
Just as one translates English into Japanese,
we translate the real world into a form a computer can understand.
Translating the concept of delivery
into a database.
Translating the accounting system
into a program.
Translating a hospital's operations
into screens.
I think this translation
was what a software engineer's job was all along.
If so,
just because AI has started writing code,
the work of translation doesn't disappear.
On the contrary,
I think the things to be translated will increase.
The World That Can Be Systematized Is Still Vast
In my daily work,
there are countless moments when I think
"this has not yet become a system."
Phone calls.
Paper.
Excel.
Verbal handovers.
Tacit knowledge.
Judgments only veterans can make.
Region-specific operations.
A company's own rules.
Common sense that exists only within an industry.
There are countless mechanisms in society
that still exist only in human heads.
Until now,
even when we wanted to systematize them, we couldn't.
Because development costs were too high.
Because building software itself
was very expensive.
But thanks to AI,
that premise is starting to change.
AI Widens the Range of What Can Be Systematized
I think what AI will change most
is not the speed of writing code.
What will change
is the range of what can be systematized.
Until now,
systems we couldn't build because they'd cost 10 million yen.
Systems we gave up on because the company had only 10 employees.
Tools we didn't build because only one person would use them.
Such things
become buildable.
In other words,
software will not decrease.
On the contrary,
it may increase explosively.
Until now, humanity didn't build things
because it couldn't.
AI is about to remove that constraint.
What Will Become Valuable
So,
what should software engineers learn?
I think
it's not only programming.
Of course, technical skill is necessary.
But
what will become important from now on is
understanding society.
Understanding business operations.
Understanding law.
Understanding logistics.
Understanding healthcare.
Understanding education.
In other words,
the ability to understand the real world.
A system is a copy of the real world.
If you don't know the original,
you can't make a good system.
The same goes for AI.
AI can write code.
But
it doesn't tell you
"what should be built."
Finding the problems of the real world
is, for now, the role of humans.
I Am Optimistic
I do feel fear of AI.
So do I.
But looking back at history,
humanity has always built new mechanisms.
When law came about,
when factories came about,
when computers came about,
work changed.
But
the endeavor of "building mechanisms" did not end.
On the contrary,
its targets expanded.
That's why I think
rather than AI making software engineers unnecessary,
the world that software engineers can handle is expanding.
Writing code will no longer be the goal.
Understanding society
and designing it as a system
will become more and more important.
Perhaps such an era has already begun.
Finally
What prompted me to start writing this text
was a simple question:
"In an age when AI writes code, what is a software engineer?"
As I researched history,
researched industrialization,
researched the state,
and researched the history of computers,
I arrived at one idea.
It is that
over thousands of years, humanity has turned complexity into mechanisms.
And a software engineer
may have been a profession that, within that history,
took on the role of translating the real world into computers.
AI may be
not something that ends that work
but something that changes how that work is done.
That is what I think.