Используем LLM для поиска бага в релизе Что у нас есть: 1. Лог/стек ошибки 2. Релизная ветка в Git 🛠 Готовим контекст (пример для IntelliJ IDEA) 1. На вкладке Git открываем релизную ветку 2. Выделяем все коммиты, попавшие в релиз 3. Копируем список коммитов → вставляем в текстовый файл Файл: release_task_list.txt 4. Выделяем все измененные файлы в релизе → ПКМ → Create Patch → To file Файл: release_patch.txt 5. Логи/стек ошибки сохраняем в error.txt Идея простая: модели по этим трем файлам смогут сложить пазл. Идём в модель с большим контекстом Gemini, Claude, DeepSeek — любой флагман, который переварит пару мегабайт текста. Модель здесь используется не как «дебаггер», а как анализатор изменений: она сопоставляет стек ошибки с диффами и историей релиза и формирует гипотезы. Промпт примерно такой: [Цель] Локализовать ошибку в релизной ветке. [Контекст] Сюда пишем дополнительные детали об ошибке, системе или функционале. Файл release_task_list.txt — список коммитов в релизе Файл release_patch.txt — кумулятивный патч Файл error.txt — лог/стек ошибки Прикрепляем файлы → отправляем запрос → получаем кандидата на причину инцидента. Пример возможного ответа Наиболее вероятная причина инцидента связана с коммитом ... Основная причина: изменена логика ... Стек ошибки указывает на: ... Файл: ... строка ... Гипотеза: В этом коммите была удалена ... Было: ... Стало: ... 📌 Итог Модель не «чинит» прод и не принимает решений за инженера. Она быстро сокращает область поиска, показывая, где именно стоит смотреть в первую очередь. Для крупных релизов это экономит часы, а иногда и дни расследования — при условии, что результат воспринимается как гипотеза, а не как истина. #Промпты #Кейсы