Как я заставил ИИ перестать галлюцинировать в нашей кодовой базе
Инструменты ИИ для написания кода пасуют перед реальными продакшн-проектами. Они хорошо работают с новым кодом, но разваливаются при работе со старым кодом с историей изменений.
Нашему финтех-проекту три года. У него два фронтенда на React, админ-панель и бэкенд на FastAPI. База данных сложная, с множеством таблиц и тяжелыми соединениями.
Мы пытались использовать ИИ, чтобы ускориться. Это не сработало.
Я попросил ИИ создать таблицу контактов (contacts). Он создал новые колонки для имен и email-адресов. Он не понял, что они уже есть в нашей таблице пользователей (users). Вместо использования внешнего ключа (foreign key) он просто продублировал данные.
ИИ не был глупым. У него не было контекста. Он принимал решения на основе неполной информации.
Я перестал спрашивать, как получить лучший код. Я начал спрашивать, какой контекст нужен ИИ, чтобы принимать правильные решения.
Мы выстроили структурированный рабочий процесс. Эффективность ИИ напрямую зависит от предоставленного контекста. Мы сделали этот контекст явным.
Вот наша настройка:
- Директория ADR: Мы создали папку для записей об архитектурных решениях (Architecture Decision Records). Эти файлы объясняют, почему мы делаем тот или иной выбор. Один из файлов предписывает ИИ проверять существующие таблицы перед созданием новых. Он запрещает дублировать данные пользователей.
- context.md: Этот файл объясняет нашу специфическую терминологию. Он подсказывает ИИ, как наши уникальные термины связаны друг с другом.
- plot.md: Этот файл представляет собой высокоуровневую карту проекта и показывает, как взаимосвязаны его части.
- Обязательные тесты: Каждый новый API-маршрут требует наличия тест-кейсов.
Это изменило всё. Однажды ИИ изменил общую утилитарную функцию. Это изменение сломало восемь других частей системы. Набор тестов мгновенно это обнаружил. ИИ увидел ошибку и исправил её самостоятельно, создав версию, которая учитывала и старые, и новые требования.
Без тестов этот баг попал бы в продакшн.
Относитесь к ИИ как к новому разработчику. Вы же не вините новичка за то, что он не знает вашу кодовую базу. Вы предоставляете документацию и проводите онбординг. Мы сделали то же самое для ИИ.
Наша структура:
- docs/context.md: Термины и связи проекта.
- docs/plot.md: Высокоуровневая карта кодовой базы.
- docs/adr/: Конкретные правила, такие как создание таблиц и структура API.
Три правила для вашей команды:
- Будьте конкретны в ADR. Используйте четкие инструкции вместо расплывчатых советов.
- Сделайте документацию авторитетной. Скажите ИИ, что эти правила имеют приоритет.
- Превращайте ошибки в правила. Каждый раз, когда ИИ ошибается, пишите новый ADR.
Эта система не делает ИИ идеальным. Она делает его предсказуемым. Нам нужна кодовая база, в которой ИИ работает последовательно, чтобы команда могла двигаться быстрее.