Why do developers continue to write code by hand?
Imagine you need to write a long piece of text that requires you to think things through, gather information, and analyze it. Then you have to write the text itself, proofread it, correct any errors, and refine the wording. Let’s say you spend 10 hours on this task. Now you need to translate this finished text into another language that you also know very well. You can translate it yourself or use an automatic translator. In the first case, you’ll need to translate each sentence manually and choose the best idioms so that the text sounds natural to a native speaker. The time required for translation increases proportionally to the length of the text. But if you use an automatic translator, you’ll get the translation in a matter of seconds. All that’s left for you to do is proofread the text and correct any words that were translated incorrectly. The time spent on intellectual work when drafting the text is dozens of times greater than that spent on mechanical translation.
Here’s another example. You’ve decided to rewrite a large project from C++ to Rust or from PHP to TypeScript. You’re working out a refactoring plan, choosing frameworks and libraries, determining the order in which to rewrite the modules, and figuring out how to migrate tests and update the documentation. You get a complete picture of what the end result will look like. Now all that’s left is the routine task — actually writing the code according to the plan. You can write every line of code by hand or assign the task of executing the plan to an AI agent. The time it takes to migrate the codebase can vary by a factor of tens or even hundreds.
Yes, translating an existing text and refactoring an existing codebase are not the same as creating new projects. But what’s the difference? After all, in new projects, before we write any code, we also work out an implementation plan, discuss possible solutions to the problem with the AI, and make many small decisions. Before writing the code, we already have a rough idea of what the code will look like, what modules it will contain, and what the test coverage will be. If we can’t plan the entire project, we start by planning just a few modules, and after implementing them, we move on to the next ones. But we always plan the implementation and make decisions first, and only then do we write the code. Just as we draft the text itself before translating it into another language, translating text from one natural language to another is just as routine a task as translating from a natural language into a programming language.
Some people still don’t believe that AI can speed up code writing several times over. Although they’re no longer surprised that AI in a regular chat can generate meaningful, structured text in seconds. With graphs, images, lists, and tables. But when it comes to writing code, people have doubts about whether the process can actually be sped up.
Others believe it can be sped up, but wonder: if our efficiency increases tenfold, the company won’t pay us ten times more, will it? So why bother improving our efficiency?
But we live in a capitalist world. We have to work efficiently not only to increase our income, but also simply to keep from getting fired. AI may not even increase a business’s revenue, but it will certainly increase the amount of visible work that your manager can monitor.
Businesses won’t always have good times when they can afford to keep inefficient employees. Sooner or later, there will come a time when someone has to be let go. If other employees, with the help of AI, are writing more lines of code, making more commits, and closing more tasks, while your productivity remains the same, you’ll be first on the list to be laid off.
You may disagree with the idea that employees should be evaluated based on the number of lines of code, commits, or tokens burned. In this case, you have three options: try to convince management to adopt your point of view, accept their approach, or quit and find another company where employees are evaluated based on different criteria.
If you try to challenge the company’s management practices, I can only wish you luck — but chances are, luck won’t be on your side, and you’ll be fired. The system doesn’t like those who try to change it. If you choose to change jobs, your life will once again become a series of random circumstances and stress, and you may spend several years searching for the right job.
All that’s left is to accept the business’s demand that employees use AI to improve their efficiency. And that means you’ll have to write more code, make more commits, and complete more tasks. Yet you won’t get a raise.
Skeptics often argue that the code will become unmaintainable, technical debt will grow, programmers won’t see the whole system, and they won’t be able to fix bugs or make changes to the code on their own.
And yet even young people aged 25-30 make these arguments, even though some of them already have many years of development experience. These aren’t middle-aged people who are used to writing code manually and don’t want to change anything in their lives. These are young professionals who, as I thought, should be open to new experiences.
If I assign tasks to an AI agent, make decisions about the architecture, review the code, and run all the tests, how can anyone say that I don’t understand the project’s code? After all, the AI writes exactly the same code that I would have written myself. And if I haven’t opened the project for a whole year, it doesn’t matter at all who wrote the code: me, someone else, or an AI agent. The code will be incomprehensible without reading the documentation. I’ll have to try to remember what was done and why.
Another reason for rejection is that the AI writes a lot of useless code that isn’t even relevant to the task. And for them, that’s a compelling reason to write all the code by hand. Although all you need to do is simply ask the AI agent to review the code and remove anything unnecessary. You don’t even need to review the code immediately after the task is completed. First, ask the AI agent to review the code, then fix the errors, then review it again, and fix it again. If you don’t want to ask it to do this every time, it can do it on its own in a loop. One subagent writes the code, another refactors it, a third reviews it, and a fourth fixes the errors. You can configure any sequence you like. It’s highly likely that after this cycle, there won’t be any useless code left in the project.
But then we’ll forget how to write code and won’t be able to maintain projects at all. But why would we need to manually maintain projects in the future? This scenario should be considered if we assume that the AI bubble will burst, providers will raise prices hundreds of times over, and AI with open weights will stop evolving. But even now, you can set up a home server, run something like Qwen, and not depend on paid providers. And when used correctly, the code will be the same as when using Claude or GPT.
So why do people want to do routine work that an AI agent can do automatically?