Здравствуйте, gandjustas, Вы писали:

PD>>>>Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ.
G>>>Ты же сам понимаешь ущербность этой позиции?
G>>>Если что без человека вообще ничего ии пока не умеет. Кто-то должен поставить задачу и "принять" результат.

PD>>Ну он же должен прогрессировать . Почему бы ему со временем самому все мои пункты 1-6 не сделать ? Так что ущербности не вижу.
PD>>Я же не требую, чтобы это было завтра. Он вообще это сможет ?
G>Он вообще это делает уже сейчас. Браузер же появился.

Появился, но не без участия человека, видимо.



PD>>Да ради бога. Это все существенно, и я не спорю. Но если бы он лишь одно сказал — программу надо хранить в памяти, как числа и там выполнять — этого было бы достаточно. Потом анализировали бы и наводили теорию. А принцип бы остался.
G>То есть его "принципы" не являются "законами" как в физике. Для фон Неймана это был удачный формализм чтобы доказывать утверждения, для инженеров это оказалось достаточно хорошей, на тот момент, идеей.

Ну зачем же требовать от информатики законов в стиле физики ? ЭВМ все же не природный объект, а творение рук человеческих. Законы Ньютона иными быть не могли, а в ЭВМ многое могло бы быть иначе сделано. Сделали бы байт 16-битным — и не знали бы мы проблем с кодировками, а сразу был бы Юникод . Только не надо мне объяснять, почему такое не могло быть

Формализм это или нет — не очень содержательная дискуссия. Я просто отметил одно — он предложил способ, которого до него не было, и аналогов, на которые ты упираешь, тоже не было. А он вдруг взял и предложил. Причем так, что почти в неизменном виде это до сих пор используется. Вот это и есть озарение.


PD>>Он может генерировать со скоростью, намного большей чем человек или даже команда. Это неудивительно.
PD>>Интересно другое — а когда он по качеству будет давать то, что сравнимо с кодом команды профессионалов ?
G>Как ты "качество" измеряешь?

А черт его знает. Когда-то тут были длинные дискуссии на эту тему, не без моего участия. Не хотел бы их начинать заново, тем более, что строго формальный критерий едва ли возможен. И тем не менее мы как-то говорим — вот эта программа качественная, а эта не очень, а это вообще барахло. И, как правило, не ошибаемся.



PD>> это же будет примерно то же, что собрать сотню студентов 3 курса и поручить им разработку. Даже если они владеют всем, что нужно для этой разработки (или смогут найти) — это же не значит, что они качественный продукт сделают. Что-то сделают, допустим, вот только вылетать это будет чаще, чем работать.
G>Давай проведем эксперимент — возвращайся когда их браузер хоть что-то откроет.

Не понял. Что браузер открыть может ?


PD>>И наплодят они этот код, вот только не получится, как здесь — по другому поводу сказанное, конечно
G>Я прекрасно понимаю к чему эта риторика. И прекрасно понимаю, что несмотря на любые успехи ИИ ты будешь доказывать что "не торт", предлагая эксперименты, которые точно провалятся, хотя ты уверен что не будешь их проводить.

Нет , не буду. Я просто по натуре скептик и не готов бросаться на все появившееся новое с криком "ура, вот это панацея". Я предпочитаю выждать, прежде чем сделать суждения, а до тех пор занимать осторожно-недоверчивую позицию. Если окажется, что мой скепсис был чрезмерен — признаю.

Кстати, и сейчас готов такое признание сделать. Я весьма скептически относился к идее Википедии, когда она появилась. По той же причине — "и станем все одним Шекспиром". Более того, я требовал от студентов в списке литературы не давать ссылки на Википедию, а только на оригинальные источники (ну это я и сейчас бы потребовал).
Прошли эти 15 лет, и могу сказать, что мой скепсис был несколько чрезмерным. Я и сейчас не считаю ее хорошим источником по конкретному вопросу, но роль ее я признаю.

PD>>Ты вполне используешь код от серьезных фирм и не исследуешь его.
G>Там гарантия есть, финансовая. Да и обычно я не использую совершенно неизвестные мне программы. То есть их уже кто-то использовал, они уже прошли какое-то тестирование.

Ну какая там финансовая гарантия при использовании JRE в твоем, допустим, open source проекте ? Да и 100500 других библиотек . Там же везде в лицензии "отказ от ответственности".

G>С кодом от ИИ не так, его вообще никто не проверял. Ты всегда первый кто это сделает.

Верно. С этим согласен. Но если ты вынужден использовать некую библиотеку , сделанную людьми, но не настолько хорошо протестированную, как, скажем, JRE или .Net, то ты все же должен как-то определить для себя, брать ее или нет. А это основывается на том, доверяешь ты ей или нет ? По каким критериям решаешь, стоит брать или нет ?



PD>>Ты ему просто доверяешь (что не отменяет , конечно, тестирования, но своего кода, использующего их, а не его). Или, скажем, берешь код откуда-то, но знаешь, что его автор тоже известный и хороший программист.
G>Если ты решил мои мысли выдумывать за меня, то не надо.

Да ничего я тебе не приписываю. Я просто предполагаю, потому что ты ответа не даешь. Дай ответ сам. Я сейчас выделил выше вопрос.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А все-так, пожалуйста, объясните, как работает.
Охрененно работает, между нами говоря.

PD>Я что-то вижу противоречие между "ИИ посмотрел — и увидел, что логика нарушена" и словами из прошлого сообщения о том, что он делает свой анализ после запуска unit тестов.
Нет никакого противоречия. Тесты — отдельно, ИИ — отдельно. Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

PD>На что именно посмотрел ? На код или еще и на результат прохождения юнит-тестов ?
На код.

PD>Вообще-то юнит — тесты сами либо ничего не сообщают, либо выдают информацию про непрошедшие assert или про падению по исключению. Поэтому просто при их запуске ничего о том, что происходило внутри, узнать не удастся.
Дофига всего удастся. ИИ умеет, к примеру, по выхлопу юнит-тестов и исходному коду разобраться в первопричине проблемы, порыться в спецификациях проекта и решить — толи это тест косячный (тестирует неактуальные инварианты), или в коде реально баг. А потом починить проблему.
Раньше это могло быть типичной практикой для джуна — "смотри, вот у нас после этого коммита CI репортит фейлы юнит-тестов. Иди разберись и почини".

Но это другой вопрос, который в исходном топике не ставился. Если интересно — можем и его обсудить.


PD>Ну слава богу. Если бы анализатор выдал просто "CreateFile result not checked",
Не "CreateFile result not checked", a "function return value is ignored". Разница — в том, что первый тип сообщения опирается на то, что кто-то когда-то построил ОГРООООООООМный список функций стандартной библиотеки, и для каждой из них написал, можно ли игнорировать её результат. И если я в проекте написал свою собственную функцию, то инструмент понятия не имеет, можно ли игнорировать её результат или нет.
Так вот ИИ отличается от всех этих прекрасных инструментов как раз тем, что он не требует рукопашного написания сотен правил заранее. Ему достаточно скормить код проекта, и он сам найдёт, какие функции нужно проверять, а какие нет.

PD>if(hFile == INVALID_HANDLE_VALUE) ...
PD>вполне мог бы.
А если бы у бабушки...

PD>Да бог с ней, с PVS. Мне IDEA для программ на Java то и дело выдает всякие рекомендации типа "этой переменной стоит дать модификатор final" или "лучше заменить вызов лямбда-функции на ссылку на метод" и т.п. Но сама не делает обычно, а предлагает мне подтвердить. Соглашусь — сделает. А еще у нее есть пункт "Code cleanup", и там она автоматом все изменения делает. Я его боюсь
А, ну так это подход пред-предыдущего поколения. Проактивные рефакторинги, да. Ну, кстати, бояться — правильно: далеко не все средства рефакторинга хорошо написаны. В идеале, они не должны ломать семантику кода (за исключением, быть может, экзотических сценариев — вроде наличия доступа через рефлекшн замаскированным способом. Если у нас там есть в код, который в рантайме вычисляет имя метода как "foobar", и потом по нему обращается, то никакой инструмент не сможет это отловить при рефакторинг-переименовании из foobar в barfoo). Но на практике я, емнип, для TS встречал какие-то инструменты, которые мне неверно трансформировали код.

Но опять: этот подход основан на заранее закодированных паттернах. Есть чёткий список правил "что мы считаем кодом, для которого возможны улучшения". Например — не-final поле, в которое нет присваиваний за пределами конструктора. Есть чёткий список правил "как улучшить код, на котором сработало правило номер X". Эти правила придуманы и закодированы заранее.
Очень иногда тулчейн можно кастомизировать за пределами включения/выключения каких-то правил. Например, научить его обнаруживать нарушения локальных правил вроде "в моём проекте все однобуквенные переменные должны быть целыми". Но опять — это ручная работа, которая требует предварительной подготовки.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Во-первых, ограничимся достаточно узкой областью. Какой-нибудь open source фреймворк.
PD>Что тут вообще может делать интеллект, неважно какой.

PD>1. Освоить имеющийся материал по этому фреймворку
PD>2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
PD>3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
PD>4. Разработать свой код в качестве contibutor и предложить pull request
PD>5. Принять этот pull request (или отвергнуть его)
PD>6. Внести изменения в release и сделать следующую версию.

PD>ЕИ все это может. Разумеется, разные представители ЕИ
PD>Ну ладно, (6) мы пока ИИ не поручим
PD>(1) — (2) ИИ вроде как может.
PD>Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?

У современных "ИИ" фатальный недостаток. Не у самих ИИ, а у того как их
используют. Типичный "агент" ограничен своим контекстом. Пусть там даже
миллион токенов. Это на самом деле очень немного, туда не вместится весь
исходный код, документация, размышления самой модели, полученная ей через
функции/тулы информация... Дальше очевидно. У агентов в которых всё
ограничивается чатом с единственным контекстом это фатальное ограничение.
А как по-другому толком никто не знает. Есть разные экспериментальные подходы,
но в целом нужно время, годы, чтоб что-то выросло толковое. Предрекаю, что
ровно те же модели что есть сейчас станут намного более способными в течении
нескольких следующих лет когда сами агенты из чата с единственным контекстом
превратятся во что-то гораздо более сложное (скорей это будет обычная программная
система, не AI, выступающая в роли "планировщика" задач и базы знаний для AI).

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:

PD>>>>>Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ.
G>>>>Ты же сам понимаешь ущербность этой позиции?
G>>>>Если что без человека вообще ничего ии пока не умеет. Кто-то должен поставить задачу и "принять" результат.

PD>>>Ну он же должен прогрессировать . Почему бы ему со временем самому все мои пункты 1-6 не сделать ? Так что ущербности не вижу.
PD>>>Я же не требую, чтобы это было завтра. Он вообще это сможет ?
G>>Он вообще это делает уже сейчас. Браузер же появился.

PD>Появился, но не без участия человека, видимо.
Ок, пошли по второму кругу. Даже с ИИ человек должен поставить задачу и принять результат. Это не входит в твои 6 пунктов если что.


PD>>>Он может генерировать со скоростью, намного большей чем человек или даже команда. Это неудивительно.
PD>>>Интересно другое — а когда он по качеству будет давать то, что сравнимо с кодом команды профессионалов ?
G>>Как ты "качество" измеряешь?

PD>А черт его знает.
Тогда какой смысл писать?


PD>>> это же будет примерно то же, что собрать сотню студентов 3 курса и поручить им разработку. Даже если они владеют всем, что нужно для этой разработки (или смогут найти) — это же не значит, что они качественный продукт сделают. Что-то сделают, допустим, вот только вылетать это будет чаще, чем работать.
G>>Давай проведем эксперимент — возвращайся когда их браузер хоть что-то откроет.
PD>Не понял. Что браузер открыть может ?
Страницу с CSS и JS. Главную rsdn например.


PD>>>И наплодят они этот код, вот только не получится, как здесь — по другому поводу сказанное, конечно
G>>Я прекрасно понимаю к чему эта риторика. И прекрасно понимаю, что несмотря на любые успехи ИИ ты будешь доказывать что "не торт", предлагая эксперименты, которые точно провалятся, хотя ты уверен что не будешь их проводить.

PD>Нет , не буду. Я просто по натуре скептик и не готов бросаться на все появившееся новое с криком "ура, вот это панацея". Я предпочитаю выждать, прежде чем сделать суждения, а до тех пор занимать осторожно-недоверчивую позицию. Если окажется, что мой скепсис был чрезмерен — признаю.
Ты не скептик. Скептик это тот кто сомневается, а тот кто сомневается ищет подтверждение, в том числе через эксперимент. А то чем ты занимаешься называется "неолуддизм" — это критика и отвергание прогресса и его влияния на нашу жизнь.


PD>>>Ты вполне используешь код от серьезных фирм и не исследуешь его.
G>>Там гарантия есть, финансовая. Да и обычно я не использую совершенно неизвестные мне программы. То есть их уже кто-то использовал, они уже прошли какое-то тестирование.
PD>Ну какая там финансовая гарантия при использовании JRE в твоем, допустим, open source проекте ? Да и 100500 других библиотек . Там же везде в лицензии "отказ от ответственности".
Ты же не первый будешь его использовать? И даже не второй. Как минимум отзывы в сети прочитаешь, CVE поищешь.

G>>С кодом от ИИ не так, его вообще никто не проверял. Ты всегда первый кто это сделает.

PD>Верно. С этим согласен. Но если ты вынужден использовать некую библиотеку , сделанную людьми, но не настолько хорошо протестированную, как, скажем, JRE или .Net, то ты все же должен как-то определить для себя, брать ее или нет. А это основывается на том, доверяешь ты ей или нет ? По каким критериям решаешь, стоит брать или нет ?
Мне кажется ты полностью игнорируешь что было два сообщения назад: если я ничего не знаю, то я читаю код. Без исключения.


PD>>>Ты ему просто доверяешь (что не отменяет , конечно, тестирования, но своего кода, использующего их, а не его). Или, скажем, берешь код откуда-то, но знаешь, что его автор тоже известный и хороший программист.
G>>Если ты решил мои мысли выдумывать за меня, то не надо.
PD>Да ничего я тебе не приписываю. Я просто предполагаю, потому что ты ответа не даешь. Дай ответ сам. Я сейчас выделил выше вопрос.
Ты предполагаешь мои мысли и сам отвечаешь на эти предположения. Заканчивай.

Здравствуйте, Sinclair, Вы писали:

PD>>Я что-то вижу противоречие между "ИИ посмотрел — и увидел, что логика нарушена" и словами из прошлого сообщения о том, что он делает свой анализ после запуска unit тестов.
S>Нет никакого противоречия. Тесты — отдельно, ИИ — отдельно. Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

S>Но это другой вопрос, который в исходном топике не ставился. Если интересно — можем и его обсудить.

Вот и давай обсудим. Для выяснения.

Раз тесты отдельно, ИИ — отдельно, значит на мой вопрос о том, запускает ли он тесты под собой в стиле профайлера, ответ — нет, не запускает.

Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.

S>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.https://pvs-studio.com/en/blog/posts/cpp/0543/

Принял к сведению. Вопрос ясен — он информацию, которая могла бы быть получена от прохождения тестов, не получает и поэтому не использует.

Тогда остается только статический (без выполнения) анализ.

Я готов допустить в принципе, что он тут лучше других статических анализаторов. Есть некоторые сомнения, просто из тех соображений, что авторы той же PVS Studio ее десяток, если не больше, лет пилят и всех собак в округе съели, а тут явился кто-то и одним махом их всех превзошел. Но допустим все же.

Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.

Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.

Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.

Это твой ИИ сможет ? Без запуска, только, как ты писал, "смотрит на код" ?

Если сможет — у него фантастические возможности, потому что без запуска под профайлером это ни один человек не сможет. На то профайлер и делается.

S>Речь о том, что ИИ находит косяки, которые никакие другие инструменты найти не могут.

А вот тут я двумя руками за. Пусть находит. Еще один инструмент в ряду других. Со своими преимуществами и ограничениями. Все нормально.

В общем, вспоминаю Ф. Искандера

Недели через две, когда замолкли последние залпы контрпропаганды и нашествие козлотуров было полностью подавлено, а их рассеянные, одиночные экземпляры, смирившись, вошли в колхозные стада,...

Вот так и ИИ войдет в этой области.

S>Так вот ИИ отличается от всех этих прекрасных инструментов как раз тем, что он не требует рукопашного написания сотен правил заранее. Ему достаточно скормить код проекта, и он сам найдёт, какие функции нужно проверять, а какие нет.

Вполне принимаю. Пусть ищет. Еще один инструмент.

PD>>if(hFile == INVALID_HANDLE_VALUE) ...
PD>>вполне мог бы.
S> А если бы у бабушки...

А IDEA это дедушка, все же ? Просто она это делает, а PVS такой функциональности нет, не предусмотрено.

S>А, ну так это подход пред-предыдущего поколения. Проактивные рефакторинги, да. Ну, кстати, бояться — правильно: далеко не все средства рефакторинга хорошо написаны. В идеале, они не должны ломать семантику кода (за исключением, быть может, экзотических сценариев — вроде наличия доступа через рефлекшн замаскированным способом. Если у нас там есть в код, который в рантайме вычисляет имя метода как "foobar", и потом по нему обращается, то никакой инструмент не сможет это отловить при рефакторинг-переименовании из foobar в barfoo). Но на практике я, емнип, для TS встречал какие-то инструменты, которые мне неверно трансформировали код.

Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ? И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.

S>Но опять: этот подход основан на заранее закодированных паттернах. Есть чёткий список правил "что мы считаем кодом, для которого возможны улучшения". Например — не-final поле, в которое нет присваиваний за пределами конструктора. Есть чёткий список правил "как улучшить код, на котором сработало правило номер X". Эти правила придуманы и закодированы заранее.
S>Очень иногда тулчейн можно кастомизировать за пределами включения/выключения каких-то правил. Например, научить его обнаруживать нарушения локальных правил вроде "в моём проекте все однобуквенные переменные должны быть целыми". Но опять — это ручная работа, которая требует предварительной подготовки.

Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами. Ну и хотелось бы иметь возможность с ним подискутировать, если сочту нужным. И возможность что-то принять,а что-то отвергнуть, а он пусть скажет, можно ли сделать такое частичное изменение и не приведет ли это к плохим последствиям. Черт его знает, что он там в итоге накрутил, как там одно связано с другим. Интеллект все же

А то ведь может крайне неприятная ситуация возникнуть. Вот есть у меня код, который я писал и тестировал несколько лет назад. Я ему вполне доверяю и о нем не думаю. А в нем ошибка все же есть, только она никогда не проявлялась, так уж вышло. Я этот код в новый проект вставил, без анализа. Он ошибку в нем нашел. Спасибо ему. И поправил. И неверно поправил, потому что он что-то в моем коде не понял. И результатом этого исправления будет вот что. Код будет работать иначе для этого редкого случая, может и лучше. Вот только в половине остальных обычных случаях он работать перестанет. И что мне теперь делать, если, начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей ? Сидеть и вспоминать, что я там такое 3 года назад написал, и как это с его исправлениями вяжется и как мне сделать, чтобы его "улучшения" мне все не ломали ?

Здравствуйте, gandjustas, Вы писали:

G>Ок, пошли по второму кругу. Даже с ИИ человек должен поставить задачу и принять результат. Это не входит в твои 6 пунктов если что.

Да, похоже, повторяемся. Пора заканчивать.


PD>>>>Он может генерировать со скоростью, намного большей чем человек или даже команда. Это неудивительно.
PD>>>>Интересно другое — а когда он по качеству будет давать то, что сравнимо с кодом команды профессионалов ?
G>>>Как ты "качество" измеряешь?

PD>>А черт его знает.
G>Тогда какой смысл писать?

Ну я же ответил. Ты мой ответ просто удалил, без комментариев. Другого у меня нет. Мне и того хватает.


G>>>Давай проведем эксперимент — возвращайся когда их браузер хоть что-то откроет.
PD>>Не понял. Что браузер открыть может ?
G>Страницу с CSS и JS. Главную rsdn например.

Фу ты... Я уж подумал, что открытие какое-то он сможет сделать

Сможет, наверное. Правила достаточно формализованные, так что сможет. Да может, и делает уже.


PD>>Нет , не буду. Я просто по натуре скептик и не готов бросаться на все появившееся новое с криком "ура, вот это панацея". Я предпочитаю выждать, прежде чем сделать суждения, а до тех пор занимать осторожно-недоверчивую позицию. Если окажется, что мой скепсис был чрезмерен — признаю.
G>Ты не скептик. Скептик это тот кто сомневается, а тот кто сомневается ищет подтверждение, в том числе через эксперимент. А то чем ты занимаешься называется "неолуддизм" — это критика и отвергание прогресса и его влияния на нашу жизнь.

Ну это ты зря. Я ничего ни ломать, ни запрещать не призываю и целиком за прогресс. Пусть развивается, посмотрим. Я просто не готов , увидев что-то новое, немедленно стать яростным адептом этого и испытать восторг. Я именно скептик — моя реакция на все новое простая — давайте посмотрим, что будет через несколько лет. Вот тогда подтверждения и будут. Либо за, либо против.

Просто я столько видел начинаний, которые в своем начале позиционировались как глобальная революция, а в итоге скромно занимали свое место, что спешить с выводами я не хочу.


G>Ты же не первый будешь его использовать? И даже не второй. Как минимум отзывы в сети прочитаешь, CVE поищешь.

Ну наверное не первый. И поищу, да. И найду возможно не один пакет. И должен буду выбрать. Так вот, по каким критериям ? В исходниках копаться не буду, да их может и не быть.

G>Мне кажется ты полностью игнорируешь что было два сообщения назад: если я ничего не знаю, то я читаю код. Без исключения.


PD>>>>Ты ему просто доверяешь (что не отменяет , конечно, тестирования, но своего кода, использующего их, а не его). Или, скажем, берешь код откуда-то, но знаешь, что его автор тоже известный и хороший программист.
G>>>Если ты решил мои мысли выдумывать за меня, то не надо.
PD>>Да ничего я тебе не приписываю. Я просто предполагаю, потому что ты ответа не даешь. Дай ответ сам. Я сейчас выделил выше вопрос.
G>Ты предполагаешь мои мысли и сам отвечаешь на эти предположения. Заканчивай.

Давай закончим, верно.

Спасибо за дискуссию.

Если хочешь, за тобой завершающее слово. Я больше отвечать не буду.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот и давай обсудим. Для выяснения.

PD>Раз тесты отдельно, ИИ — отдельно, значит на мой вопрос о том, запускает ли он тесты под собой в стиле профайлера, ответ — нет, не запускает.

PD>Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.
Я ничего не дезавуировал. Просто не нужно читать то, чего нет в тексте

S>>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.https://pvs-studio.com/en/blog/posts/cpp/0543/
Всё верно. Сначала запускаем компилятор. Он отлавливает ошибки типизации.
Потом линтер — он отлавливает нарушения конвенций и сомнительные места, которые компилятор не проверяет.
Хорошие линтеры могут делать довольно сложные проверки (см. напр. PVS Studio).

Потом юнит-тесты — они проверяют соответствие кода решения коду тестов

И вот когда все это уже отработало, и можно бы уже и PR мерджить, приходит ИИ. И всё ещё находит проблемы, которые ни один из предыдущих инструментов не увидел.
Так понятно?

PD>Я готов допустить в принципе, что он тут лучше других статических анализаторов. Есть некоторые сомнения, просто из тех соображений, что авторы той же PVS Studio ее десяток, если не больше, лет пилят и всех собак в округе съели, а тут явился кто-то и одним махом их всех превзошел. Но допустим все же.
Не обязательно "превзошёл". Он делает очень много из того, что PVS Studio не делает и не может делать (по крайней мере, до тех пор, пока внутрь неё не завернут LLM).
Например — проверить, не нарушает ли PR какие-то из правил, которые написаны в документах проекта на естественном языке.
PD>Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.
Это работает в обе стороны.

PD>Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.
Конечно. Но code coverage работает в одну сторону, а ИИ умеет в противоположную: "сделай code coverage = 95%".

PD>Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.
Перед ИИ не ставится такая задача. Вернёмся к старту топика:

1. Освоить имеющийся материал по этому фреймворку
2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
6. Внести изменения в release и сделать следующую версию.

Где тут "сколько раз выполнялся данный метод"? Нету? Ну и правильно. Потому что мы обсуждаем темы уровня "принять этот PR или отвергнуть". Сможет это сделать профайлер?
При этом ИИ запросто может работать по инструкции вида "посмотри на результат бенчмарков, и если PR замедляет ключевые бенчмарки хуже, чем X, запусти тесты под профайлером и предложи способы оптимизировать места основного вклада в это замедление".

PD>Вот так и ИИ войдет в этой области.


PD>Вполне принимаю. Пусть ищет. Еще один инструмент.
Всё верно. Он не заменяет существующие инструменты. Он работает поверх них.

PD>Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ?
А почему нет? Он прекрасно поддерживает такие дискуссии. И изменения показывает, и обосновывает почему. И ошибается, бывает — и так же, как коллегу, ему на это указываешь, и он исправляет. В отличие от коллеги, он доступен 24 часа в сутки, и не начинает ныть, что ты придираешься, и что он устал, и вообще ты сам должен понимать, что тут написано, а если нет — иди нафиг, не умеешь ревьювить — не берись.

PD>И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.
Не убедят — не примешь изменение. Делов-то.

PD>Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами.
Всё так и работает. Не, можно вайбкодить и в стиле "напиши мне какую-нибудь сетевую игру. Не трогай меня, пока всё не будет готово", но результат будет не сильно лучше, чем если такую же задачу поставить десятикласснику.
А в нормальном подходе разработка ведётся в режиме диалога. Ставишь задачу — он обрисовывает варианты её реализации, ты утверждаешь какой-то из них (или объясняешь, почему ни один не подходит, и вы продолжаете дискуссию до принятия решения), это документируется. Если решение затрагивает другие, уже решённые задачи — в их спецификации вносятся исправления, или, наоборот, в текущую доку вносятся исправления, чтобы противоречий не было.
Дальше он к этой реализации предлагает варианты архитектуры, ты утверждаешь какой-то из них. Точно так же — если где-то в документах есть что-то несогласующееся с новой архитектурой, это обсуждается и правится.
Дальше он предлагает тест-план, который опять же утверждаешь ты. Потом он пишет тесты по этому плану, потом код. Потом гоняет код и тесты, пока они не заработают. Потом он замеряет coverage и добивает тесты до нужного уровня покрытия. Потом, если надо, выполняется бенчмаркинг, анализируются результаты, и ты принимаешь решение — обновить требования перформанса, или оптимизировать. Предлагаются варианты стратегий оптимизации, обсуждаются. Утверждённый вариант документируется, и так далее.

PD>А то ведь может крайне неприятная ситуация возникнуть. Вот есть у меня код, который я писал и тестировал несколько лет назад. Я ему вполне доверяю и о нем не думаю. А в нем ошибка все же есть, только она никогда не проявлялась, так уж вышло. Я этот код в новый проект вставил, без анализа. Он ошибку в нем нашел. Спасибо ему. И поправил. И неверно поправил, потому что он что-то в моем коде не понял. И результатом этого исправления будет вот что. Код будет работать иначе для этого редкого случая, может и лучше. Вот только в половине остальных обычных случаях он работать перестанет. И что мне теперь делать, если, начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей
Как что? Прогнать цикл регрессионного тестирования, естественно. Не может же быть такого, что код был не покрыт тестами? А если вдруг так случилось, что был непокрыт, то надо не с поиска ошибки начинать, а с фиксации дизайна в тестах и подъёме покрытия до 90-95%. А уже потом рассматривать любые идеи про починку. ИИ тут ничего не меняет — ну, кроме 10х подьёма продуктивности разработчика, поэтому те вещи, которые раньше откладывались с мыслью "да тут полгода пердолиться нужно" делаются за выходные.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну это ты зря. Я ничего ни ломать, ни запрещать не призываю и целиком за прогресс. Пусть развивается, посмотрим. Я просто не готов , увидев что-то новое, немедленно стать яростным адептом этого и испытать восторг. Я именно скептик — моя реакция на все новое простая — давайте посмотрим, что будет через несколько лет. Вот тогда подтверждения и будут. Либо за, либо против.
Просто "несколько лет" уже прошли. Смотреть можно не когда-то потом, а прямо сейчас. Мы обсуждаем не гипотетическое будущее, а вполне активное настоящее. Прямо вот берёшь, втыкаешь — и пользуешься.
Изо всех инструментов, которые я для разработки в своей карьере встречал, у этого семейства — самый низкий порог входа. Не надо ничего сложного качать, собирать, настраивать, обучаться. Просто сел — и поехал. Ну, понятно, что эффективно использовать инструмент получится не сразу. Я вот от своего начальника очень и очень сильно отстаю.
Он, к примеру, решил поиграться в мультиагентность — это когда собирается консилиум "специалистов", и дизайнят любую фичу коллективно. В рамках одной сессии у современных агентов очень плохо получается переключать точку зрения — типа "а теперь покритикуй предложенное тобой решение". А несколько параллельных сессий не все инструменты поддерживают из коробки. Ну вот начальник собственно и попросил LLM "взломать" код её же плагина к студии, и научить плагин стартовать несколько параллельных сессий

Вот до такой эквилибристики мне ещё далеко. Но даже то малое, что я освоил — уже даёт такое ощущение, как в детстве велосипед. Типа "заскочить" на другой конец деревни на гусей посмотреть превращается в из путешествия на полдня в моментальный полёт туда-обратно.

Здравствуйте, Sinclair, Вы писали:

PD>>Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.
S>Я ничего не дезавуировал. Просто не нужно читать то, чего нет в тексте

Или не удалять постфактум (то есть после моих замечаний) свою строку. Я-то первый раз цитировал, когда она там еще была


S>И вот когда все это уже отработало, и можно бы уже и PR мерджить, приходит ИИ. И всё ещё находит проблемы, которые ни один из предыдущих инструментов не увидел.
S>Так понятно?

Вполне. Ради бога, я же не против. Я вполне за. Было N инструментов, добавился N+1-й. Очень хорошо. Только панацею из него делать не надо.

PD>>Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.
S>Это работает в обе стороны.

Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ. Аргумент тут простой — статический анализ , не запуская код, обнаруживает ошибки, значит, может быть и тест, который эту же ошибку обнаружит. Если такой тест сделать вообще нельзя, то это ошибка ли ?
Другое дело, что статический анализ прост и для него есть инструменты. Натравил их — получи. А тесты делать надо, да и есть риск того, что именно под эту ошибку тест и не будет сделан.

Так что да, они дополняют друг друга.

PD>>Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.
S>Конечно. Но code coverage работает в одну сторону, а ИИ умеет в противоположную: "сделай code coverage = 95%".

PD>>Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.
S>Перед ИИ не ставится такая задача. Вернёмся к старту топика:
S>

S>1. Освоить имеющийся материал по этому фреймворку
S>2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
S>3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
S>4. Разработать свой код в качестве contibutor и предложить pull request
S>5. Принять этот pull request (или отвергнуть его)
S>6. Внести изменения в release и сделать следующую версию.

S>Где тут "сколько раз выполнялся данный метод"? Нету? Ну и правильно. Потому что мы обсуждаем темы уровня "принять этот PR или отвергнуть". Сможет это сделать профайлер?

Все было бы верно, если бы не пресловутая удаленная фраза насчет работы ИИ после юнит-тестов. Половина нашей дискуссии из-за нее и возникла. Я эту фразу понял как способность ИИ запускать тесты и анализировать их прохождение. А это без методов типа профайлинга невозможно. Вот я и задал вопрос — как ему это удается. Ну а коль в это обсуждение мы перешли, то естественно было мне упомянуть и те инструменты, которые это делают.

PD>>Вот так и ИИ войдет в этой области.
S>

Пусть входит, бога ради.


PD>>Вполне принимаю. Пусть ищет. Еще один инструмент.
S>Всё верно. Он не заменяет существующие инструменты. Он работает поверх них.

Ну не совсем поверх, скорее параллельно. Поверх профайлера он все же не работает, как мы выяснили уже.

PD>>Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ?
S>А почему нет? Он прекрасно поддерживает такие дискуссии. И изменения показывает, и обосновывает почему. И ошибается, бывает — и так же, как коллегу, ему на это указываешь, и он исправляет. В отличие от коллеги, он доступен 24 часа в сутки, и не начинает ныть, что ты придираешься, и что он устал, и вообще ты сам должен понимать, что тут написано, а если нет — иди нафиг, не умеешь ревьювить — не берись.

PD>>И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.
S>Не убедят — не примешь изменение. Делов-то.

В том-то и дело, что черт его знает. Не принять точечное изменение, которое сделала IDEA — несложно. И то, если пустить ее на автомате делать эти изменения, потом придется просматривать все изменения. А вот если это сделает ИИ, да еще на per-project основе, внося изменения по данной проблеме в несколько файлов кода — поди потом найди изменения, относящиеся именно к этой проблеме и отличи их от других. А если он еще несколькими взаимосвязанными проблемами одновременно займется, то тут, боюсь, кроме полного отказа от его изменений ничего и не может быть.

PD>>Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами.
S>Всё так и работает. Не, можно вайбкодить и в стиле "напиши мне какую-нибудь сетевую игру. Не трогай меня, пока всё не будет готово", но результат будет не сильно лучше, чем если такую же задачу поставить десятикласснику.
S>А в нормальном подходе разработка ведётся в режиме диалога. Ставишь задачу — он обрисовывает варианты её реализации, ты утверждаешь какой-то из них (или объясняешь, почему ни один не подходит, и вы продолжаете дискуссию до принятия решения), это документируется. Если решение затрагивает другие, уже решённые задачи — в их спецификации вносятся исправления, или, наоборот, в текущую доку вносятся исправления, чтобы противоречий не было.
S>Дальше он к этой реализации предлагает варианты архитектуры, ты утверждаешь какой-то из них. Точно так же — если где-то в документах есть что-то несогласующееся с новой архитектурой, это обсуждается и правится.
S>Дальше он предлагает тест-план, который опять же утверждаешь ты. Потом он пишет тесты по этому плану, потом код. Потом гоняет код и тесты, пока они не заработают. Потом он замеряет coverage и добивает тесты до нужного уровня покрытия. Потом, если надо, выполняется бенчмаркинг, анализируются результаты, и ты принимаешь решение — обновить требования перформанса, или оптимизировать. Предлагаются варианты стратегий оптимизации, обсуждаются. Утверждённый вариант документируется, и так далее.

Звучит хорошо. Насколько реально все это можно, и не будет ли ситуации вроде ответа от вполне человеческих служб (ну вроде чата поддержки какого-то банка, где уже удалось пробиться через бота к реальному человеку, но этот человек все шлет и шлет свои стандартные ответы вместо того, чтобы ответить по существу — и делает это потому, что среди стандартных ответов у него ответа на мой вопрос нет, а за их пределы он выйти не имеет права) — не знаю. Но хотелось бы посмотреть на реальный лог таких общений по какому-то, пусть не слишком сложному проекту. Чтобы понять, что из этого фактически сейчас имеет место быть

PD>>А то ведь может крайне неприятная ситуация возникнуть. Вот есть у меня код, который я писал и тестировал несколько лет назад. Я ему вполне доверяю и о нем не думаю. А в нем ошибка все же есть, только она никогда не проявлялась, так уж вышло. Я этот код в новый проект вставил, без анализа. Он ошибку в нем нашел. Спасибо ему. И поправил. И неверно поправил, потому что он что-то в моем коде не понял. И результатом этого исправления будет вот что. Код будет работать иначе для этого редкого случая, может и лучше. Вот только в половине остальных обычных случаях он работать перестанет. И что мне теперь делать, если, начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей
S>Как что? Прогнать цикл регрессионного тестирования, естественно. Не может же быть такого, что код был не покрыт тестами? А если вдруг так случилось, что был непокрыт, то надо не с поиска ошибки начинать, а с фиксации дизайна в тестах и подъёме покрытия до 90-95%. А уже потом рассматривать любые идеи про починку. ИИ тут ничего не меняет — ну, кроме 10х подьёма продуктивности разработчика, поэтому те вещи, которые раньше откладывались с мыслью "да тут полгода пердолиться нужно" делаются за выходные.

Про тесты понятно. И покрыто было. И после его изменений половина тестов упала. А вот про любые идеи про починку понятно меньше. Я же написал — начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей. Так что на починку может уйти очень много времени.
Поэтому будет лучше, если он сам вносить изменения не будет, а предложит их мне для обсуждения. Может, я вообще эти изменения отвергну. Ну нашел он ошибку, которая нефатальна и может проявиться раз в 100 лет. Ну и черт с ней. Или не черт с ней, а скажи просто, в чем она заключается. Я после этого пойму, насколько она серьезна. Может, и исправлю, если за 10 минут смогу, а может, не стану — пусть через 100 лет кто-то ее поправит

В общем, я против автоматического редактирования кода.

Здравствуйте, Sinclair, Вы писали:

>Ну вот начальник собственно и попросил LLM "взломать" код её же плагина к студии, и научить плагин стартовать несколько параллельных сессий


Ох, гляди. Доиграетесь.

Король немедля принялся так и так исправность машины испытывать; разок даже приказал ей по телеграфу, чтобы она отколола электроколенце; было ему интересно, правду ли говорят инженеры, что машина эта может все делать. Если она все может, размыслил король, — так пусть подерется. Однако содержание депеши подверглось небольшому искажению, и машина вместо приказа учинить электродраку получила приказ учинить электродракона; и как можно лучше она исполнила заданную программу.
...
аппарат тук-тук-тук, да тук-тук-тук, и отстукал такую телеграмму: «Электродракон депешей повелевает Воемужу Храбрунишке убираться прочь, ибо он, дракон, на его троне воссесть намерен!»

https://teremok.in/Pisateli/Zarub_Pisateli/lem/tsifrovaja_mashina.htm

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Или не удалять постфактум (то есть после моих замечаний) свою строку. Я-то первый раз цитировал, когда она там еще была
Я ничего не удалял.
PD>Вполне. Ради бога, я же не против. Я вполне за. Было N инструментов, добавился N+1-й. Очень хорошо. Только панацею из него делать не надо.
Никто и не делает. Вы спрашиваете — мы отвечаем.

PD>Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ.
Нет. Термином "тест" называют в нашей отрасли вполне конкретную штуку, а именно запуск тестируемого кода и последующий анализ рантайм-поведения.
А термином "статический анализ" называют другую вполне конкретную штуку, а именно попытки выявить особенности поведения кода без запуска.
Смешивать термины не надо — это только снижает конструктивность дискуссии. Иначе "статическим анализом" можно назвать также и запуск кода в тестовом окружении на всём множестве возможных входных данных

PD>Другое дело, что статический анализ прост и для него есть инструменты. Натравил их — получи. А тесты делать надо, да и есть риск того, что именно под эту ошибку тест и не будет сделан.
Смиялсо. Статического анализа есть великое множество видов, и далеко не все из них сводятся к запуску инструмента на файле исходников.
Например, дедуктивная верификация и модел чекинг тоже относятся к статическому анализу (причём к самой ценной его разновидности — той, у которой нет false positives).
Но простой бы я их не назвал — требуются существенные усилия как при реализации инструментов, так и при подготовке кода к такой верификации.

PD>Все было бы верно, если бы не пресловутая удаленная фраза насчет работы ИИ после юнит-тестов.
Нет никакой удалённой строчки. Просто кое-кто прочёл "после" как "на основе", и отсюда пошла целая ветка заблуждений.
PD>Я эту фразу понял как способность ИИ запускать тесты и анализировать их прохождение.
И такая возможность тоже есть, но в том примере, ссылку на который я дал, она не использовалась.
PD>А это без методов типа профайлинга невозможно.
Конечно возможно. Человек вполне успешно может запускать тесты, смотреть на результат, и исправлять ошибки безо всякой помощи профайлера.

PD>Ну не совсем поверх, скорее параллельно. Поверх профайлера он все же не работает, как мы выяснили уже.
Повторю простую мысль: и поверх профайлера он тоже может работать. Просто в указанном мной примере он этого не делает.

PD>В том-то и дело, что черт его знает. Не принять точечное изменение, которое сделала IDEA — несложно. И то, если пустить ее на автомате делать эти изменения, потом придется просматривать все изменения. А вот если это сделает ИИ, да еще на per-project основе, внося изменения по данной проблеме в несколько файлов кода — поди потом найди изменения, относящиеся именно к этой проблеме и отличи их от других.
Что за странные фантазии?
Во-первых, есть системы контроля версий и инструменты diff.
Во-вторых, ИИ-агентов тоже не идиоты писали, поэтому любой агент показывает, что именно он изменил, не заставляя разработчика бегать за ним вручную и реконструировать набор правок.
Более того, он эти диффы снабжает пояснениями на человеческом языке — что именно он сделал и зачем.
И в зависимости от настроек он эти диффы может не применять даже локально, пока пользователь их не подтвердит.
Рукоятку параноидальности можно крутить в обе стороны — от ручного подтверждения каждой правки в каждый файл, до автоматической отправки PR в репозиторий.

PD>А если он еще несколькими взаимосвязанными проблемами одновременно займется, то тут, боюсь, кроме полного отказа от его изменений ничего и не может быть.
Ну так это и к кожаным мешкам тоже относится. Как поставлена задача — так и будет делать. Попросишь решить сразу семь проблем — займётся семью проблемами.
Потребуешь решить одну — постарается решить одну, а если потребуется вылезти за пределы выданных полномочий — попросит разрешения.

PD>Звучит хорошо. Насколько реально все это можно, и не будет ли ситуации вроде ответа от вполне человеческих служб (ну вроде чата поддержки какого-то банка, где уже удалось пробиться через бота к реальному человеку, но этот человек все шлет и шлет свои стандартные ответы вместо того, чтобы ответить по существу — и делает это потому, что среди стандартных ответов у него ответа на мой вопрос нет, а за их пределы он выйти не имеет права) — не знаю. Но хотелось бы посмотреть на реальный лог таких общений по какому-то, пусть не слишком сложному проекту. Чтобы понять, что из этого фактически сейчас имеет место быть
А что останавливает? Сбер свои инструменты бесплатно вроде раздаёт. Это если жалко двух тыщ рублей за полноценного агента.

PD>Про тесты понятно. И покрыто было. И после его изменений половина тестов упала. А вот про любые идеи про починку понятно меньше. Я же написал — начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей. Так что на починку может уйти очень много времени.
Тогда делаем revert и едем дальше.
PD>В общем, я против автоматического редактирования кода.
Против так против. А зачем тогда спрашивать "а может ли ИИ автоматически редактировать код"?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Или не удалять постфактум (то есть после моих замечаний) свою строку. Я-то первый раз цитировал, когда она там еще была
S>Я ничего не удалял.

Да, верно. Я просто пытался эту фразу найти и не нашел. Посмотрел версии — там она стоит как удаленная, но лишь потому, что добавлено продолжение. Признаю свою ошибку.

PD>>Вполне. Ради бога, я же не против. Я вполне за. Было N инструментов, добавился N+1-й. Очень хорошо. Только панацею из него делать не надо.
S>Никто и не делает. Вы спрашиваете — мы отвечаем.

Ну и хорошо.

PD>>Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ.
S>Нет. Термином "тест" называют в нашей отрасли вполне конкретную штуку, а именно запуск тестируемого кода и последующий анализ рантайм-поведения.
S>А термином "статический анализ" называют другую вполне конкретную штуку, а именно попытки выявить особенности поведения кода без запуска.
S>Смешивать термины не надо — это только снижает конструктивность дискуссии. Иначе "статическим анализом" можно назвать также и запуск кода в тестовом окружении на всём множестве возможных входных данных

Что действительно не надо — это при цитировании вырезать кусок моего ответа таким образом, что искажается смысл. Вот как он выглядел в оригинале. Удаленное при цитировании отметил жирным.

PD>Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ. Аргумент тут простой — статический анализ , не запуская код, обнаруживает ошибки, значит, может быть и тест, который эту же ошибку обнаружит. Если такой тест сделать вообще нельзя, то это ошибка ли ?

Так что речь идет не о смешении терминов, а просто о том, что если статический анализ находит ошибку, то можно сделать тест, который эту ошибку ловит при его прохождении.

Если с этим не согласны , из этого следует, что статический анализ может обнаружить ошибки, которые никогда в рантайме не проявляются (тест сделать нельзя). Несколько странное утверждение получится.


PD>>Все было бы верно, если бы не пресловутая удаленная фраза насчет работы ИИ после юнит-тестов.
S>Нет никакой удалённой строчки. Просто кое-кто прочёл "после" как "на основе", и отсюда пошла целая ветка заблуждений.

Именно так. Но если просто "после" и не указывая, что этот запуск не имеет отношения к работе ИИ и ИИ его никак не учитывает — я имел право понимать, что и это им используется. Стоит формулировать точнее. А еще стоило бы просто сразу сказать — ИИ срабатывает после выполнения тестов, но их выполнение никакого отношения к его работе не имеет. Я же об этом ясно спрашивал — да или нет ? Был бы дан сразу ответ "не имеет" — не было бы и этой ветки.


PD>>Я эту фразу понял как способность ИИ запускать тесты и анализировать их прохождение.
S>И такая возможность тоже есть, но в том примере, ссылку на который я дал, она не использовалась.
PD>>А это без методов типа профайлинга невозможно.
S>Конечно возможно. Человек вполне успешно может запускать тесты, смотреть на результат, и исправлять ошибки безо всякой помощи профайлера.

Тут речь не об ошибках в тестах и их исправлении (это и так понятно), а про то, что в этих тестах исполнялось и что нет, (вне связи с тем, прошли тесты или нет) , какие были результаты в плане использования памяти, времени и т.д. Это только профайлер может.

PD>>Ну не совсем поверх, скорее параллельно. Поверх профайлера он все же не работает, как мы выяснили уже.
S>Повторю простую мысль: и поверх профайлера он тоже может работать. Просто в указанном мной примере он этого не делает.

Совершенно верно, только не может (в том виде, как Вы его действия описали), а сможет (когда-нибудь). Вот если он действительно будет запускать тесты с профилировкой (может, с существующим профайлером, может, со специально для него написанным), то он сможет анализировать все результаты профайлинга и делать выводы.
Более того. Теоретически я могу представить себе некий ИИ — профайлер, который будет код профилировать, как это обычно и делается, но в котором будет ИИ — блок, который по ходу профилировки будет делать ИИ заключения, а потом (или опять же по ходу действия) выдаст, что он о работе этого кода думает. Вот это действительно мощный инструмент получится — сейчас мы чаще всего лишь видим лог профайлера, и даже если видим в рантайме, то выводы делать нам трудно, скорость работы нашего процессора нет та

PD>>В том-то и дело, что черт его знает. Не принять точечное изменение, которое сделала IDEA — несложно. И то, если пустить ее на автомате делать эти изменения, потом придется просматривать все изменения. А вот если это сделает ИИ, да еще на per-project основе, внося изменения по данной проблеме в несколько файлов кода — поди потом найди изменения, относящиеся именно к этой проблеме и отличи их от других.
S>Что за странные фантазии?
S>Во-первых, есть системы контроля версий и инструменты diff.
S>Во-вторых, ИИ-агентов тоже не идиоты писали, поэтому любой агент показывает, что именно он изменил, не заставляя разработчика бегать за ним вручную и реконструировать набор правок.
S>Более того, он эти диффы снабжает пояснениями на человеческом языке — что именно он сделал и зачем.
S>И в зависимости от настроек он эти диффы может не применять даже локально, пока пользователь их не подтвердит.

О господи! Ну неужели я не знаю про cvs и diff ? Я же вовсе не о том говорю, как эти изменения потом увидеть человеку. Это и так понятно. А вот как потом определить, с какими изменениями стоит согласиться, какие стоит отвергнуть, а какие, возможно, не принять, но внести изменения самому, при том, что эти изменения могут иметь достаточно сложную логику и затрагивать несколько файлов — вот это и вопрос.

PD>>А если он еще несколькими взаимосвязанными проблемами одновременно займется, то тут, боюсь, кроме полного отказа от его изменений ничего и не может быть.
S>Ну так это и к кожаным мешкам тоже относится. Как поставлена задача — так и будет делать. Попросишь решить сразу семь проблем — займётся семью проблемами.
S>Потребуешь решить одну — постарается решить одну, а если потребуется вылезти за пределы выданных полномочий — попросит разрешения.

Совершенно верно. Это и к людям так же относится. Но с одним существенным отличием. Если, скажем, я написал код, а потом кто-то его серьезно правит, то теперь именно он скорее ответственен за этот код. Он мой код понял и серьезно изменил, он и отвечает. Я могу вообще устраниться, да может, меня в этом проекте уже и нет, так что мне поздно претензии предъявлять. Это теперь код под его ответственностью, а он, положим, имеет квалификацию не ниже моей.
А тут под чьей ответственностью ? Передать этот код целиком ИИ, пусть он за все и отвечает ? . Не получится. Отвечать все равно человеку.

PD>>Звучит хорошо. Насколько реально все это можно, и не будет ли ситуации вроде ответа от вполне человеческих служб (ну вроде чата поддержки какого-то банка, где уже удалось пробиться через бота к реальному человеку, но этот человек все шлет и шлет свои стандартные ответы вместо того, чтобы ответить по существу — и делает это потому, что среди стандартных ответов у него ответа на мой вопрос нет, а за их пределы он выйти не имеет права) — не знаю. Но хотелось бы посмотреть на реальный лог таких общений по какому-то, пусть не слишком сложному проекту. Чтобы понять, что из этого фактически сейчас имеет место быть
S>А что останавливает? Сбер свои инструменты бесплатно вроде раздаёт. Это если жалко двух тыщ рублей за полноценного агента.

Да нет, поздно мне уже. Я лучше просто посмотрю, что у других получится.

PD>>Про тесты понятно. И покрыто было. И после его изменений половина тестов упала. А вот про любые идеи про починку понятно меньше. Я же написал — начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей. Так что на починку может уйти очень много времени.
S>Тогда делаем revert и едем дальше.

Это не сложно, но это просто отказ от его изменений.

S>Против так против. А зачем тогда спрашивать "а может ли ИИ автоматически редактировать код"?

А я разве спрашивал, может ли он это делать ? Особенно с учетом того, что я как раз и приводил примеры, когда это делается автоматически даже без всякого ИИ (в той же IDEA). Я несколько о другом говорил — стоит ли ему это доверять, и если доверять, какие тут проблемы могут возникнуть.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ. Аргумент тут простой — статический анализ , не запуская код, обнаруживает ошибки, значит, может быть и тест, который эту же ошибку обнаружит. Если такой тест сделать вообще нельзя, то это ошибка ли ?
PD>Так что речь идет не о смешении терминов, а просто о том, что если статический анализ находит ошибку, то можно сделать тест, который эту ошибку ловит при его прохождении.
Это как раз понятно. Я просто плохо объясняю: статический анализ не обязательно находит ошибку. Но его принципиальное отличие от тестирования — в получаемых результатах.

Когда мы запустили тесты, то есть четыре возможности:
1. Тесты показали фейл, ошибка — в тестах
2. Тесты показали фейл, ошибка — в коде
3. Тесты прошли успешно, в коде есть неотловленные ошибки.
4. Тесты прошли успешно, в коде ошибок нет
Отличить ситуацию 3 от 4 невозможно даже теоретически.
Верификатор даёт три возможных результата:
1. Код точно нарушает спецификацию (и у нас есть контрпример)
2. Код точно соответствует спецификации (и мы это доказали)
3. Не удалось провести верификацию.
Вот этот пункт 3 внешне похож на пункт 3 из списка выше, но благодаря существованию пункта 2, можно считать такой вариант фейлом и требовать продолжить разметку кода до тех пор, пока верификатор не получит тот или иной результат.
Но это далеко не всегда проще, чем писать тесты. Проектов с хорошим тестовым покрытием — в избытке. Ткни в любой гитхаб, и там всё красивенько.
А вот проектов, покрытых верификацией, единицы.

PD>Если с этим не согласны , из этого следует, что статический анализ может обнаружить ошибки, которые никогда в рантайме не проявляются (тест сделать нельзя). Несколько странное утверждение получится.
Это демагогия. Это примерно как рассуждать о спортлото как источнике заработка. Ведь выигрышные последовательности номеров существуют — кто мешает просто писать их на билетиках?
Так и тут — почему бы вам просто не писать тесты сразу с контрпримерами к коду.
Вопрос не в том, можно ли проверить выигрышность билета. А в том, чтобы найти способ подобрать за разумные деньги выигрышный набор номеров.

PD>Именно так. Но если просто "после" и не указывая, что этот запуск не имеет отношения к работе ИИ и ИИ его никак не учитывает — я имел право понимать, что и это им используется. Стоит формулировать точнее. А еще стоило бы просто сразу сказать — ИИ срабатывает после выполнения тестов, но их выполнение никакого отношения к его работе не имеет. Я же об этом ясно спрашивал — да или нет ? Был бы дан сразу ответ "не имеет" — не было бы и этой ветки.
Ну так он и был сразу дан. Цитирую:

Нет, я говорю о том, что обычные, не ИИ инструменты в проекте уже есть. И они все ничего не нашли. А вот ИИ посмотрел — и увидел, что логика нарушена.

PD>Совершенно верно, только не может (в том виде, как Вы его действия описали), а сможет (когда-нибудь). Вот если он действительно будет запускать тесты с профилировкой (может, с существующим профайлером, может, со специально для него написанным), то он сможет анализировать все результаты профайлинга и делать выводы.
Всё это он уже умеет. Агент может делать примерно всё, что делаете вы.
В том числе — запускать тесты с инструментированием и смотреть на результаты code coverage.
В том числе — запускать тесты с инструментированием и смотреть на результаты профилирования.
Примерно любой современный тулчейн управляется из командной строки и выдаёт результаты в виде того или иного текста. LLM отлично справляются с порождением команд и разбором результатов. DIXI.

PD>Более того. Теоретически я могу представить себе некий ИИ — профайлер, который будет код профилировать, как это обычно и делается, но в котором будет ИИ — блок, который по ходу профилировки будет делать ИИ заключения, а потом (или опять же по ходу действия) выдаст, что он о работе этого кода думает. Вот это действительно мощный инструмент получится — сейчас мы чаще всего лишь видим лог профайлера, и даже если видим в рантайме, то выводы делать нам трудно, скорость работы нашего процессора нет та
Не очень понятно, что имеется в виду. Обычно мы видим не столько лог профайлера, сколько некую рассчитанную из неё статистику. Потому что сам по себе лог мало-мальски интересного приложения — это миллионы точек, их вручную читать бессмысленно. По одному отсчёту делать какие-то выводы тоже не имеет смысла.
Ну так вот ИИ, конечно же, умеет читать выхлоп этих инструментов и делать из них выводы. Не "по ходу профилировки", естественно, а по его итогам.
Если вас интересуют инструменты, которые используют профилирование на ходу, то ИИ тут незачем — он слишком дорогой и медленный. Вот tiered JIT — это как раз оно. Когда из исполняемого прямо сейчас кода выбираются самые влияющие на производительность кусочки и переоптимизируются (с использованием собранных к этому моменту профилей).
У нас вот и спецкурс на эту тему в университете ежегодно читают

PD>О господи! Ну неужели я не знаю про cvs и diff ? Я же вовсе не о том говорю, как эти изменения потом увидеть человеку. Это и так понятно. А вот как потом определить, с какими изменениями стоит согласиться, какие стоит отвергнуть, а какие, возможно, не принять, но внести изменения самому, при том, что эти изменения могут иметь достаточно сложную логику и затрагивать несколько файлов — вот это и вопрос.
Ну, так для этого человеку интеллект и дан.
Если человек на такое неспособен, то пусть делегирует сложную работу ИИ. Тот прекрасно может оценить, стоит ли делать определённые изменения, и нет ли в них нежелательных побочных эффектов.
Именно такой пример я привёл по ссылке.

PD>Совершенно верно. Это и к людям так же относится. Но с одним существенным отличием. Если, скажем, я написал код, а потом кто-то его серьезно правит, то теперь именно он скорее ответственен за этот код. Он мой код понял и серьезно изменил, он и отвечает. Я могу вообще устраниться, да может, меня в этом проекте уже и нет, так что мне поздно претензии предъявлять. Это теперь код под его ответственностью, а он, положим, имеет квалификацию не ниже моей.
Боюсь, если вы возьмёте джуна на работу и не станете проверять его код, то потом свалить ответственность на него под тем предлогом, что он что-то там много всего изменил, не выйдет. Ну, то есть джуна-то может быть и накажут (а может быть и нет — если окажется, что он не нарушал никаких инструкций), а вот его куратору (то есть вам) выпишут по первое число.

PD>А тут под чьей ответственностью ? Передать этот код целиком ИИ, пусть он за все и отвечает ? . Не получится. Отвечать все равно человеку.
Мне даже любопытно стало — о какой ответственности речь? На моей памяти за косяки в коде даже выговоров никому не объявляли.
Потому, что в хорошо организованной работе стабильность кода держится не на личном подвиге отдельных разработчиков, а на общей инженерной культуре и процессах.
Если культуры и процессов нету — то код, скорее всего, будет говном и у живого человека. Ну, разве что ваша фамилия Накамура .
А если есть культура и процессы — то ни джун, ни сениор, ни ИИ не сможет нанести существенного вреда. Ни случайно, ни намеренно.

PD>Да нет, поздно мне уже. Я лучше просто посмотрю, что у других получится.
Странно. Любопытство вроде есть, а желания его удовлетворить нету.
Вы ж все равно чужим рассказам не поверите.

PD>А я разве спрашивал, может ли он это делать ?
Мне не сложно повторно процитировать:

...
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
...
Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?

Здравствуйте, Sinclair, Вы писали:

S>Когда мы запустили тесты, то есть четыре возможности:
S>1. Тесты показали фейл, ошибка — в тестах
S>2. Тесты показали фейл, ошибка — в коде
S>3. Тесты прошли успешно, в коде есть неотловленные ошибки.
S>4. Тесты прошли успешно, в коде ошибок нет
S>Отличить ситуацию 3 от 4 невозможно даже теоретически.
S>Верификатор даёт три возможных результата:
S>1. Код точно нарушает спецификацию (и у нас есть контрпример)
S>2. Код точно соответствует спецификации (и мы это доказали)
S>3. Не удалось провести верификацию.
S>Вот этот пункт 3 внешне похож на пункт 3 из списка выше, но благодаря существованию пункта 2, можно считать такой вариант фейлом и требовать продолжить разметку кода до тех пор, пока верификатор не получит тот или иной результат.
S>Но это далеко не всегда проще, чем писать тесты. Проектов с хорошим тестовым покрытием — в избытке. Ткни в любой гитхаб, и там всё красивенько.
S>А вот проектов, покрытых верификацией, единицы.

Все это можно сказать короче.
Статический анализ может сказать о наличии ошибок в коде, которые в настоящий момент тестами не определяются. Тесты для этих ошибок сделать можно, но это может быть затруднительно без предварительного статического анализа — мы можем просто не догадаться их сделать. Ну и писать тесты сложнее и требует больше затрат, чем натравить статический анализатор (хоть ИИ, хоть не ИИ) и посмотреть результат.

Так что предмета спора я тут не вижу. Одно другому не мешает, они дополняют друг друга. Но тем не менее в принципе тесты могут обнаружить все ошибки, обнаруживаемые статическим анализатором.


PD>>Более того. Теоретически я могу представить себе некий ИИ — профайлер, который будет код профилировать, как это обычно и делается, но в котором будет ИИ — блок, который по ходу профилировки будет делать ИИ заключения, а потом (или опять же по ходу действия) выдаст, что он о работе этого кода думает. Вот это действительно мощный инструмент получится — сейчас мы чаще всего лишь видим лог профайлера, и даже если видим в рантайме, то выводы делать нам трудно, скорость работы нашего процессора нет та
S>Не очень понятно, что имеется в виду. Обычно мы видим не столько лог профайлера, сколько некую рассчитанную из неё статистику. Потому что сам по себе лог мало-мальски интересного приложения — это миллионы точек, их вручную читать бессмысленно. По одному отсчёту делать какие-то выводы тоже не имеет смысла.

Имеется в виду, что не статистику (которая выдается по окончании профайлинга) он будет анализировать, а прямо по ходу профайлинга смотреть, что происходит и делать выводы.

S>Если вас интересуют инструменты, которые используют профилирование на ходу, то ИИ тут незачем — он слишком дорогой и медленный. Вот tiered JIT — это как раз оно. Когда из исполняемого прямо сейчас кода выбираются самые влияющие на производительность кусочки и переоптимизируются (с использованием собранных к этому моменту профилей).
S>У нас вот и спецкурс на эту тему в университете ежегодно читают

А в сети его нет или его материалов ? Я бы посмотрел, интересно. На спецкурс ваш я не запишусь

PD>>О господи! Ну неужели я не знаю про cvs и diff ? Я же вовсе не о том говорю, как эти изменения потом увидеть человеку. Это и так понятно. А вот как потом определить, с какими изменениями стоит согласиться, какие стоит отвергнуть, а какие, возможно, не принять, но внести изменения самому, при том, что эти изменения могут иметь достаточно сложную логику и затрагивать несколько файлов — вот это и вопрос.
S>Ну, так для этого человеку интеллект и дан.
S>Если человек на такое неспособен, то пусть делегирует сложную работу ИИ. Тот прекрасно может оценить, стоит ли делать определённые изменения, и нет ли в них нежелательных побочных эффектов.
S>Именно такой пример я привёл по ссылке.

Речь же идет о том, что ИИ эти изменения уже сделал. Теперь ревю человеком. А Вы что, предлагаете тут ИИ самого себя ревьюировать ,

PD>>Совершенно верно. Это и к людям так же относится. Но с одним существенным отличием. Если, скажем, я написал код, а потом кто-то его серьезно правит, то теперь именно он скорее ответственен за этот код. Он мой код понял и серьезно изменил, он и отвечает. Я могу вообще устраниться, да может, меня в этом проекте уже и нет, так что мне поздно претензии предъявлять. Это теперь код под его ответственностью, а он, положим, имеет квалификацию не ниже моей.
S>Боюсь, если вы возьмёте джуна на работу и не станете проверять его код, то потом свалить ответственность на него под тем предлогом, что он что-то там много всего изменил, не выйдет. Ну, то есть джуна-то может быть и накажут (а может быть и нет — если окажется, что он не нарушал никаких инструкций), а вот его куратору (то есть вам) выпишут по первое число.

Джуна — да. Но джуну обычно поручают сравнительно локальные изменения, с более или менее конкретно поставленной задачей. А ответственность за этот код будет не у джуна, а у куратора его. И ему действительно выпишут. Так что здесь все ясно — есть человек, который ответственность и несет. Тут все ясно.

PD>>А тут под чьей ответственностью ? Передать этот код целиком ИИ, пусть он за все и отвечает ? . Не получится. Отвечать все равно человеку.
S>Мне даже любопытно стало — о какой ответственности речь? На моей памяти за косяки в коде даже выговоров никому не объявляли.

Антон, Вы что-то самому себе противоречите. Вы же только что написали (см. чуть выше, выделили жирным)

А теперь вдруг Вам стало неясно, о какой ответственности может идти речь.

Разумеется, не юридический это вопрос. И не о наказании речь идет, хоть джуна, хоть сеньора. А о том, что этот сеньор, взявшись за разработку этого куска проекта, несет ответственность за ее выполнение и сроки. Неужели это надо объяснять ?

S>Потому, что в хорошо организованной работе стабильность кода держится не на личном подвиге отдельных разработчиков, а на общей инженерной культуре и процессах.
S>Если культуры и процессов нету — то код, скорее всего, будет говном и у живого человека. Ну, разве что ваша фамилия Накамура .
S>А если есть культура и процессы — то ни джун, ни сениор, ни ИИ не сможет нанести существенного вреда. Ни случайно, ни намеренно.

Одно другому не мешает. Разумеется, культура работы должна быть. И в случае ухода или болезни разработчика его кто-то должен заменить. Но пока он на месте, за этот код отвечает в основном именно он.

PD>>Да нет, поздно мне уже. Я лучше просто посмотрю, что у других получится.
S>Странно. Любопытство вроде есть, а желания его удовлетворить нету.

Поздно.

S>Вы ж все равно чужим рассказам не поверите.

Просто рассказам — не поверю, мало ли что говорят. Увижу своими глазами подробный лог — почему не поверю, вполне могу и поверить.

PD>>А я разве спрашивал, может ли он это делать ?
S>Мне не сложно повторно процитировать:
S>

S>...
S>3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
S>4. Разработать свой код в качестве contibutor и предложить pull request
S>5. Принять этот pull request (или отвергнуть его)
S>...
S>Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?

Спасибо за цитату, но в нижних строках нашей дискуссии мы давно уже обсуждали не это, а вопрос, стоит ли поручать ИИ вносить изменения в код, написанный человеком. Я не спрашивал, может ли ИИ делать такие изменения, и странно было бы спрашивать, если я разговор об этом начал с того, что упомянул изменения, которые делает IDEA и сказал, что я их не очень люблю.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все это можно сказать короче.
PD>Статический анализ может сказать о наличии ошибок в коде, которые в настоящий момент тестами не определяются. Тесты для этих ошибок сделать можно, но это может быть затруднительно без предварительного статического анализа — мы можем просто не догадаться их сделать. Ну и писать тесты сложнее и требует больше затрат, чем натравить статический анализатор (хоть ИИ, хоть не ИИ) и посмотреть результат.
Нет. Тесты принципиально ничего не могут нам сказать о поведении кода за пределами списка тестовых случаев. А для любых мало-мальски интересных задач количество возможных вариантов входных данных запредельно велико.

Стат.анализ может, в отличие от тестов, сказать "ошибок ТОЧНО НЕТ". Не "я не нашёл", а "их нет".

PD>Так что предмета спора я тут не вижу. Одно другому не мешает, они дополняют друг друга. Но тем не менее в принципе тесты могут обнаружить все ошибки, обнаруживаемые статическим анализатором.
Тут не спор, а скорее обсуждение точки зрения. Нас, вообще говоря, не интересует "поиск ошибок". Поэтому бессмысленно обсуждать, способна ли одна технология найти те ошибки, которые находит другая.
Нас интересует доказательство отсутствия ошибок.

PD>Имеется в виду, что не статистику (которая выдается по окончании профайлинга) он будет анализировать, а прямо по ходу профайлинга смотреть, что происходит и делать выводы.
Нереалистично. Профилирование это адски затормозит, а особой ценности в инфе, полученной "по ходу", а не интегрально за полчаса, нету.

PD>А в сети его нет или его материалов ? Я бы посмотрел, интересно.
Нету. Это сбертех читает, у них материалы закрытые.
PD>На спецкурс ваш я не запишусь
Ну там ничего принципиально нового нет. Машинке HotSpot уже почти тридцать лет. Материалов про то, как она выбирает, какой из методов оптимизировать/деоптимизировать, и когда принимаются такие решения — полно.

PD>Речь же идет о том, что ИИ эти изменения уже сделал. Теперь ревю человеком. А Вы что, предлагаете тут ИИ самого себя ревьюировать ,
Именно. Если лень ревьювить — можно делегировать. Ну, то есть можно писать руками, ревьювить ИИ. Можно дать написать ИИ, ревьювить руками. Можно попросить один ИИ написать, а другой — отревьювить.
Или даже один и тот же ИИ, только сначала в режиме творчества, а потом в режиме критики.

PD>Джуна — да. Но джуну обычно поручают сравнительно локальные изменения, с более или менее конкретно поставленной задачей.
Ну так и перед ИИ никто вас не заставляет ставить задачи эпических масштабов. Можно, конечно, использовать промпт вроде "вот тебе доступ к репозиторию, измени код так, чтобы у нас продажи выросли в два раза без роста затрат на саппорт". А потом бегать и всем рассказывать, что все ИИ — тупые и делают чё попало.
А можно поручить сравнительно локальные изменения, с более или менее конкретно поставленной задачей.
PD>Антон, Вы что-то самому себе противоречите. Вы же только что написали (см. чуть выше, выделили жирным)
Не, не противоречу. В реальной работе дюлей дают не за код, а за нарушение процедур. То есть если в коде баги — ну, дело житейское. Надо спрашивать не с того, кто написал код с багой, а с тех, кто допустил этот код до запуска на клиенте. Почему QA не нашли? Если потому, что это стреляет только когда звёзды определённым образом встают — то одно. А если потому, что кто-то решил неполный набор тестов прогнать для ускорения релиза — то другое. Почему на код ревью не было поймано? Если потому, что код ревью не было — то виноват тот, кто этот код смёрджил без ревью.

PD>Одно другому не мешает. Разумеется, культура работы должна быть. И в случае ухода или болезни разработчика его кто-то должен заменить. Но пока он на месте, за этот код отвечает в основном именно он.
Ну так всё верно. Так это и работает. И тут совершенно неважно, участвовал ли в подготовке кода джун или ИИ. Разработчик отвечает за то, чтобы верно их запромптить, и потом проверить результат.
PD>Просто рассказам — не поверю, мало ли что говорят. Увижу своими глазами подробный лог — почему не поверю, вполне могу и поверить.
Ну, может кто-то и опубликует такой лог.