Hacker News Digest

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

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

Основная причина безумия разработчиков — не само ПО, а его отрыв от реальных пользователей, финансовые стимулы, управленческие искажения и технологический шум. Изоляция от клиентов и взаимодействие только через менеджеров резко повышают риск безумия; регулярное общение с пользователями возвращает фокус на реальность. Современные команды из 60–80 человек разрабатывают CRUD-приложения, тогда как 20 лет назад небольшие команды из 4–5 человек создавали критически важные системы на C++ — это указывает на рост технологического шума и снижение эффективности. Технические лидеры ошибочно принимают успех в абстрактной модели за победу над реальной доменной областью, что ведёт к эгоцентризму и потере связи с потребностями пользователей. Программирование, лишённое физических ограничений, создаёт иллюзию неограниченной свободы, активируя неуверенность и компульсивное вмешательство. Большинство программ — электронные таблицы с интерфейсом, но сложная архитектура (сервис-меш, event-driven) используется как маркетинг, а не как необходимость, искажая восприятие ценности работы. Финансовые стимулы — обещание быстрых миллионов от стартапов — заставляют разработчиков искать «идеальный путь» вместо реального решения. Отсутствие жёсткой обратной связи и физических ограничений делает ПО средой для неадекватного поведения: ошибки не имеют немедленных последствий. Управление ПО часто осуществляется неразработчиками, которые воспринимают изменения в коде как простые физические доработки, не понимая их сложности и рисков. Современные инструменты, включая LLM, делают изменения в ПО дороже, снижая частоту произвольных правок, так как PM больше не могут «спасти» бюджет за счёт лёгких правок. Работа за экранами и цифровая перегрузка вызывают диссоциацию и потерю связи с реальностью — коллеги за 10 лет превращаются в истощённых «мурмурщиков». Оставлять всё как есть — недооценённый навык инженерии: постоянные изменения ради «улучшения» разрушают стабильность и создают психологическую нагрузку без реальной пользы. Интернет и цифровая среда создают замкнутую эпистемологию, где всё субъективно и самоподтверждающе, усиливая иррациональные убеждения и отрывая от внешней реальности. Пользователи хотят простые, надёжные инструменты — успешные приложения вроде BookFusion и Libro.fm доказывают, что минимализм и фокус на базовых функциях приводят к большей ценности. Совет: применяй зен-подход — смотри на код как на инструмент, а не как на средство для славы; тогда эго, соревнование и ненужные изменения теряют силу, и сохраняется психическое здоровье. Совет: используй MVP и быструю обратную связь — если функция не приживается, удаляй её, а не усложняй систему ради «идеального» решения, которое никто не использует.

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

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

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

Разработчики всё чаще сталкиваются с увеличением времени на модификацию или исправление кода, сгенерированного большими языковыми моделями. Это явление, названное «долгом понимания», напоминает работу с унаследованными системами, где перед внесением изменений необходимо глубоко разобраться в логике и контексте кода. Однако масштаб проблемы стал беспрецедентным из-за лавинообразного роста объёмов нечитаемого кода, который ИИ-инструменты производят с огромной скоростью.

Команды, заботящиеся о качестве, тратят время на ревью и рефакторинг такого кода, сводя на нет первоначальную экономию времени. Другие же просто коммитят непроверенные и непонятые фрагменты, создавая риски на будущее. Хотя ИИ может помочь с 70% правок, остальные 30% приводят к «петлям безысходности», когда модели не справляются с задачей, и разработчикам приходится разбираться в чужом коде самостоятельно. Это накопление долга понимания становится бомбой замедленного действия для миллионов проектов.

• LLM-генерация кода ускоряет разработку, но часто приводит к сложному, плохо понятному коду, что создает долгосрочные проблемы с поддержкой и увеличивает "долг понимания".
• Мнения разделились: одни считают проблему поддержки LLM-кода преувеличенной или временной, другие видят в ней фундаментальный сдвиг, усугубляющий существующие проблемы с legacy-кодом.
• Предлагаются стратегии работы: строгий ревью, использование LLM только для тривиальных задач/черновиков, написание тестов и документации, либо полное принятие модели "черного ящика".
• Многие ожидают, что будущие LLM смогут сами понимать и поддерживать сгенерированный код, что изменит роль разработчика на более высокоуровневую.
• Параллель с прошлыми проблемами (офшорная разработка, копипаст с Stack Overflow), но масштаб и скорость генерации LLM создают беспрецедентные вызовы.

Код-ревью часто превращается в формальность из-за слишком больших и сложных пул-реквестов. Разработчики избегают глубокого анализа, ограничиваясь поверхностными комментариями, что ведёт к накоплению технического долга и уязвимостей. Ключевое решение — нормализовать возврат непонятных PR авторам и дробить функциональность на мелкие изменения объёмом до 300 строк, которые можно проверить за 5–10 минут.

Важную роль играют коммиты, рассказывающие историю изменений: они должны отражать логику и итеративный процесс, а не просто фиксировать результат. Например, осмысленные сообщения коммитов и использование fixup-коммитов помогают сохранить ясность истории даже после правок. Это снижает когнитивную нагрузку на ревьюверов и повышает качество кода, поскольку каждый участник чувствует ответственность за систему в целом.

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

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

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

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