When I started programming, my whole day revolved around development. I’d wake up, write code, and go to sleep. And that’s how it was day in and day out. My entire social circle consisted of people who also wrote code. I studied frameworks, libraries, and various programming languages.

I got into development because I was fascinated by the idea that by writing code, I could create new programs. All I needed to do was learn how to program, and I’d be able to create anything. If I learned PHP, I could build back-end applications. If I learned HTML and CSS, I could build websites.

I could choose what I wanted to create, learn the necessary technologies for it, and start building. You open an IDE, create a new project, and build it from scratch. You choose patterns, libraries, and frameworks; you read the documentation and dive into the source code. You get so immersed in the process that you don’t even notice how the days fly by. Over time, you develop your own coding style.

I wrote code, and I enjoyed writing code, but it wasn’t the kind of work I wanted to do for the rest of my life. I preferred creating something new to the actual process of writing code. I liked starting from scratch — with nothing but an idea — to create a product that people actually use. That’s why I’ve always worked exclusively at startups and never at large companies.

I’ve always dreamed of advancing my career — to become a team lead, a manager, or to take on another role that didn’t involve writing code. And whenever someone else could write the code, I’d shift away from coding toward managerial tasks. Whether I wrote the code myself or delegated it to others didn’t matter to me.

Although I got into development out of an interest in creating things, later on I did it solely because I was getting paid for it. For me, it was just a job. Even though I wrote code in my free time, I still used that approach to build my own startups, which I planned to make money from. Writing code and making money were inseparable. Over time, income from projects became the main focus, rather than simply the desire to create projects.

But there’s another type of person. These are true programmers who write code regardless of income. They write code simply because they can’t help but write it. It doesn’t matter to them how much money they make from it. They might work on open-source projects that will never generate any income for them.

They enjoy writing code, solving development challenges, designing, figuring out the logic, fixing bugs, and understanding the entire system as a whole. They enjoy the process itself. And they’ll never hand that over to AI agents.

I love building startups, and they love writing code. For me, building projects is a way to make money. For them, programming is art.

That’s why all my arguments about how AI helps me build projects are completely irrelevant to true artists. They don’t need AI to help them with anything.

And that’s why there’s often a negative reaction to the claim that AI will soon replace all programmers. For artists, this claim itself is illogical. Even if some technological breakthrough occurs and AI can truly work autonomously and solve problems hundreds of times faster than humans, people will still continue to write code by hand, line by line. AI will never be able to take away their ability and desire to write code.

I don’t use AI when writing. It produces soulless, bland text. AI slop that no one wants to read. I want to come up with the wording myself, proofread and edit the text, come up with a title, and delete unnecessary sentences and entire paragraphs. I like it when new ideas for the text come to me as I’m writing. The writing process itself — the thinking that goes on in the moment — is important to me, not just the result. If I asked an AI to write a text on the topic “Programming is art”, that thought process wouldn’t happen. I wouldn’t experience the same emotions that come with writing it myself. For me, writing is art that I pursue regardless of money. I think people who enjoy writing code feel the same way.

The article "Why do developers continue to write code by hand?" was poorly received by the audience. It received only negative comments across all platforms. Everyone was convinced that all code should be written by hand, every single line of code.

I’m surprised by this because I really thought that many developers used AI agents to write code. The reality turned out to be different.

Programmers aren’t ready to lose their identity. For them, writing code is, to some extent, an art.

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?

The hardest thing is to achieve a balanced life. One where you have family, friends, work, hobbies, beer on the weekends, and trips abroad.

Creative people tend to lean heavily toward their creative pursuits and devote all their time to them. Career-driven people have no time left for family and friends. Party people have no time for work or creativity.

Sometimes, in your youth, you’re a party animal, then a career-driven person, and then a family person. Or the other way around: first you became a career-driven person, achieved success or became disillusioned with it, and then became a creative person.

Which is better: leading a balanced life or swinging from one extreme to another?

1. An inexperienced vibecoder might create an app where all user passwords are stored in plain text.
2. An inexperienced user might use the same password across all services and not use two-factor authentication.
3. An inexperienced hacker uses AI to find a vulnerability in the app and gains access to the database.
4. The password from the database gives the hacker access to all the services where the user is registered.

This problem has always existed.

But now, almost any inexperienced person can create an app, and an inexperienced hacker can find a vulnerability in that app.

At the same time, the number of inexperienced users hasn’t changed. It’s just that they’ve now started using vibe-coded products and are exposing themselves to greater risk than before.