Hacker News Digest

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

При этом суждение по-прежнему важно: изменение почти бесплатно, но понимание, правильное ли оно, — нет. Без вкуса, контекста, архитектуры и ограничений всё скатится в «слоп». Автор выделяет два полюса. «Ремесленник» остаётся в цикле и применяет суждение на каждой итерации — это не просто «вайб-кодинг», если оцениваешь ещё и форму кода. «Фабрика» убирает человека из цикла: конвейер из спецификаций, генераторов и проверяющих агентов, где суждение встроено заранее. Оба подхода дополняют друг друга: крупным продуктам нужны ремесленники для новых задач, а одиночкам — фабрики для рутины и масштаба.

Участники обсуждения (@jameskilton, @Megranium, @sirnicolaz, @kazinator, @andersmurphy) ставят под сомнение новизну метафоры «кода как глины», утверждая, что ПО всегда было пластичным (software), а подобные концепции давно реализованы в Lisp. По мнению @keyle, AI не изменил природу кода, а лишь радикально снизил стоимость итераций. Однако это создает риски: код может стать «одноразовым пластиком» (@besterman23) или настолько запутанным «мусором», что даже LLM предпочтут переписать его с нуля (@jameskilton). Критики (@sdevonoes, @YmFzZTY0ZGFkZHk) добавляют, что такая пластичность неприменима в крупных проектах, где важны бизнес-правила, согласование с экспертами и учет недокументированного поведения. @closeparen отмечает, что внедрение нового функционала через AI в больших системах часто усложняет ревью и исправление ошибок. В качестве решения @melvinroest предлагает использовать «vibe-coding» для быстрого прототипирования и проверки требований: создавать приложение за 1–2 дня, а затем использовать прототип как спецификацию для полноценной ручной разработки.

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

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

ИИ не заменяет мудрость, а усиливает когнитивную атрофию разработчиков: переставая читать и анализировать код, они теряют интуицию, необходимую для поддержки сложных систем. Большинство кода в продакшене уже плохо написано — ИИ ускоряет его деградацию, обучаясь на низкокачественных данных и воспроизводя плохие паттерны. Архитектурная мудрость не измеряется линтерами (SonarQube и т.п.) — она возникает из глубокого понимания контекста, многолетнего опыта отладки и чувства «запахов» кода. ИИ не может воспроизвести эту интуицию. Даже если опытные разработчики полагаются на тесты и не читают сгенерированный код — это исключение, не правило. Для большинства, особенно новичков с менее чем 5-летним опытом, ИИ маскирует дефицит проектных навыков, ускоряя создание кода, но не обучение. Если команда не понимает, как работает сгенерированный код, она не может его изменять при новых требованиях. Использование ИИ без понимания каждого изменения приводит к потере контроля над архитектурой и невозможности отвечать за долгосрочную жизнеспособность системы. ИИ не создаёт знания — он отражает паттерны в данных. Если данные — плохой код, ИИ генерирует плохой код, ускоряя деградацию крупных кодбаз, которые и так со временем ухудшаются. Проблема не в ИИ как таковом, а в том, что люди перестают учиться писать хороший код и теряют способность отличать хорошее от плохого. Новички, получая код от ИИ вместо чтения кода опытных коллег, не усваивают институциональные знания — никто не знает, почему код написан так, а не иначе. «NO-AI» политика маловероятна как конкурентное преимущество: большинство компаний ценят скорость и прибыль, а не архитектурную целостность. Совет: используйте ИИ только для генерации шаблонов, но всегда задавайте себе вопрос: «Понимаю ли я, почему этот код работает так, а не иначе?» — иначе вы становитесь пассивным наблюдателем за собственной работой.

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

Автор экспериментально тестировал метрики: оценка кода самими LLM — нестабильна и часто случайна; ручная проверка неприменима в масштабе; изменение числа строк (LOC) — простая, но хрупкая метрика, подверженная закону Гудхарта. Два новых показателя из SlopCodeBench — на основе анализа AST и структурных паттернов — лучше разделяют «LLM-грязь» от устаревшего кода. Они выявляют избыточную связанность функций и низкую когезию, но всё ещё опираются на ручные хэристики. В итоге, даже при прогрессе в автоматизации, человеческая интуиция остаётся неотъемлемой частью оценки качества кода.

Измерение «грязи» кода требует учета глобальных архитектурных свойств — разделения обязанностей, слоистой архитектуры и четких интерфейсов — а не только локальных метрик. Человеческий опыт и управление ментальной моделью команды остаются критически важными, даже при использовании LLM: если AI становится основным автором кода, человеческое понимание теряется через «потерянный» канал коммуникации. Метрики вроде циклической сложности и LCOM известны давно, но их эффективность для LLM не изучена, и их применение требует осторожности из-за риска Goodhart's law. Изменение числа строк кода (LOC) как метрика работает в практике, но теряет смысл при оптимизации под неё. Тесты, которые не проверяют ничего (например, всегда возвращают True), не обнаруживаются статическим анализом или покрытием, но выявляются mutation testing — это важный, но игнорируемый индикатор грязи. Сложность, вводимая LLM, может превышать их способность к управлению — неизвестно, есть ли предел, при котором модели теряют контроль над собственной сложностью. Для оценки качества кода следует использовать комбинацию метрик (циклическая сложность, churn, авторство) и анализировать их динамику во времени, а не только статические значения. Использование LLM как судьи в оценке кода (harness evals) перспективно при правильном проектировании метрик и контекста. Оптимизация под минимальное количество LOC, проходящее тесты, не гарантирует чистоту кода и может усугубить проблему без учета архитектурной целостности. Для улучшения качества кода, генерируемого LLM, необходима обратная связь на основе качественных репозиториев и комплексных метрик, а не только на корректность выполнения задач. Споры: - Код «решен» LLM? Работающий код ≠ поддерживаемый, особенно в сложных системах. - AI-генерируемый код — эволюция существующего «мусора» или его объем превышает человеческие возможности управления? - Стоимость токенов делает AI-генерацию экономически нецелесообразной? Или это временный этап? - Один участник отметил, что его репозиторий, написанный агентами, показал более низкую «verbose» метрику, чем у людей — что противоречит ожиданиям. Качество кода не измеряется только техническими метриками — ключевой индикатор — способность команды понимать и поддерживать систему, что требует коммуникации, а не автоматизации.

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-код станет новым легаси, а успех зависит от качества спецификаций и дисциплины, а не скорости генерации.