Wildberries mostrou como um agente local de AI começou a escrever testes unitários para Android

Wildberries & Russ опубликовала практический разбор того, как тимлид Android-команды превратил локальную LLM из любопытной игрушки в рабочего помощника для unit-тестов. Эксперимент занял около двух месяцев: сначала ИИ стабильно ошибался и галлюцинировал, но после перенастройки начал выдавать компилируемые тесты и даже сам исправлять замечания ревью.

От скепсиса к задаче

Автор текста описывает путь, знакомый многим разработчикам: от первых восторгов вокруг ChatGPT в 2023 году — к усталости от хайпа и сомнениям, что нейросети реально дают прирост в большой продуктовой разработке. После изучения докладов, статей и кейсов он пришёл к более приземлённому выводу: в существующих кодовых базах речь обычно идёт не о замене команды, а о приросте эффективности примерно на 10–20%, если инструмент правильно встроен в процесс.

«Разница между джуном и сеньором в области использования нейросетей составляет 3–4 месяца».

С этой точки автор выбрал не абстрактную цель «внедрить ИИ», а очень конкретную и нелюбимую многими задачу — написание unit-тестов для Android-проекта на Kotlin. Важное ограничение: использовать можно было только локальную LLM или модель в корпоративном контуре. Из-за требований безопасности отпали облачные сценарии, где код проекта индексируется и уходит на внешние серверы, поэтому ставка была сделана на инструменты, совместимые с локальной инфраструктурой.

Почему не взлетело Первый заход выглядел логично, но провалился.

Разработчик собрал большой системный промпт, подробно описал проект, добавил md-файл с инструкциями для агента и шаблон промпта для тестов, рассчитывая, что максимум контекста даст максимум качества. На практике локальная модель писала тест на маленький маппер около 20 минут, а на выходе приносила не рабочий результат, а набор предупреждений, ошибок импортов и некомпилируемого кода. Чем крупнее был класс, тем сильнее росли галлюцинации и тем хуже модель понимала, какие тестовые инструменты вообще нужно применять.

Главные проблемы первой итерации выглядели так: слишком подробные инструкции перегружали модель, и она игнорировала важные требования; выводы Gradle после сборки и запуска тестов забивали контекст и ухудшали последующие ответы; параллельный запуск нескольких сессий не ускорял работу, а просто умножал число сломанных тестов; попытка сразу тестировать большие ViewModel заканчивалась потерей фокуса и вымышленными решениями. Ручная доводка такого результата тоже не спасала ситуацию. Исправлять сгенерированный тест часто оказывалось дольше, чем написать его с нуля.

В итоге первый этап дал полезный, но неприятный вывод: сама по себе LLM не превращается в надёжного помощника только потому, что ей выдали длинный промпт и доступ к коду. Нужны другая структура контекста, фильтрация шума и более чёткое разделение работы внутри агентной системы.

Что в итоге сработало Во второй итерации автор поменял не только модель, но и сам подход.

Он добавил RAG с индексом проекта, чтобы ускорить поиск релевантных файлов, и настроил обработку Gradle-вывода так, чтобы в промпт попадала только полезная информация, а не весь технический шум сборки. После этого поверх OpenCode была собрана структура из основного агента, сабагентов и отдельных skills. Идея простая: вместо одной гигантской инструкции модель получает короткие правила под конкретный этап работы.

Система для генерации тестов была разбита на три роли: планировщик анализировал класс и собирал todo с кейсами, писатель тестов реализовывал сами проверки, а ревьюер проверял компиляцию, полноту покрытия и соответствие стилю. Именно после такой декомпозиции модель впервые выдала готовый компилируемый тест на небольшой маппер. Merge request прошёл ревью с замечанием по стилю, это замечание добавили в соответствующий skill, а исправление снова выполнила сама модель.

На локальных мощностях один тест всё ещё занимал около 19 минут, но это уже было полезно в реальном ритме работы: агент мог писать тесты, пока разработчик был на созвоне. Позже, после запуска на более мощной инфраструктуре, время сократилось примерно до 5–10 минут на один тест.

Что это значит

Кейс Wildberries показывает, что корпоративный ИИ-агент начинает приносить пользу не после «магического» подключения модели, а после инженерной настройки: с индексом проекта, фильтрацией шума, ролями и обязательной проверкой результата. До полной замены разработчиков здесь очень далеко, но рутинные задачи вроде unit-тестов или мелких исправлений уже можно делегировать машине — особенно там, где важны локальный контур и контроль над кодом.