Разработка ПО страдает от кода «996», ИИ не спасет ситуацию
Бесконечный поток плохого кода, который людям приходится чинить, только усугубляет проблему переработок.
Основные идеи
Мнение автора
Современная разработка программного обеспечения оказалась на перекрёстке двух заблуждений: мифа о «результате = усилия» и слепого увлечения ИИ. Как отмечает Гергей Орос, культура 996 рождает не инновации, а копии и раздутый код, и та же ловушка ждёт нас с генеративными инструментами. Использование ИИ для ускоренного написания кода без осмысленного планирования лишь увеличивает сложность и ответственность за продукт.
В разработке программного обеспечения живет опасный миф: результат измеряется объемом. Словно больше часов работы или строк кода гарантируют победу в решении проблемы.
Гергей Орос, автор знаменитого журнала The Pragmatic Engineer, недавно с хирургической точностью разбил этот миф. Он жестко высказался о культуре «996» — графике с 9 утра до 9 вечера шесть дней в неделю, который популяризировали китайские техногиганты. Орос заявил: сложно назвать хоть одну компанию с таким графиком, которая создала бы что-то стоящее, а не просто скопировала или переделала чужой качественный продукт. Такой темп работы не просто бесчеловечен, он контрпродуктивен.
Грубая сила обеспечивает объем, но редко дает уникальность и почти никогда — инновации.
Прежде чем критиковать Китай за подобные практики, стоит взглянуть на свои. Основатели называют это «хардкором», «выкладкой на 100%» или «культурой пахоты», но суть одна: давить на людей часами и ждать гениальности. Теперь мы пытаемся воплотить эту идею в коде и графических процессорах. Некоторые верят, что если заставить большие языковые модели (LLM) работать за тысячу человек, генерируя код со сверхчеловеческой скоростью, программное обеспечение магическим образом станет лучше.
Этого не случится. Мы просто получим еще больше того, что уже имеем: вторичный, раздутый и абсолютно неуправляемый код.
Высокая цена обновления кода
Я давно бью тревогу по этому поводу. Недавно я писал, что интернет задыхается от бесполезного, но объемного контента, ведь создавать его стало слишком просто. С нашим программным обеспечением происходит то же самое.
Данные подтверждают это. Анализ 153 миллионов строк кода от GitClear в 2024 году показал резкий рост «перемешивания кода» — количества строк, которые меняют или удаляют в течение двух недель. Исследование выявило больше копирования и вставки при значительном снижении рефакторинга.
ИИ помогает писать код быстрее (до 55%, согласно анализу GitHub), но не помогает проектировать лучше. Мы генерируем больше кода, хуже его понимаем и чаще исправляем. Реальный риск ИИ заключается не в самом написании кода, а в том, что он побуждает нас писать его слишком много. Раздутые базы сложнее защищать и анализировать, людям трудно ими управлять. Чем меньше кода, тем лучше.
Это ловушка 996, которую перенесли на машины. Мышление 996 предполагает, что инновации ограничивает количество отработанных часов. Подход «с упором на ИИ» считает ограничением количество набранных символов. Оба мнения ошибочны. Главным ограничением всегда была и будет ясность мысли.
Код — это пассив, а не актив
Вернемся к фундаментальным принципам. Любой старший инженер знает, что разработка ПО — это не соревнование по скорости печати. Это процесс принятия решений. Работа заключается не в написании кода, а в понимании того, чего писать не стоит. Основатель Honeycomb и технический директор Чарити Мейджорс говорит, что должность старшего инженера подразумевает умение понимать, поддерживать, объяснять и управлять большим объемом работающего софта. Также важно переводить потребности бизнеса в техническую реализацию.
Каждая строка отправленного кода — это ответственность. Ее нужно защищать, отлаживать, поддерживать и в итоге рефакторить. Использование ИИ для грубого написания увеличивает эту ответственность. Мы создаем огромные зоны сложности, которые закрывают задачу в Jira, но ставят под угрозу будущую стабильность платформы.
Аргумент Ороса о компаниях формата 996, создающих лишь копии, показателен. Инновациям нужна тишина, чтобы думать без постоянных совещаний. В минуту покоя можно понять, что запланированная функция вообще не нужна. Если разработчики целыми днями проверяют лавину запросов на включение кода от ИИ, у них нет времени на размышления. Они становятся не архитекторами, а уборщиками за роботом, который никогда не спит.
Это не значит, что ИИ вреден для разработки. Все наоборот. Профессор Гарварда и светило открытого исходного кода Карим Лакхани подчеркнул, что ИИ не заменит людей. Однако люди с ИИ заменят тех, кто его не использует. ИИ эффективен как инструмент, но только если не использовать его как дубину для копирования ложных обещаний культуры 996.
Человеческая часть стека
Как избежать создания культуры 996 на кремнии? Нужно перестать относиться к ИИ как к «замене разработчика» и начать воспринимать его как инструмент, который возвращает время, уничтожаемое культурой 996.
Если ИИ берет на себя рутину вроде модульных тестов, шаблонного кода или обновления документации, это не повод впихивать больше функций в спринт. Это возможность замедлиться и сосредоточиться на человеческих аспектах стека:
- Формулировка проблемы. Вопрос «что мы на самом деле пытаемся сделать?» звучит просто, но именно здесь проваливается большинство проектов. Выбор правильной задачи требует погружения в контекст и эмпатии. Языковая модель подскажет пять способов создания виджета, но не скажет, что этот виджет не подходит для рабочего процесса клиента.
- Безжалостное редактирование. Если ИИ делает написание кода почти бесплатным, самым ценным навыком становится удаление. Люди должны говорить «нет». Нужно вознаграждать разработчиков не за скорость, а за простоту решений. Следует ценить удаление лишнего, когда код упрощается, а не усложняется.
- Контроль зоны поражения. Когда что-то сломается (а это обязательно случится), в отчете об инциденте будет стоять ваше имя, а не имя языковой модели. Глубокое понимание системы для отладки во время сбоя — это навык, который деградирует без самостоятельного написания кода. Нужно гарантировать участие человека. Я подчеркивал важность того, чтобы младшие разработчики не использовали слепо то, что выдает нейросеть. Необходимо обучение для эффективного использования ИИ на любом уровне.
Восстание против роботизированного мусора — это вопрос качества.
Орос критикует 996 за то, что такой подход плодит изнуренных людей и ненужные продукты. Если мы не будем осторожны, внедрение ИИ приведет к тому же: уставшие люди будут поддерживать гору ненужного и хрупкого кода, сгенерированного машинами.
Нам не нужно больше кода. Нам нужен лучший код. А лучший код рождается в человеческом разуме, где есть тишина и порядок. Пусть ИИ возьмет на себя грубую силу и освободит время для инноваций.















