Когда я начал программировать, весь мой день строился вокруг разработки. Я просыпался, писал код, уходил спать. И так было изо дня в день. Весь мой круг общения состоял из людей, которые тоже пишут код. Я изучал фреймворки, библиотеки, разные языки программирования.

Я пришёл в разработку, потому что меня восхищала мысль о том, что с помощью написания кода я могу создавать какие-то новые программы. Всё, что мне нужно, — это просто научиться программировать, и я смогу создать что угодно. Если я изучу PHP, то смогу делать бэкенд. Изучу HTML и CSS и смогу создавать сайты.

Я мог выбрать, что я хочу создавать, изучить под это нужные технологии, и начать создавать. Открываешь IDE, создаёшь новый проект, и с чистого листа реализовываешь. Выбираешь паттерны, библиотеки, фреймворки, читаешь документацию, разбираешься в исходниках. Ты настолько погружаешься в процесс, что не замечаешь, как проходят дни. Со временем появляется свой собственный стиль разработки.

Я писал код, и мне нравилось писать код, но это была не та деятельность, которой я хотел бы заниматься всю жизнь. Я больше любил создавать что-то новое, а не сам процесс написания кода. Мне нравилось с нуля, с одной только идеи, создавать такие продукты, которыми пользуются люди. По этой причине я всегда работал только в стартапах и никогда в крупных компаниях.

Я всегда мечтал о карьерном росте, чтобы стать тимлидом, менеджером, или занять другую роль, в которой не будет написания кода. И всякий раз, когда код мог написать другой человек, я уходил из написания кода к менеджерским задачам. Пишу я код сам или делегирую это другим людям, для меня не имело значения.

Я хоть и пришёл в разработку из интереса самого создания чего-либо, позже я стал заниматься этим только потому, что мне платили за это деньги. Это для меня было именно профессией. Хоть я и писал код в свободное от работы время, я всё же таким способом делал свои стартапы, с которых планировал зарабатывать деньги. Написание кода и деньги были неотделимы друг от друга. Со временем главным стал доход с проектов, а не просто желание создавать проекты.

Но есть другой тип людей. Это истинные программисты, которые занимаются написанием кода независимо от дохода. Они пишут код просто потому, что не могут его не писать. Им не важно, сколько денег они на этом зарабатывают. Они могут делать опенсорс проекты, которые никогда не принесут им дохода.

Им нравится писать код, решать задачи разработки, проектировать, продумывать логику, исправлять баги, понимать всю систему целиком. Им нравится сам процесс. И они никогда не отдадут это ИИ агентам.

Я люблю создавать стартапы, а они любят писать код. Для меня создание проектов это способ заработать деньги. Для них программирование это искусство.

Поэтому все мои аргументы о том, как мне ИИ помогает в создании проектов, абсолютно не применимы для людей искусства. Им не нужно, чтобы ИИ в чём-то им помогал.

И поэтому часто есть негативная реакция на утверждение, что скоро ИИ заменит всех программистов. Для людей искусства само это утверждение нелогичное. Даже если произойдет какой-то технологический прорыв и ИИ действительно сможет автономно работать и решать задачи в сотни раз быстрее людей, то люди всё равно продолжат писать код руками, каждую строчку кода. ИИ никогда не сможет забрать у них способность и желание писать код.

Я не использую ИИ при написании текстов. Он пишет бездушный, пресный текст. ИИ слоп, который не хочется читать. Я хочу сам придумывать формулировки в тексте, вычитывать его и редактировать, придумывать название, удалять лишние предложения и целые абзацы. Мне нравится, когда в процессе написания текста у меня появляются новые идеи к этому тексту. Мне важен сам процесс написания, мышление в этот момент, а не только результат. Если бы я попросил ИИ написать текст на тему "Программирование это искусство", этого процесса мышления бы не было. Я бы не получил тех эмоций, которые есть при ручном написании текста. Для меня написание текстов это искусство, которым я занимаюсь независимо от денег. Думаю, у людей, которым нравится писать код, ощущения такие же.

Статья "Почему разработчики продолжают писать код руками?" была плохо воспринята аудиторией. На всех площадках были только отрицательные комментарии. Все были убеждены, что весь код нужно писать руками. Каждую строчку кода.

Я удивлён этому, потому что я действительно считал, что многие разработчики используют ИИ агентов для написания кода. Реальность оказалась другой.

Программисты не готовы потерять свою идентичность. Написание кода для них это в какой-то степени искусство.

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.

Представьте, вам нужно составить какой-то большой текст, где нужно подумать, собрать информацию, проанализировать. Затем написать сам текст, вычитать его, исправить ошибки и улучшить формулировки. Вы тратите на эту работу например 10 часов. Теперь вам нужно перевести этот готовый текст на другой язык, который вы тоже очень хорошо знаете. Вы можете перевести его сами или воспользоваться автоматическим переводчиком. В первом случае вам нужно переводить каждое предложение вручную, подбирать лучшие идиомы, чтобы текст звучал нативно для носителя языка. Количество времени для перевода растёт пропорционально размеру текста. Но если вы воспользуетесь автоматическим переводчиком, вы получите перевод за несколько секунд. Вам останется только вычитать текст и поменять в нём некоторые слова, которые были переведены неправильно. Время интеллектуальной работы при составлении текста в десятки раз больше механического перевода.

Еще пример. Вы решили переписать большой проект с C++ на Rust или с PHP на TypeScript. Вы продумываете план рефакторинга, выбираете фреймворки и библиотеки, составляете порядок переписывания модулей, думаете как будете переносить тесты и обновлять документацию. У вас появляется полная картина того, как это будет выглядеть в итоге. Теперь остаётся рутина — само написание кода, следуя плану. Вы можете написать каждую строчку кода вручную или дать задачу по выполнению плана ИИ агенту. Срок миграции кодовой базы может различаться в десятки или даже сотни раз.

Да, перевод готового текста и рефакторинг готовой кодовой базы — это не создание новых проектов. Но в чём отличие? Ведь в новых проектах мы перед написанием кода также продумываем план реализации, обсуждаем с ИИ варианты решения задачи, принимаем много мелких решений. До написания кода мы уже примерно понимаем, какой это будет код, какие модули, какое покрытие тестами. Если мы не можем продумать весь проект, то мы начинаем с продумывания только нескольких модулей, а после их реализации переходим к следующим модулям. Но мы всегда сначала продумываем реализацию и принимаем решения, а уже потом пишем код. Так же, как и перед переводом текста на другой язык, мы сначала составляем сам текст. Перевод текста с одного естественного языка на другой — это такая же рутинная работа, как перевод с естественного языка на язык программирования.

Некоторые люди до сих пор не верят в то, что ИИ способен ускорить написание кода в несколько раз. Хотя они уже не удивляются тому, что ИИ в обычном чате может создавать осмысленный структурированный текст за секунды. С графиками, картинками, списками, таблицами. Но когда речь заходит о написании кода, у людей появляются сомнения в ускорении процесса.

Другие верят в ускорение, но задаются вопросом: если наша эффективность вырастет в 10 раз, бизнес не будет нам платить в 10 раз больше, так ведь? Зачем тогда повышать свою эффективность?

Но мы живём в капиталистическом мире. Мы должны эффективно работать не только для повышения своего дохода, но и просто для того, чтобы нас не уволили. ИИ может даже не увеличивать доход бизнеса, но он точно повысит объём видимой работы, которую может проверить ваш руководитель.

У бизнеса не всегда будут хорошие времена, когда он может держать неэффективных сотрудников. Рано или поздно настанет такой момент, когда нужно будет кого-то уволить. Если другие сотрудники с помощью ИИ пишут больше строк кода, делают больше коммитов, закрывают больше задач, а ваша эффективность не меняется, то вы будете первым в списке на увольнение.

Вы можете быть не согласны с тем, что нужно оценивать сотрудников по количеству строк кода, коммитов или сожжённых токенов. И здесь у вас есть 3 варианта: попытаться убедить руководство принять вашу точку зрения, смириться с их подходом или уволиться и найти другую компанию, где оценивают сотрудников по другим параметрам.

Если вы попытаетесь оспорить подходы руководства компании, я могу пожелать вам только удачи, но скорее всего удача будет не на вашей стороне и вас уволят. Система не любит тех, кто пытается её изменить. Если выберете вариант смены работы, то ваша жизнь снова превратится в череду случайных обстоятельств и стресса, и возможно подходящую работу вы будете искать несколько лет.

Остаётся только принять требование бизнеса о том, что сотрудники должны использовать ИИ для повышения своей эффективности. А это значит, вы должны писать больше кода, больше комитить и закрывать больше задач. При этом зарплату вам не повысят.

Часто скептики аргументируют тем, что код станет неподдерживаемым, вырастет техдолг, программист не будет видеть всю систему целиком, не сможет сам исправить баги или поменять что-то в коде.

И ведь такие аргументы дают даже молодые люди 25-30 лет, при этом у некоторых из них уже много лет опыта в разработке. Это не люди среднего возраста, которые привыкли к ручному написанию кода и не хотят что-либо менять в жизни. Это молодые специалисты, которые как мне казалось должны быть открыты новому опыту.

Если я ставлю ИИ агенту задачи, принимаю решения по архитектуре, делаю ревью кода и проверяю все тесты, то как можно говорить о том, что я не понимаю код проекта? Ведь ИИ пишет точно такой же код, который я бы написал сам. А если я целый год не открывал проект, то тут вообще без разницы кто писал код: я, другой человек или ИИ агент. Код будет непонятным без прочтения документации. Придётся вспоминать, что и зачем было сделано.

Еще одна причина отказа состоит в том, что ИИ пишет больше бесполезного кода, который даже не относится к задаче. И это для них является веской причиной, чтобы писать весь код вручную. Хотя всё, что нужно, — это просто попросить ИИ агента проверить код и убрать из него всё лишнее. Вам даже не нужно сразу делать ревью кода после выполнения задачи. Сначала попросите ИИ агента сделать ревью, затем исправить ошибки, затем снова ревью и снова исправление. Если не хотите каждый раз просить его об этом, он может сам это делать в цикле. Один субагент пишет код, другой делает рефакторинг, третий делает ревью, четвёртый исправляет ошибки. Вы можете настроить любую последовательность. С очень большой вероятностью после этого цикла в проекте не останется бесполезного кода.

Но ведь мы тогда разучимся писать код и вообще не сможем поддерживать проекты. Но зачем нам в будущем понадобится вручную поддерживать проекты? Такой вариант надо рассматривать, если мы предполагаем, что ИИ пузырь лопнет, провайдеры повысят цены в сотни раз, а ИИ с открытыми весами перестанут развиваться. Но уже сейчас вы можете настроить домашний сервер, поднять какой-нибудь Qwen и не зависеть от платных провайдеров. И при правильном использовании код будет таким же, как при использовании Claude или GPT.

Так почему же люди хотят делать рутинную работу, которую ИИ агент может сделать автоматически?

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?