Статья называется «Не все так просто», потому что может возникнуть ощущение, что современный искусственный интеллект позволяет делать код-ревью простым действием: берем какой-нибудь ChatGPT, засовываем туда код – и он нам все выдает. Я так попробовал – не получилось. Поэтому решил рассказать вам про свои мытарства.
Сразу скажу, что моя статья устарела. Она устарела в тот момент, когда я начал ее писать. Потому что искусственный интеллект, LLM и все это развивается настолько быстро, что знания, которые вы получаете осенью, к весне уже устаревают.
Для примера: есть система Claude Code, которая сейчас считается наилучшей для создания кода. Осенью для того, чтобы хорошо писать код с помощью Claude Code, необходимо было грамотно заполнять файл agent.md. Сейчас этот файл уже заполнять не нужно. То есть правила создания кода с помощью LLM меняются каждый месяц.
Постоянно выходят новые модели. Сейчас, например, вышел ChatGPT 5.4 (на момент публикации статьи уже 5.5). Считается, что она лучшая с точки зрения создания кода. Она уже умеет управлять компьютером, она уже умеет многое. В ближайшее время, на Китайский Новый год, должна была выйти DeepSeek четвертая, которая по внутренним замерам превосходит ChatGPT и Claude Code.
Соответственно, для того чтобы идти в ногу со временем, нужно не просто бежать, а лететь на ракете, чтобы успевать за всем, что происходит.
Поэтому я не буду рассказывать вам конкретные методики. Я расскажу принципы, по которым строил свое решение, и, возможно, они будут вам полезны.
Не ждите, что в итоге вы возьмете решение и скажете: «Отлично, вот у нас есть решение для проведения код-ревью. Мы теперь его в своей компании запустим и будем использовать ближайшие 20 лет». В LLM и работе с ИИ это не так.
Да, в конце я покажу примеры. Решение выложено на GitHub, вы можете его скачать, запустить. Но, скорее всего, оно потребует доработки. И через полгода снова нужно будет делать какие-то изменения.
Особенности разработки в крупном бизнесе
Теперь про особенности разработки в крупном бизнесе.
Я работаю в крупной телеком-компании. Автоматизация на 1С у нас – это в первую очередь наша собственная розница: полторы тысячи магазинов. Соответственно, у нас порядка 100 000 чеков в день, и любая, даже небольшая ошибка может привести к тяжелым последствиям.
Поэтому у нас стандартный классический процесс разработки: бизнес-анализ, затем разработка, потом автотесты, нагрузочные тесты, регрессионные тесты и так далее. И, естественно, в процессе разработки у нас делается код-ревью.
Я хотел бы сказать, что разработка у нас с помощью LLM не ведется. Потому что все LLM, которые существуют, обучены в первую очередь на GitHub. 1С-кода там не очень много. Да, они умеют писать, но качество не очень.
Повторюсь, я возвращаюсь к тому дисклеймеру, который сказал в начале: может быть, через два месяца они будут писать идеально. А может быть, я с кем-нибудь встречусь, и меня через два часа убедят, что на самом деле с помощью LLM можно прекрасно писать и на 1С.
Но это не значит, что я не верю в написание кода. Продукт, про который я сейчас рассказываю, полностью написан с помощью LLM. Он полностью написан с помощью Codex. Я использую для разработки Codex, не Claude Code.
Я в код не заглядывал. Я, в принципе, ни одной строчки не написал. Продукт полностью написан с помощью LLM. На текущий момент LLM пишут код на языках программирования, отличных от 1С, например на Python или Java, на уровне, как я считаю, крепкого мидла.
Итак, как я сказал, процесс разработки включает в себя код-ревью. На текущий момент над крупнейшим нашим продуктом работает 20 разработчиков. Я сейчас не говорю про аналитиков и тестировщиков – именно 20 разработчиков. Из них четыре крепких сеньора, которые проводят код-ревью.
Соответственно, вместо того чтобы заниматься своими задачами, эти четыре разработчика вынуждены проверять код, который написали 16 других разработчиков. Во-первых, они занимаются не своими задачами. Во-вторых, практика показала, что не все разработчики любят заниматься код-ревью, многих это демотивирует.
Людям, которым проводят код-ревью и которые на этом обучаются, в большинстве случаев все нравится. А вот учить нравится не всем. Это одна из причин, почему мы решили использовать искусственный интеллект для проведения код-ревью.
Опыт применения LLM для анализа кода 1С
Возьмем код из какой-то типовой конфигурации. Я даже не помню, из какой именно. И попробуем написать обычный промт, с помощью которого мы поищем ошибки в этом коде.
То есть мы возьмем ChatGPT в глубоком рассуждающем режиме, и напишем простой промт: «Найди ошибки в данном коде. Выведи их строго в последовательности. Не галлюцинируй. Выведи 20 ошибок» – и так далее.
Она выведет какие-то ошибки. Здесь на самом деле не очень важно, какие именно ошибки она выведет, потому что суть этого изображения в том, что, когда вы задаете LLM некий промт, результат, который вы получите, будет зависеть от используемой модели, от используемого промта и, в конце концов, не знаю, от фазы Луны. То есть повторить результат будет очень сложно.
Это тот же самый запрос, тот же самый промт, который я задал в обычный ChatGPT 5, без рассуждающей модели. Видно, что результаты разные. И на самом деле те ошибки, которые нашел ChatGPT, если не считать варианты с отказом, не очень сложные и не очень проблемные. Нет четкого понимания, что это действительно ошибки.
Какие у нас есть ограничения LLM при проведении код-ревью?
Первое ограничение – отсутствие детерминируемости. Сколько раз вы спросили, столько разных вариантов и получили. Сегодня спросили: «Найди мне 10 ошибок» – он нашел 10 ошибок. Попросили найти 50 ошибок – он вам в маленьком кусочке найдет 50 ошибок. Возьмете процедуру на 10 строк и скажете LLM: «Найди мне в ней 50 ошибок» – она найдет. Она скажет, что у вас переменные неправильно названы, вы использовали не те буквы, надо большие, а не маленькие, и так далее.
К этому важно добавить, что галлюцинаций на самом деле практически нет. Если раньше LLM сильно галлюцинировали, сейчас они почти не галлюцинируют. Просто они находят те ошибки, которые с точки зрения разработчика ошибками не являются. Например, переменная из 50 букв – ну вроде бы не ошибка.
Второе ограничение – нечеткость. Мы не знаем, насколько ошибка критична. Вот он нашел 30 ошибок. А какие из них надо исправлять? На самом деле из этих 30 ошибок, скорее всего, одна, две или три важные, а все остальное – ерунда. Поэтому нам нужно четко определять, какие ошибки критичны, а какие критичными не являются.
И наконец третье ограничение – непрозрачность. У нас нет информации о том, откуда LLM взяла сведения об ошибке. У нас нет ссылок на документацию.
Можно попробовать задать промт, в котором мы напишем искусственному интеллекту: «Предоставь информацию о том, откуда ты взял сведения об ошибке». Но в этом случае мы гарантированно получим галлюцинации. Он начнет придумывать документацию.
Гибридный подход на основе норм и LLM
Как мы придумали решить эту проблему?
Для того чтобы проводить код-ревью с помощью LLM, мы решили разработать список правил, по которым это код-ревью будет выполняться.
Что мы делаем? У нас есть стандарты разработки, большие книги, из которых можно выделить отдельные части, которые четко являются правилами написания кода. Например, процедура должна начинаться с большой буквы, транзакция всегда должна закрываться: начали транзакцию – завершили транзакцию, в запросах нельзя разыменовывать поля через точку. И другие подобные вещи.
Мы взяли правила, которые в дальнейшем будем использовать при проведении код-ревью.
Откуда взять эти правила? Первый, самый очевидный вариант – посадить разработчиков, которые должны будут эти правила написать. Но это, во-первых, трудозатратно. Во-вторых, таких разработчиков, к сожалению, у меня нет: я не могу посадить людей на два месяца писать правила. И в-третьих, это, скорее всего, опять же будет демотивировать людей, которым придется этим заниматься.
Проще всего взять документацию и, используя ту же самую LLM, попросить ее написать эти правила. Что мы и сделали.
В результате у нас получилось порядка полутора тысяч различных правил. Среди них есть и сложные, и простые. Главное, что их много, и они охватывают достаточно широкий спектр проблем, которые могут возникать в коде.
Чтобы получить эти правила, я брал стандарты разработки с сайта, книги по языку запросов и официальную документацию.
Что мы делаем дальше для того, чтобы провести код-ревью? Процесс разбивается на несколько частей.
Скорее всего, те кто делают код-ревью, используют SonarQube, то есть так называемый статический анализатор. В системе, которую я разрабатывал, статический анализатор тоже существует. Это самая простая часть. Из этих полутора тысяч правил есть вещи, которые мы можем определить статически, без использования LLM. Например, та же самая история с «начать транзакцию» и «завершить транзакцию». Или такие вещи, как использование больших букв в запросах, и прочее.
То есть для тех вещей, по которым не нужна LLM, используется статический анализатор.
В чем плюс решения, которое у нас есть? Правило для статического анализатора мы можем писать на лету. Когда мы запускали эту систему, ко мне пришли разработчики и сказали: «У нас есть у некоторых разработчиков фишка: они в конце строки добавляют пустые табы». Эти табы не видны, но когда запускаешь сравнение и объединение, это становится проблемой, потому что вроде бы строки изменены. Мы добавили это в статический анализатор, и теперь такие проблемы точно так же ловятся при нашем код-ревью.
После того как проведен статический анализ, мы выбираем из существующих норм те, которые теоретически могут подойти.
Как это работает? Есть код, он разбивается не на слова, а на токены. У нас есть код, разбитый на токены, и есть правила, которые тоже разбиты на токены.
Что это означает? Например, если у нас есть в коде слово «если», мы выберем все нормы, в которых есть правила, связанные с условиями. Если у нас есть слово «цикл», мы выбираем все правила, связанные с циклами: не использовать вложенные циклы, внутри цикла не использовать, например, «сообщить», и все остальное, что связано с циклами.
Таким образом, от полутора тысяч норм, о которых мы говорили, остается примерно 100–200.
На третьем шаге мы отправляем те нормы, которые у нас получились, в LLM вместе с кодом и говорим: «Найди нормы, которые, по твоему мнению, могут быть нарушены». То есть мы не ищем проблемные места. Мы ищем правила, которые теоретически могут быть нарушены.
Соответственно, количество норм у нас еще сокращается. Если на первом этапе было полторы тысячи, на втором этапе остается 100–150, то на третьем этапе остается, предположим, 30–40.
На четвертом этапе начинается основной этап: мы отправляем код, отправляем нормы и просим LLM найти проблемы, то есть те ошибки, которые совершил разработчик. И вот здесь мы уже получаем информацию, которая нам наиболее интересна: ошибка обнаружена, и самое главное – есть ссылка на документацию, почему это ошибка и почему она совершена именно здесь.
Еще один важный момент – мы получаем критичность. Потому что критичность проблем определяет не LLM, не искусственный интеллект говорит, что эта ошибка критична, а эта нет. Критичность мы задали сами, когда прописывали нормы по умолчанию.
Следующий этап, пятый: мы просим LLM найти дополнительные нормы, которые здесь могут быть нарушены.
Это очень спорный момент, потому что как раз здесь LLM может галлюцинировать. Но нам это необходимо на случай, если среди полутора тысяч норм, которые у нас есть, каких-то вещей не хватает.
И наконец шестой этап – это уже непосредственно работа ревьюера, который просматривает код.
Итак, мы получили результат статического анализатора. Мы получили нарушения норм со ссылками на документацию, в которых мы уверены. Мы получили список норм, которые могут быть нарушены, но не точно. И наконец – ручной анализ.
Вот примеры анализа нарушений в запросах, которые LLM нашла при анализе конкретного запроса. Например, запрещено разыменовывать поля через точку. Для временных таблиц обязательно нужны индексы. Есть замечания по сортировке и другие вещи.
Некоторые вещи спорные. Например, для индексов имеется в виду, что они нужны для таблиц. Если мы делаем запрос к таблице, в которой пять строк, понятно, что индексы не нужны. Но LLM не знает, какие у нас массивы, какие масштабы запроса, какие масштабы таблиц, поэтому предполагается, что она будет это использовать.
В любом случае это можно докрутить. У нас в планах передавать не только код, но еще и объемы таблиц, чтобы результат возвращался более верный.
Безопасность и контроль при использовании LLM
Безопасность в данном случае разделена на две части.
Во-первых, зачастую разработчики любят писать в коде информацию, которая не должна никуда уйти. Бывают пароли, бывают персональные данные, бывают комментарии, в которых описывается алгоритм, обход какого-то бага или какой-то фичи.
Для решения этой проблемы мы поступаем следующим образом: все строковые переменные и комментарии полностью удаляем. Это ухудшает результат, но в целом опыт показал, что влияние на итоговый результат не велико.
Вторая проблема – сам факт передачи кода в LLM. Я, к сожалению, общался со многими, и никто не может четко сказать, готов ли он передавать свой код в стороннюю LLM: например, в американский ChatGPT или в китайский DeepSeek. Потому что не очень ясно, к каким последствиям это может привести.
Понятно, что персональные данные никто передавать не будет. Но можно ли передавать код? Этот риск можно решить либо использованием локальных моделей – хотя понятно, что локальные модели работают хуже, – либо развертыванием DeepSeek, например, на своих мощностях. Но это, конечно, будет очень дорого.
Ну и конечно, мы логируем все действия.
Текущее состояние проекта и дорожная карта развития
Теперь про текущее состояние сервиса. Об этом важно рассказать отдельно.
Если бы речь шла в первую очередь про ИТ-директоров, их бы, конечно, интересовало, сколько денег мы сэкономили, сколько людей можно было бы высвободить после внедрения этого процесса, сколько планируем заработать и так далее. То есть какие-то цифры: как было и как стало.
Давайте честно: на самом деле на текущий момент в моей крупной телеком-компании эта штука не запущена, потому что мы споткнулись об информационную безопасность, которая запретила передавать код в сторонние модели.
Поэтому сейчас я нахожусь на этапе выбора локальных моделей. У нас есть несколько локальных моделей, и мне необходимо для запуска протестировать, какая из них будет работать лучше всего.
Так что сказать, что все уже запущено и мы получаем прекрасные результаты, я не могу. Зато честно.
Дальнейшее развитие – это, во-первых, развитие норм. Повторюсь, те полторы тысячи норм, которые уже существуют, – это не конечный список. Он будет развиваться.
И одна из важных вещей системы – это то, что в эти нормы можно добавлять новые правила. В ролевой модели, которую мы создали, есть роль пользователя: он вводит код и получает результат. А есть роль учителя: это тот, кто проверяет, насколько норма корректна, насколько ее можно применять, и может создавать свои нормы.
То есть сейчас самое важное – это развитие дополнительных норм.
Ну и, естественно, запуск сервиса в production, который мы планируем в компании. Как я уже сказал, для этого мне необходимо протестировать локальные модели.
Еще одно направление – интеграция. У меня в голове есть картинка, как это должно работать. После того как разработчик пометил тикет в Jira как выполненный – ну или в какой-то вашей системе, в которой вы работаете с тикетами, – код автоматически отправляется в систему code-review. И буквально через 2–3 минуты разработчик получает результат проверки своего кода, который уже может поправить. То есть в теории это должно работать в полностью автоматическом режиме.
Загружайте, запускайте, пробуйте
Как попробовать? Как посмотреть?
https://github.com/Repich/CodeReview
Код лежит на GitHub, пожалуйста, заходите.
Те, кому самостоятельно разбираться не хочется, могут зайти по ссылке https://cdrw.tech: там развернут этот сервис, туда можно вставить код и получить результат. Написано, что это платно, но нет, это бесплатно. На самом деле там просто есть ограничение по количеству вызовов, потому что используется платный DeepSeek. И для того чтобы этот сервис не заспамили платными запросами, количество вызовов в день ограничено, по-моему, десятью.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт