Hacker News Digest

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

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

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

Автор критикует привычку relayить ответы ИИ как «мясной прокси» — просто копировать и вставлять их в Slack, PR или чаты. Такой подход не добавляет ценности: текст часто перегружен жаргоном, содержит выдуманные детали и требует дополнительного разбора. Примером стал абсурдный отрывок про «NATS control-plane events», где каждое слово требовало поиска.

Главная идея: использовать ИИ как инструмент, а не как замену размышлению. Нужно самому понять материал, проверить его и оформить ответ своими словами. Особенно это критично в code review: копируя тикет в Claude Code, можно быстро получить черновик, но окончательную реализацию и проверку должен выполнить человек. Иначе вы превращаетесь в «мясной прокси», а ценность вашего участия исчезает. Запомните: AI — помощник, а не замена вашего мышления.

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

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

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

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

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

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

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

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

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

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

• AI‑сгенерированные PR‑ы и сообщения перегружают команду, их трудно быстро проверить и обсудить.
• Люди всё чаще полагаются на LLM, но без собственного усилия их работа становится заменяемой и менее ценной.
• Принцип «не тратить больше усилий, чем вложил другой» подчёркивает необходимость человеческого вклада в ответы и ревью.
• Качество AI‑вывода часто уступает обещаниям, поэтому без глубокого понимания темы полагаться только на нейросети недопустимо.

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

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

• Обсуждение показало, что проблема не ограничивается кодом: LLM-генерированные PR, не раскрывая этого, создают нагрузку на рецензентов и нарушают принцип "не навредь".
• Сообщество разделилось: одни считают, что любой вклад полезен, другие настаивают, что важно различать, где использовался ИИ, и требуют прозрачности.
• Обсуждение затронуло вопрос, как отличить человеческий вклад от ИИ-генерированного, и какие нормы могли бы регулировать это.
• Участники обсудили, что если кто-то утверждает, что может писать код с LLM, то он должен быть способен писать и e2e тесты.
• Были выдвинуты идеи, что проекты могли бы требовать, чтобы вклад был помечен как ИИ-генерированный, и что в будущем репутация и идентичность могут стать критически важными для рассмотрения вклада.

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

• Пользователи обсуждают, что код, сгенерированный LLM, часто выглядит правильным, но на практике требует переписывания, что перекладывает бремя на коллег-ревьюверов.
• Подчеркивается, что внедрение ИИ-инструментов часто сопровождается агрессивным продвижением, даже если это идет вразрез с продуктивностью и UX.
• Участники обсуждают, что вместо того, чтобы навязывать инструменты, компании должны инвестировать в обучение и поддержку разработчиков, чтобы они могли эффективно использовать ИИ.
• Поднимается вопрос, что если ИИ-инструменты действительно так эффективны, почему бы не сделать их использование добровольным, а не навязывать.
• Участники также обсуждают, что вместо того, чтобы требовать использование ИИ, компании должны сосредоточиться на создании культуры, где разработчики могли бы выбирать, какие инструменты использовать, включая ИИ, и где они могли бы расти.

Инженеры всё чаще запускают несколько агентов одновременно — например, одновременно работают несколько экземпляров Claude Code или Codex CLI в разных директориях или даже в разных репозиториях. Саймон Уиллисон, который сам пишет код на Python и JavaScript, решил проверить, насколько полезно это на практике.

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

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

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

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

• Обсуждение в основном вращается вокруг трёх тем: высокая стоимость ревью кода, параллельные агенты и их влияние на фокус и продуктивность, а также культурные и этические аспекты использования AI-агентов.
• Участники делятся личными стратегиями, такими как использование различных инструментов вроде Conductor и Crystal для управления агентами, и обсуждают, как сделать их более эффективными.
• Обсуждается, как сделать ревью кода менее трудоёмким, включая использование инструментов вроде bottleneck для ревью кода, и как влияет на продуктивность и фокус.
• Также обсуждается, как влияет на эффективность работы использование AI-агентов, и какие могут быть последствия для долгосрочной устойчивости и качества кода.

Даниель Стенберг получил от Джошуа Роджерса огромный список потенциальных уязвимостей в curl, включая более 100 потенциальных проблем. Это привело к интенсивному анализу и исправлению кода, что подчеркивает важность краудсорсинга в безопасности ПО. Команда curl оперативно реагирует на такие отчеты, укрепляя стабильность и надежность библиотеки.

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

• Успешное применение набора AI-инструментов для поиска уязвимостей в проекте curl, что привело к множеству реальных исправлений
• Подчёркивается ценность AI не для генерации кода, а для анализа и указания на потенциально проблемные места, требующие внимания разработчика
• Обсуждение конкретных инструментов (ZeroPath, Claude Code, Cursor BugBot) и методик работы с LLM для эффективного поиска багов
• Отмечается проблема ложных срабатываний и спама от AI в прошлом, но в данном случае подход оказался эффективным
• Размышления о том, как интегрировать подобные AI-инструменты в рабочий процесс для аудита безопасности и повышения качества кода

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

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

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

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

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

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

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

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

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

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

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

• Сомнения в эффективности использования ИИ для генерации кода из-за высокого процента ошибок и необходимости тщательного ревью, которое может быть более трудоемким, чем написание кода с нуля.
• Озабоченность качеством и надежностью ИИ-сгенерированного кода, особенно в зрелых проектах и open source, где отсутствие публичного ревью может подорвать доверие.
• Увеличение нагрузки на разработчиков из-за необходимости ревью большего объема кода, который часто требует повышенного внимания из-за непредсказуемости ИИ.
• Потеря преимуществ человеческого взаимодействия в процессе ревью, поскольку ИИ не может участвовать в обсуждении или доработке кода.
• Необходимость разработки новых процессов и инструментов для эффективного ревью ИИ-сгенерированного кода, включая возможность комментирования и взаимодействия с агентами.

Краткий перевод и сжатие

Инженер Sanity Винсент Куигли за 6 недель перешёл от ручного кода к 80 % генерации ИИ.
Ключевые идеи:

• 4 этапа: «пишу сам» → «ИИ как Stack Overflow» → «ИИ пишет, я ревью» → «я ставлю задачи, ИИ решает».
• 3 попытки:
  1. 95 % мусора, но быстрое черновое решение.
  2. 50 % мусора, структура ясна.
  3. Рабочий код после уточнений.
• Контекст: claude.md в корне проекта хранит архитектуру, стандарты, примеры.
• Команда агентов: один пишет код, другой тесты, третий документацию; ежедневно «забывают» контекст.
• Ревью: ИИ → я → команда; человек смотрит только критические места.
• Фоновые агенты: ночью чинят мелкие баги, утром присылают PR.
• Цена: 400 $/мес на токены, но экономит 30 % времени инженера (≈ 6 000 $).
• Риски: регрессии, безопасность, зависимость от ИИ.
• Эмоции: ушла «владение кодом», пришло «владение проблемой».
• Советы тимлиду: начинать с экспериментов, выделять «зоны ИИ», усиливать ревью.
• Советы разработчику: заведи claude.md, ставь ИИ задачи помельче, проверяй критикуй, не верь на слово.

• Участники сходятся: LLM хороши для отладки и брейншторма, но не способны самостоятельно писать сложный продакшен-код без доработки.
• Все обсуждают Claude Code: кто-то активно использует и хвалит, кто-то жалуется на переусложнённый код и высокие расходы (до $1500/мес).
• Повторяется один и тот же набор советов: дробить задачи, писать тесты, держать короткие циклы обратной связи, использовать линтеры и логирование.
• Некоторые инженеры предпочитают сначала строить архитектуру сами, а LLM оставляют для рутины; другие наоборот.
• Общий вывод: AI-ассистенты становятся стандартным инструментом, но пока не заменяют разработчиков и требуют постоянного контроля.

Требование: раскрывать использование ИИ-инструментов при любом вкладе в проект.

• Что добавляется: в CONTRIBUTING.md новый раздел «AI-Generated Content Disclosure».
• Суть: авторы pull-request’ов и issue обязаны явно указывать, если текст, код, коммиты или дизайн были созданы или существенно изменены при помощи ИИ (ChatGPT, Copilot, Claude и т.д.).
• Формат: достаточно короткой пометки в описании PR/issue или в коммит-сообщении, например:
  AI-assist: code comments and variable naming via GitHub Copilot.
• Цель: сохранить прозрачность, облегчить ревью, защитить проект от лицензионных и качественных рисков.
• Без наказаний: нарушение не влечёт блокировку, но ревьюеры могут запросить уточнение.

• Проблема: LLM не может подписать DCO, а человек не может гарантировать происхождение кода, если он был сгенерирован ИИ.
• Правовые риски: код может быть заимствован из неизвестных источников, что создаёт угрозу нарушения авторских прав.
• Сообщество: многие мейнтейнеры требуют явного раскрытия использования ИИ, чтобы сохранить качество ревью и обучение новичков.
• Практика: проекты вроде Ghostty и Caddy уже маркируют AI-PR метками или текстовыми пометками.
• Противники считают, что важен результат, а не процесс, и предлагают полагаться на ревью кода, а не на дисклеймеры.

Код-ревью можно улучшить

Мы отложили эксперимент с git-review — инструментом, который делает ревью коммитом поверх PR.
Проблемы GitHub:

• состояние ревью не хранится в репозитории;
• всё через веб, с лагами и лишними кликами.

Локальный workflow
Я клонирую ветку, сбрасываю её, чтобы код выглядел «моим», и ревью в Magit: запускаю тесты, перехожу к определениям, помечаю файлы через git add -p.
Но оставлять замечания приходится в браузере: долго, неудобно, текстовое поле тормозит.

Идея git-review

• ревью = коммит с комментариями вида // CR(name): …;
• автор и ревьюер редактируют этот коммит (--force-with-lease);
• по окончании добавляется revert-коммит, сохраняя историю.

Почему не зашло
Комментарии в коде — супер, но:

• если меняешь код, комментарии смещаются и конфликтуют;
• --force-with-lease добавляет трения;
• нужен более мягкий merge для ревью, а не строгая цепочка хэшей.
  Довести до ума потребовало бы >500 строк «быстрого хака».

К тому же, в upstream-git может появиться Change-Id в стиле Gerrit, что изменит ландшафт.

• Основная боль: ревью приходит слишком поздно, заставляя переписывать всё с нуля.
• Решения: локальное ревью в IDE (IntelliJ, VS Code), stacked-PR, «reviewer merges»-подход.
• Инструменты: Gerrit, Phabricator, Graphite, GitButler, SourceHut, GitPatch, Tangled.
• Надёжный Change-ID в Git обещает фиксить проблемы с force-push и interdiff.
• Культура важнее инструментов: мелкие, самостоятельные коммиты, RFC-прототипы, совместное проектирование до кода.

Почему наём — боль

Компании теряют время: 9 раундов, охота за «трендовыми» разрабами, не могут отличить программиста от LLM. Кандидаты страдают: лучшие разрабы (Rust, Haskell) проваливают стресс-интервью, рекрутеры называют их «не-технарями», а потом пропадают на месяцы.

Каким должен быть хороший процесс

1. Различать сеньора и маркетолога с ChatGPT.
2. Применимо к работе: код, архитектура, ревью, документация.
3. Долгосрочно: люди не взаимозаменяемы, уход дорого, специализация под стек выучивается за месяц.
4. Экономно: инженерное время дорого.
5. Уважительно: неуважение отпугивает лучших.
6. Вкус: быстрое, но грязное решение — долгий долг команде; «клей» (поддержка коллег) множит продуктивность.

Почему популярные форматы не работают

• Live-coding / LeetCode
  Не различают, не про работу, уничтожают уважение и вкус, дорогие при многократных раундах.

• Take-home
  Легко сгенерировать ChatGPT, неуважительны к времени кандидата, отпугивают сильных.

• Проектирование архитектуры
  Лучше: ChatGPT не пройдёт, близко к реальной работе, можно оценить вкус и командное влияние.

• Современные «интервью» больше похожи на серию экзаменов, чем на профессиональный разговор.
• Многие считают, что достаточно 1-2 коротких встреч или пробы через контракт «temp-to-perm», чтобы понять, подходит ли человек.
• Популярные live-coding и leetcode почти не отражают реальную работу и отбирают не тех специалистов.
• Лучше обсуждать реальные задачи, ревьюить существующий код или решать мелкий баг в паре — это ближе к ежедневным обязанностям.
• Кандидаты теряют время и энергию на домашние задания и 9-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу Claude проверить свой код.
• Глобальный гайд ~/.claude/CLAUDE.md с правилами: мелкие шаги, TDD, простые решения, максимум 3 попытки при ошибке.

Качество
Я вручную читаю и тестирую всё, что выходит из LLM; отвечаю за PR независимо от автора кода.

• Ключ к успеху — писать подробные спецификации: кто-то тратит 2 часа на 12-шаговый документ и получает отличный результат, другие же считают, что даже «чистые» спеки не спасают от схода с курса и бесконечных правок.
• Мнения о CLAUDE.md разделились: одни держат файл коротким (<100 строк) и минималистичным, другие вообще не видят в нём пользы из-за «context rot» и субъективных инструкций.
• Работа с большими старыми кодовыми базами по-прежнему сложна: большинство признаёт, что Claude Code лучше справляется с новыми pet-project’ами, чем с «грязными» legacy-фичами.
• Популярные тактики: шаг-за-шагом микро-PR, TDD-агент, запуск puppeteer-тестов для «замыкания цикла», code-review собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.