Самый скучный текст в разработке оказался лучшей задачей для языковой модели

Что именно сделали. Команда разработки собрала консольный инструмент AI Describer: он берёт git diff относительно целевой ветки, отправляет его языковой модели и публикует структурированное описание обратно в merge или pull request. Запускается одним шагом пайплайна — сразу в двух системах сборки, GitLab CI и Jenkins, на Windows-агентах и при двух хостингах репозиториев. Подробности — в материале Habr «Как мы перестали писать описания к merge request руками» (habr.com/ru/articles/1086306).

Первый урок виден уже в постановке задачи: вход и выход были формализованы до того, как в проект пришла модель. Вход — diff, точный список изменений, выход — текст по шаблону. Модели не нужно рассуждать, что происходит в проекте: у неё есть факты и форма, в которую их надо уложить. Сравните с задачей, где ИИ стабильно проваливается: вход размыт (переписка, пожелание «сделай красиво»), а критерий готовности живёт в голове заказчика. Разница не в модели, а в постановке.

Второй урок: модель не должна знать больше, чем источник. Если разрешить ей додумывать мотивацию изменения, в описании появится причина правки, которой не было. В разборе это решается тем, что единственный вход — diff. То же правило работает в любом деловом тексте: цены, сроки и условия берутся из источника дословно, а не восстанавливаются моделью по памяти.

Третий урок касается не модели, а обвязки. Инструмент работает в GitLab CI и Jenkins, на Windows-агентах, при двух хостингах репозиториев. Скрипт, который отлично живёт на одном стенде, в компании не работает вообще: реальная стоимость внедрения — не вызов модели, а совместимость с зоопарком инфраструктуры, который уже есть. Кто считает бюджет автоматизации по цене запросов к модели, узнаёт об этом на второй неделе.

Четвёртый урок — про точку встраивания. Описание генерируется одним шагом пайплайна: не отдельный сервис, не новая привычка, не ещё одна вкладка в браузере. Работа живёт там, где возникала, — рядом с правкой. Автоматизация, которая требует «не забыть открыть инструмент», по факту не внедрена: она держится на той же дисциплине, которую должна была заменить.

1. Проверяйте формализуемость до выбора инструмента: точный вход (diff, карточка сделки, лог) и фиксированная форма результата.
2. Запрещайте модели выходить за пределы источника: лишняя «уверенная» деталь в деловом тексте дороже пропуска.
3. Считайте бюджет по совместимости, а не по цене запросов: две системы сборки, два хостинга и Windows-агенты стоят дороже работы модели.
4. Встраивайте инструмент в существующий процесс одним шагом, а не отдельным сервисом: автоматизация, которую надо не забыть запустить, не работает.
5. Ищите тексты, которые повторяются каждый день и собираются из данных: это первые кандидаты на автоматизацию.