"AI will make software engineers unnecessary." Over the past few years I have heard some version of that line far more often than I would like. To be honest, I am one of the people it frightens. AI is simply moving very fast.
When ChatGPT first appeared, it felt like little more than a slightly easier Google search. Today it builds entire applications, proposes designs, and even reviews code. Watching all this, it is only natural that some people conclude the profession is on its way out.
I work as a software engineer myself, and I use AI almost every day while developing. I might as well confess that I consulted AI about this very article. So this change is anything but someone else's problem.
Where are things headed, and how should I build my career? I think about little else, nearly every day. Fortunately, I still have a job for now. In Japan there is still a sense of an engineer shortage, so things are presumably fine for the moment.
In the United States, though, I hear that engineering jobs are already shrinking. Will there still be work like this ten years from now, and what skills would let me at least get by? Once I start down that road, anxiety is hard to avoid.
So I decided to look at past revolutions. The agricultural revolution, the industrial revolution, the arrival of computers, the internet, the cloud. Humanity has overhauled "the way we work" many times, and each of those shifts must have felt revolutionary in its day.
While digging into them, I want to think about the AI era from the broad perspective of "systematization." It sounds grander than it is; in plain terms, it means building things into a system, so that what used to depend on someone's head or hands runs on its own, whether or not a computer is involved. I have no idea whether there's a rigorous academic definition, but that's what I'll call it here. If you want the precise definition, ask an AI. That's what it's for. Consider this text at least half an exercise in sorting out my own head.
Mechanisms, Not Just Tools
If you tell it as a history of technology, humanity made stone tools, used fire, and invented the wheel. Look at the same history as a software engineer, though, and a slightly different landscape appears. What humanity has built is not only tools but also mechanisms. And for thousands of years, it seems, we have kept building mechanisms that produce roughly the same result without anyone having to think it through every time.
Take law. Without laws, every time someone caused trouble, a judgment would have to be made on the spot. With laws, most situations can be settled by following the same rules.
Taxes work the same way. Nobody sits down each year and wonders, person by person, "What shall we do about this one's taxes?" They are processed, quietly and dutifully, according to rules decided in advance.
Companies, too. You define roles, approval flows, and areas of responsibility so that the organization keeps running even as people come and go. That is a system in its own right.
When we hear the word "system," we tend to picture web systems or business software. Take a wider view, though, and humanity was systematizing society itself long before computers showed up.
The Job of Translating Reality
In my line of work, I sometimes get requests along the lines of "please turn our operations into a system." The fields vary, from retail to education to healthcare, but the job is largely the same. I observe the work on the ground and dig out what information people look at and who makes the decisions. I also collect the exceptions and the unwritten rules.
Then I convert that work into a form a computer can handle. In other words, it is the job of translating the real world into software. The source text lives on the ground; the translation becomes code.
Do this long enough and, strangely, history starts to look the same way. Law is a translation of society, factories of production, companies of organization. And software is a translation of information processing. The targets differ, but each is an endeavor to turn reality into a reproducible mechanism.
If that is so, AI may not be an entirely new creature at all. It may be merely a new stage in the long human enterprise of systematization. That is how I have been thinking lately.
Of course, this is one perspective and by no means an established view in historical scholarship. I wanted to check whether it holds water, so I have been slowly reading the literature. History, economics, management, software engineering, AI research: the fields are all over the map.
As far as I can tell, calling it "completely correct" would be a stretch. That said, I did find researchers who seem to think along quite similar lines.
So in what follows, I will work through a few questions from a software engineer's standpoint. What is a system, and what has humanity systematized? What did industrialization and computers each change? And finally, I want to place the profession of software engineering, and AI, within history.
I am not trying to predict the future of AI with any precision. I simply suspect that placing AI back into the long arc of human history makes it a little easier to see where this work is heading.
The Word "System"
The word "system" is, frankly, a bit too convenient. In the IT industry it flies around daily: business systems, sales management systems, reservation systems, core systems. Yet ask what a system actually is, and the answer suddenly gets stuck in your throat.
Is it the software? The servers? The database? Those are all parts of a system, but surely not the whole of it.
The first thing to establish is that the word "system" was not born alongside computers. Its roots are said to go back to the ancient Greek systēma. It means "multiple things combined so that they function as a single whole." A system, in the original sense, is a mechanism in which parts relate to one another to serve a single purpose.
The idea spread into biology, management, and sociology, and today connects to a field known as systems theory. Society, the economy, organizations, and the human body are all systems. Seen that way, software is just one kind of system.
With that in place, let me narrow the definition in my own terms. I think of a system as "a mechanism that yields a consistent result without people having to make a judgment every time." It is not a rigorous academic definition, just a working one for the purposes of this text.
Take traffic lights. Red means stop, green means go. There is not a police officer directing traffic at every intersection. Yet because the rules and the mechanism exist, society moves in a more or less predictable way.
A company is the same: it keeps running when a department head takes a day off, and the work goes on when employees are replaced. Not everything depends on individual ability; it runs on the mechanism called an organization.
Software, too. Press a button and an order is registered, stock goes down, and an invoice is issued. Change the person in charge and you basically get the same result. That is why we call it a system.
Externalizing Judgment
So what is systematization? I see it as taking judgments that people used to make inside their heads and externalizing them as a mechanism.
A restaurant makes this easy to see. While the owner runs the place alone, every call can be made in their head. Give this customer something on the house, let this regular run a tab, go a little lighter on the seasoning today.
But once there are 100 locations, the story changes completely. You now have 100 store managers and 1,000 part-timers, and at that moment the business can no longer run on "what's in the owner's head." You need manuals and recipes, and a POS system and attendance management become indispensable. You have no choice but to convert human judgment into mechanisms, and that is systematization.
One point that is easy to get wrong is that systematization and automation are not the same thing. A checklist is just writing on paper, with no computer involved whatsoever. Yet it lets a newcomer carry out an inspection at the same quality, so it is very much a system.
Conversely, a vending machine is automated, in the sense that you press a button and a product comes out. Behind it, though, stand all sorts of systems: restocking, sales management, change, repairs. Automation is one part of systematization, and computerization is likewise just one part of it.
Indeed, long before computers, humanity kept building systems: law, taxes, armies, factories, companies, schools. Then what did computers change? They made it possible to run systems that handle information at overwhelming speed.
In banking, people once copied ledgers by hand. With computers, the calculation happens in an instant. Inventory management is the same story. Rather than creating new work, the computer was a device for running society's existing systems at high speed.
I build business systems for a living. When I am designing, I often spend more time asking "what is actually being decided on the ground?" than writing code. What is a reservation? What is a cancellation? What is a return? Without understanding that, not a single line of code gets written.
Before writing code, then, a software engineer deciphers the rules of the real world and translates them into a form a computer can handle. From this vantage point, a software engineer is less a programmer than a professional systematizer. Writing code is merely the last step.
If human history really is a history of systematization, what was the first system? Not the computer, not the factory; the beginning seems to lie much further back. It lies in the systematization of society itself: law, the state, and bureaucracy.
The State as a Mechanism
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 held together 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 are not written on paper, and there are no laws and no taxes, yet society works anyway.
This resembles a modern startup a little. With only five employees, you can get by without detailed work rules, and a single message on Slack often settles things. Try the same approach at a company of 5,000 and it simply does not hold. Society was probably no different.
The turning point was the agricultural revolution. Farming led humans to settle down; the population grew, and concepts like land and property emerged. Food was stockpiled, and eventually cities formed. And people who did not know each other started living in the same society.
Only then did questions arise like who owns what, who collects taxes, and who settles disputes. Society itself had become complex.
Law as a Giant If Statement
Consider law. Suppose someone steals another person's property. Without law, a king or village chief would have to rule on it every time. The outcome might vary by who was judging, or the standard might drift between yesterday and today.
With law, the case can be handled according to rules decided in advance. Real law, of course, is complicated and nothing you can apply mechanically. There are judges' rulings, and there are exceptions. Even so, in the sense of moving judgment from the individual to the rule, it must have been a major shift.
Through a software engineer's eyes, law starts to look like a giant collection of if statements. Actual law is far more tangled than that. Still, the way an entire society shares an agreement about what to do when certain conditions are met does bear some resemblance to a modern program.
Another fascinating case is bureaucracy. Take taxes: there is no way a single king could manage the taxes of an entire population. So the roles get split into people who collect, record, audit, and report; procedures are defined and areas of responsibility are set. This let the state keep running even as people were replaced.
Work continues after someone quits, there are manuals, there are approval flows, there are roles. In that respect, bureaucracy closely resembles a modern corporation. In both cases it is the organization, not the person, doing the work, and I consider that a kind of systematization too.
Going further, the state was also a giant information system. Without information on population, land, harvests, tax revenue, soldiers, and roads, a state cannot be run. Today we would put all of that in a database, but antiquity had no computers, so it was managed on paper and clay tablets. The medium was different, but the idea of collecting, storing, updating, and using information to make decisions already existed.
Looking back this far, one thing stands out. When society grew larger, humanity did not solve the problem by producing more brilliant people. Individual human ability has hardly changed in thousands of years, after all.
The reason we could build states anyway is that we created laws, roles, and organizations; in short, we created mechanisms. Not the steam engine, not the computer. The ability to handle, through mechanisms, a complexity that humans alone could not process: that, I suspect, is humanity's greatest invention and the force that has pushed civilization forward.
From Craftsman to Conveyor Belt
Even with the state in place, though, a problem remained. Society ran, and there were laws and organizations. But the speed at which things could be made was still bound by the ability of a single person. If a craftsman can make only one of something a day, only one of it exists per day.
Then came the industrial revolution. Humanity succeeded in systematizing not just society but work itself.
Before the industrial revolution, furniture, shoes, clothes, and tools were mostly made by craftsmen. One craftsman would select the materials, process them, assemble them, and finish them. The knowledge needed to complete a product lived in that person's head; each craftsman was, you could say, a system unto himself.
There were technical books and apprentices, but in the end it all depended heavily on experience, intuition, and skill. When a great craftsman quit, quality fell; when he died, the technique died with him. It was a society that depended on people.
In the 18th century, Adam Smith introduced his famous pin factory example. Rather than having one person make everything, splitting the process among people who cut, draw out the wire, sharpen, and package raises productivity enormously. Merely breaking the work apart multiplied output dozens of times over.
This story is usually told as economics. To me, though, it also reads as the story of breaking work itself down into a system. Work that lived in one person's head was split into steps and roles so that anyone doing it would get the same result.
Split a giant function into small ones, separate responsibilities, modularize to make things easier to understand. That is practically indistinguishable from software design. Division of labor may well have been system design all along.
In the early 20th century, Frederick Taylor went a step further. He observed work exhaustively. How do people walk, how do they hold their tools, how many seconds does it take, and is any movement wasted? Then he standardized "the most efficient way to work."
This approach, known as scientific management, is sometimes criticized today for treating people like machines. To a software engineer, however, it looks like writing an algorithm for work. Observe the work, extract the judgments, reduce the exceptions, write down the procedure, make it reproducible. It is strikingly similar to how we design business systems.
The person who extended that mechanism to the entire factory was Henry Ford, with the conveyor belt. Until then, workers went to the product. Ford flipped it and brought the product to the worker. Each worker performed only their assigned task, and the flow of work itself became a system.
What Ford did was not invent the automobile but design the flow of work. In software terms, he built something like a workflow engine. Who handles this, in what order does it proceed, and what must be finished before moving on? He pulled off, long ago, exactly what we design in business systems every day.
The Factory as a Flowchart
Whenever I tour a factory, I feel as if I am looking at a program. Materials come in, get processed, get inspected, and leave as finished products. Along the way there are conditional branches: send back defective items, pass good ones along, halt when stock runs short, send a notification when a step completes. It is a flowchart in physical form.
A factory is not software, of course. But as a mechanism for processing work in sequence, it is a near twin of a program. Industrialization, then, was also a history of systematizing manufacturing.
What I find interesting is that software development has walked the same road. In the old days, one person did the design, implementation, testing, and release. But as systems grew, review, CI, automated testing, Docker, the cloud, and microservices crept in. Roles and responsibilities were divided and things came to run on mechanisms, so the job of building software was no exception to systematization either.
Seen this way, humanity was not chasing convenience alone. The real enemy was probably complexity. As society grows, as people multiply, as work and information pile up, a single person can no longer cope.
So we build mechanisms, divide roles, standardize. In a word, we systematize. For thousands of years, humanity has kept building systems to manage complexity.
Paperwork Left Behind
Factories had their limits too. Goods could be made efficiently, but ledgers, accounting, and banking were still on paper. Information alone was still processed by people.
What humanity systematized next was not things but information. The computer was the first giant system humanity built to process information itself. And along with it came a new profession to design such systems: the software engineer.
The industrial revolution transformed factories and made mass production possible. Step outside the factory, though, and the picture was entirely different. Orders, inventory, accounting, and payroll were on paper; banks, government offices, and shops were on paper. While the mechanisms for handling things had advanced, work involving information was still done by people.
The bigger a company grew, the more paper, ledgers, calculations, and checks piled up. Factories got faster, yet information alone was left behind at human speed. A new bottleneck was born.
We tend to think of the computer as a machine that speeds up calculation. That is not wrong. Judging by computers today, though, their larger role has been managing information.
What a bank wants to manage is not money as such but information: account details, balances, transfer histories, loan records. A library is not managing books as such, but information about where each book is, who has borrowed it, and when it will come back. A reservation system does not manage the hotel itself but the information called vacancy. The computer, in short, was a machine that handles not reality itself but information that represents reality.
When you design business systems, you notice that the real world already has a database in it. A library has books, members, loans, and due dates. They are related to one another, and if you draw an ER diagram, it looks almost exactly like the real world.
We are not inventing databases. We are merely re-expressing the real world as data. Accounting, education, and healthcare are no different; the real world has rules, relationships, and states. Software engineers translate them into a language computers can read.
Software as a Translation of Society
Let me return to the job of software engineering itself. I do not think of it as a profession of writing code. Of course we write code. But there is something we do before that.
We go on site, listen to how the work is done, look at the paperwork, listen to phone calls, ask about exceptions, and question the people in charge. What is a return? What counts as an intake being complete? What is a cancellation? Who makes the call at this point? More often than not, this takes longer than the implementation.
Rather than writing code, we are understanding the real world. Only at the end do we convert that understanding into a program. A software engineer, then, is someone whose profession is translating the real world into computers.
If that view is right, what is software? I think of it as a translation of society. Accounting software is a translation of the accounting system; attendance software, of labor management. An e-commerce site renders commerce, and a reservation system renders the guest register and the ledger.
Software does not create a world from scratch. It moves an already existing society into the computer. Along the way there are improvements and new value, of course, but the source text is always the real world.
So let me ask again: what did computers change? Less society itself than the speed of information processing. The time to write ledgers, to search, to calculate, to tally, to check. All of it shrank dramatically, and information systems themselves got faster.
That is why companies could grow huge and business could be done worldwide. Retail and finance can no longer function without computers.
Interestingly, though, even after society's information processing was systematized, the job of building software itself remained heavily dependent on people for a long time. Writing code, working out specs, hunting bugs, designing, reviewing. IDEs evolved, libraries multiplied, frameworks appeared, but the act of building was still carried by humans. That began to change, little by little, around the time Google arrived.
From Search to CI/CD
Society was systematized, then work, then information. Next in line, I suspect, was the job of building software itself.
When software development began, programming was an extremely specialized job. You memorized language specs, understood the OS and compilers, understood memory management and the CPU, and then wrote your own algorithms. It was true craftsmanship, and the ability to write code was itself the value.
The best programmers carried in their heads which API to use, which algorithm to choose, and which libraries existed. What held all of that up was experience, pure and simple. Programmers of that era closely resembled craftsmen before the industrial revolution.
When Google arrived, the way we developed changed. If you did not know something, you searched; if an error came up, you searched; how to use an API, you searched. Where we once opened technical books from the shelf, the browser took over.
This was not merely a matter of convenience; it was the systematization of access to knowledge. The strong were no longer "people who remember everything" but "people who can reach the information they need." Our dependence on human memory shrank a little.
Next came Stack Overflow. Developers around the world began writing down their experience with errors, design, implementation, and best practices. Experience that once existed only inside people's heads piled up on the internet, and "what someone struggled with in the past" became available to everyone. You could say experience itself became a system.
GitHub was an even bigger shift. Until then, what we shared was knowledge; GitHub shares software itself. Through libraries, frameworks, and OSS, developers worldwide could publish, improve, and reuse code.
Authentication, which you once had to build from scratch, now takes installing a library. HTTP servers, ORMs, UI libraries: somebody has built all of them for us. Implementation itself was systematized.
What changed next was not code but environments. On development teams of old, the well-worn excuse "well, it works on my machine" was an everyday occurrence. Everyone has heard it at least once. If you added up all the hours that one phrase has burned worldwide, I suspect you would land somewhere around a small nation's budget.
Different OS, different library versions, different Node.js versions. Setting up an environment depended heavily on people. Docker made it possible to share the environment itself, turning even that people-dependent chore into a mechanism.
And code is not done once it is written. You review it, test it, build it, deploy it. People used to do all of that too, but now a push to GitHub sets off the tests, runs the build, and finishes the deployment. With CI/CD, the job of releasing itself became a system.
Line them up, and Google, Stack Overflow, GitHub, OSS, Docker, and CI/CD look like completely different technologies. In fact, each turned work that people used to do into a mechanism. Knowledge, experience, code, environments, releases: software development has steadily reduced its dependence on people.
Did AI Come Out of Nowhere?
This is where I started thinking about AI. AI is certainly an impressive technology. It writes code, reviews it, thinks through designs, and even writes tests. But did it really appear out of nowhere? I cannot bring myself to believe so.
Google systematized knowledge, and Stack Overflow systematized experience. GitHub shared code, Docker systematized environments, and CI/CD systematized releases. On that same trajectory, AI has begun to systematize the intellectual work of implementation.
Seen this way, AI looks less like a revolution that dropped from the sky and more like the next step. It is the next step in the systematization of software development that humanity has pursued for decades.
If this reading is right, will AI take away the job of writing code? Partly, probably. But I sense a bigger change coming. What to systematize will matter more than writing code.
Software that used to be too expensive to build will become buildable with AI. When that happens, the weight of a software engineer's work will shift even further from writing code to designing systems.
Is AI going to make software engineers unnecessary? Or is it forcing us to ask afresh what the profession really is? From here on, I want to place AI back into the full sweep of history.
Revolution and Continuation
The state, law, factories, computers, the internet, software, and now AI. They look like entirely separate events, but I believe one thing runs through all of them: humanity has built systems in order to endure complexity.
Is AI a revolution? My answer is both yes and no. As technology, it is unquestionably a revolution. Things unthinkable a few years ago are now everyday.
Writing code, thinking through designs, writing tests, summarizing documentation. AI has begun to take on part of the intellectual work that humans used to carry.
Viewed against the whole of history, though, a slightly different landscape appears. We systematized society, then work, then information, and now we are trying to systematize software development itself. Seen this way, AI is a revolution and, at the same time, a continuation of a very long history.
Whenever AI comes up, someone inevitably says "the job of writing code will disappear." In a sense, that is true. I myself spend more and more time writing code with AI, and implementation that once took an hour sometimes finishes in ten minutes.
But that raises a question. Was writing code ever the essence of software engineering in the first place?
I do not think it was. When building business systems, before writing a single line, you go on site, talk to the people in charge, and read the paper forms. You understand the workflow and surface the exceptions. Only then do you think about what a reservation is, what a return is, what an order is.
Without that time, not one line of code gets written. Code is merely the artifact that appears at the end.
At the risk of repeating myself, I still think of software engineers as translators. Just as you translate English into Japanese, you translate the real world into a form computers can understand. The concept of a reservation into a database, the institution of accounting into a program, a hospital's operations into screens.
If this translation was the real job of a software engineer all along, then AI writing code does not make translation disappear. If anything, the amount of source text waiting to be translated will grow.
Still a World of Paper and Phone Calls
In my day-to-day work, I am forever running into moments where I think, "this still isn't a system." Phone calls, paper, Excel, verbal handoffs, tacit knowledge, judgments only veterans can make. Region-specific practices, company-specific rules, conventions that exist only within an industry: the list goes on and on. Society is still full of mechanisms that live only inside people's heads.
Think of it as a mountain of source text nobody has translated yet. Until now, we could not systematize it even if we wanted to. Development was expensive, and building software was itself a costly undertaking. AI, however, is starting to change that premise.
That is why I think what AI changes most is not the speed of writing code but the range of what can be systematized. Systems never built because they would cost 10 million yen, systems abandoned because the company has only ten employees, tools never made because only one person would use them. These become buildable.
Software, far from shrinking, could explode in volume. Humanity has simply not built what it could not afford to build. AI is about to remove that constraint.
Reading the Source Text
So what should software engineers learn? Technical skill is still necessary, of course, but programming alone will not be enough. What will matter is understanding society, business operations, and real-world domains such as law, accounting, healthcare, and education. In a word, the ability to understand the real world.
Since a system is a translation of the real world, you cannot build a good one without being able to read the source. AI is no exception. It can write code, but it will not tell you "what should be built." Finding problems in the real world is, for now, a human role.
I, too, feel some fear of AI. But looking back through history, humanity has always built new mechanisms. When law appeared, when factories appeared, when computers appeared, work changed. Yet the enterprise of "building mechanisms" never ended; if anything, its scope widened.
So I do not believe AI will make the job of software engineer disappear. What the job consists of, though, will change completely. Just as factories gradually replaced the handwork of craftsmen, programming as a task will, sooner or later, be taken over by AI. Software engineers will remain, but writing code by hand will surely stop being the center of the job.
In exchange, the world software engineers can take on will widen. Writing code will stop being the goal, and understanding society and designing it as a system will matter more and more. That era may already have begun.
In that sense, I am surprisingly optimistic. Which does raise the question of who exactly was so frightened at the top of this post.
That's the story of how I started from a naive question, what is a software engineer in an age when AI writes code, and traced it through history: the state, industrialization, computers, and software development. Where I ended up is this: over thousands of years, humanity has turned complexity into mechanisms. Within that history, software engineering has been the profession that translates the real world into computers.
AI is not here to end that work but to change how the translating gets done. Building mechanisms is not something that stops just because the tools changed.