Hacker News Digest

• Обсуждение сосредоточено на том, что PR объемом 9000 строк кода и 63 файла невозможно ревьюить и должен быть разбит на части или отвергнуться без разбора.
• Участники подчеркивают, что такие PR нарушают базовые практики разработки и требуют автора разбить PR на меньшие, самодостаточные части.
• Сообщество подчеркивает, что такие PR часто не сопровождаются тестами или документацией, что делает невозможным проверить их корректность.
• Некоторые участники отмечают, что такие PR могут быть результатом использования AI, что вызывает дополнительные вопросы о качестве и поддержке кода.
• В конечном счете, большинство участников соглашаются, что такие PR должны быть отвергнуты с просьбой к автору разбить их на меньшие части, если это возможно, или начать с RFC или документации.

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

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

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

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

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

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

I've got this feeling that the endless feature creep of Github has begun to cause rot of core essential features. Up until only recently, the PR review tab performed so poorly it was practically useless for large PRs. HN sure has changed. A few years ago there would be at least a

Reminds me when I got banned from Amazon for suspected fraud (had an old account, but deleted my email and number since it was in a lot of DB dumps). After I got hired, I reached out to the guy in charge of the anti-fraud team at Amazon, and got unbanned. Emails to support etc. d