Hacker News Digest

В команде Claude Code около 90% кода пишет сам Claude, поэтому проверку пришлось переосмыслить: вместо ручного чтения строк основная нагрузка легла на машины, а человеческое время и внимание берегут для задач, которые под силу только людям. С июня по сентябрь число влитых пул-реквестов удвоилось, а доля откатов упала более чем на 40%. В монорепозитории Anthropic объём изменений вырос примерно с 2500 в день в мае до более 30 000 в сентябре.

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

Проверки выстроены слоями, а не одним шлюзом. Сначала работа верифицируется до появления пул-реквеста: Claude дают тесты, сборку или скриншот для сравнения с дизайном и просят показать результат, а не утверждать, что готово; затем субагент свежим взглядом проверяет диф. Цель — чтобы большинство пул-реквестов влилось максимум с одним человеком в цепочке без роста откатов и инцидентов. Метрики — одобрения и комментарии людей, время ожидания, а откаты и инциденты служат ограничителем: если они растут, время не сэкономлено, а лишь перемещено.

Автоматизированный обзор кода в Claude Code вызывает сомнения: 30 000 PR в день делают процесс формальным, возникают вопросы о стоимости токенов, соответствию SOC2 и безопасности. Есть риск «игры» метриками (например, снижение откатов как цель, а не улучшение качества). Большинство участников считают, что полностью заменить человеческий контроль нельзя. Для критических задач и соответствия требованиям аудита (SOC2) необходимо сохранять минимум одного человека в цепочке проверки. Также отмечается, что ресурсы Anthropic (неограниченные токены) не масштабируемы для большинства компаний, и требуются механизмы сортировки изменений и практические примеры агент-ассистированного обзора, где человек остаётся в курсе при росте PR. Понимание кода через непосредственное знакомство остаётся ключевым для качественного ручного ревью.

В Anthropic узким местом разработки стала не генерация кода, а инфраструктура для людей: система контроля версий, сборки и CI. Если в мае 2026 года в монорепозиторий вливалось в среднем около 2 500 изменений в день, то к сентябрю — уже более 30 000. Рост не замедляется: спрос на слияние кода практически бесконечен, и снятие каждого узкого места сразу увеличивает объём производимого кода.

Git плохо подходит для такой нагрузки. История главной ветки — почти 100 ГБ, а сжатая рабочая копия — свыше 25 ГБ; выполняется порядка 25 млн извлечений кода в день только для CI, что при наивной загрузке дало бы более 600 ПБ трафика. Обходные пути — shallow-клоны, sparse-checkout, promisor-remote, а также внутренние зеркала и «снимки» репозитория в хранилище — на пике это были сотни зеркал. Они выигрывали время, но становились всё сложнее в эксплуатации по мере роста частоты слияний: снимки отстают от вершины main, а операции вроде diff и blame на частичных клонах требуют всё больше усилий.

Решение — собственный контроль версий Scion, на который монорепозиторий полностью перевели с git за пять месяцев. В этот же срок создали поверхность код-ревью Antique, поиск по коду, систему управления доступом IAM и новые способы проводить большие объёмы проверенного кода. Ирония в том, что способность Claude писать код и создала проблему, и помогла быстро построить масштабируемую систему. Anthropic планирует делиться наработками с сообществом git, GitHub и GitLab.

Обсуждение дополняет статью скепсисом относительно качества кода при темпе 30к мержей в день и ставит под сомнение техническую необходимость отказа от Git в пользу кастомного решения, сравнимого с возвратом к SVN. Часть пользователей считает отказ от Git неизбежным при агентном кодинге (@jqdsouza, @Gepsens), другие (@bob1029) не видят технических доказательств, что Git не справился бы с такой нагрузкой при правильной настройке. Пользователи спорят о качестве кода: @duttish находит в коде Claude «кривые вещи» (janky crap), что вызывает вопросы о том, как Anthropic обеспечивает ревью 30 000 PR в день без потери качества. Роль инженера смещается от написания кода к функции «контролера», чья основная задача — говорить нейросети «нет», когда она нарушает системные ограничения ради следования паттернам (@alex_suzuki, @kburman, @bob1029). Снижение стоимости написания кода с помощью ИИ делает экономически выгодным создание собственных кастомных инструментов вместо адаптации существующих решений (@kburman). Огромный объем изменений (churn rate) может быть признаком не эффективности, а отсутствия единого видения продукта или плохой архитектуры (@he0001, @netburst). Архитектурно Scion напоминает возвращение к централизованным системам контроля версий вроде Subversion (SVN) (@tatersolid, @mijoharas, @mey). Для коллаборации агентов в качестве альтернативы Git рекомендуется обратить внимание на Pijul (@blurbleblurble). Существует риск «FOMO-эффекта», когда другие компании начнут копировать подход Anthropic, не обладая их ресурсами и объемом данных (@preommr).

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

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

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.