AI в старом коде: как не сломать систему, пока модель её улучшает
Языковые модели быстро рефакторят код, но легаси-системы полны невидимых соглашений и скрытых зависимостей. Искусственный интеллект их не видит — и вот уже упал production. Рассказываем, как внедрять AI-агентов без потерь.
Почему AI часто ломает старый код
Представьте: модель за минуту переписала вашу функцию валидации, сделав её компактнее и понятнее. Но она не знала, что эта функция парсит данные из устаревшего API, который иногда передаёт null вместо пустой строки. Или что в одном месте системы специально вызывается исключение для логирования. Или что определённый обработчик ошибок полагается на частный баг в зависимости, которую уже два года никто не обновляет.
AI видит только код. Она не видит:
- Неявные контракты между модулями (кто кому какие гарантии даёт)
- Исторические компромиссы и причины, по которым что-то выглядит странно
- Бизнес-правила, закодированные в цифрах и условиях
- Граничные случаи, которые срабатывают раз в полугодие
- Зависимости от поведения внешних систем
Результат: «тихие регрессии» — баги, которые не вызывают исключений, но нарушают корректность системы. Пользователь видит неправильный результат, аналитика сломана, или деньги считаются неверно.
Стратегия: три уровня защиты
Нужен многоуровневый подход, чтобы AI действительно помогала, а не травила. Вот проверенная схема:
1. Документация как договор
Перед тем как пустить агента в код, напишите для каждого модуля краткую spec:
- Входные условия — какие значения и в каких случаях может получить функция
- Выходные гарантии — что ровно гарантируется на выходе
- Побочные эффекты — что ещё происходит (логирование, кэширование, вызовы API)
- Известные граничные случаи — что обрабатывается специально и почему
Не нужны 100 страниц. Достаточно 5-10 строк, которые помещаются в комментарий функции. Это не только для AI — это для вашего будущего я через полгода.
2. Тесты: от банальных к коварным
Стандартные unit-тесты AI пройдёт легко. Нужны тесты именно на граничные и странные случаи:
| Тип теста | Зачем нужен | Пример |
|---|---|---|
| Happy path | Базовая функциональность | Корректные данные → корректный результат |
| Граничные значения | Ловит наивные оптимизации | Пустая строка, 0, -1, максимальное число |
| Интеграционные | Проверяет контракты между модулями | Вызов функции A влияет на результат функции B |
| Регрессионные | Охраняет известные баги и костыли | Null вместо исключения, особая обработка для одного клиента |
3. Контролируемые зоны миграции
Не давайте AI переписать весь легаси сразу. Разбейте на этапы:
- Фаза 1 — анализ без изменений. Агент изучает код, предлагает изменения, но не применяет их.
- Фаза 2 — рефакторинг отдельных функций. Меняете одну функцию, запускаете все её тесты локально.
- Фаза 3 — интеграционное тестирование. Меняется целый модуль, тестируется взаимодействие с соседями.
- Фаза 4 — staging и smoke-тесты. Всё работает на тестовой среде перед боевым деплоем.
Каждый этап — это отдельный PR, который ревьюит человек. Никаких автоматических мержей.
Что задать AI перед работой
Хороший промпт для агента должен содержать:
- Зачем вообще нужны изменения (перформанс, читаемость, совместимость)
- Какие части кода неприкасаемы и почему
- Какие тесты должны пройти без изменений
- Что нельзя делать (менять API, удалять логирование)
- Как запустить локально и проверить
Чем яснее инструкция, тем меньше сюрпризов.
Итог
AI-агенты — это мощный инструмент для ускорения разработки, но только если вы его правильно держите за поводок. Добавьте документацию, напишите тесты на граничные случаи, проводите миграцию этапами, и тогда модель будет действительно помогать, а не создавать ночные инциденты. Главное правило: любое изменение в легаси-коде должно пройти через человека, который понимает, почему код устроен именно так.