Harness запустила перестроенный Git-репозиторий и продукт AI Code Review после того, как команды начали получать не просто больше кода, а больше pull request’ов, чем способны переварить ревьюеры и тестировщики. По данным The New Stack, внутренние инженеры Harness, по оценке самой компании, сэкономили более 10 000 часов ручного ревью в месяц. Для русскоязычных разработчиков и IT-директоров это знакомый сигнал: узкое место в AI-разработке переезжает из IDE в CI/CD, ревью и релизный контур.
Сюжет рассказал Martin Reynolds, field CTO Harness. По его словам, в ранних экспериментах с GitHub Copilot и Amazon CodeWhisperer компания уже видела рост объема нового кода в 1,5-2 раза. Тогда первыми застонали тестировщики: pull request’ы приходили быстрее, чем команда могла их проверить. Сейчас, говорит Reynolds, у некоторых клиентов рост доходит до 10 раз, а отдельные команды говорят и о 50-кратном увеличении. Тут уже не помогает бодрый лозунг «пишем быстрее»: если ревью стоит в очереди, бизнес быстрее ничего не получает.
Ответ Harness состоит из двух частей. Первая — обновленный Code Repository, который компания позиционирует как Git-хранилище, изначально рассчитанное на людей и AI-агентов. Вторая — AI Code Review, который должен помогать ревьюерам отделять содержательные изменения от шума: автосгенерированной обвязки, массовых обновлений зависимостей и десятков файлов, где человек чаще всего только теряет фокус. Логика простая: смотреть надо не на весь дифф как на монолит, а на те места, где действительно меняется поведение системы.
Harness продает собственный репозиторный сервис с 2023 года, когда запустила Harness Code на базе своего open source Git-проекта. Новую версию, по словам Reynolds, компания перестроила как «AI-first» репозиторий: Kubernetes-архитектура, работа в нескольких облаках и регионах, тестирование на тысячах коммитов в секунду. В бете продукт использовали около 20 корпоративных клиентов, но их названия Harness не раскрывает. Это важная оговорка: пока перед нами сильная инженерная заявка, а не публично проверенный рыночный стандарт.
Контекст у запуска очень удачный для Harness и не самый приятный для GitHub. Reynolds связывает проблему с тем, что классические Git-платформы исторически проектировались под человеческий ритм: команда из 10-15 разработчиков, pull request на несколько часов или дней, рабочий день с началом и концом. AI-агентам это расписание, мягко говоря, неинтересно. Они могут плодить изменения ночью, в выходные и параллельно в десятках веток. GitHub 17 августа 2026 года пережил почти восьмичасовой сбой; в постмортеме CTO GitHub Vlad Fedorov писал, что критический инфраструктурный компонент в дата-центре Central US не масштабировался под новый пик трафика. GitHub также указывает масштаб своей нагрузки: 2,9 млрд коммитов в месяц, то есть чуть больше 1000 в секунду в среднем.
Harness, конечно, не GitHub по масштабу. Но для enterprise-клиентов это может быть не минусом, а аргументом: многим крупным компаниям нужен не глобальный публичный хаб, а предсказуемая внутренняя фабрика кода, где можно жестко привязать репозиторий к политикам, инцидентам, пайплайнам и требованиям комплаенса. Для этого Harness за последний год строила software delivery knowledge graph — граф знаний о пайплайнах, деплоях, инцидентах и политиках клиента. Идея в том, чтобы AI-ревьюер не просто ругался на стиль кода, а понимал контекст доставки. В примере Harness система могла подсветить миграцию, потому что похожий неиндексированный CREATE INDEX раньше заблокировал production-таблицу на 14 минут.
Главная интрига тут не в том, заменит ли AI Code Review человека. Скорее наоборот: Harness явно продает не магического робота-релизера, а фильтр для человеческого внимания. Reynolds прямо говорит, что детерминированные инструменты должны остаться на месте: результаты тестов должны приходить из test runner, политики — из системы политик, пайплайны — из CI/CD. AI полезен там, где нужно быстро поднять контекст, разложить риск по файлам и подсказать, кому лучше смотреть конкретный участок кода. Это куда менее романтично, чем «автономный SDLC», зато больше похоже на то, что можно внедрить без коллективного прыжка в неизвестность.
Для разработчиков это означает новую норму ревью: ценность будет не в том, чтобы героически читать 30 файлов подряд, а в том, чтобы понимать, какие три из них требуют человеческого суждения. Для тимлидов и CTO — новый класс метрик: не только сколько кода сгенерировал агент, но сколько PR’ов зависло, сколько изменений дошло до тестов, где ревью стало формальностью и насколько вырос операционный риск. Для HR в IT это тоже неприятная, но практичная новость: производительность AI-команд нельзя мерить количеством строк или закрытых задач, если downstream-процессы не успевают за генерацией.
Рынок инструментов разработки быстро приходит к трезвой фазе: AI уже умеет писать много кода, но инженерная система вокруг него должна выдерживать этот поток. Следующий спор будет не о том, какой агент красивее дописывает функцию, а о том, кто контролирует очередь изменений, риск и право последнего апрува.