Comments 56
Кардиостимулятор похожий на кардиостимулятор себе поставите ?
Я в статье упомянул, что вещи, связанные с безопасностью все еще важны. Если воспользоваться вашей аналогией, то очки, которые работают, как очки, я бы себе взял.
Можно еще такой мыслительный эксперимент примерить на себя. Вы бы купили машину с двигателем, который работает как двигатель? Точнее можете допустить такую ситуацию на рынке авто, что существует компания, инженеры которой сами не делают двигатель, а лигь проверяют, что он работает, как двигатель, не взрывается, не течет и вообще по работе не отличается от двигателя, спроектированного вручную?
Нет, я не купил бы.
Яб в нее не сел, даже если бы ее купил кто-то еще и была такая возможность.
Я слишком часто видел некоторое дерьмо, при том, что все тесты были зеленые.
Если вам всё равно есть ли ошибки, может проще этот код вообще не писать ? Зачем он нужен ?
инженеры которой сами не делают двигатель, а лигь проверяют, что он работает, как двигатель, не взрывается, не течет и вообще по работе не отличается от двигателя, спроектированного вручную?
А принципиально он ничем и не отличается. Как "вручную" спроектировали двигатель?
Как вообще работает "наука"?
Придумывается теория, проводится куча экспериментов, теория признается работающей, при этом она может не во всех экспериментах работать (ньютоновская физика та же).
Замените слово "теория" на двигатель и ... и вот, приехали. Никто понятия не имеет как что работает, но все полагаются на выводы сделанные из кучи тестов. Можно с умным видом говорить про е=мц-квадрат и вот это всё, но опять же, это не более чем что-то подтвержденное ограниченном количеством тестов и объединенное в более общую формулу.
Всё равно как прийти в казино, наткнуться на шарик выпадающий на красное 1000 раз подряд и сделать теорию о том, что выпадают только красное, провести эксперимент еще 10к раз и снова получить красное и принять как факт, что выпадает только красное. Возможна такая ситуация? По терверу возможна. S - наука:)
Так может нам теперь и не нужно делать ревью ИИ кода в большинстве случаев и более внимательно относится к архитектуре и тестирванию? Я об этом в статье
Так может нам теперь и вообще не нужно думать, критически мыслить, анализировать, выстраивать различные математические модели в голове и в принципе рассуждать? Зачем, ведь ИИ делает это всё гораздо быстрее, обладая всеми возможными информационными ресурсами людей... Смысл тогда вообще что-либо делать? ИИ придумает идею, придумает её архитектуру, придумает к ней тесты, придумает как её сделать и сделает, ИИ выпустит продукт, наберёт команду из других ИИ, создаст скрипт и будет делегировать работу суб-агентам, ИИ будет торговать акциями на бирже, ИИ будет указывать людям что им делать (он ведь знает это лучше, чем сами люди) и как вообще жить.
ИИ...ИИ..ИИ..ИИ..ИИ..ИИ.. и только ИИ. Ничего кроме ИИ. Одно ИИ. Везде ИИ.... Даже там где его нет (о ужас) скоро будет только ИИ. Один сплошной ИИ...
Думаю, рано или поздно, человечество в принципе целиком и полностью будет поглощено одной единственной темой (учитывая мировые тенденции - 100% гарантия) - искусственный интеллект (ИИ). И ничего кроме не останется... даже думать самому будет запрещено.
В целом, Ваша статья не несёт ничего нового... И так понятно что везде будет ИИ и что не нужно уже ничего делать. Забыли добавить, разве что, что и проектировать, и тесты писать, и идеи придумывать тоже не надо. Можно ведь оценивать результат по деньгам - вот сделал ИИ проект, принёс прибыль и значит всё хорошо. А если нет - значит плохо... Вот и всё. А то мелочитесь... архитектуру и тестирование нам, людям, оставить. Зачем, когда ИИ всё это уже делает? Особенно передовые модели. Всё теперь сводится чисто к экономической составляющей. Чем больше разнообразного мусора (который обязательно будут хавать), тем лучше. Главное чтобы генерацию этого мусора самому возглавлять, иначе будущая экономика тебя съест :)
А через день после покупки машина отказалась заводиться. Вы приезжаете в официальный сервис по гарантии, а там разводят руками - нужно двигатель менять, у нас нет такого оборудования чтобы чинить его. - Но вы же дилер этих машин! - Понимаете, каждый двигатель проектируется на основе генератора случайных чисел, и у каждой машины он индивидуален. У этой вот что вы купили - есть поршни, а другая такая же - там внутри что-то бултыхается, подозреваем что он ротационный. А вот у нас в ремонте полюбуйтесь - стоит машина со смешанным циклом, мы уже два месяца чешем репу, как оно должно работать. Вроде бы ДВС, но зачем там баллон с азотом и огромный теплообменник...может стирлинг.. Вот еще машинка стоит. Вроде бы все работает но масло жрет. Это бы ладно, но двигатель неразборный! Он отливается целиком на заводе. А вот у этого авто вроде все по классическим стандартам, разобрали, надо кольца менять. Но размеры колец нестандартные, делают по спецзаказу, ну стоит уже месяцев девять, что мы можем тут поделать, если нет запчастей?
И клиент такой - а нахрена ж ваш сервис нужен, если вы ничего сделать не можете? а ему в ответ - Поглядите пункт такой то: в случае поломки ИИ-проектированного двигателя ответственность несет сервис ЕСЛИ у него есть компетенции и оборудования для ремонта. В противном случае все издержки и риски перекладываются на пользователя.
Вы бы купили такой автомобиль?
Вы, будучи дилером продали бы такой автомобиль?
А самолетом разработанным кем попало без нормального ревью кода полетите?
https://habr.com/ru/articles/458224
В любом текущем проекте больше 90% кода который создатель проекта не проверял, подключаемые библиотеки, копипаста с предыдущих проектов, код от вчерашних джунов.
5 минут гугления и Вы найдете кучу проблем (в т.ч. с безопасностью) порожденных надеждой на либы, пакеты и вот это всё.
TDD так вообще этот принцип (работает и значит ок) спустило официально на уровень разработки (давайте сделаем чтобы тесты проходило и ладно), а заказчик продукта никогда и не разбирался в коде который ему дают - у него исходно этот принцип был.
ИИ кв этом смысле качественно ничего не меняет, просто вскрывает вещи, которые и так были очевидными.
TDD так вообще этот принцип (работает и значит ок) спустило официально на уровень разработки (давайте сделаем чтобы тесты проходило и ладно)
TDD больше про использование тестов как спецификаций для разработки. Но многие люди понимают как "тесты зелёные значит работает"
ИИ не меняет, трудно что-то поменять когда тебя нет :).
Но то, что некоторые готовы перейти на следующую ступень "херак херак и в продакшн - факт".
Я это не приветствую. Но по понятным причинам лично я остановить этот парад глупости и жадности вряд ли смогу.
Но безусловно буду бойкотировать.
Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review.
int add(int x, int y);
Поймите, правильно ли работает эта функция без code review. При условии что её реализацию сгенерировала система с мандатом писать любой бред пока он проходит проверки.
100% тестовое покрытие? ~30% ошибок заключаются в отсутствующих логических путях, ~40% - в неверных результатах на уникальной комбинации логических путей (статистика от Р. Гласса).
Не совсем понял мысль. В современных реалиях вы просите вашего агента написать фугкцию сложения, задаете ограничения - работаем только с целыми числами и проверяете, что числа складываются правльно. Можно, конечно, идти по пути ревью, если вы это пишете для космического корабля, но если это, к примеру, калькулятор калорий, можно использовать этот принцип утки и доверится что там навайбкодит агент. Моя мысль такая.
и проверяете, что числа складываются правльно
Как? Если программа прошла N тестов, то с какой вероятностью она пройдёт ещё M в проде? Если у вас нет никаких дополнительных убеждений, если программа есть идеальный чёрный ящик, то ответ известен: [(N+1)/(N+2)]^M ("правило Лапласа"). Что примерно равно -exp(M/N). Чтобы быть уверенным в надёжности программы таким образом, вычислительные ресурсы тестирования должны превышать вычислительные ресурсы использования.
И это, заметьте, в не-адверсариальных сценариях, когда пользователь просто гоняет приложение примерно в ожидаемых вами условиях, а не ломает его целенаправленно.
т.е. вопрос полноты покрытия валидацией - что мешает уменьшить Зоны покрываемые каждой отдельной валидацией? т.е. писать код так чтобы его можно было валидировать на вашем уровне ресурсов, а потм и з этих кодовых блооков уже собирать приложение, за однои проблему с тем что ИИ теряет контекс решим - тут правда вопрос достаточности - есть конечно крайние случаи когда всё равно всё упадет как бы ты не валидировал, но насколько они часты? если их скажем 2% то вопрос насколько велики эти два процента? и насколько часто они выпадают? а то окажется что валидируем мы ради одного случая из сотен миллионов и ситуации которая складывается с такой же вероятностью... может имеет смысл посмотреть на Внешние уровни защиты которые будут защищать данные от прохода "мусора" из-за редких ошибок?
int add(int x, int y);Поймите, правильно ли работает эта функция без code review.
add(INT_MAX , 42)
Ага. А потом проверить обратное сочетание, а потом на ноли, а потом на отрицательные числа, а потом на два максимума. А потом окажется, что ИИ нагаллюцинировал там внутри что-то вроде "return (short int)(a+b)" и поэтому при прохождении всех этих тестов функция всё равно работает категорически неверно.
т.е. вопрос полноты покрытия валидацией - что мешает уменьшить Зоны покрываемые каждой отдельной валидацией?
То что мы обсуждаем попытку не заглядывать в код.
Хорошо валидированные Зоны у нас есть - это операторы и стандартные функции языка.
Проблема в том, что из них хочется собрать уникальную, сложную конфигурацию и быть уверенным что она работает правильно.
Есть попытка отождествить "правильно" с "то что проходит написанные мной тесты". Но в полном пространстве сложных конфигураций есть много объектов. Пусть программа - это цепочка из N блоков, каждый из которых может быть выбран K способами. Тогда я начинаю с пространства размером K^N. Пусть каждый тест имеет T вариантов исхода, из которых только один правильный. Тогда набор тестов, который проходится только правильной программой, имеет в среднем N*log_T(K) независимых тестов (а независимые в совокупности тесты практически недостижимы).
Следствие-раз: раньше нам надо было N*log(K) бит информации чтобы написать программу, теперь нам надо N*log_T(K)*log(T) бит информации чтобы определить правильные результаты тестов - в информационном смысле, наша задача не упростилась ни на йоту.
Следствие-два: раньше нам надо было искать ошибки в коде, теперь нам надо искать ошибки в тестах кода. Проблема в том что ошибки кода, обычно, достаточно локальны - они дают конфигурацию, которая коротко описывается конструкцией "ведёт себя как надо, за исключением: ...". А ошибки тестов дают некоторое подмножество пространства конфигураций, которое может вообще не иметь компактного выражения на доступном нам языке (потому что всех подмножеств конфигураций 2^(K^N), их слишком много чтобы у всех них были короткие описания).
В целом, можно представить себе кучу тестов вида
assertEquals(add(2,2), 4)
assertEquals(add(3,4), 7)
и т.д. Набрав достаточное количество таких тестов, вы можете с достаточной уверенностью предполагать, что сгенеренная функция действительно делает сложение, не глядя в код самой функции
Вопросы/проблемы вот какие:
Для ряда задач легче разобраться как работает сложение регистров в ассемблере и написать "математически верный" код руками, чем составить мильен тестов (которые еще и запускать надо всякий раз)
Для другого ряда задач не требуется 100%-я точность результатов, достаточно 80-90-95% ("а перед остальными 10% мы извинимся и даже вернем деньги" - вполне себе рабочая бизнес-модель во многих случаях, особенно если у бизнеса низкий горизонт планирования)
Я согласен и об этом и пишу. AI, на мой взгляд, уже пришел в нашу профессию и вопрос, как мы его проверяем - нужен ли ревью его кода в большинстве случаев?
Как мне кажется, ответ зависит от от факторов, которые я указал выше
Стоимость. Написать нормально руками через код-ревью и "по науке" может быть дешевле, чем составлять промпты и "очерчивать границы" агентам через тестирование и проч
Надежность. И код, написанный вручную, и код, сгенеренный через ИИ, будет содержать ошибки. Вопрос - какой процент ошибок допустим на вашем проекте? 10%? 1%? 0,0001%? Высокие показатели качества сложно достичь на одних только тестах, не понимая как работает система внутри.
В целом, можно представить себе кучу тестов вида
Откуда в тестах взялись эталонные значения и почему вы им доверяете? Если вы их сгенерировали сами и руками, то суммарно разработка этой функции обошлась вам абсурдно дорого. Если вы их сгенерировали автоматически некоторым доверенным процессом, который было написать не сложнее чем проверяемую функцию, то зачем вам вообще функция, используйте этот процесс.
("а перед остальными 10% мы извинимся и даже вернем деньги" - вполне себе рабочая бизнес-модель во многих случаях, особенно если у бизнеса низкий горизонт планирования)
Вернуть деньги хрен бы с ним, клиенты с претензией "ваша программа не считает что нам надо" обычно не слезут пока не получат результат расчёта. И это ещё хорошо если ошибка выглядит как "программа упала", а не "программа втихую выдала неверные результаты".
Затем, если в программе 50 мест где можно ошибиться (это довольно простая программа), то для уровня ошибок в 20%, в каждом отдельном месте вероятность ошибки должна быть 0.45%.
А в чём смысл писать тестов больше чем код?
Кто ревьюит тесты?
~30% ошибок заключаются в отсутствующих логических путях, ~40% - в неверных результатах на уникальной комбинации логических путей
Если Вы знаете, что логические пути отсутствуют, то знаете, какие именно, а значит, можете проверить.
Всё, что формализуется, можно формально же и проверить. Условно говоря, скрмптом, а не моделью.
Ваш пример с функцией не имеет смысла без контекста. Будут требования, можно будет сказать, работает она или нет. И сказать это сможет не только reviewer, но и формальный скрипт.
Всё, что формализуется, можно формально же и проверить. Условно говоря, скрмптом, а не моделью.
P = NP - проверяйте.
Если Вы знаете, что логические пути отсутствуют, то знаете, какие именно, а значит, можете проверить.
???
Не знаю. Вот я написал программу, которая обрабатывает некоторые входные данные.
Вопрос: не забыл ли я какой-то конкретный случай?
Ответ: а хрен его знает. Что мне пришло в голову - я проверил. Как проверить, пришло ли мне в голову всё что нужно проверить?
Будут требования, можно будет сказать, работает она или нет.
Требования к add(): должна работать правильно во всех нынешних и будущих, ещё не написанных вызовах. При компиляции любым потенциально используемым компилятором.
Нет, можно сказать "дайте мне документацию на двенадцати листах, и любая претензия к поведению add(), которая не указывает, какой пункт документации нарушен - не моя проблема". Но это задача перекладывания ответственности, а не задача разработки ПО: проблема всё равно будет чья-то.
Необходимо не забывать, что одной из задачь code-review является то, что код должен быть понятен всем членам команды. Для чего это нужно? Что бы любой член команды мог корректно внести изменения, когда это понадобится (оговорки на зоны ответсвенности принимаются). С другой стороны, при подходе описаном в статье, команда не нужна. Тогда вопрос - зачем вообще код ревьювить? Оставить надо одного заказчика. Купить ему токенов (взять коммисию с них конечно), а програмистов всех уволить.
Слепому не покажешь, глухому не расскажешь. Люди, ушедшие с головой в омут ИИ истерии, уже не смогут представить себе, что в мире кроме генерации есть подходы, которые часто и много где просто лучше и эффективнее. Число строк кода != качество получившегося кода, но именно это принято замалчивать
а надо ли? вопрос в том что не правильнее ли каждый раз генерировать новый артефакт? ну вот при достаточном уровне дробления вполне можно прийти к тому что ИИ генерит кучу конструктивных блоков к схеме доступной для понимания человеком и уже тогда получается так что схема приложения понятна и внести изменения надо не в код, а в логику работы блока через правку запроса, валидирующие массивы и тесты, а что там за код в блоке несколько без разницы....
от кодревью нас спасёт только BDD.
Я согласен с автором насчет того, что программист в конечном итоге перестанет владеть кодом.
В то же время чтобы быть уверенным в правильной работе системы нужно задавать поведенческие тесты. Они, эти тесты должны выглядеть понятными для разработчика ( или продакт оунера ). Что на данный момент к сожалению не так.
Нужна тестовая система которая позволит описыват поведение в более или менее человеческим языком.
Я мечтаю о том, чтобы тесты задавались текстом. На основе этого текста генерировался код теста ( одноразово ). А потом уже система проверялась этим тестом.
1) Кому-то ревьюить код всё равно придётся. Если не человеку, то другому ИИ агенту. А потом ревьюить фиксы и так далее в цикле, пока агент ревьюер не перестанет находить серьёзные ошибки.
2) Сколько не работаю с ИИ, не перестаю обращать внимание на то, что у ИИ есть сложности с отделением важного от неважного. Он регулярно ставит в один ряд серьёзности реальный баг "мы забыли сохранить результаты работы программы" и "мы забыли обработать ситуацию, если поставщик API кардинально именит схему данных всех ответов API и это произойдёт одновременно с падением ОС и исчерпанием дискового пространства" (то что в принципе нельзя обработать и просто принимается, а любая попытка обработать, как правило, делает программу хуже). И как минимум иногда нужен человеческий ревью "баг реальный или звучит как перестраховка от того от чего невозможно перестраховаться".
3) Важный вопрос - планируется ли человеку работать с этим кодом. Если предполагается работа ИИ рука об руку с человеком, то человеческий ревью обязателен, чтобы код не стал слишком инопланетным (даже если в нём и не будет крупных ошибок) и поддерживать alignment с тем, с чем конкретная команда способна работать. Если это проект, который предполагается целиком и полностью доверить ИИ, тогда ревью человеком менее важен.
4) Не надо становиться жертвой культа продуктивности "всё автоматизировать и ускорить до предела".
Некоторые компании уже используют N8N для процесса ревью кода и автоматических доработок. Но тут как ружье Чехова на мой взгляд без SAST и DAST для компаний средней руки
А что, если AI-код вообще не нужно ревьюить?
Ну так не ревьювьте, кто вас заставляет? Организуйте уже легендарную компанию-единорога из одного человека и агентов. А то три года уже одни разговоры.
Вопрос уровня "а почему не напечатать деньги, чтобы в мире не было бедных". Значит, есть на то причины.
Сейчас ИИ для разработки больше напоминает педального коня, нежели поумневшую лошадь.
Мы становимся в большей мере Product Owner'ами, архитекторами, инженерами по качеству, инженерами по безопасности.
Работа ролей, которые всю дорогу воспринимались как вспомогательные, вдруг обрела особый смысл и важность благодаря ИИ? ИИдиократия какая-то получается.
агент способен написать или переписать тысячу строк за несколько минут, а человек будет читать их значительно дольше.
типа как в народной мудрости - один дурак может задать столько вопросов что и сто мудрецов не ответят
Допустим, что мы дали AI задание написать программу сортировки с использованием алгоритма quicksort. Код написан и проходит все тесты (данные сортируются). Но как проверить без code review, что реализован именно алгоритм qucksort, а не какой-то другой?
Так задачу не ставят.
А вот проверить объём памяти и время можно
Так задачу не ставят.
Как не ставят? Нельзя говорить, что задача должна быт решена с использованием определенного алгоритма?
В чуть более сложном случае за разумное время уже не проверить.
Мердж сорт чего-то очень большого. С дисковыми кешами и возможно на нескольких хостах. Тест будет работать так долго что он почти беполезен.
проверить объём памяти и время можно
где вы возьмете эталонные значения?
Для этого мы посылаем другого агента с вопросом, как работает код.
Буквально вчера клод нагенерировавший мне стрпшную функцию на 20 строк заставил меня искать альтернативы. 5 минут времени и была 6айдена альтернатива в 5 всего сторок!
Генерация методов которые не используются - как за здрасьте.
Достаточно частые недопонимания контекста и соответственно неверные выводы о том, безопасен ли тот или иной кусок или нет.
А попросить написать код и тесты к нему, которые абсолютно всегда проходят и при жтом почти всегда покрывают не совсем нужные сценарии а иногда и вовсе не нужные.
Нужно ли ревью сгенерированного кода?
У меня есть проект , обработка данных html (парсер) , был написан ИИ еще в начале 2025 года , файлов 5-6 из которых извлекались нужные данные + был многопоток , очереди и работа с БД. В принципе код рабочий .. бегает. Но отдав этот код уже современной сети вроде Opus , Fable , GPT 5.5+ или GLM 5.2 , они этот код разнесли в пух и прах .. оценка 3.2 из 10 , мол написал какой то джун , какого черта тут не используется Virtual Threads (проект на Java21) , зачем так усложнять было в контроллере и в итоге из 800 строк , превратил мне в 300 с сохранением функционала , ну и т.п. Ну и находил критические баги , на которые я просил тест сделать для проверки и результат в итоге True .. некоторые ложные попадались да , но чем модель круче , тем попадание более явное. В плане ревью кода у меня отдельная песня , я даже написал отдельное приложение для этого , подход муторный у меня , но зато результатом я доволен. В итоге в следующий раз проходя даже серьезной моделью по какому то коду в прошлом , ИИ результатом доволен обычно.
Есть и такое .. Fable 5 найдет баг и предложит якобы чистый вариант , который в итоге в пух и прах разнесет дешевый Deepseek 4 Flash.. мол не доработка братан. Этот же ответ даешь Fable и он соглашает)
А что, если AI-код вообще не нужно ревьюить?