Аудит кода с помощью ИИ
Jun. 1st, 2026 09:41 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
green_frВ начале мая у меня в ленте пробежали подряд два поста. Сначала avva написал о разные уровнях использования программистами ИИ. Я однозначно был где-то на уровне № 1 (использует ИИ для поиска документации и примеров использования), с очень небольшим началом уровня № 2 (генерация кода). С интересом прочитал про все остальные уровни. Интересная для меня тема: в каких проектах я готов отдать контроль над кодом другим людям / программам, а в каких я до сих пор предпочитаю чётко понимать смысл каждого пробела, иначе мне некомфортно. До сих пор мне казалось, что у меня всё в режиме «контрол-фрика», но нет, за последние пару лет появилось какое-то количество мелких скриптов, которые я использую, сгенерив и даже не прочитав. Но тут вот задумался о целесообразности более активного перехода на № 2, как минимум давать свой код ИИ на критику.
Примерно в это же время были новости про Anthropic, то ли сделавший, то ли просто заявивший о какой-то совсем мощной, а потому секретной версией ИИ, которая якобы находит баги чуть ли не во всём. И буквально на следующий день у меня в ленте пост про красивую дыру в OpenSSH — коде, который был в открытом доступе 15 лет, который однозначно проверяли тысячи человек, и в котором была дыра размером с паровоз, позволявшая любому пользователю получить права root’а.
На следующий же день я попробовал уровень № 2. Взял достаточно случайный кусок кода нашей самой большой программы (для людей не в тесе: моделирование страхового бизнеса; для людей в теме: реализация стандартной формулы Solvabilité II актива и пассива Vie). Не совсем случайный кусок: я взял то, в чём точно нет никакой конфиденциальной информации, и то, что имеет смысл изолированно от всего остального — класс управления таблицами смертности.
Сначала запустил стандартный рабочий Copilot. Вот, говорю, есть кусок кода на MatLab, что скажешь по его поводу? Он отвечает: боже мой, какой прекрасный код, и какой ты молодец, что спросил моё мнение о нём! После чего выдаёт 5 пунктов, что в нём не так — 4 предложения улучшения, а 1 — конкретный баг. Точнее, риск бага: сейчас всё работает, но он описал, при каких обстоятельствах оно навернётся, причём даже не предупредив, т.е. без сообщения об ошибке. Вау. Ну и под конец: хозяин, я ещё умею кофе варить, под дудку плясать, я могу тебе переписать весь этот код, пересказать пару релевантных глав из учебника по программированию — только не бросай, только не бросай, только не бросай...
Потом спросил то же самое у специализированного ChatGPT, натренированного MathWorks именно на работу с кодом MatLab. Этот ведёт себя слегка приличнее: всё равно начинает с комплиментов, но не такие топорных. У него было 8 предложений по улучшению кода (те же самые + 4 новых), и та же самая бага. Ну и закончил он не попыткой любой ценой оставить меня в чате, а рекламой нового ToolBox, который умеет делать подобные вещи прямо вот из IDE MatLab.
Сделал презентацию начальнику, предложил запустить проект аудита всего нашего кода.
Тут нужно отдельно отметить, потому что подобные тексты обычно понимают люди, работающие программистами, что нет, у нас отдел не программистов. Вообще вот не программистов. Но код люди пишут. На коленке. Последний анекдот: в прошлом году уходил парень, занимавшийся скриптами SAS — вытаскивает данные из разных источников, определённым образом форматирует, готовит новые таблицы для последующего использования и т.п. Он передал дела другому парню и ушёл. Шеф спрашивает у принявшего дела человека: ты всё принял? да! ничего не забыли? нет! а сколько у нас вообще подобных скриптов? а хрен его знает... Для каждой задачи есть какие-то процедуры, по большей части в устной форме. Где-то в недрах сетевых дисков могут быть спрятаны какие-то программы. Контроль версий осуществляется копированием каждой программы в новую папку при каждом новом использовании. То есть, понятно, что аудит нужен. Но начинать нужно даже не с аудита, а хотя бы с инвентаризации.
Тем не менее, запустили проект. Я скормил Copilot ещё один проект, в этот раз на VBA (расчёт PM для ренты). Я его унаследовал два года назад, но в прошлом году очень серьёзно перелопатил. Там всего 3 функции, но расчёт был предусмотрен только годовой, а считали мы каждый триместр. До сих пор мы каждый триместр делали расчёт как годовой, а потом довольно хитро сглаживали результат, чтобы получался аналог триместрового. Я же сделал честный расчёт по триместрам. Поскольку это смена методологии расчёта официального результата, то я целый год вёл двойной расчёт, контролируя и объясняя отклонения нового метода относительно старого. Сделал отдельный файл с поэтапным разбором двух методов расчёта. Презентацию на 20 страниц со схемами. Два часа представлял команде, разбирали по кусочкам, утвердили. То есть, как бы не должно быть никаких проблем. Даю Copilot код, задаю ему другой вопрос типа «как всё это свести к одной функции?» — он говорит, что это очень интересный вопрос, и вот какой у него есть ответ. И да, кстати, видел ли я огромную багу в этой функции? И выдаёт багу. Упс.
Бага идиотская: унаследованный код начинался типа с «if sexe = femme then => код, который использует женскую таблицу смертности, else => тот же самый код, который использует мужскую таблицу смертности». Я ещё подумал в своё время, что надо бы заменить на просто if, который читает нужную таблицу, а потом общий код. Но решил не отвлекаться, сначала — дело, потом — красота. Ну и понятно, что в какой-то момент забыл скопировать последнюю версию от женщин к мужчинам. А все мои test cases были на женщинах. Позор, короче.
Прошу Copilot сгенерить мне test cases, покрывающие всё множество случаев, чтобы не повторить этой ошибки. Он генерит блок A — это то, что не должно поменяться в процессе исправления кода (test de non-régression). Блок B — строки, которые должны поменяться для мужчин, и не должны меняться для женщин (тест смены функционала). И да, кстати, говорит, вот тебе ещё блок C на проверку граничных условий. А то ты мне дал только код, я не вижу твоих данных, а выход за границы массивов — это типичная ошибка, давай и её проверим тоже? Очевидно, весь блок C вылетает к чёртовой матери с ошибками. Упс.
Тут тоже смешно. Во Франции стандартная таблица смертности — это TGHF-05. «T» — как «table», «G» — как «génération» (поколение), «HF» — «homme / femme» (м/ж), а самое интересное это «05» — таблицу делали в 2000-х, и у неё предусмотрены поколения от родившихся в 1900 году до родившихся в 2005 году. Напоминаю, что мы уже в 2026. Мой проект для контракта «рента вдов» — если рабочего убило на стройке, его вдова получает пожизненную пенсию (формально бывает и наоборот, когда женщину убило на стройке, и её муж получает пенсию, но это настолько редкие случаи, что в названии сохранили женский род слова «вдова»). И постепенно в портфеле появляются родившиеся после 2005 года. Почему код продолжал работать? Потому что мой предшественник, обнаружив первый такой случай, тупо взял таблицу смертности женщин и скопировал последнюю строчку 10 раз — теперь женская таблица до 2015 года. В принципе, почему бы и нет, тоже метод.
Резюмируя: я в восторге. Лично мои выводы:
* Однозначно нужно дать весь код на аудит. Даже если кажется, что «ну здесь-то точно никаких проблем быть не может».
* Однозначно нужно анализировать все предложения ИИ. Не все они полезны, уж тем более не все обязательны. Отбор за нами (я всё ещё на уровне № 2, и мне здесь пока комфортно).
* Однозначно читать весь текст, который ИИ выдаёт, там могут быть ответы на вопросы, которые ты и не задавал, но которые надо было бы задать. И это просто фантастика.
* Для каждого изменения, которое решил сделать, начинать с генерации test cases. И аккуратно следить за тем, как меняются значения при каждом изменении. ИИ даже пытается помогать в этом, но конкретно в моём случае он иногда ошибался (исправление приводило к увеличению степени одного из множителей — значит, говорит ИИ, результат должен увеличиться; но это была степень числа < 1, поэтому на самом деле он уменьшался).
* Пока непонятно, есть ли на моём уровне разница между разными версиями ИИ. По крайней мере между бесплатным ChatGPT + MathWorks и платным Copilot я радикальной разницы не увидел. В планах попробовать бесплатный Claude. Но в любом случае, для меня результат есть и на самых базовых моделях.
* Надо попробовать сдавать на аудит код сразу с данными. Тут явно будет проблема конфиденциальности, и над ней надо будет ещё думать. Впрочем, про конфиденциальность кода тоже надо думать — у нас есть какие-то кусочки, публикацию которых начальство запрещало прямым текстом (типа, наше know how).
* Очевидный психологический барьер, когда ты вынужден анализировать баги, которые сделал ты же сам. Особенно, если учесть, что ты не можешь просто тихонечко исправить их :-)
А ещё, оказалось, что читать и понимать предложения ИИ — это тоже умение. Коллега в рамках нашего проекта скормил какую-то свою функцию, возвращается ко мне, говорит — всё ок, ИИ ничего не нашёл. Сказал, что код прекрасный. Ну что же, говорю, отрицательный результат — это тоже результат. Покажи, как ты спрашивал, и что конкретно написал ИИ? Показывает: ответ Copilot начинается с «боже мой, какой прекрасный код», после чего дюжина конкретных предложений, как его улучшить, потому что на самом деле код, конечно же, говно. Предложения коллега даже прочитал, но комплименты настолько затмили ему глаза, что у него в голове осталось только «код прекрасен».
avva написал о разные уровнях использования программистами ИИ. Я однозначно был где-то на уровне № 1 (использует ИИ для поиска документации и примеров использования), с очень небольшим началом уровня № 2 (генерация кода). С интересом прочитал про все остальные уровни. Интересная для меня тема: в каких проектах я готов отдать контроль над кодом другим людям / программам, а в каких я до сих пор предпочитаю чётко понимать смысл каждого пробела, иначе мне некомфортно. До сих пор мне казалось, что у меня всё в режиме «контрол-фрика», но нет, за последние пару лет появилось какое-то количество мелких скриптов, которые я использую, сгенерив и даже не прочитав. Но тут вот задумался о целесообразности более активного перехода на № 2, как минимум давать свой код ИИ на критику.Примерно в это же время были новости про Anthropic, то ли сделавший, то ли просто заявивший о какой-то совсем мощной, а потому секретной версией ИИ, которая якобы находит баги чуть ли не во всём. И буквально на следующий день у меня в ленте пост
На следующий же день я попробовал уровень № 2. Взял достаточно случайный кусок кода нашей самой большой программы (для людей не в тесе: моделирование страхового бизнеса; для людей в теме: реализация стандартной формулы Solvabilité II актива и пассива Vie). Не совсем случайный кусок: я взял то, в чём точно нет никакой конфиденциальной информации, и то, что имеет смысл изолированно от всего остального — класс управления таблицами смертности.
Сначала запустил стандартный рабочий Copilot. Вот, говорю, есть кусок кода на MatLab, что скажешь по его поводу? Он отвечает: боже мой, какой прекрасный код, и какой ты молодец, что спросил моё мнение о нём! После чего выдаёт 5 пунктов, что в нём не так — 4 предложения улучшения, а 1 — конкретный баг. Точнее, риск бага: сейчас всё работает, но он описал, при каких обстоятельствах оно навернётся, причём даже не предупредив, т.е. без сообщения об ошибке. Вау. Ну и под конец: хозяин, я ещё умею кофе варить, под дудку плясать, я могу тебе переписать весь этот код, пересказать пару релевантных глав из учебника по программированию — только не бросай, только не бросай, только не бросай...
Потом спросил то же самое у специализированного ChatGPT, натренированного MathWorks именно на работу с кодом MatLab. Этот ведёт себя слегка приличнее: всё равно начинает с комплиментов, но не такие топорных. У него было 8 предложений по улучшению кода (те же самые + 4 новых), и та же самая бага. Ну и закончил он не попыткой любой ценой оставить меня в чате, а рекламой нового ToolBox, который умеет делать подобные вещи прямо вот из IDE MatLab.
Сделал презентацию начальнику, предложил запустить проект аудита всего нашего кода.
Тут нужно отдельно отметить, потому что подобные тексты обычно понимают люди, работающие программистами, что нет, у нас отдел не программистов. Вообще вот не программистов. Но код люди пишут. На коленке. Последний анекдот: в прошлом году уходил парень, занимавшийся скриптами SAS — вытаскивает данные из разных источников, определённым образом форматирует, готовит новые таблицы для последующего использования и т.п. Он передал дела другому парню и ушёл. Шеф спрашивает у принявшего дела человека: ты всё принял? да! ничего не забыли? нет! а сколько у нас вообще подобных скриптов? а хрен его знает... Для каждой задачи есть какие-то процедуры, по большей части в устной форме. Где-то в недрах сетевых дисков могут быть спрятаны какие-то программы. Контроль версий осуществляется копированием каждой программы в новую папку при каждом новом использовании. То есть, понятно, что аудит нужен. Но начинать нужно даже не с аудита, а хотя бы с инвентаризации.
Тем не менее, запустили проект. Я скормил Copilot ещё один проект, в этот раз на VBA (расчёт PM для ренты). Я его унаследовал два года назад, но в прошлом году очень серьёзно перелопатил. Там всего 3 функции, но расчёт был предусмотрен только годовой, а считали мы каждый триместр. До сих пор мы каждый триместр делали расчёт как годовой, а потом довольно хитро сглаживали результат, чтобы получался аналог триместрового. Я же сделал честный расчёт по триместрам. Поскольку это смена методологии расчёта официального результата, то я целый год вёл двойной расчёт, контролируя и объясняя отклонения нового метода относительно старого. Сделал отдельный файл с поэтапным разбором двух методов расчёта. Презентацию на 20 страниц со схемами. Два часа представлял команде, разбирали по кусочкам, утвердили. То есть, как бы не должно быть никаких проблем. Даю Copilot код, задаю ему другой вопрос типа «как всё это свести к одной функции?» — он говорит, что это очень интересный вопрос, и вот какой у него есть ответ. И да, кстати, видел ли я огромную багу в этой функции? И выдаёт багу. Упс.
Бага идиотская: унаследованный код начинался типа с «if sexe = femme then => код, который использует женскую таблицу смертности, else => тот же самый код, который использует мужскую таблицу смертности». Я ещё подумал в своё время, что надо бы заменить на просто if, который читает нужную таблицу, а потом общий код. Но решил не отвлекаться, сначала — дело, потом — красота. Ну и понятно, что в какой-то момент забыл скопировать последнюю версию от женщин к мужчинам. А все мои test cases были на женщинах. Позор, короче.
Прошу Copilot сгенерить мне test cases, покрывающие всё множество случаев, чтобы не повторить этой ошибки. Он генерит блок A — это то, что не должно поменяться в процессе исправления кода (test de non-régression). Блок B — строки, которые должны поменяться для мужчин, и не должны меняться для женщин (тест смены функционала). И да, кстати, говорит, вот тебе ещё блок C на проверку граничных условий. А то ты мне дал только код, я не вижу твоих данных, а выход за границы массивов — это типичная ошибка, давай и её проверим тоже? Очевидно, весь блок C вылетает к чёртовой матери с ошибками. Упс.
Тут тоже смешно. Во Франции стандартная таблица смертности — это TGHF-05. «T» — как «table», «G» — как «génération» (поколение), «HF» — «homme / femme» (м/ж), а самое интересное это «05» — таблицу делали в 2000-х, и у неё предусмотрены поколения от родившихся в 1900 году до родившихся в 2005 году. Напоминаю, что мы уже в 2026. Мой проект для контракта «рента вдов» — если рабочего убило на стройке, его вдова получает пожизненную пенсию (формально бывает и наоборот, когда женщину убило на стройке, и её муж получает пенсию, но это настолько редкие случаи, что в названии сохранили женский род слова «вдова»). И постепенно в портфеле появляются родившиеся после 2005 года. Почему код продолжал работать? Потому что мой предшественник, обнаружив первый такой случай, тупо взял таблицу смертности женщин и скопировал последнюю строчку 10 раз — теперь женская таблица до 2015 года. В принципе, почему бы и нет, тоже метод.
Резюмируя: я в восторге. Лично мои выводы:
* Однозначно нужно дать весь код на аудит. Даже если кажется, что «ну здесь-то точно никаких проблем быть не может».
* Однозначно нужно анализировать все предложения ИИ. Не все они полезны, уж тем более не все обязательны. Отбор за нами (я всё ещё на уровне № 2, и мне здесь пока комфортно).
* Однозначно читать весь текст, который ИИ выдаёт, там могут быть ответы на вопросы, которые ты и не задавал, но которые надо было бы задать. И это просто фантастика.
* Для каждого изменения, которое решил сделать, начинать с генерации test cases. И аккуратно следить за тем, как меняются значения при каждом изменении. ИИ даже пытается помогать в этом, но конкретно в моём случае он иногда ошибался (исправление приводило к увеличению степени одного из множителей — значит, говорит ИИ, результат должен увеличиться; но это была степень числа < 1, поэтому на самом деле он уменьшался).
* Пока непонятно, есть ли на моём уровне разница между разными версиями ИИ. По крайней мере между бесплатным ChatGPT + MathWorks и платным Copilot я радикальной разницы не увидел. В планах попробовать бесплатный Claude. Но в любом случае, для меня результат есть и на самых базовых моделях.
* Надо попробовать сдавать на аудит код сразу с данными. Тут явно будет проблема конфиденциальности, и над ней надо будет ещё думать. Впрочем, про конфиденциальность кода тоже надо думать — у нас есть какие-то кусочки, публикацию которых начальство запрещало прямым текстом (типа, наше know how).
* Очевидный психологический барьер, когда ты вынужден анализировать баги, которые сделал ты же сам. Особенно, если учесть, что ты не можешь просто тихонечко исправить их :-)
А ещё, оказалось, что читать и понимать предложения ИИ — это тоже умение. Коллега в рамках нашего проекта скормил какую-то свою функцию, возвращается ко мне, говорит — всё ок, ИИ ничего не нашёл. Сказал, что код прекрасный. Ну что же, говорю, отрицательный результат — это тоже результат. Покажи, как ты спрашивал, и что конкретно написал ИИ? Показывает: ответ Copilot начинается с «боже мой, какой прекрасный код», после чего дюжина конкретных предложений, как его улучшить, потому что на самом деле код, конечно же, говно. Предложения коллега даже прочитал, но комплименты настолько затмили ему глаза, что у него в голове осталось только «код прекрасен».
no subject
Date: 2026-06-01 08:34 am (UTC)Вроде можно попросить обойтись без комплиментов? Или потеряется половина удовольствия?
no subject
Date: 2026-06-01 08:49 am (UTC)no subject
Date: 2026-06-01 04:51 pm (UTC)Просить обходиться без комплиментов в начале каждой сессии?
no subject
Date: 2026-06-01 08:42 am (UTC)no subject
Date: 2026-06-01 08:51 am (UTC)no subject
Date: 2026-06-01 10:23 am (UTC)no subject
Date: 2026-06-01 11:56 am (UTC)no subject
Date: 2026-06-01 11:28 am (UTC)Именно такие тесты LLM любит добавлять и потом рапортовать, что они проходят. По-моему это cargo science. Тест проверяет один if, потому что положено добавить тест и тест должен проходить. Зачем положено добавлять тесты, роботу уже всё равно.
Человеческий тест должен сравнивать новый результат с ожидаемым значением, а не только убеждаться в том, что новый результат отличается от старого.
no subject
Date: 2026-06-01 12:00 pm (UTC)А то, что результат нужно сравнивать с просчитанным ручками - это да, конечно. Это то, что я делал в своём файле для валидации новой методологии (где я облажался, забыв протестировать мужчин). То есть конкретно эта схема была исключительно для идентификации того, что поменялось, а не для валидации самого изменения. Не знаю, как по-английски, но наверняка те же корни, по-французски это test de non-régression, проверка того, что улучшение в одном месте ничего не ухудшило в другом.
no subject
Date: 2026-06-01 04:56 pm (UTC)Regression test это другое. Например, у вас есть функция f(x), которая возвращает квадратный корень, и вы хотите чтоб она возвращала не только квадратный, но и кубический, в зависимости от параметра. Вы сначала делаете regression test, который вызывает функцию f(4) и сравнивает результат с 2, вызывает f(9) и сравнивает результат с 3 и так далее. Потом вы добавляете флаг и проверяете, что f(4, false) по-прежнему возвращает 2, f(9, false) возвращает 3 и так далее.
Отдельными тестами покрываете новую функциональность. Что f(8, true) возвращает 2, f(-27, true) возвращает -3 и так далее.
LLM же вместо этого добавляет тест, который проверяет, что f(4, true) возвращает не то же самое, что f(4, false). Что именно возвращает, неважно.
no subject
Date: 2026-06-01 04:50 pm (UTC)Так Claude Code именно такие тесты, обычно, пишет.
Почему вы такие тесты называете "человеческими"?
no subject
Date: 2026-06-01 04:59 pm (UTC)Потому что Claude Code часто пишет тесты нечеловеческие. Которые проверяют то, что проверять не надо. А что надо — не проверяют.
no subject
Date: 2026-06-01 05:41 pm (UTC)no subject
Date: 2026-06-01 04:46 pm (UTC)У подавляющего большинства людей (90%+) - серьезные проблемы с восприятием критической обратной связи. Вне зависимости от того, кто эту обратную связь даёт: люди или ИИ.
no subject
Date: 2026-06-01 04:53 pm (UTC)Как это повлияло на практические результаты работы программы?
Клиентам-мужчинам продали слишком дешевую страховку?
no subject
Date: 2026-06-01 05:34 pm (UTC)О, слушай, ну это же еще одна великолепная иллюстрация к разнице культур! Не знаю, читал ли ты The Culture Map by Erin Meyer (если нет, то настойчиво рекомендую, https://erinmeyer.com/books/the-culture-map/). Одна из осей, по которым она располагает разные культуры, это то, как в них принято давать отрицательную оценку (direct vs. indirect negative feedback). Франция и США здесь достаточно сильно расходятся (США где-то посредине, Франция сильно в сторону direct; а на концах оси - с одной стороны Россия и Израиль, а с другой стороны Япония).
Она там приводит пример, когда французский менеджер (менеджерша? :)) среднего звена перешла в американский офис. После того, как у нее был performance review (как это по-русски?), автор связался с ней и ее начальником. Она: "все великолепно, начальник меня очень хвалил, я никогда такие замечательные оценки еще не получала!". Начальник: "как-то средненько, есть достижения, но много проблем, и главное, я пытаюсь ей указать на проблемы, а она не слушает...". А все дело в том, что по американской традиции, надо перед тем, как критиковать, сделать минимум три комплимента (вроде сейчас это уже не совсем так, но тем не менее). А во Франции о проблемах принято говорить без этих экивоков. В результате, услышав в начале беседы "ты замечательно делаешь это, это и это", она уже больше ничего не слушала.
Не получается ли, что ИИ, сделанный в США и натасканный на американские стандарты, тоже начинает с похвал, а ваш сотрудник, привыкший, что о проблемах говорят прямо и сразу, на этих похвалах и останавливается?