Во-первых, ограничимся достаточно узкой областью. Какой-нибудь open source фреймворк.
Что тут вообще может делать интеллект, неважно какой.
1. Освоить имеющийся материал по этому фреймворку
2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
6. Внести изменения в release и сделать следующую версию.
ЕИ все это может. Разумеется, разные представители ЕИ
Ну ладно, (6) мы пока ИИ не поручим
(1) — (2) ИИ вроде как может.
Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?
Иными словами, сможет он стать разработчиком нового или останется только компилятором существующего ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может ли он (3) — (5) ?
Может. Да и с пунктом 6 проблем нет. Тут скорее вопрос насколько это отвечает ожиданиям потребителя, пока еще ИИ не может этого оценить. Как говорится "красота в глазах смотрящего".
PD>Если сейчас не может — сможет ли ?
В будущем сможет еще лучше
PD>Иными словами, сможет он стать разработчиком нового или останется только компилятором существующего ?
Это философский вопрос. Есть мнение, что и люди не изобретают новое с нуля, а составляют из зарных известных частей.
GPT делает именно это — "понимает нетривиальную логику" (настраивает параметры на воспроизводство этой логики) составления сложного текста или изображения, может как разбирать существующие тексты\изображения, так и генерировать новые на основе входных данных.
Уже сейчас есть ИИ который генерирует гипотезы для научных работ и отсекает заведомо нежизнеспособные.
Здравствуйте, gandjustas, Вы писали:
PD>>Может ли он (3) — (5) ? G>Может.
Пример можно ? Код, созданный ИИ и принятый в репозиторий. Разумеется , код какого-то фреймворка, а не просто проекта. И, конечно, без его правки человеком.
>Да и с пунктом 6 проблем нет. Тут скорее вопрос насколько это отвечает ожиданиям потребителя, пока еще ИИ не может этого оценить. Как говорится "красота в глазах смотрящего".
С 6 проблем технических нет, это понятно, просто едва ли это нужно сейчас — кто ответственность будет нести ?
PD>>Иными словами, сможет он стать разработчиком нового или останется только компилятором существующего ? G>Это философский вопрос. Есть мнение, что и люди не изобретают новое с нуля, а составляют из зарных известных частей.
Как сказать... В каком-то смысле все, что ни было придумано, имеет какой-то аналог в предыдущем. Совсем уж с нуля сложно.
И тем не менее.
Можно, конечно, говорить, что тот, кто изобрел колесо, катал ошкуренные куски стволов и догадался. Но все же колесо — это скорее новое, а не из известных частей.
И ракета тоже, кстати.
G>Уже сейчас есть ИИ который генерирует гипотезы для научных работ и отсекает заведомо нежизнеспособные.
Гипотезы разные бывают.
Гипотезы, скажем, о влиянии тех или иных функциональных групп в молекуле или о пространственном расположении их на активность в качестве лекарства для такой-то болезни — вполне возможно. Это базируется на накопленном опыте таких исследований, а ИИ может перебирать миллионы комбинаций и рекомендовать те, которые наилучшим образом соответствуют имеющимся представлениям.
Гипотезы фундаментального типа, где нет аналогов — не уверен. Смог бы он, если бы был тогда, предложить гипотезу о дуализме электрона (частица-волна) ? Базируясь на всем массиве информации того времени ? Или, скажем, предложить гипотезу о кварках, причем не на уровне умозрительных общих соображений (вроде атомарной теории Демокрита), а с предсказанием их типов и взаимодействия ?
Да ладно гипотезы. Смог бы он принцип фон Неймана сформулировать ? Вычислительные машины уже были, электронные лампы тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>Может ли он (3) — (5) ? G>>Может.
PD>Пример можно ? Код, созданный ИИ и принятый в репозиторий. Разумеется , код какого-то фреймворка, а не просто проекта. И, конечно, без его правки человеком.
Недавно пробегало https://github.com/wilsonzlin/fastrender
А еще у меня есть на работе проект, который внешняя команда с помощью ChatGPT делает. Там не 100% когда сгенерировано, но порядка 80% минимум. я и сам переодически прошук написать какой-то код ИИшку, когда знаю что она даст или 100% результат или близкий к нему.
>>Да и с пунктом 6 проблем нет. Тут скорее вопрос насколько это отвечает ожиданиям потребителя, пока еще ИИ не может этого оценить. Как говорится "красота в глазах смотрящего". PD>С 6 проблем технических нет, это понятно, просто едва ли это нужно сейчас — кто ответственность будет нести ?
Это смотря что вы понимаете под словом ответственность.
PD>>>Иными словами, сможет он стать разработчиком нового или останется только компилятором существующего ? G>>Это философский вопрос. Есть мнение, что и люди не изобретают новое с нуля, а составляют из заранее известных частей. PD>Как сказать... В каком-то смысле все, что ни было придумано, имеет какой-то аналог в предыдущем. Совсем уж с нуля сложно. PD>И тем не менее. PD>Можно, конечно, говорить, что тот, кто изобрел колесо, катал ошкуренные куски стволов и догадался. Но все же колесо — это скорее новое, а не из известных частей.
Увы мы не знаем ничего про то, как было изобретено колесо, поэтому можем догадываться только.
PD>И ракета тоже, кстати.
Серьезно?
То есть ракеты Циолковскому просто приснились, не было фейерверков в Китае в 10 веке и реактивных снарядов в индии в 18ом?
И как вы себе видите изобретение ракет?
Кстати ответ на этот вопрос я получил с помощью ИИ
G>>Уже сейчас есть ИИ который генерирует гипотезы для научных работ и отсекает заведомо нежизнеспособные. PD>Гипотезы разные бывают. PD>Гипотезы, скажем, о влиянии тех или иных функциональных групп в молекуле или о пространственном расположении их на активность в качестве лекарства для такой-то болезни — вполне возможно. Это базируется на накопленном опыте таких исследований, а ИИ может перебирать миллионы комбинаций и рекомендовать те, которые наилучшим образом соответствуют имеющимся представлениям.
Думаете ученые действуют от озарения? Увы, они также перебирают, используют направленный перебор, эвристики итд. Вот сейчас им ИИ помогает.
PD>Гипотезы фундаментального типа, где нет аналогов — не уверен. PD>Смог бы он, если бы был тогда, предложить гипотезу о дуализме электрона (частица-волна) ?
Она же базировалась на дуализме фотонов, который был известен давно — преломление света (ведет себя как волна волна) и фотоэффект (ведет себя как частица). Луи де Бройль потом выдвинул гипотезу, что электрон ведет себя также, как фотон, проявляя двойственность. Дальнейшие эксперименты гипотезу подтвердили. Базируясь на всем массиве информации того времени ? Или, скажем, предложить гипотезу о кварках, причем не на уровне умозрительных общих соображений (вроде атомарной теории Демокрита), а с предсказанием их типов и взаимодействия ?
Мог ли ИИ выдвинуть такую гипотезу на основе знаний о дуализме фотонов и том что электрон тоже проявляет свойство элементарной частицы? Мог конечно, так же перебором соединив два факта. Предсказать взаимодействия не мог, но и на гипотезы де Бройля никто не мог, это уже более поздние работы.
PD>Да ладно гипотезы. Смог бы он принцип фон Неймана сформулировать ? Вычислительные машины уже были, электронные лампы тоже.
Вот тут я не уверен является при принцип фон-неймана фундаментальным законом и вообще верным в любых условиях. Например существует много устройств, построенных по не-фоннеймановской архитектуре.
Поэтому даже "принципом" называть это не стоит, просто одна их архитектур вычислительных устройств.
Мы тут приходим к проблеме: какой промпт надо написать для ИИ, чтобы он в принципе начал что-то полезное генерировать. А уж тем более предложил что-то, что человечеству еще неизвестно.
Промпт инжиниринг сейчас самая сложная часть всей работы с ИИ. Я столько времени иногда трачу на промптинг для простых частей кода, что возможно быстрее было бы самому написать. Как можно исследования так делать — ума не приложу. Там специализированные ИИ и хз как реально они работают.
Удравствуйте, gandjustas, Вы писали:
PD>>Пример можно ? Код, созданный ИИ и принятый в репозиторий. Разумеется , код какого-то фреймворка, а не просто проекта. И, конечно, без его правки человеком. G>Недавно пробегало https://github.com/wilsonzlin/fastrender
Хм. Возможно, я что-то не понял.
Contributors
3
@wilsonzlin
wilsonzlin Wilson Lin
@wilson-anysphere
wilson-anysphere Wilson
@cursoragent
cursoragent Cursor Agent
Первые 2 вроде как люди, а не боты. Третий, возможно, бот, но для него No commits history
G>А еще у меня есть на работе проект, который внешняя команда с помощью ChatGPT делает. Там не 100% когда сгенерировано, но порядка 80% минимум. я и сам переодически прошук написать какой-то код ИИшку, когда знаю что она даст или 100% результат или близкий к нему.
То, что такое возможно , я , конечно не спорю. Но это все же рабочий проект, в котором используется код, написанный ИИ. А я говорил о фреймворках или библиотеках. И не на 80% с ревизией потом человеком этих 80% и дописыванием 20, а целиком.
G>Увы мы не знаем ничего про то, как было изобретено колесо, поэтому можем догадываться только.
Увы...
PD>>И ракета тоже, кстати. G>Серьезно? G>То есть ракеты Циолковскому просто приснились, не было фейерверков в Китае в 10 веке и реактивных снарядов в индии в 18ом? G>И как вы себе видите изобретение ракет? G>Кстати ответ на этот вопрос я получил с помощью ИИ
Я же написал в предыдущем сообщении, что да, почти всегда можно какой-то аналог найти, или хотя бы за уши притащить. Вопрос в том, насколько далеко этот аналог уходит от прототипа.
PD>>Гипотезы, скажем, о влиянии тех или иных функциональных групп в молекуле или о пространственном расположении их на активность в качестве лекарства для такой-то болезни — вполне возможно. Это базируется на накопленном опыте таких исследований, а ИИ может перебирать миллионы комбинаций и рекомендовать те, которые наилучшим образом соответствуют имеющимся представлениям. G>Думаете ученые действуют от озарения? Увы, они также перебирают, используют направленный перебор, эвристики итд. Вот сейчас им ИИ помогает.
Когда да, а когда и от озарения.
Идея Демокрита об атомах — тоже своего рода озарение. Впрочем, она была чисто умозрительной.
Архимед с его "Эврика". "Тело, впернутое в воду...
Яблоко Ньютона
Кекуле, как утверждают, предложил структурную формулу бензола после сна, где он увидел сцепившихся в кольцо хвостами обезьян. Можно, конечно, утверждать, что эти сцепившиеся обезьяны есть прообраз структурной формулы бензола, но это уже будет именно "притянуть за уши".
Похоже, озарением была идея двойной спирали ДНК Крика и Уотсона. Состав белка был уже хорошо известен, но из эти компонентов можно придумать миллионы структур. А тут одну — и сразу все верно.
G>Мог ли ИИ выдвинуть такую гипотезу на основе знаний о дуализме фотонов и том что электрон тоже проявляет свойство элементарной частицы? Мог конечно, так же перебором соединив два факта. Предсказать взаимодействия не мог, но и на гипотезы де Бройля никто не мог, это уже более поздние работы.
Возможно.
PD>>Да ладно гипотезы. Смог бы он принцип фон Неймана сформулировать ? Вычислительные машины уже были, электронные лампы тоже. G>Вот тут я не уверен является при принцип фон-неймана фундаментальным законом и вообще верным в любых условиях. Например существует много устройств, построенных по не-фоннеймановской архитектуре. G>Поэтому даже "принципом" называть это не стоит, просто одна их архитектур вычислительных устройств.
Я имею в виду лишь принцип хранимой программы — то, что она хранится в памяти. Это основное, остальное детали. До фон Неймана "программа" задавалась физической коммутацией схем. Есть ли сейчас компьютеры, где программа не хранится в памяти ?
G>Мы тут приходим к проблеме: какой промпт надо написать для ИИ, чтобы он в принципе начал что-то полезное генерировать.
В переводе на мою преподавательскую деятельность — какой набор инструкций надо выдать студенту, чтобы он начал что-то полезное делать
G>Промпт инжиниринг сейчас самая сложная часть всей работы с ИИ. Я столько времени иногда трачу на промптинг для простых частей кода, что возможно быстрее было бы самому написать. Как можно исследования так делать — ума не приложу. Там специализированные ИИ и хз как реально они работают.
Мне-то уж точно проще было бы самому написать, чем добиться от студента, чтобы он сделал, как я хочу
PD>Первые 2 вроде как люди, а не боты. Третий, возможно, бот, но для него No commits history
Ну кто-то же должен промпты делать. Хотя там первоначально, сразу как они выложили даже не собиралось нормально, и кажется вручную как-раз подправляли.
Вообще сам процесс очень даже впечатляет:
Чтобы протестировать эту систему, мы поставили перед собой амбициозную цель: создание веб-браузера с нуля. Агенты работали примерно неделю и написали больше миллиона строк кода в тысяче файлов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Удравствуйте, gandjustas, Вы писали:
PD>>>Пример можно ? Код, созданный ИИ и принятый в репозиторий. Разумеется , код какого-то фреймворка, а не просто проекта. И, конечно, без его правки человеком. G>>Недавно пробегало https://github.com/wilsonzlin/fastrender
PD>Хм. Возможно, я что-то не понял. PD>Первые 2 вроде как люди, а не боты. Третий, возможно, бот, но для него No commits history
Ну то что там почти 30к коммитов за полтора месяца тебя ни на какие мысли не наталкивает.
Думаешь человек способен хотя бы ревью такого объема провести?
G>>А еще у меня есть на работе проект, который внешняя команда с помощью ChatGPT делает. Там не 100% когда сгенерировано, но порядка 80% минимум. я и сам переодически прошук написать какой-то код ИИшку, когда знаю что она даст или 100% результат или близкий к нему. PD>То, что такое возможно , я , конечно не спорю. Но это все же рабочий проект, в котором используется код, написанный ИИ. А я говорил о фреймворках или библиотеках. И не на 80% с ревизией потом человеком этих 80% и дописыванием 20, а целиком.
Ну сегодня 80%, а через два года это станет 90%, а еще через 5 (очень с запасом срок) — 95%. Твоя риторика изменится?
G>>Увы мы не знаем ничего про то, как было изобретено колесо, поэтому можем догадываться только. PD>Я же написал в предыдущем сообщении, что да, почти всегда можно какой-то аналог найти, или хотя бы за уши притащить. Вопрос в том, насколько далеко этот аналог уходит от прототипа.
Тут не вопрос насколько далеко "изобретение" от существующих знаний, а является ли изобретение какоим-то озарением или открытием, связывающим уже известные нам вещи. Сейчас большинство склоняется к мысли что всё-таки открытие. ИИшка может генерировать варианты возможных открытий связывая вещи по смыслу, которые не догадался связать человек.
PD>Когда да, а когда и от озарения.
А есть пример прям "озарений" в науке?
PD>Идея Демокрита об атомах — тоже своего рода озарение. Впрочем, она была чисто умозрительной. PD>Архимед с его "Эврика". "Тело, впернутое в воду...
Это же скорее исторический анекдот. Опять-таки мы очень мало знаем как было на самом деле.
PD>Яблоко Ньютона
А тут знаем. Я попробую пересказать вкратце то, что рассказывает Фейнман на своих лекциях.
Вкратце: Кеплер еще до рождения Ньютона описал законы движения планет вокруг солнца и луны вокруг земли. Это тоже он не сам придумал, он опирался на данные астронома Тихо Браге, который просто записывал положение планет. Кроме того Кеплер занимался физикой, ввёл понятие инерции, почти открыл закон тяготения.
Ньютон же, опираясь на все знания подготовленные Кеплером, понял, что луна "падает" на землю (но промахивается за счет вращения) с такой же скоростью, как яблоко у поверхности земли. Выдвинул гипотезу о наличии силы притяжения, которая пропорциональна массам и обратно пропорциональна расстоянию. На основе этой гипотезы рассчитали положения небесных тел и ооооооочень точно угадали.
Это не было озарением, как об это принято писать, это была гипотеза которая подтвердилась. Было еще много гипотез, которые не подтвердились, но они не дошли до наших дней.
Через 50 лет после Ньютона Рёмер заметил движения спутников Юпитера не соответствует закону Ньютона, что иногда они появляются в расчетной точке на 8 минут раньше, а иногда на 8 минут позже. Он сделал гипотезу о конечности скорости света. Её применили в расчетах далеких небесных тел, выяснилось что точность расчётов повысилась.
Потом с помощью этих знаний — о притяжении тел друг к другу и конечности скорости света сделали гипотезу что за Сутрном есть еще планета, которая отклоняет траекторию спутников Урана. С развитием оптики там нашли планету, которую назвали Нептун.
Озарений в этой истории я не вижу.
PD>Кекуле, как утверждают, предложил структурную формулу бензола после сна, где он увидел сцепившихся в кольцо хвостами обезьян. Можно, конечно, утверждать, что эти сцепившиеся обезьяны есть прообраз структурной формулы бензола, но это уже будет именно "притянуть за уши". PD>Похоже, озарением была идея двойной спирали ДНК Крика и Уотсона. Состав белка был уже хорошо известен, но из эти компонентов можно придумать миллионы структур. А тут одну — и сразу все верно.
Это до нас дошли имена Крика и Уотсона, потому что они своей гипотезой угадали, до нас не дошли имена тех, кто не угадал.
PD>>>Да ладно гипотезы. Смог бы он принцип фон Неймана сформулировать ? Вычислительные машины уже были, электронные лампы тоже. G>>Вот тут я не уверен является при принцип фон-неймана фундаментальным законом и вообще верным в любых условиях. Например существует много устройств, построенных по не-фоннеймановской архитектуре. G>>Поэтому даже "принципом" называть это не стоит, просто одна их архитектур вычислительных устройств. PD>Я имею в виду лишь принцип хранимой программы — то, что она хранится в памяти. Это основное, остальное детали.
Причем именно в той же памяти, где данные самой программы (однородность памяти). Это важно.
PD> До фон Неймана "программа" задавалась физической коммутацией схем. Есть ли сейчас компьютеры, где программа не хранится в памяти ?
Конечно, сейчас много девайсов, где программа физически отделена от памяти, с которой программа работает — все FPGA.
G>>Мы тут приходим к проблеме: какой промпт надо написать для ИИ, чтобы он в принципе начал что-то полезное генерировать. PD>В переводе на мою преподавательскую деятельность — какой набор инструкций надо выдать студенту, чтобы он начал что-то полезное делать
Именно. Причем ИИ не умеет "разбираться сам". То есть надо выдать очень подробную инскрукцию, с примерами и еще долго пинать потом, чтобы результат был удовлетворительным.
Поэтому браузер, написанный ИИ, по ссылке выше и вызывает такой восторг. Нельзя сейчас даже самому дорогому ИИ сказать "напиши браузер".
G>>Промпт инжиниринг сейчас самая сложная часть всей работы с ИИ. Я столько времени иногда трачу на промптинг для простых частей кода, что возможно быстрее было бы самому написать. Как можно исследования так делать — ума не приложу. Там специализированные ИИ и хз как реально они работают. PD>Мне-то уж точно проще было бы самому написать, чем добиться от студента, чтобы он сделал, как я хочу
Зачастую так и есть.
Вчера генерировал с помощью ИИ код на C# небольшой, но нетривиальной функции.
Я сам этот код написал за два часа, включая изучение необходимой документации.
Давая довольно поддробную иснтрукцию для ИИ и несколько раз пиная его справить ошибки я получил за 40 минут рабочий код.
Если бы писал сам с нуля, уже имея все знания, то сделал бы то же самое быстрее.
Возможно автоматизация процессов за счет агентов и тестов могла бы решить проблему, то есть:
1) Один агент ИИ сгенерировал бы тест-кейсы
2) Второй генерировал бы код по запросу
3) Третий — запускал код второго, собирал фидбек и отдавал второму на исправление
Но я пока не разобрался как это запустить без Claude Code, а за подписку последнего платить не хочу.
Опять таки на каждом шаге промптинг, который тоже непонятно как делать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем понял. Что означает, например
Это фигня, репорт от CI.
PD>Ну а это
PD>
PD>Codex Review
PD>Here are some automated review suggestions for this pull request
PD>вполне умели делать статические анализаторы и без всякого ИИ. Тот же PVS-Studio, например.
Ну, я не знаю, умеют ли PVS-тулзы находить дефекты в проекте неизвестной заранее структуры, и не формальные нарушения паттернов типа "у вас там в метод может передаваться null".
А так задача ставится не просто "проведи статический анализ", а "посмотри, нет ли каких-то проблем в этом PR".
Вот ещё из того же проекта: https://github.com/kimak-irmagi/taidon/pull/28#discussion_r2724783735
Какой PVS сумеет найти проблему
When a job reaches a terminal status, this block only clears fields and cancels the ticker, but it leaves the m.beats[jobID] entry allocated. Because every job that emits any event creates a heartbeatState (see the earlier m.beats[jobID] = state), the map grows monotonically and will retain one entry per completed job for the lifetime of the engine. Over time this becomes a memory leak and increases lock contention on m.mu. Consider deleting the map entry when the status is succeeded/failed (or when canceling) so completed jobs don’t accumulate.
?
Я с удовольствием посмотрю на такой анализатор.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Ну то что там почти 30к коммитов за полтора месяца тебя ни на какие мысли не наталкивает. G>Думаешь человек способен хотя бы ревью такого объема провести?
Тут ты прав. Видимо, автор действительно ИИ. Но см. отзыв FR об этом коде
Но вообще да, признаю, что может.
PD>>То, что такое возможно , я , конечно не спорю. Но это все же рабочий проект, в котором используется код, написанный ИИ. А я говорил о фреймворках или библиотеках. И не на 80% с ревизией потом человеком этих 80% и дописыванием 20, а целиком. G>Ну сегодня 80%, а через два года это станет 90%, а еще через 5 (очень с запасом срок) — 95%. Твоя риторика изменится?
Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ.
PD>>Идея Демокрита об атомах — тоже своего рода озарение. Впрочем, она была чисто умозрительной. PD>>Архимед с его "Эврика". "Тело, впернутое в воду... G>Это же скорее исторический анекдот. Опять-таки мы очень мало знаем как было на самом деле.
Конечно, знаем мало. Но выглядит именно так. Аналогий, который бы его сподвигли на это открытие, я что-то не просматриваю. А закон Архимеда есть.
PD>>Яблоко Ньютона G>А тут знаем. Я попробую пересказать вкратце то, что рассказывает Фейнман на своих лекциях. G>Вкратце: Кеплер еще до рождения Ньютона описал законы движения планет вокруг солнца и луны вокруг земли. Это тоже он не сам придумал, он опирался на данные астронома Тихо Браге, который просто записывал положение планет. Кроме того Кеплер занимался физикой, ввёл понятие инерции, почти открыл закон тяготения.
Это все хорошо известно и без Фейнмана.
G>Ньютон же, опираясь на все знания подготовленные Кеплером, понял, что луна "падает" на землю (но промахивается за счет вращения) с такой же скоростью, как яблоко у поверхности земли. Выдвинул гипотезу о наличии силы притяжения, которая пропорциональна массам и обратно пропорциональна расстоянию. На основе этой гипотезы рассчитали положения небесных тел и ооооооочень точно угадали. G>Это не было озарением, как об это принято писать, это была гипотеза которая подтвердилась. Было еще много гипотез, которые не подтвердились, но они не дошли до наших дней.
Тут много чего было.
Другой приоритетный спор был связан с открытием закона тяготения. Ещё в 1666 году Гук пришёл к выводу, что движение планет есть суперпозиция падения на Солнце благодаря силе притяжения к Солнцу, и движения по инерции по касательной к траектории планеты. По его мнению, эта суперпозиция движения и обусловливает эллиптическую форму траектории планеты вокруг Солнца[81]. Однако доказать это математически он не смог и послал в 1679 году Ньютону письмо, где предложил сотрудничество по решению этой задачи. В этом письме было также изложено предположение об убывании силы притяжения к Солнцу обратно пропорционально квадрату расстояния[82]. В ответ Ньютон заметил, что ранее занимался проблемой движения планет, но оставил эти занятия. Действительно, как показывают найденные впоследствии документы, Ньютон занимался проблемой движения планет ещё в 1665—1669 гг., когда он на основании III закона Кеплера установил, что «стремление планет удалиться от Солнца будет обратно пропорционально квадратам их расстояний от Солнца»[83]. Однако представление об орбите планеты как исключительно результате равенства сил притяжения к Солнцу и центробежной силы у него до конца в те годы ещё не выработалось[83][84].
G>Озарений в этой истории я не вижу.
Ладно, допустим.
PD>>Кекуле, как утверждают, предложил структурную формулу бензола после сна, где он увидел сцепившихся в кольцо хвостами обезьян. Можно, конечно, утверждать, что эти сцепившиеся обезьяны есть прообраз структурной формулы бензола, но это уже будет именно "притянуть за уши".
На это ответа не нашлось ?
PD>>Похоже, озарением была идея двойной спирали ДНК Крика и Уотсона. Состав белка был уже хорошо известен, но из эти компонентов можно придумать миллионы структур. А тут одну — и сразу все верно. G>Это до нас дошли имена Крика и Уотсона, потому что они своей гипотезой угадали, до нас не дошли имена тех, кто не угадал.
Тут тоже не все так просто. Дошли. Не архимедовы все же времена, а середина 20 века.
Кроме Уотсона и Крика структуру ДНК пытались выяснить еще две группы ученых. В Лондоне Морис Уилкинс и Розалинд Франклин, постоянно ругаясь, всматривались в рентгеновские снимки кристаллизованных молекул, а в Калифорнийском технологическом институте над загадкой жизни бился знаменитый химик Лайнус Полинг, который до этого первым определил строение компонентов белков.
...
По рассказам Уотсона, он приезжал в Лондон, чтобы обсудить статью Полинга с Франклин, но та не разделила его энтузиазм и сказала, что молекула ДНК не может быть спиральной.
PD>>Я имею в виду лишь принцип хранимой программы — то, что она хранится в памяти. Это основное, остальное детали. G>Причем именно в той же памяти, где данные самой программы (однородность памяти). Это важно.
А вот это ИМХО не так важно. Если бы фон Нейман предложил сделать 2 памяти — для команд и для данных, то потом, конечно, имели бы кучу ненужных проблем и кто-нибудь другой догадался бы эти 2 памяти свести в одну.. Но тогда это вполне могло пройти, и проблем бы не вызвало, потому что задачи были примитивны. А сам принцип хранимой программы остался бы — именно это главное в его концепции.
G>Конечно, сейчас много девайсов, где программа физически отделена от памяти, с которой программа работает — все FPGA.
Да ради бога. Одна память, несколько памятей однородных (NUMA), одна или несколько неоднородных (VRAM), разные способы обращения и т.д. Это все детали. Главное в его идее именно принцип хранимости программы в памяти. Что данные можно хранить в памяти — понимал не он один, тут гением быть не нужно, а вот что программу можно хранить в памяти — догадался он.
G>Поэтому браузер, написанный ИИ, по ссылке выше и вызывает такой восторг. Нельзя сейчас даже самому дорогому ИИ сказать "напиши браузер".
Ну судя по отзыву FR, восторг так себе.
G>Вчера генерировал с помощью ИИ код на C# небольшой, но нетривиальной функции. G>Я сам этот код написал за два часа, включая изучение необходимой документации. G>Давая довольно поддробную иснтрукцию для ИИ и несколько раз пиная его справить ошибки я получил за 40 минут рабочий код.
А вот такой вопрос задам.
Примем твое доверие к твоему собственному коду, написанному без помощи ИИ за 100.
Тебе нужно сделать некий код. Решил делать с помощью ИИ.
Сколько баллов дашь ему в первой его попытке ?
Сколько баллов дашь ему в окончательном его коде (после всех пинаний)? Дашь 100 ? Или же в финальной версии его когда тебе придется разбираться детально и править его самому, чтобы доверять ему на 100 ?
Условие — ты этот код сам не писал, поэтому решения, с которым можно сравнивать, у тебя нет.
Здравствуйте, FR, Вы писали:
FR>Чтобы протестировать эту систему, мы поставили перед собой амбициозную цель: создание веб-браузера с нуля. Агенты работали примерно неделю и написали больше миллиона строк кода в тысяче файлов. FR>[/q] FR>Но результат очень посредственный https://rsdn.org/forum/flame.comp/9051858.1
FR>Фактически этот браузер равносилен пре-альфа версии движка Blitz в которой всего ~25000 строк раст кода.
И все равно не то. Это написание кода по известному "алгоритму" (в расширенном понимании этого слова).
Приведу пример из своей практики.
Мне была дана задача
На конвертах почтовый индекс в этой стране пишут внутри прямоугольных клеток. Эти клетки мешают потом распознаванию. Убери эти клетки, но не трогай цифры индекса.
Все было бы просто, если бы
1. клетки были всегда горизонтальны-вертикальны. Увы, сканер иногда их получал с наклоном.
2. если бы толщина линий клетки была всегда одной и той же. Увы, сканер иногда часть линий клетки не сканировал, так что линия была прерывистой или переменной толщины
3. и наконец, если бы цифры всегда аккуратно лежали в клетках. Увы, эти чертовы юзеры иногда писали их так, что они за пределы клеток выходили, то есть пересекали их линию или предполагаемую линию, которая не прорисовалась.
4. ну и на закуску — на картинке есть шум, то есть непонятно откуда взявшиеся черные точки.
Тесты ручные сделать невозможно. Есть некий набор картинок, несколько сотен, на них и проверяй.
Исследовательская работа, в общем. Есть идеи. Никакой уверенности, что эта идея сработает, нет. Попробуем, посмотрим, что получится.
Возился я довольно долго. Перепробовал разные методы, ни один из них не давал нужного результата. Так, эта идея вроде и неплохая, линии убирает, но и портит изображение тоже. Как-то можно ее улучшить, чтобы не портила ? Хм, не получается. Смягчаю критерии — оставляет мусор от линий. Но вообще-то что-то в ней есть. Ладно, возьмем от нее, что она может, а дальше будем думать, что делать с тем, что получилось. Нет, не выходит. В корзину эту первоначальную идею, жалко, конечно, но увы.. Пробуем что-то иное. И т.д.
В конце концов все же сделал, комбинируя несколько своих методов, каждый из которых результата не давал, а все вместе дали.
А теперь допустим, что я эти картинки ИИ скормил и как-то задачу сформулировал (убери линии клеток). Справится ?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Ну, я не знаю, умеют ли PVS-тулзы находить дефекты в проекте неизвестной заранее структуры, и не формальные нарушения паттернов типа "у вас там в метод может передаваться null".
Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты. Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
S>Какой PVS сумеет найти проблему S>
S>When a job reaches a terminal status, this block only clears fields and cancels the ticker, but it leaves the m.beats[jobID] entry allocated. Because every job that emits any event creates a heartbeatState (see the earlier m.beats[jobID] = state), the map grows monotonically and will retain one entry per completed job for the lifetime of the engine. Over time this becomes a memory leak and increases lock contention on m.mu. Consider deleting the map entry when the status is succeeded/failed (or when canceling) so completed jobs don’t accumulate.
S>?
Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты.
Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект. PD>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
А ИИ прекрасно анализирует ошибки, размытые между файлами.
PD>Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Речь о неполной очистке. Когда мы какой-то из объектов разрушили, а соответствующий ему объект из мапы удалить забыли.
PD>Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но ИИ нашёл, что нигде в проекте этой очистки нет. И что по логике, которая там присутствует явно в виде документов проекта на естественном языке и неявно — в виде структуры кода, очистку нужно делать именно тут.
PD>Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
This block — это не класс. Это просто текст на английском языке: "в этом блоке выполняется очистка задания, достигшего терминального статуса". PD>https://pvs-studio.com/en/blog/posts/cpp/0543/
Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
З.Ы. Важно обратить внимание на формат подачи. Это не просто "правило ES-0051 нарушено в строке такой-то", и сиди разбирайся — то ли это false positive, то ли реальный баг.
А на нормальном, человеческом языке написан комментарий про суть проблемы (в терминах проекта, а не линтера). Ровно так же, как это написал бы мега-внимательный, хорошо разбирающийся в коде проекта ревьювер.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>То, что такое возможно , я , конечно не спорю. Но это все же рабочий проект, в котором используется код, написанный ИИ. А я говорил о фреймворках или библиотеках. И не на 80% с ревизией потом человеком этих 80% и дописыванием 20, а целиком. G>>Ну сегодня 80%, а через два года это станет 90%, а еще через 5 (очень с запасом срок) — 95%. Твоя риторика изменится? PD>Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ.
Ты же сам понимаешь ущербность этой позиции?
Если что без человека вообще ничего ии пока не умеет. Кто-то должен поставить задачу и "принять" результат.
PD>>>Кекуле, как утверждают, предложил структурную формулу бензола после сна, где он увидел сцепившихся в кольцо хвостами обезьян. Можно, конечно, утверждать, что эти сцепившиеся обезьяны есть прообраз структурной формулы бензола, но это уже будет именно "притянуть за уши". PD>На это ответа не нашлось ?
А я что-то пропустил в предыдщем ответе этот абзац.
Могу сказать что почему-то "озарения" приходят к тем, кто долго темой занимается и собрал много знаний.
Всего один случай есть, когда "озарение" пришло человеку, не владеющему огромных объемом накопленных ранее знаний — математик из индии Сриниваса Рамануджан. И то до сих пор люди сомневаются что его история не преукрашена.
PD>>>Похоже, озарением была идея двойной спирали ДНК Крика и Уотсона. Состав белка был уже хорошо известен, но из эти компонентов можно придумать миллионы структур. А тут одну — и сразу все верно. G>>Это до нас дошли имена Крика и Уотсона, потому что они своей гипотезой угадали, до нас не дошли имена тех, кто не угадал.
PD>Тут тоже не все так просто. Дошли. Не архимедовы все же времена, а середина 20 века. PD>
PD>Кроме Уотсона и Крика структуру ДНК пытались выяснить еще две группы ученых. В Лондоне Морис Уилкинс и Розалинд Франклин, постоянно ругаясь, всматривались в рентгеновские снимки кристаллизованных молекул, а в Калифорнийском технологическом институте над загадкой жизни бился знаменитый химик Лайнус Полинг, который до этого первым определил строение компонентов белков.
PD>...
PD>По рассказам Уотсона, он приезжал в Лондон, чтобы обсудить статью Полинга с Франклин, но та не разделила его энтузиазм и сказала, что молекула ДНК не может быть спиральной.
То есть было много вариантов, но одна группа ученых таки уагадала, а остальные нет.
Вот ИИ предлагает генкрирова гипотезы. А может быть найдется другой ИИ, который эти гипотезы будет тестировать.
PD>>>Я имею в виду лишь принцип хранимой программы — то, что она хранится в памяти. Это основное, остальное детали. G>>Причем именно в той же памяти, где данные самой программы (однородность памяти). Это важно.
PD>А вот это ИМХО не так важно.
Конечно же важно. на этом он построил строгие доказательства эквиваленности проблем останова и вычислимости.
PD>Если бы фон Нейман предложил сделать 2 памяти — для команд и для данных, то потом, конечно, имели бы кучу ненужных проблем и кто-нибудь другой догадался бы эти 2 памяти свести в одну.. Но тогда это вполне могло пройти, и проблем бы не вызвало, потому что задачи были примитивны. А сам принцип хранимой программы остался бы — именно это главное в его концепции.
Как раз наоборот он предложил такой вариант, потому что в реализации он был сильно проще. Только с развитием микроэлектроники канал доступа к памяти стал узким местом и появились другие инженерные решения.
Это если не говорить о формализме.
G>>Поэтому браузер, написанный ИИ, по ссылке выше и вызывает такой восторг. Нельзя сейчас даже самому дорогому ИИ сказать "напиши браузер". PD>Ну судя по отзыву FR, восторг так себе.
Ты серьезно?
ИИ смог написать браузер. За полтора месяца нагенерив 30к коммитов и десятки (сотни?) тысяч строк. Да с багами, но он запускается, открывает сайты.
ты сможешь повторить этот результат? Никто из известных мне программистов не сможет это повторить в те же сроки.
G>>Вчера генерировал с помощью ИИ код на C# небольшой, но нетривиальной функции. G>>Я сам этот код написал за два часа, включая изучение необходимой документации. G>>Давая довольно поддробную иснтрукцию для ИИ и несколько раз пиная его справить ошибки я получил за 40 минут рабочий код.
PD>А вот такой вопрос задам.
PD>Примем твое доверие к твоему собственному коду, написанному без помощи ИИ за 100. PD>Тебе нужно сделать некий код. Решил делать с помощью ИИ. PD>Сколько баллов дашь ему в первой его попытке ? PD>Сколько баллов дашь ему в окончательном его коде (после всех пинаний)? Дашь 100 ? Или же в финальной версии его когда тебе придется разбираться детально и править его самому, чтобы доверять ему на 100 ? PD>Условие — ты этот код сам не писал, поэтому решения, с которым можно сравнивать, у тебя нет.
не понимаю вопроса... Если это баллы доверия, то я любому написанному не мной коду, который я до этого не видел, который не проходил никаких тестов и не использовался другими людьми, я доверяю на ноль.
Я его читаю и уровень доверия повышается.
Но это я рассуждаю как программист. А если бы я рассуждал как человек, которому нужна программа, и который вообще не лезет в код, то какая разница кем она написана, лишь бы работала.
Здравствуйте, Sinclair, Вы писали:
S>Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект.
Ну так PVS Studio и давали файл кода. Больше ничего.
PD>>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил. S>А ИИ прекрасно анализирует ошибки, размытые между файлами.
Этого у него тогда не было, но это было лет 10 назад. С тех пор я с ним дела не имел. Да и его тогда для C# вроде как не было, а для Java только в альфа-версии.
S>Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
Чего ради он будет делать то, для чего он не предназначен ? Он вообще про PR не знал тогда ИМХО, и не уверен, что сейчас знает. Его дело файл с кодом проанализировать и потенциальные ошибки найти. По крайней мере тогда так было.
S>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
А вот это уже интереснее. Линтеры и верификаторы — бог с ними, а вот юнит-тесты — это интересно. Насколько я понимаю, такое можно сделать только если запускать код под собой и контролировать его выполнение. Это уже не статический анализ, а контроль в рантайме. Профайлеры это умеют, но они инструментируют байт-код. Для С++ это неплохо умел покойный Bounds Checker, я им студентов долго мучил. А тут как и кто ? Используется некий инструмент ? И он есть только в этом ИИ, а отдельно его нет ? Чтобы я сам под ним свои unit тесты запустил ? Хм...
S>З.Ы. Важно обратить внимание на формат подачи. Это не просто "правило ES-0051 нарушено в строке такой-то", и сиди разбирайся — то ли это false positive, то ли реальный баг. S>А на нормальном, человеческом языке написан комментарий про суть проблемы (в терминах проекта, а не линтера). Ровно так же, как это написал бы мега-внимательный, хорошо разбирающийся в коде проекта ревьювер.
Ну и там вполне нормальные сообщения были, а не просто ES-0051. Номер лишь для ссылки на документацию, там дается подробная информация об этом типе ошибки, иногда с примерами.
Здравствуйте, gandjustas, Вы писали:
PD>>Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ. G>Ты же сам понимаешь ущербность этой позиции? G>Если что без человека вообще ничего ии пока не умеет. Кто-то должен поставить задачу и "принять" результат.
Ну он же должен прогрессировать . Почему бы ему со временем самому все мои пункты 1-6 не сделать ? Так что ущербности не вижу.
Я же не требую, чтобы это было завтра. Он вообще это сможет ?
PD>>>>Кекуле, как утверждают, предложил структурную формулу бензола после сна, где он увидел сцепившихся в кольцо хвостами обезьян. Можно, конечно, утверждать, что эти сцепившиеся обезьяны есть прообраз структурной формулы бензола, но это уже будет именно "притянуть за уши". PD>>На это ответа не нашлось ?
G>А я что-то пропустил в предыдщем ответе этот абзац. G>Могу сказать что почему-то "озарения" приходят к тем, кто долго темой занимается и собрал много знаний.
Мы тут уйдем в дебри психологии, подсознательного и т.д. Предлагаю не углубляться в эти дебри. Но вообще-то да. Ни с того ни с сего , не будучи в теме вообще, открытие вряд ли сделаешь.
Хотя... Был такой Шлиман. Дилетант в археологии. Прочитал Илиаду и сказал — Троя вот тут должна быть. Поехал и раскопал Трою. Правда, потом возникли сомнения, та ли это Троя.
А другие, вполне специалисты в археологии, так и не нашли ее и были потом страшно обижены.
PD>>Тут тоже не все так просто. Дошли. Не архимедовы все же времена, а середина 20 века. PD>>
PD>>Кроме Уотсона и Крика структуру ДНК пытались выяснить еще две группы ученых. В Лондоне Морис Уилкинс и Розалинд Франклин, постоянно ругаясь, всматривались в рентгеновские снимки кристаллизованных молекул, а в Калифорнийском технологическом институте над загадкой жизни бился знаменитый химик Лайнус Полинг, который до этого первым определил строение компонентов белков.
PD>>...
PD>>По рассказам Уотсона, он приезжал в Лондон, чтобы обсудить статью Полинга с Франклин, но та не разделила его энтузиазм и сказала, что молекула ДНК не может быть спиральной.
G>То есть было много вариантов, но одна группа ученых таки уагадала, а остальные нет.
Сложнее. Они как-то прямо точно, почти без серьезных изменений потом "выстрелили". На удивление верно. Причем подтверждение рентгеноструктурным анализом появилось потом. А тут какое-то наитие.
G>Вот ИИ предлагает генкрирова гипотезы. А может быть найдется другой ИИ, который эти гипотезы будет тестировать.
Вполне возможно, но в варианте Крика-Уотсона идею не тестировали. Просто они ее высказали и потом уже оказалось , что она верна.
PD>>>>Я имею в виду лишь принцип хранимой программы — то, что она хранится в памяти. Это основное, остальное детали. G>>>Причем именно в той же памяти, где данные самой программы (однородность памяти). Это важно.
PD>>А вот это ИМХО не так важно. G>Конечно же важно. на этом он построил строгие доказательства эквиваленности проблем останова и вычислимости.
Да ради бога. Это все существенно, и я не спорю. Но если бы он лишь одно сказал — программу надо хранить в памяти, как числа и там выполнять — этого было бы достаточно. Потом анализировали бы и наводили теорию. А принцип бы остался.
Вот еще один пример. Тед Хофф. Первый микропроцессор. Идея — ЭВМ на одном кристалле. До него ЭВМ были и БИС тоже. А вот ЭВМ на одной БИС не было. Он придумал. А что потом из всего этого вышло — сам знаешь. Но идея его, он создателем МП так и останется. Хотя Intel 4004 не совсем то же, что Intel i7
PD>>Если бы фон Нейман предложил сделать 2 памяти — для команд и для данных, то потом, конечно, имели бы кучу ненужных проблем и кто-нибудь другой догадался бы эти 2 памяти свести в одну.. Но тогда это вполне могло пройти, и проблем бы не вызвало, потому что задачи были примитивны. А сам принцип хранимой программы остался бы — именно это главное в его концепции. G>Как раз наоборот он предложил такой вариант, потому что в реализации он был сильно проще. Только с развитием микроэлектроники канал доступа к памяти стал узким местом и появились другие инженерные решения. G>Это если не говорить о формализме.
Я же говорю — это все детали. Могло быть так, а могло быть иначе. Или вначале так, а потом иначе. А принцип хранимой программы, а не коммутируемых схем — он навсегда.
G>>>Поэтому браузер, написанный ИИ, по ссылке выше и вызывает такой восторг. Нельзя сейчас даже самому дорогому ИИ сказать "напиши браузер". PD>>Ну судя по отзыву FR, восторг так себе. G>Ты серьезно? G>ИИ смог написать браузер. За полтора месяца нагенерив 30к коммитов и десятки (сотни?) тысяч строк. Да с багами, но он запускается, открывает сайты. G>ты сможешь повторить этот результат? Никто из известных мне программистов не сможет это повторить в те же сроки.
Нет, я точно не повторю. Но вот тут самое интересное.
Он может генерировать со скоростью, намного большей чем человек или даже команда. Это неудивительно. Интересно другое — а когда он по качеству будет давать то, что сравнимо с кодом команды профессионалов ? Пока что по отзыву FR качество так себе. Я судить не берусь о нем. Но если это качество не достигнет того, что могут делать профессионалы — это же будет примерно то же, что собрать сотню студентов 3 курса и поручить им разработку. Даже если они владеют всем, что нужно для этой разработки (или смогут найти) — это же не значит, что они качественный продукт сделают. Что-то сделают, допустим, вот только вылетать это будет чаще, чем работать.
И наплодят они этот код, вот только не получится, как здесь — по другому поводу сказанное, конечно
https://libverse.ru/ivanov-a/hlopci-i-shekspiri.html
PD>>Примем твое доверие к твоему собственному коду, написанному без помощи ИИ за 100. PD>>Тебе нужно сделать некий код. Решил делать с помощью ИИ. PD>>Сколько баллов дашь ему в первой его попытке ? PD>>Сколько баллов дашь ему в окончательном его коде (после всех пинаний)? Дашь 100 ? Или же в финальной версии его когда тебе придется разбираться детально и править его самому, чтобы доверять ему на 100 ? PD>>Условие — ты этот код сам не писал, поэтому решения, с которым можно сравнивать, у тебя нет. G>не понимаю вопроса... Если это баллы доверия, то я любому написанному не мной коду, который я до этого не видел, который не проходил никаких тестов и не использовался другими людьми, я доверяю на ноль. G>Я его читаю и уровень доверия повышается.
Ну нет. Ты вполне используешь код от серьезных фирм и не исследуешь его. Я не думаю, что ты анализировал код библиотек коллекций от MS или Sun/Oracle. Ты ему просто доверяешь (что не отменяет , конечно, тестирования, но своего кода, использующего их, а не его). Или, скажем, берешь код откуда-то, но знаешь, что его автор тоже известный и хороший программист.
G>Но это я рассуждаю как программист. А если бы я рассуждал как человек, которому нужна программа, и который вообще не лезет в код, то какая разница кем она написана, лишь бы работала.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну так PVS Studio и давали файл кода. Больше ничего.
А тут — не "файл", а проект. На смеси языков.
PD>Этого у него тогда не было, но это было лет 10 назад. С тех пор я с ним дела не имел. Да и его тогда для C# вроде как не было, а для Java только в альфа-версии.
А при чём тут C#?
PD>Чего ради он будет делать то, для чего он не предназначен ?
Тогда зачем его приводить в качестве решения п.5?
PD>А вот это уже интереснее. Линтеры и верификаторы — бог с ними, а вот юнит-тесты — это интересно. Насколько я понимаю, такое можно сделать только если запускать код под собой и контролировать его выполнение. Это уже не статический анализ, а контроль в рантайме. Профайлеры это умеют, но они инструментируют байт-код. Для С++ это неплохо умел покойный Bounds Checker, я им студентов долго мучил. А тут как и кто ? Используется некий инструмент ? И он есть только в этом ИИ, а отдельно его нет ? Чтобы я сам под ним свои unit тесты запустил ? Хм...
Нет, я говорю о том, что обычные, не ИИ инструменты в проекте уже есть. И они все ничего не нашли. А вот ИИ посмотрел — и увидел, что логика нарушена.
PD>https://pvs-studio.ru/ru/docs/warnings/v1051/
PD>Вот что мне бы выдалось
PD>V1051. It is possible that an assigned variable should be checked in the next condition. Consider checking for typos.
Ну вот это и есть шаблонный текст с кодом ошибки. PD>В общем, вполне понятно, а для если непонятно — см. пояснения и примеры на этой странице. Что ему, их все в диагностику мне выдать ?
Нет. Я же привёл пример. ИИ в отличие от шаблонных анализаторов пишет понятным языком "Код открывает файл лога вызовом CreateFile(), но её результат не проверяется. Поэтому при неудаче открытия запись FileWeite на три строки ниже не сработает".
Не, я меня нет задачи убедить кого-то, что божьей искры не существует. Но ИИ сейчас успешно берёт на себя функции, которые ещё год назад казались подвластными _исключительно_ человеку.
Как насчёт задачки "проверь соответствие кода спецификации"? Спецификация — на естественном языке, записана в маркдауне.
Или "найди противоречия в документации проекта". Вот прямо так, даже без перечисления файлов документации.
Или "найди все ссылки в документах проекта и сделай их гиперссылками", где под "ссылкой" понимается любое упоминание вроде "список констант лежит в файле consts.hpp в папке common".
Всё это никакие линтеры и ПВЗ студии не делают.
Ладно, пёс с ним, допустим, PVS Studio нашла V1051. Исправить эту проблему в коде она может?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>Не изменится. Пока не будет 100% без участия человека. Как сейчас человек может 100% без участия ИИ. G>>Ты же сам понимаешь ущербность этой позиции? G>>Если что без человека вообще ничего ии пока не умеет. Кто-то должен поставить задачу и "принять" результат.
PD>Ну он же должен прогрессировать . Почему бы ему со временем самому все мои пункты 1-6 не сделать ? Так что ущербности не вижу. PD>Я же не требую, чтобы это было завтра. Он вообще это сможет ?
Он вообще это делает уже сейчас. Браузер же появился.
PD>Вполне возможно, но в варианте Крика-Уотсона идею не тестировали. Просто они ее высказали и потом уже оказалось , что она верна.
А то что другие высказали оказалось неверно и про их высказывания благополучно забыли. Как мы забыли про мировой эфир и другие неверные теории из физики.
Поэтому рулит не "озарение", а перебор вариантов. Вопрос в том, как этот перебор оптимизировать.
PD>Да ради бога. Это все существенно, и я не спорю. Но если бы он лишь одно сказал — программу надо хранить в памяти, как числа и там выполнять — этого было бы достаточно. Потом анализировали бы и наводили теорию. А принцип бы остался.
То есть его "принципы" не являются "законами" как в физике. Для фон Неймана это был удачный формализм чтобы доказывать утверждения, для инженеров это оказалось достаточно хорошей, на тот момент, идеей.
PD>Я же говорю — это все детали. Могло быть так, а могло быть иначе. Или вначале так, а потом иначе. А принцип хранимой программы, а не коммутируемых схем — он навсегда.
Это один из вариантов, не единственный.
PD>Он может генерировать со скоростью, намного большей чем человек или даже команда. Это неудивительно. PD>Интересно другое — а когда он по качеству будет давать то, что сравнимо с кодом команды профессионалов ?
Как ты "качество" измеряешь?
PD> это же будет примерно то же, что собрать сотню студентов 3 курса и поручить им разработку. Даже если они владеют всем, что нужно для этой разработки (или смогут найти) — это же не значит, что они качественный продукт сделают. Что-то сделают, допустим, вот только вылетать это будет чаще, чем работать.
Давай проведем эксперимент — возвращайся когда их браузер хоть что-то откроет.
PD>И наплодят они этот код, вот только не получится, как здесь — по другому поводу сказанное, конечно
Я прекрасно понимаю к чему эта риторика. И прекрасно понимаю, что несмотря на любые успехи ИИ ты будешь доказывать что "не торт", предлагая эксперименты, которые точно провалятся, хотя ты уверен что не будешь их проводить.
PD>Ну нет.
Да
PD>Ты вполне используешь код от серьезных фирм и не исследуешь его.
Там гарантия есть, финансовая. Да и обычно я не использую совершенно неизвестные мне программы. То есть их уже кто-то использовал, они уже прошли какое-то тестирование.
С кодом от ИИ не так, его вообще никто не проверял. Ты всегда первый кто это сделает.
PD>Я не думаю, что ты анализировал код библиотек коллекций от MS или Sun/Oracle.
Я читал и анализировал, довольно много. И опять-таки, я никогда не был первым их пользователем, и вторым тоже не был.
Когда SharePoint занимался прям декомпилировал и читал как оно работает.
PD>Ты ему просто доверяешь (что не отменяет , конечно, тестирования, но своего кода, использующего их, а не его). Или, скажем, берешь код откуда-то, но знаешь, что его автор тоже известный и хороший программист.
Если ты решил мои мысли выдумывать за меня, то не надо.
Здравствуйте, Sinclair, Вы писали:
PD>>Ну так PVS Studio и давали файл кода. Больше ничего. S>А тут — не "файл", а проект. На смеси языков.
В общем, не стоит эту тему продолжать, тем более, что я не знаю, что PVS сейчас может.
S>Нет, я говорю о том, что обычные, не ИИ инструменты в проекте уже есть. И они все ничего не нашли. А вот ИИ посмотрел — и увидел, что логика нарушена.
А все-так, пожалуйста, объясните, как работает. Я что-то вижу противоречие между "ИИ посмотрел — и увидел, что логика нарушена" и словами из прошлого сообщения о том, что он делает свой анализ после запуска unit тестов. На что именно посмотрел ? На код или еще и на результат прохождения юнит-тестов ? Вообще-то юнит — тесты сами либо ничего не сообщают, либо выдают информацию про непрошедшие assert или про падению по исключению. Поэтому просто при их запуске ничего о том, что происходило внутри, узнать не удастся. Получить что-то большее от прохождения юнит-тестов можно только если их запустить под собой, то есть инструментировать код в стиле профайлера или Code Coverage. Это делается или нет ? Если нет, а просто юнит-тесты запускаются — какую информацию ИИ может собрать от их прохождения, чтобы делать выводы? Вот это я пока не понимаю.
S>Нет. Я же привёл пример. ИИ в отличие от шаблонных анализаторов пишет понятным языком "Код открывает файл лога вызовом CreateFile(), но её результат не проверяется. Поэтому при неудаче открытия запись FileWeite на три строки ниже не сработает".
Ну слава богу. Если бы анализатор выдал просто "CreateFile result not checked", то, как говорил Воланд, "Без тебя бы мы никак не догадались об этом". Кстати, о том, что потом используется этот непроверенный хендл, он сообщит, думаю. Тут и без ИИ несложно сделать.
S>Не, я меня нет задачи убедить кого-то, что божьей искры не существует. Но ИИ сейчас успешно берёт на себя функции, которые ещё год назад казались подвластными _исключительно_ человеку. S>Как насчёт задачки "проверь соответствие кода спецификации"? Спецификация — на естественном языке, записана в маркдауне. S>Или "найди противоречия в документации проекта". Вот прямо так, даже без перечисления файлов документации. S>Или "найди все ссылки в документах проекта и сделай их гиперссылками", где под "ссылкой" понимается любое упоминание вроде "список констант лежит в файле consts.hpp в папке common". S>Всё это никакие линтеры и ПВЗ студии не делают.
Я с этим не спорю. PVS не делает, не его это дело. Существуют ли программы без ИИ, которые нечто подобное делают — не знаю, но готов допустить, что без ИИ это невозможно. Вот только все это к 1-6 не имеет отношения, я ограничился только этой тематикой.
S>Ладно, пёс с ним, допустим, PVS Studio нашла V1051. Исправить эту проблему в коде она может?
Нет, конечно. Не ее функции. Она же только статический анализатор кода. Но в принципе ничто не мешает ей это сделать, если потребуется. Уж если она код С++ анализирует, и довольно серьезно, то добавить
if(hFile == INVALID_HANDLE_VALUE) ...
вполне мог бы.
Да бог с ней, с PVS. Мне IDEA для программ на Java то и дело выдает всякие рекомендации типа "этой переменной стоит дать модификатор final" или "лучше заменить вызов лямбда-функции на ссылку на метод" и т.п. Но сама не делает обычно, а предлагает мне подтвердить. Соглашусь — сделает. А еще у нее есть пункт "Code cleanup", и там она автоматом все изменения делает. Я его боюсь
Здравствуйте, 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 "взломать" код её же плагина к студии, и научить плагин стартовать несколько параллельных сессий
Ох, гляди. Доиграетесь.
Король немедля принялся так и так исправность машины испытывать; разок даже приказал ей по телеграфу, чтобы она отколола электроколенце; было ему интересно, правду ли говорят инженеры, что машина эта может все делать. Если она все может, размыслил король, — так пусть подерется. Однако содержание депеши подверглось небольшому искажению, и машина вместо приказа учинить электродраку получила приказ учинить электродракона; и как можно лучше она исполнила заданную программу.
...
аппарат тук-тук-тук, да тук-тук-тук, и отстукал такую телеграмму: «Электродракон депешей повелевает Воемужу Храбрунишке убираться прочь, ибо он, дракон, на его троне воссесть намерен!»
Здравствуйте, 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>Просто рассказам — не поверю, мало ли что говорят. Увижу своими глазами подробный лог — почему не поверю, вполне могу и поверить.
Ну, может кто-то и опубликует такой лог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
