Hacker News Digest

AI‑ассистенты позволяют разработчикам вносить изменения в код без необходимости обсуждать их с коллегами, но при этом исчезает общий язык проекта — совокупное представление о структуре, границах и правилах системы. Раньше такая синхронизация происходила через медленные ревью, вопросы и совместные обсуждения, которые, хоть и были неэффективны, но фиксировали взаимное понимание. Теперь каждый запрос может быть выполнен агентом, тесты проходят, а объяснения генерируются на лету, и изменения «садиваются», даже если человеческое сообщество уже потеряло согласованность.

Как в истории БАБЕЛ: «и вот они имели одно слово, и ничего не было им противостоящее». В результате проект продолжает расти, пока не исчезает архитектурный язык, который позволял людям рассуждать о системе вместе. Пример: один агент добавляет OAuth, другой — кэширование, третий — перестраивает базу и делает UI розовым; всё компилируется, тесты проходят, но никто не обсуждает, как эти изменения влияют на общую модель. В результате «башня» продолжает расти, пока не исчезнет общий язык, который раньше удерживал её в целости.

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

• Композиция в коде сравнивается с Tetris: без очистки строки (упрощения) система «вываливается».
• Потеря общего понимания проекта приводит к росту «башни» без обратной связи, как в истории Бабеля.
• Агентное программирование похоже на управление: разработчики теряют контроль и видимость над изменениями.
• Повышение производительности возможно, но без дисциплины и ревью код быстро теряет смысл и стабильность.

LLM‑генераторы могут создавать код быстро, но когда вы просите одну и ту же проверку доступа в нескольких местах, модель обычно копирует одинаковый набор условий. В примере из статьи условие состоит из четырёх проверок и встречается в пяти разных файлах: обработчике запроса, фоновой задаче, API‑эндпоинте, веб‑хуке и ещё одном месте. Вы смотрите, что тесты проходят, и сливаете код, не задумываясь о поддержке. И даже если тесты проходят, такие копии легко превращаются в «болевой» участок кода, который трудно изменить без риска сломать что‑то ещё.

Проблема в том, что каждый такой «костыль» становится сигналом для модели: она запоминает ваш стиль и в следующем запросе будет генерировать ещё одну копию того же условия. Со временем набор дублирующихся проверок превращается в устоявшуюся практику, и даже попытка рефакторинга заставит вас править пять одинаковых блоков. Как пишет автор, «Write code like a human will maintain it» — значит, не полагаться на LLM, чтобы он «помнил» плохой шаблон. Иначе вы обучаете модель ухудшать свои привычки. Это приводит к накоплению технического долга: каждый дублирующийся блок усложняет поиск ошибок и увеличивает шанс пропустить регрессию.

• Добавьте простой /review‑команду с чек‑листом проверок, чтобы агент мог планировать поиск проблем.
• LLM часто создают излишние абстракции и плохие комментарии, ухудшающие поддерживаемость кода.
• Дублирование и несогласованные изменения в разных местах кода остаются главной проблемой генеративных моделей.
• Чтобы использовать ИИ эффективно, нужно явно задавать требования к читаемости и поддерживаемости кода.

Дублирование часто дешевле, чем попытка создать «правильное» обобщение. На RailsConf 2014 я говорил: «дублирование намного дешевле неправильного абстракции», что отразилось в твите «Duplication is far cheaper than the wrong abstraction» (41 shades of blue, март 2014). Когда в коде появляется повтор, разработчик вытаскивает его в метод или класс, получая новую абстракцию. Со временем к ней добавляются параметры и условия, чтобы покрыть новые требования, и код превращается в запутанный набор ветвлений. При этом сохранение такой конструкции подпитывается эффектом удержания вложенных усилий — «sunk‑cost fallacy» заставляет считать, что сложный код обязателен и важен.

Чтобы выйти из ловушки, лучше отменить прежнее решение. Нужно вернуть дублирование, заменив вынесённый метод на его тело в каждом месте вызова, а затем оставить только те части, которые действительно нужны конкретному вызывающему. Удаляя лишние ветви, вы избавляетесь от условных параметров и получаете чистый код, который легко расширять. Такой «откат» часто раскрывает, что исходная абстракция была избыточной, и позволяет заново выделить более подходящие обобщения. Главное – не позволять заложенным усилиям удерживать плохой дизайн.

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

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

Спрос на «чистку» ИИ-наследия растёт: инженеры вроде Хамида Сиддики управляют десятками проектов одновременно, беря $200–400 в час за исправление «спагетти-кода». Специализированные платформы вроде VibeCodeFixers.com уже объединяют сотни исполнителей и заказчиков. По данным ThoughtWorks, 60% проектов с ИИ требуют серьёзного рефакторинга перед выходом в продакшен. Это создаёт новые карьерные траектории: младшие разработчики, освоившие исправление ИИ-кода, могут быстро достигать уровня зарплат сеньоров.

• Рост числа проектов с низкокачественным кодом, сгенерированным ИИ (vibe coding), требующих дорогостоящей последующей доработки и "очистки".
• Сравнение ситуации с аутсорсингом: проблемы те же (плохие спецификации, низкое качество), но ИИ ускоряет генерацию кода и ошибок.
• Споры об общей эффективности: экономия времени на MVP vs. скрытые затраты на поддержку и риски безопасности.
• Сдвиг навыков: востребованы не генераторы, а "инженеры-уборщики", способные чинить и рефакторить AI-сlop.
• Прогнозы: AI-код станет новым легаси, а успех зависит от качества спецификаций и дисциплины, а не скорости генерации.