Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта. Основные выводы: — ИИ увеличивает общий объем написанного кода примерно на 55%. — Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ. — Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1. — Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги. Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨. Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой. Один из комментаторов поделился рабочим решением: — Сделать CI-пайплайн первым и главным ревьюером. — Внедрить property-based тесты и мутационное тестирование на критичных участках. — Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений. Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания. Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/ Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198