Зачем писать код в 2026 году

Автор ведёт блог softwaredoug.com и отвечает на всё более распространённый в индустрии тезис: работа инженера теперь, не писать программы, а строить «программную фабрику». Инженер настраивает инфраструктуру, которая позволяет любому человеку, не обязательно техническому, дать промпт на изменение и сразу выкатить его в прод. Проактивная часть такой фабрики, промпты, навыки-инструкции для агентов (skills), файлы AGENTS.md, базы знаний; реактивная, автоматические проверки: тесты, линтинг, системы типов, автоматизированные оценки (evals), проверка другим ИИ. При такой обвязке даже слабая модель со свежим контекстом способна уложиться в рамки и выдать приемлемое изменение, так что смотреть в сам код, не то что писать его руками, начинает казаться нелепым и даже смешным занятием.

С этим тезисом автор не согласен: писать код вручную по-прежнему полезно. Даже при интеллекте на уровне так называемого «Fable» (в тексте это упоминается как ориентир для по-настоящему мощного ИИ) люди всё равно получают пользу от написания кода, не потому, что агенты пишут код хуже человека, а потому что программирование позволяет мыслить прямо в среде исполнения, а не через прокси естественного языка. Дело во внимании и понимании: чтобы не терять фокус, мало пассивно читать код, сгенерированный агентом, по-настоящему связать своё понимание с архитектурой системы помогает только непосредственный опыт работы с кодом. Автор с иронией сравнивает это с разницей между плоскими двумерными дифами и патчами и полным опытом погружения, вроде кинотеатра формата «4DX» (с движением кресел и спецэффектами): по его шутке, порой хочется буквально «прочувствовать», что происходит в коде. Речь не об эстетике («красивый код»), а именно о хрупкости архитектуры: если человеку трудно доработать существующий код, не сломав что-то, агенту будет ещё труднее в нём разобраться. Если получается свести код к единому архитектурному принципу без вороха исключений, «фабрика» работает лучше; если получается найти слабое место в тестовом покрытии и исправить его, это разом снимает целый класс будущих багов.

Автор признаёт: того же результата можно добиться и без ручного кодирования, и не собирается за это упрекать читателя, подавляющее большинство его собственного кода тоже сгенерировано ИИ (в шутку он называет себя «заражённым ИИ-психозом»). Но лично ему написание кода полезно, и он советует делать это и другим. Когда он выступает лишь в роли «обратного кентавра» (по аналогии с шахматами, где обычно человек и компьютер работают вместе, но здесь ведущую роль играет ИИ, а человек только наблюдает и одобряет), ему сложнее удерживать внимание, и он не чувствует того же авторства над результатом: некачественный, «мусорный» код проще проскакивает мимо проверки, его сложнее точечно доработать. В долгосрочной перспективе такой мусорный код вредит и самим агентам, хрупкость накапливается именно потому, что никто не следит за деталями. И наоборот: когда человек сам выполняет часть работы и оперативно опробует подход на практике, а агент затем тиражирует найденный паттерн, автор чувствует себя соавтором и владельцем результата.

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

Автор критикует установку, будто агентов-кодеров можно считать компиляторами, по его мнению, это лишь оправдывает выпуск небрежно написанного кода. Агенты, не компиляторы, а скорее «свежие стажёры»: они читают частичный, возможно замусоренный код, получают неточное описание изменения и должны на основе этого сгенерировать правку. Люди не могут просто передать своё мышление и вкус «армии стажёров», личное участие, а не роль потребителя, здесь и помогает. Автор спрашивает: видел ли кто-нибудь, чтобы агент сам следовал «правилу бойскаута» (оставлять код лучше, чем он был до него), и вообще, стоит ли этого от агента хотеть? По его наблюдению, агенты склонны вносить текущее изменение максимально осторожно и безопасно, из-за чего могут закреплять и усиливать разовые неудачные решения человека. Пример из личного опыта: как-то утром, ещё до кофе, у автора (по его шутливой формулировке, у его «мясного», то есть человеческого, мозга) мелькнула идея хранить часть состояния приложения в localStorage браузера, тогда как всё остальное состояние шло через серверную базу данных. Когда он позже посмотрел на код, оказалось, что объём обёрток и косвенных прослоек, сохранявших это «дурацкое» решение, увеличил общий объём кода примерно втрое. Пройдясь по коду вручную, с удовольствием удаляя лишнее и экспериментируя, автор пришёл к архитектуре получше, чем если бы просто попытался описать переделку агенту по-английски; его собственное мышление, авторство и способность направлять «фабрику» от этого выросли многократно.

Вывод автора: если инженеры строят программную фабрику, важны детали, те, что задают архитектурные принципы, вплоть до алгоритмов и производительности. Агенты подталкивают к тому, чтобы измерять, оценивать и подстраховываться, во многом благодаря им стало нормой подключать CI (непрерывную интеграцию) даже к небольшим побочным проектам с самого начала, а не откладывать на потом; по мнению автора, это огромный прогресс для индустрии в целом. Но у любого конвейера есть слабые места: как на автозаводе иногда приходится разбирать сборочную линию, разбираться в деталях двигателя внутреннего сгорания ради десятипроцентного улучшения или целый день наблюдать за испытаниями тормозных колодок, чтобы понять, почему дефект не выявляется на ранней стадии, так и здесь эту работу нельзя делать, довольствуясь только общей картиной фабрики в голове: мелкие детали нужно уметь связывать с общей картиной, а произвольные границы того, что «можно» и «нельзя» трогать в коде, только мешают этому.

Ключевые факты

Автор (блог softwaredoug.com) описывает новую роль инженера как строительство «программной фабрики»: промпты, навыки-инструкции для агентов (skills), файлы AGENTS.md, базы знаний плюс тесты, линтинг, типизация и автоматизированные оценки (evals), которые позволяют агентам безопасно вносить изменения и сразу их выкатывать.
При этом он настаивает: писать код руками по-прежнему полезно, не потому, что агенты хуже людей пишут код, а потому что кодирование даёт точный способ мышления в среде исполнения (естественный язык слишком неточен) и удерживает внимание к архитектуре, которое теряется при пассивном одобрении чужого кода.
Личный пример автора: неудачное решение хранить часть состояния приложения в localStorage браузера агенты законсервировали, обернув таким количеством обходных прослоек, что общий объём кода вырос примерно втрое, потому что агенты слишком консервативны и склонны закреплять разовые ошибки человека, а не исправлять их.
Автор возражает против взгляда на агентов-кодеров как на «компиляторы» (это, по его мнению, лишь оправдывает небрежный код), по его сравнению, агенты больше похожи на «свежих стажёров», которым нужны чистый код и точные инструкции.
Вывод: агенты сделали нормой раннее подключение CI и автоматических проверок, это прогресс, но иногда всё равно нужно вручную «разбирать конвейер»: чистить код, находить слабые места в тестах и связывать мелкие детали с общей архитектурой, не проводя жёстких границ того, что можно трогать, а что нет.

Почему это важно

Пост отвечает на всё более распространённый в индустрии тезис: с приходом ИИ-агентов, пишущих код по промпту, работа инженера сводится к тому, чтобы построить и обслуживать «программную фабрику», инфраструктуру из промптов, навыков-инструкций для агентов (skills), файлов AGENTS.md, баз знаний, тестов, линтинга, типизации и автоматизированных оценок (evals), которая позволяет любому человеку запросить изменение и сразу выкатить его в прод. При такой обвязке даже слабая модель со свежим контекстом способна уложиться в рамки и выдать приемлемый результат, так что смотреть в сам код, не говоря уже о том, чтобы писать его руками, начинает казаться бессмысленным занятием. Автор с этим не согласен и объясняет, почему ручное программирование остаётся значимым даже при очень мощном ИИ: оно даёт точный способ мышления в среде исполнения (естественный язык недостаточно точен для описания вычислений) и удерживает внимание и понимание архитектуры, которое теряется при пассивном одобрении чужого, агентского кода.

Кому это важно

Материал адресован разработчикам и техлидам, которые ежедневно работают в связке с ИИ-агентами, пишущими код, и выстраивают вокруг них процессы, тесты, CI (непрерывную интеграцию), ревью; а также руководителям инженерных команд, решающим, сколько ручной работы и личного контроля требовать от сотрудников, и где проводить (или не проводить) границы того, что человеку «можно» и «нельзя» трогать в кодовой базе.

Как это применить

Из личного опыта автора вытекают практические рекомендации: периодически возвращаться к ручной работе с кодом, чистить его, приводить к единому архитектурному принципу без вороха исключений, находить слабые места в тестовом покрытии и чинить их у корня, а не оборачивать обходными путями; для новых архитектурных решений сначала самому быстро опробовать («обкатать») подход на практике и только потом поручать агенту тиражировать найденный паттерн; не оправдывать небрежный код тем, что «агент всё равно перепишет» (сравнение агентов с компиляторами), агентам, как «свежим стажёрам», нужны точный чистый код и ясные, недвусмысленные инструкции; и не проводить жёстких границ того, что можно трогать, а связывать мелкие детали кода с общей архитектурой «фабрики».

Можно ли доверять

Это личный, авторский блог-пост на softwaredoug.com, а не исследование или пресс-релиз: выводы опираются на собственный опыт и аргументацию автора (в частности, один показательный случай с localStorage), а не на измерения, статистику или сторонние проверки. Пост набрал 52 балла и 33 комментария на Hacker News, то есть вызвал заметную дискуссию, но это мнение одного практика, которое стоит воспринимать как повод для размышления и спора, а не как установленный факт или универсальную рекомендацию.

Риски и подводные камни

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

«Агенты, не компиляторы, они куда больше похожи на свежих стажёров: они читают частичный, возможно замусоренный код, получают неточное описание изменения и обязаны на основе этого сгенерировать правку.»

— автор блога softwaredoug.com, из поста «Why Write Code in 2026»