There is a special irony in the fact that programmers spent decades automating other people's work: accountants, storekeepers, operators, secretaries. And all those years they treated the question "can You yourselves be automated?" with a slightly condescending smile. Then large language models arrived, and for many that smile became nervous. Now I am asked this question both by clients ("why pay a team if a neural network writes code?") and by developers themselves ("are we about to be replaced?"). I will answer as someone who has been building systems for many years and has spent recent years working side by side with AI agents every day.
We no longer type every character
Let me start with what has already happened, because it is not a forecast but a fact. Writing typical functions, boilerplate code, tests, data transformations and code documentation is something machines do quickly and, in most cases, well. Finding obvious bugs and vulnerabilities too. I stopped writing by hand what I can describe in words a long time ago, and that is not laziness but hygiene: why spend an hour on something that is generated in a minute and checked in five.
At Ingello this path began long before neural networks. Fractal, our generator, grew out of a simple idea: a system should not be typed by hand, it should be described, and the code, the database schema, the API and the admin panel should be produced by a machine. At first it worked by strict rules, and now AI agents have joined the rules. But the meaning has not changed: the programmer stops being a typist and becomes a conductor. He does not play every instrument, he is responsible for the orchestra sounding like music rather than like tuning up before a concert.
What cannot be automated
This is where it gets interesting. Code is the last step in a long chain. Before it, someone has to understand what the business really needs, and that almost never matches what was said at the first meeting. Someone has to choose a data model that will survive the company's growth three years from now. Someone has to decide where the system must be strict and where it must be flexible. Someone has to foresee what happens when two employees edit the same record at the same time, when an external service goes down, when accounting changes the rules.
A model answers a well-posed question brilliantly. But posing the question, seeing the real problem behind the client's words, finding the contradiction between two departments that describe the same process differently, it cannot yet do well enough to be trusted with it unsupervised. This is less about intelligence and more about context and responsibility. The model was not in the meeting where it turned out that the warehouse and sales count stock differently. The programmer was.
AI writes the answer brilliantly. But someone has to understand which question to ask, and be responsible for the result.
Who is being automated after all
I will be honest: some roles really are shrinking. A programmer whose job was to translate a detailed instruction into code without any thinking of his own found himself exactly in the zone where the machine is stronger. It is unpleasant, but it is not news: typesetters in printing houses disappeared the same way, and later typists. Value is moving up the chain: from "I can write it" to "I can understand, design and verify it".
At the same time, the amount of work for capable engineers is not shrinking but growing. When creating code gets cheaper, businesses start ordering what used to be too expensive: small internal tools, automation of narrow processes, prototypes that were never even discussed before. It is like electricity: when it got cheaper, there were not fewer electricians, there were just many more sockets.
New risks worth knowing about
Generated code is dangerous because of how plausible it is. It looks neat, the comments are in place, the variable names make sense, and inside there may be a subtle logical error that an inexperienced eye will miss. That is why automating development does not cancel but strengthens the requirements for verification: automated tests, human review, architectural control. A company that replaced its team with a neural network without engineering oversight ends up, six months later, with a system nobody understands, including the neural network itself.
The second risk: the illusion of speed. You can generate a first version in an evening. Bringing it to the state where a hundred people use it and it does not lose data is still work. A quick start does not equal a quick finish, and it is worth remembering when someone promises "a CRM over the weekend".
What this means for the client
If You are ordering development today, do not ask the contractor "how many programmers do you have", ask "how do you use automation and how do you control quality". A team that still writes everything by hand will be more expensive and slower. A team that generates everything without verification will be cheaper at the start and much more expensive later. You need the middle: machines handle the volume, people are responsible for meaning, architecture and quality.
That is exactly how we work at Systems: design, analysis and architecture stay with experienced people, while Fractal and AI agents take over the generation of code, schemas and interfaces. Can a programmer be automated? What a programmer used to do with his hands can be automated. What he does with his head has only become more valuable.
