🤝 Как я подружил AI-агента со статическим анализатором, или История одной миграции

Делал на днях миграцию в проекте: переводил код с Java Date API на котлиновский kotlinx-datetime. Вроде бы всё классно, AI-агент прошёлся, основную массу мест поправил. Но нет — в коде всё равно оставались вызовы старого API. Почему? Проблема оказалась в том, как агент ищет места для замены. По умолчанию он ориентируется на импорты. А если класс используется с fully qualified name (полным путём без импорта), такие вызовы он просто пропускает. Не нашёл — не поменял.

Долго мучиться не стал, а сделал простую, но жёсткую штуку: написал кастомное правило для Detekt (статический анализатор кода). Правило запрещает использование определённых классов и пакетов — как в короткой форме, так и в полной.

Теперь процесс выглядит так:
1. Хочу что-то замигрировать — сначала добавляю "старые" классы в анализатор
2. Ветка начинает светиться красным от ошибок анализатора.
3. Агент, видя этот контекст, чётко понимает, где и что нужно менять, и идёт править уже точечно и полностью.

По итогу всё сработало! Если работаете с AI агентами в коде, не полагайтесь только на их "поиск по тексту". Лучше обвяжите их статическими проверками. Чем жёстче и точнее правило, тем меньше шансов, что агент что-то упустит. По сути, это готовый скилл для миграций — или просто надёжный способ не оставлять хвостов.

#AI #Kotlin #Detekt