В последние месяцы технологические компании активно модернизируют свои системы разработки. Так, Anthropic столкнулась с резким ростом объёма кода и была вынуждена заменить Git на систему контроля версий Scion. Над Scion 7 инженеров работали 5 месяцев. Результаты внедрения впечатляют: если в мае Anthropic ежедневно объединяла около 2500 изменений кода, то к сентябрю этот показатель превысил 30 000. При этом CI‑система компании ежедневно выполняла около 25 млн операций извлечения кода.
Git обеспечивает работу в автономном режиме, но для задач Anthropic (CI‑задания и агентские песочницы) это создаёт избыточные затраты. История основного филиала Anthropic приближается к 100 ГБ, сжатые рабочие копии — более 25 ГБ. При 25 млн ежедневных извлечений теоретический трафик превысит 600 ПБ. Scion решает эти проблемы: он сокращает клиентскую часть до лёгкого интерфейса. Основные операции (создание, объединение, перебазирование и запрос истории) выполняются на центральном сервисе, а локально — только отслеживание изменений файлов и поддержание небольшого кэша. CI может вычислять diff через API без полного извлечения.
В Scion вместо Git‑коммитов используются changeset: они записывают изменённые относительно первого родительского коммита файлы в виде предварительных журнальных записей, используют указатели с адресацией по содержимому. Создание changeset не требует генерации Git packfile и немедленного перемещения общих ветвей. Scion поддерживает derived data для blame, истории путей и графиков коммитов — данные предварительно вычисляются по родительским коммитам либо генерируются при запросе.
Процесс работы с Scion выглядит так: при проверке через «» (：) клиент scn запрашивает только недостающие tree и blob, начиная с целевого каталога. Запросы проходят через scion-daemon, область scion-cache, затем scion-server обращается к Spanner или объектному хранилищу. Объекты после записи неизменяемы, кэш можно повторно использовать между задачами — это сокращает переговоры, сжатие и повторную передачу. Anthropic заявляет, что уровень попадания в кэш превышает 99%, а также ограничивает поток обращений к источнику при сбоях. После миграции Scion требует в 200 раз меньше ресурсов CPU и памяти по сравнению со старой системой Git‑зеркал, время проверки сократилось с минут до секунд, CI высвобождает около 25% ресурсов CPU.
Кроме того, Anthropic разрабатывает инструменты Antique (для рецензирования кода, поиска исходного кода, IAM и массового слияния) под новый протокол. При этом компания столкнулась с новой проблемой: ещё до завершения тестирования в основную ветку могут быть внесены сотни или тысячи изменений. Зависимость от глобальных блокировок приводит к накоплению изменений, а повышение параллелизма — к новым рискам. Для решения этих проблем Anthropic усиливает тестирование после слияния и проверку перед развёртыванием, а для обычных команд приоритет — совершенствование анализа зависимостей, инкрементального тестирования и кэша сборки.
Не только Anthropic, но и GitHub модернизирует свои системы. Компания заменила общий LLM на доработанную модель ModernBERT в сканировании ключей. GitHub использует регулярное выражение как начальный фильтр, а для дальнейшего анализа — дообученный ModernBERT: он анализирует строки‑кандидаты, тип ключа, имена переменных, пути к файлам и соседний код, выдаёт оценку риска, по порогу решается, выдавать ли предупреждение. Модель экспортируется в ONNX и квантуется до 8 бит для снижения затрат на вывод. Новая схема показала рост офлайн‑Precision на 13%, Recall — на 19%. В онлайн‑A/B‑эксперименте медиана времени выполнения Post‑push‑сканирования снизилась на 86%, затраты на сервис модели — более чем на 98%, взвешенный по владельцам репозитория показатель принятия предупреждений вырос на 11,5%.
Также стоит отметить работу Колумбии университета и Google DeepMind: с помощью BTTF они преобразовали сигналы моделирования чипов в SQLite, чтобы агенты могли использовать SQL для выявления аномалий. При проверке сбоев в верификации чипов возникают сложности с обработкой данных RTL‑симуляции: VCD и FSDB‑файлы могут достигать десятков ГБ или ТБ. Инженеры «» ищут аномалии в просмотрщике волн по временной шкале. Если Agent преобразует исходные волны в текст, контекст быстро заполняется временными метками, именами сигналов и повторяющимися переходами.
BTTF передаёт доступ к данным SQLite: signalmetadata хранит статическую информацию (название, тип, уровень сигнала), signalchanges — ID сигнала, временную метку и изменённое значение; таблицы связаны по ID. Для запроса состояния сигнала в определённый момент SQL находит ближайшее предыдущее изменение; для анализа интервала — фильтрует и агрегирует по временному окну. BTTF при сборе данных создаёт сопоставление идентификаторов волн с ID базы данных, подсчитывает переходы сигналов, применяет фильтрацию по часам, обрезку сигналов без переходов и пакетную вставку. Без обрезки база данных занимает 1420 МБ, время запроса — около 410,5 мс; после фильтрации часов и сигналов без переходов размер сокращается до 395 МБ, время — до 94,8 мс. При удалении сигналов с частотой переходов ниже среднего размер базы может быть уменьшен до 185 МБ, но охват активности упадёт до 64,23%. Существует риск потери данных о редких сбоях, возникающих в почти неподвижных управляющих сигналах. Обрезка данных должна соответствовать требованиям отладки и утверждений.
BTTF использует SQL‑интерфейс и разные агенты: Orchestration Agent (разбивает задачу), Analysis Agent (генерирует запрос), Verification Agent (проверяет утверждения и связывает с RTL‑кодом), Evaluation Agent (проверяет временной диапазон, связи полей и целостность результата). В эксперименте с 4,2 GB сигналов, 18450 сигналами и 150 экспертными запросами достигнута точность выполнения 95,33%. Качество Multi‑Agent на 17,3% выше, чем у Single Agent, среднее время задержки увеличилось примерно в 1,96 раза, точность статической проверки SVA — 84,62%.
Подписаться в Макс
