Hacker News Digest

В 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).

Turbopuffer переходит от вектор-ориентированной архитектуры к новой модели, где ANN-индекс становится вторичным, а не основным. В v1 и v2 документы хранились вокруг векторных кластеров, что ограничивало размер блоков данными 100–200 записей — недостаточно для эффективных агрегаций, GROUP BY и полнотекстового поиска. Хотя FTS v2 улучшил ситуацию за счёт фиксированных блоков по 256 записей, фундаментальное ограничение оставалось: все планы запросов были привязаны к структуре векторного индекса. Теперь в v3 хранилище перепроектировано так, чтобы документы могли группироваться оптимальным образом для каждого типа запроса, а векторный поиск стал просто одним из вторичных индексов. Это изменение позволит ускорить все операции — включая текст, regex и SQL-подобные запросы — и заложит основу для масштабирования до более сложных аналитических нагрузок. Уже достигнуто 100% прохождения CI на v3, и команда готовится делиться бенчмарками по производительности в ближайшие недели. Turbopuffer сейчас обрабатывает ponad 1T документов, 10M+ записей в секунду и 25k+ запросов в секунду, и команда уверена, что новая архитектура раскроет его потенциал ещё дальше.

Turbopuffer перешёл к вторичному ANN‐индексу, снижая запись‐амплитуду, аналогично подходам InnoDB и PostgreSQL. В реальных проектах предпочтительнее использовать SQL‐БД с нативной векторной поддержкой, так как они объединяют векторный поиск с полнотекстовым, фильтрами, JOIN‐ами и ACL, устраняя необходимость синхронного слоя. В Turbopuffer v3 ANN‐слоты заменены на внутренние идентификаторы (segment ID, doc ID), а пользовательский ключ стал вторичным индексом — как в InnoDB — что уменьшает стоимость переиндексации при обновлениях. ElasticSearch успешно используется как единый движок для векторного и традиционного поиска, позволяя добавлять векторные запросы к существующим фильтрам и сортировкам. LanceDB реализует ANN как вторичный индекс, храня строки в фрагментах без их перемещения при перестройке индекса, что схоже с архитектурой Turbopuffer v3. Обсуждаются альтернативы: generative поиск и трансформер‐как‐индекс. Отмечается, что векторные БД изначально ориентированы на поиск, а не на хранение, и термин стал маркетинговым. Для больших кодовых баз (десятки миллионов строк) рекомендуется мульти‐БД система вместо готовых векторных СУБД для лучшей производительности. Отсутствие истинных кластерных индексов в PostgreSQL ограничивает производительность при запросах по PK, в отличие от MSSQL и Oracle. Для оценки масштабируемости необходимо измерять p99‐задержку при нагрузке 1 000+ запросов/сек. При проектировании систем с векторным поиском следует учитывать стоимость дополнительного чтения (например, S3 GET) при переходе от прямых указателей к PK‐ориентированным индексам. Ранее высокая запись‐амплитуда в Turbopuffer делала оптимизацию индексации малоэффективной; новая модель уменьшила эту проблему. В дискуссии gopalv сравнивает старый дизайн Turbopuffer с PostgreSQL (оптимизирован под поиск) и новый с MySQL/InnoDB (оптимизирован под записи), тогда как malisper указывает, что выгода от множества индексов в MySQL не полностью компенсирует общие затраты.

CI стал узким местом из‑за ускорения разработки: тестовый набор вырос в четыре раза, но проверка изменений отстаёт, увеличивая время ожидания и стоимость инфраструктуры. Чтобы ускорить обратную связь, мы оптимизировали время ожидания PR и потребление раннер‑времени, снизив среднее время ожидания с более 6 минут до чуть более 5 и вдвое сократив машинное время на тест.

Улучшения реализованы в четырёх направлениях: переход на более быстрые сторонние раннеры с лучшим кэшем ускорил задачи в среднем на 34 % (tsc — на 52 %); замена tsc на tsgo сократила медианное время проверки типов на 73 %; переписывание линт‑правил на работу с AST вместо TypeScript уменьшило время линтинга API на 68 % и полного репозитория — на 55 %, а также подготовило почву для перехода на Oxlint; увеличение количества тестовых шардов с 4 до 8 при одновременном улучшении параллелизма сократило время настройки с 8,3 до 7,5 минут, позволив запускать больше тестов одновременно. Без этих усилий тестовый набор занимал бы около 11 минут — почти вдвое дольше текущего показателя. С темпом роста около 2000 тестов в неделю дальнейшая оптимизация CI останется непрерывным процессом.

Ускорение разработки с помощью ИИ создало новый системный узкий пункт в виде CI. Решение проблемы требует не только оптимизации инфраструктуры, но и пересмотра архитектуры, процессов и ролей. Для ускорения пайплайнов и снижения затрат рекомендуют: — переход с GitHub Actions на сторонние раннеры с быстрыми CPU, производительным хранилищем и кэшем (например, blacksmith.sh); — использование Bazel для достижения времени сборки около 10 секунд при разогретом кэше в крупных проектах; — применение RWX как более гибкой альтернативы Bazel с кэшированием по содержимому и графовым выполнением задач. Для повышения эффективности разработки и тестирования: — разделять сервисы на изолированные компоненты с чёткими контрактами; — в Vitest балансировать нагрузку по длительности выполнения тестов, а не по количеству файлов. После оптимизации CI критическими узкими местами становятся деплой, откат и человеческое тестирование (QA), так как важно обеспечить удобство и любовь пользователей к продукту. Автоматизация продукт-менеджмента остается более сложной и важной задачей, чем автоматизация кода. Для соло-разработчиков целью является сокращение времени сборки до 5 минут для комфортной работы с агентами. Компании (например, Linear) обычно приступают к глубокой оптимизации инфраструктуры при достижении масштабов вроде 100M ARR. Существует спор о влиянии ИИ: одни считают, что погоня за скоростью ведет к падению качества, энергозатратности и неэффективному «бросанию кода на стену», другие отмечают рост числа приложений и незаметные, но частые улучшения UX (например, в YouTube для Android). Стартапы YC растут быстрее благодаря ИИ, в то время как крупные корпорации (Apple, Microsoft, Nintendo) не используют передовые инструменты разработки. Системы неизбежно становятся громоздкими со временем, и сейчас этот цикл проходят Linear и другие инструменты.

Homebrew 7.0.0 ускоряет установку и обновление пакетов за счёт оптимизации загрузки и распаковки, а также вводит нативное macOS-приложение с графическим интерфейсом для управления формулами и кегами. Поддержка macOS 10.15 Catalina прекращена — теперь минимальная версия — macOS 11 Big Sur, а Intel-маки переведены в Tier 3: новые бинарные пакеты (bottles) для них больше не собираются, и рекомендуется мигрировать на MacPorts или обновлять систему до Sequoia 15+ для полной совместимости. Apple Silicon Macs остаются на Tier 1 с полной поддержкой и готовыми бинарниками.

В области безопасности добавлены встроенные проверки уязвимостей и база рекомендаций (advisory database), которая сканирует установленные пакеты на известные проблемы при brew upgrade и brew info. Усилено изолирование (sandboxing) при установке и работе с taps — теперь сторонние репозитории работают в более строгом контексте, а установка через setuid-обёртки запрещена: команды должны выполняться от владельца префикса. Для команд CI и нестандартных префиксов улучшена надёжность и прозрачность поведения, а образ ghcr.io/homebrew/ubuntu22.04 удалён — пользователям рекомендовано перейти на ghcr.io/homebrew/brew. Также объявлено, что ветка master в репозитории Homebrew/brew будет заморожена и удалена 1 марта 2027 года — необходимо перейти на main. Проект остаётся полностью волонтёрским и призывает к поддержке через спонсорские платформы. На момент выпуска открытых issues в репозитории нет — впервые с версии 6.0.0.

Обсуждение подтверждает заявленное ускорение Homebrew 7, но выявляет реальные проблемы: прекращённая поддержка Intel‐Mac, требование sudo/root, баги GUI‐приложения и удаление wine, а также подчёркивает новые механизмы sandbox и возможности альтернативных менеджеров вроде Mise.

• Много пользователей отмечают, что установка и обновление пакетов стали заметно быстрее, что подтверждает обещанное ускорение в Homebrew 7.

• Совет: @asadhaider делится алиасом: alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup", позволяющим автоматически поддерживать систему в актуальном состоянии.

• Совет: @AbuAssar указывает, что новое графическое приложение можно установить командой brew install homebrew-app.

• Спор: Пользователи делятся противоположными мнениями: одни хвалят значительное ускорение и новые функции, другие расстраиваются из‐за прекращения поддержки Intel‐Mac и невозможности использовать GUI‐приложение на старом железе.

• Совет: @Sytten и @azuanrb советуют использовать менеджер Mise для единой конфигурации пакетов, отмечая, что он не ломает виртуальные окружения Python и упрощает управление зависимостями.

• Несколько комментариев (например, @mkrishnan, @gdevenyi) подтверждают, что установка Homebrew по‐прежнему требует sudo/root, что остаётся барьером для некоторых пользователей.

• Совет: @simonw раскрывает, что механизм sandbox в Homebrew построен на собственном wrapper‐е sandbox‐exec, что важно учитывать при оценке безопасности.

• Спор: Пользователи @spdustin и @mpweiher сообщают об ошибке GUI‐приложения "Failed to decode Homebrew JSON output", указывая на текущие проблемы стабильности нового интерфейса.

• Много участников отмечают улучшения в безопасности, такие как усиленный sandbox и встроенные проверки уязвимостей, как важные плюсы релиза.

• Совет: @basedpolymer делится опытом: на старом Intel‐MacBook GUI‐приложение не работает, поэтому пришлось вернуться к традиционным методам установки.

• Удаление cask wine вызвало разочарование у пользователей, например @xvilka, подчёркивая, что некоторые популярные пакеты могут исчезать из репозитория.

• Совет: @yougotwill хвалит функцию trusted taps, позволяющую заранее включить её и упростить миграцию конфигураций перед обязательным включением.

AI-сканеры создают постоянную нагрузку на git.kernel.org, потребляя около 20% вычислительных ресурсов — 14–16 из 90 ядер на пяти узлах постоянно тратятся на рендеринг коммитов в HTML для обучения моделей, что превышает нагрузку от всех легитимных запросов, включая git clone. Причина — неэффективный метод сбора данных: вместо простого клонирования репозиториев сканеры запрашивают каждый коммит как отдельную HTML-страницу, генерируя миллиарды дублирующих URL из-за форков и параметров вроде diff и patch, что создаёт «фоновое излучение» нагрузки. Хотя сайт остаётся отзывчивым для людей, основные сбои вызывают не сканеры, а плохо спроектированные CI-системы с поверхностными клонами. Администраторы пытаются бороться блокировкой IP и подсетей, но боты маскируются под браузеры и распределяются по облакам. В долгосрочной перспективе планируется ограничить функциональность и сократить количество сканируемых URL, хотя это ухудшит доступ для анонимных пользователей. Все данные останутся доступны для загрузки, но с дополнительными барьерами. Проблема системная: пока спрос на обучающие данные для LLM растёт, а простых решений нет.

Обсуждение дополняет статью: проблема не в технической неэффективности, а в системном провале этики веб-скрапинга. AI-скраперы игнорируют robots.txt и rate limiting, а защита через proof-of-work вредит легитимным пользователям, не останавливая продвинутых ботов. Советы по противодействию: - Замена Anubis на кастомную хеш-функцию без публикации обходит ASIC-скраперы, заточенные под стандартную реализацию. - Отказ от публичного HTML-интерфейса в пользу git clone для всех и веб-интерфейса только для авторизованных пользователей. - Лимит неавторизованных запросов — 5 в минуту с разрешением высокой частоты для авторизованных. - Рендеринг HTML на клиенте через JS-клиент, который клонирует репозиторий в браузере и кэширует данные. - Ловушки (бесконечные пути, медленная передача изображений, генерация абсурдного контента) заставляют ботов тратить ресурсы впустую. - Whitelist по IP/ASN вместо blacklist с общим списком между сайтами (риск: рынок поддельных доверенных узлов). - Повышение стоимости доступа к старым коммитам относительно новых — легитимные пользователи редко запрашивают древние данные. - Превращение proof-of-work в добровольный майнинг криптовалюты, где боты «платят» хостингом. - Временное повышение сложности Anubis при запросах к нестандартным URL с подсказкой посетить главную страницу. - Кэширование HTML-рендеров git-репозиториев, так как коммиты редко меняются. - Блокировка cgit-эндпоинтов (diffs, blame, snapshots) и возврат 402 за доступ — признание поражения, но единственный рабочий способ остановить ботов без отключения сервиса. Споры: - Anubis неэффективен: скраперы обходят его через куки, а мобильные пользователи страдают от высокой сложности. - AI-скраперы тратят ресурсы на обучение, но это не оправдание — они могли бы клонировать репозитории, а не запрашивать каждый коммит в HTML. Консенсус: - Современные AI-скраперы игнорируют robots.txt, rate limiting и другие устоявшиеся практики, делая традиционные методы защиты бесполезными. - Рост нагрузки от ботов не связан с качеством контента: скраперы сканируют всё подряд без фильтрации, создавая комбинаторный взрыв URL.

Код теперь можно размещать напрямую в Cursor через новую функцию Origin — early‑beta‑режим для платных пользователей. В появившемся Codebase‑разделе можно создать репозиторий, задать ему название (URL будет выглядеть как cursor.com/codebase/название), установить CLI и начать пушить локальный проект. Синхронизация с GitHub позволяет держать репозитории как на GitHub, так и в Origin, при этом выбирая, какие из них синхронизировать, и отключать их в любой момент.

Pull‑requests работают в обе стороны: комментарии и реакции в Cursor мгновенно отражаются в GitHub и обратно. В каждом репозитории доступны встроенные агенты, которые могут отвечать на вопросы о коде, менять PR‑ы и пушить ветки. Интеграции с Vercel, Depot и Buildkite уже готовы: через Apps‑таб можно привязать Vercel для preview‑деплоя каждого PR, а Depot и Buildkite — для запуска CI‑pipeline, включая GitHub Actions. Настройки репозитория позволяют проверять статус синхронизации, управлять доступом и подключать приложения.

Запомните: название репозитория становится частью URL, а синхронизация происходит в реальном времени, сохраняя GitHub как источник истины. Сейчас Origin доступен в early‑beta для всех платных планов, кроме компаний, которые явно отключили его. Начать работу можно сразу в интерфейсе Cursor.

Пользователи отвергают Origin как GitHub-альтернативу из-за связи с Илоном Маском и опасений, что код будет использоваться для обучения Grok. Предпочтение отдается децентрализованным решениям (Radicle, Forgejo, SourceHut, Codeberg, Tangled) или self-hosted Git — как более безопасным для приватности. Origin ограничен синхронизацией с GitHub и не предлагает инноваций в агентных рабочих процессах, что вызывает критику как «GitHub clone». Технические недостатки — высокий расход CPU и требование SMS-верификации — снижают доверие. Споры идут о природе рисков: одни считают проблему в росте кода из-за AI, другие — в принудительном сборе данных Cursor для обучения моделей. Эксперты полагают, что Cursor ориентирован не на хостинг, а на сбор истории версий и патчей для AI.

Qwen3.8-Max — новый флагман серии Qwen, впервые открывающий веса модели уровня Max (2,4 трлн параметров, из которых 95 млрд активно используются). Основное новшество — способность самостоятельно реализовывать сложные, длительные задачи: от создания полноценного CLI‑утилита с автогенерируемым механизмом обратной связи до многократного улучшения собственного тест‑пакета без вмешательства человека. В тестах модель прошла 10‑дневный автономный цикл, где её агент формировал задачи в GitHub Issues, выбирал их, писал код, запускал CI, сливал PR и даже улучшал процесс тестирования на основе результатов. Такой «loop‑engineering» позволяет модели не просто выполнять сценарии, а адаптировать их под текущие ограничения, что делает её результаты более надёжными и воспроизводимыми.

Ключевые цифры: 2,4 трлн параметров, 95 млрд активных, 10+ дней непрерывного кодинга без человеческого контроля, публичный репозиторий [qwen-code-dev-bot/oh‑my‑cli] с полной историей изменений. Открытие весов запланировано на следующую неделю, что откроет доступ к этим возможностям шире.

Qwen3.8-27B может быть более эффективным, чем Qwen3.6-27B и Qwen3.5, а также чем KimiK3-Thinking. Qwen3.8-Max показывает лучшие результаты в визуальном веб-разработке и перцепшенбенче, имеет 2,4 трлн параметров и может быть слишком большим или сложным для использования на домашних компьютерах. Qwen3.6-35B-A3B подходит для задач Python и баз данных. Некоторые считают, что Qwen3.6 модели эффективны для домашнего использования. Qwen3.8-Max может иметь более низкую стоимость, чем Deepseek. Alibaba Cloud может создавать излишние барьеры для домашнего использования. Если LLM не может запоминать и учиться, его легко заменить — это означает, что AI-компании не обладают монопольным положением на рынке.

Разработчики часто сталкиваются с тем, что официальная документация описывает функцию, но не показывает, как её использовать. Пример: вместо того, чтобы показать, как вызывать max() в Python, документация тратит абзацы на то, чтобы объяснить, что такое iterable и что значит key=. А ведь достаточно было бы показать, как передавать кастомную функцию сортировки в max().

Проект ClojureDocs берёт на себя роль «примеры — лучшая документация». Пользователи добавляют примеры к встроенным функциям, и это оказывается куда более полезным, чем формальное описание API. Примеры показывают, как вызывать функцию, какие есть подводные камни и какие есть альтернативы.

• Документация должна включать и примеры, и полное API-описание; оба формата дополняют, а не конкурируют.
• Примеры важны для новичков, но не заменяют полное описание параметров и контрактов; примеры без спецификации приводят к тому, что разработчики вынуждены читать исходники.
• Примеры должны быть живыми: если они не запускаются как часть CI или не покрыты тестами, они быстро устаревают и вводят в заблуждение.
• Документация должна быть двух типов: краткий пример для быстрого старта и полное руководство для продвинутых пользователей.
• Примеры должны быть частью тестов и наоборот: примеры в документации должны быть тестируемыми как часть CI.