Команда AI for Devs подготовила перевод статьи Miguel Grinberg. Его позиция проста: генеративный ИИ в программировании не даёт реального ускорения, а лишь создаёт новые риски. А что думаете вы?
Меня часто спрашивают, пользуюсь ли я инструментами генеративного ИИ для программирования и что о них думаю. Поэтому я решил изложить свои мысли в статье — так проще отправлять людей сюда, чем каждый раз повторять одно и то же.
Из названия уже понятно, что это не текст «за ИИ». Но и не «против ИИ» тоже, по крайней мере, мне так кажется. Про- и анти-ИИ материалов и без меня хватает, так что писать ещё один в том же ключе смысла не вижу. Хотя у меня есть своё мнение, здесь я хочу поделиться исключительно личным опытом использования этих инструментов — с чисто технической точки зрения.
ИИ не ускоряет
Главная и самая важная причина, по которой инструменты генеративного ИИ мне не подходят, — они не делают меня быстрее. Всё очень просто.
Конечно, я могу попросить такие инструменты сгенерировать за меня код. А ещё удобнее было бы, если бы «агент» редактировал файлы прямо в проекте, пока я занимаюсь чем-то другим. Звучит заманчиво.
Но проблема в том, что отвечать за этот код буду я. Я не могу просто так вставить его в проект и надеяться на лучшее. Чтобы использовать сгенерированный код, я должен внимательно его просмотреть, понять каждую деталь и быть уверен, что смогу доработать его в будущем. Иначе — никак.
Ревью кода, вопреки распространённому мнению, — очень непростая задача. Проверка чужого кода у меня занимает как минимум столько же времени, сколько написание собственного, а то и больше. В нашей сфере даже есть известная фраза: «читать код труднее, чем писать». Кажется, первым это сформулировал Джоэл Спольски (создатель Stack Overflow и Trello) в статье Things You Should Never Do, Part I.
Кто-то может возразить, что код ИИ можно рассматривать как «чёрный ящик»: работает — и ладно, зачем проверять? Но это крайне безответственно. Если что-то пойдёт не так, отвечать буду я, а не ИИ. Идти на такой риск я не готов.
Особенно это критично в проектах, где есть договорные обязательства и деньги. Если меня наняли как профессионала, я должен соответствовать. А инструменты ИИ не помогают мне заработать больше или работать быстрее. Единственный путь «ускориться» — это снизить качество и увеличить риски. На такое я не пойду.
ИИ — не множитель эффективности
Некоторые утверждают, что инструменты генеративного ИИ помогают им работать быстрее и решать более сложные задачи. Но это лишь субъективные ощущения, подтверждений в цифрах нет. Возможно, кто-то и вправду быстрее справляется с ревью кода, чем я, но честно говоря, сомневаюсь. Скорее, такие люди просто просматривают код выборочно или вообще пропускают ревью — а для меня это неприемлемо.
Часто говорят ещё и так: мол, ИИ полезен, когда нужно писать на незнакомом языке или с новой технологией. Но именно в этом и есть кайф работы программистом — в постоянном обучении. Чем больше практикуешься, тем проще и быстрее идёт процесс. За последние годы мне приходилось изучать Rust, Go, TypeScript, WASM, Java и C# для разных проектов — и я бы не стал перекладывать эту задачу на ИИ. Да и не сэкономил бы на этом времени, ведь за результат всё равно отвечаю я.
Код ИИ и код человека — не одно и то же
Недавно я объяснял все эти доводы другу, а он спросил: «А как же open source-вклад в твои проекты? Ты ведь принимаешь чужой код — почему он подходит, а код ИИ нет?»
Честный ответ: сторонние pull request’ы тоже не экономят мне времени, потому что я всё равно провожу тщательное ревью. Но с живыми людьми интересно работать. Они сообщают о багах, предлагают улучшения, вносят вклад. Это источник идей и энергии. Ради таких взаимодействий я и люблю open source.
Друг не сдавался и предложил: «А если запустить пачку ИИ-агентов, чтобы они сразу закрыли все баги?» Казалось бы, «game changer». Но на деле — лишние расходы и только замедление. Даже если представить, что ИИ-инструменты уже достаточно умны (а это не так), узким местом остаюсь я, ведь всё равно обязан проверять каждую строку перед слиянием.
Хуже того, доступность ИИ привела к тому, что некоторые пользователи начали присылать «ленивые» PR’ы, сгенерированные на автомате. У них есть эффект «зловещей долины» — вроде бы код похож на нормальный, но при чтении ощущается искусственность. Я начинаю задавать авторам вопросы по странным участкам, потому что считаю их ответственными за свой вклад. Ответа почти никогда не получаю.
ИИ — не стажёр
Многие сторонники ИИ говорят: относитесь к инструменту как к стажёру. Но те, кто так считает, видимо, никогда не работали со стажёрами.
В начале стажировка действительно снижает вашу продуктивность: нужно много объяснять, всё тщательно проверять. Но в этом есть смысл — стажёры учатся. Вложенное время окупается: они становятся самостоятельными, и в итоге их берут в штат.
ИИ же — это стажёр с антероградной амнезией: каждый раз начинает с нуля, не помня предыдущего опыта. Такой «стажёр» бесполезен.
Заключение
Надеюсь, мне удалось объяснить, почему генеративные ИИ-инструменты неприменимы в моей работе.
На практике бесплатных обедов с ИИ не бывает. Те, кто заявляет, что он делает их быстрее и продуктивнее, просто сознательно снижают требования к качеству. Или же говорят так потому, что сами зарабатывают на продаже ИИ.
Русскоязычное сообщество про AI в разработке
Друзья! Эту статью перевела команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (63)
bromzh
02.09.2025 10:15Ну если не уметь пользоваться - то да, всё плохо.
Huchlers
02.09.2025 10:15Дело даже не в умении, луддиты неспособны мыслить в перспективе, у них память золотой рыбки. Никто уже не помнит, что лишь несколько лет назад никто тоже всерьёз не воспринимал каракули Dalle 1, а сейчас ИИ обманывает ценителей искусства на выставках. То же самое будет и здесь, со временем.
IUIUIUIUIUIUIUI
02.09.2025 10:15И почему конкретно здесь будет то же самое, что и с dall-e, а не то же самое, что с SQL (который обещал дать возможность каждому менеджеру гонять отчёты), или с UML (который обещал дать возможность каждому аналитику создавать приложения без кодинга), или с визуальным программированием (то же), или с $current-year-no/low-code-платформой (то же), причём $current-year начинается очень давно, минимум от informix 4gl из бородатых 80-х?
Я бы скорее сравнивал как раз с SQL и UML, а не с «каракулями dall-e», потому что, упрощая, код либо компилируется, либо нет, тогда как Высокое Искусство — это кругодроч тех самых «ценителей» на ощущение причастности к «понимающим» каракули Пикассо или вообще что-то такое:
thethee
02.09.2025 10:15... Почему будет тоже самое что и с dalle, а не как с SQL/UML?
Потому что эти технологии не имеют способности к саморазвитию. Ну "типа" саморазвитию, сейчас поясню. В SQL нельзя накидать побольше компьюта (железа/бабок) и сделать его сильно лучше, а в нейронки можно. И пока не достигнут реального потолка улучшения будут. Будут казаться минимальными, но каждая доля процента в бенчмарках - это очередная успешно выполненная задача для бизнеса.
Код это на низком уровне это логика, описанная специальным языком. Но на более высоком уровне его можно сравнивать с искусством, т.к. он требует значительной фантазии, если это не дефолтное перекладывание json. Решить вопрос галлюцинаций тем или иным способом, и качество уже приемлемое на сегодняшний день в некоторых задачах.
И технические задачи не ограничиваются только лишь кодом, современные агенты, при наличии инструментов, могут самостоятельно залезть в базу, прочитать значения и порядочно так отдебажить проект, пусть и относительно небольшой, но ещё пару лет назад это казалось сказкой, при том что GPT-3 была прорывом, а GPT-4 - прорывом относительно GPT-3. Но ни та ни другая модель не смогут сделать подобное ни при каких промптах, настройках, линтерах, тестах и прочем. Просто не хватает вычислительной мощности, даже при том что GPT-4 обучалась чуть ли не на всем гитхабе. А современные могут.
Пока нет причин заявлять об AGI/ASI и прочих единорогах, но в правильных руках и с правильной настройкой эта технология уже выглядит как магия - машина с переменным успехом самостоятельно действует в среде с большой неопределенностью. Так что как нет причин верить в безудержный успех, но также и нет причин заявлять о неминуемом крахе/провале.
На мой взгляд это просто очередной инструмент, который в некоторой степени изменит то как ведётся разработка. SQL полезен? Полезен. Не так как предсказывали ведуны, но полезен. UML диаграммы полезны? Наверное, не берусь оценивать то что не знаю, но слышал, что системные аналитики пользуются. Так что и нейросети будут полезны. Вполне возможно, что ни вы, ни я, ни комментатор выше не правы и они найдут свою нишу в какой то конкретной сфере деятельности, а писать код с их помощью будет считаться моветоном. Загадывать на долгосрок бесполезно.
i-netay
02.09.2025 10:15Если не уметь пользоваться компилятором и вместо понимаемого самостоятельно колонна поручать нейронке делать то, чего сам не понял, то да, очень плохо... Или речь про "не уметь" в отношении чего-то другого?
YegorP
02.09.2025 10:15Не сеньор, не джун и не стажёр. Скорее, смесь поисковика, документации и IDE с командной строкой на естественном языке. Всё, о чём вы могли только мечтать как программист любого уровня. Супер-инструмент для одних задач и полная хрень для других, как и любой другой инструмент.
My-name
02.09.2025 10:15Согласен.
Хотя и - тоже приходится ревьювить код от AI, выполняя свои проекты.
Бывает и откровенная лажа. Вот здесь-то и пригождается белковый интеллект.
Потому моя оценка этого инструмента - весьма неплохая. Хоть и требующая, порой, детального анализа,
что это здесь получаем/делаем.
X-P0rt3r
02.09.2025 10:15Примерно так. Но с одной оговоркой: ответ этого мега-IDE-поисковика-CLI имеет до некоторой степени вероятности характер! Это тот принципиальный момент, который совсем нельзя игнорировать.
Вот я - тот самый консерватор-ретроград, луддит и хейтер-ИИ. И вообще не разработчик. Но даже мне приходилось ловить DeepSeek на вранье уже несколько раз. Причем на довольно несложных вопросах типа "Какая последняя версия %IDE% поддерживает %OS%?" Задавалось на английском - What is the latest...
Тут, конечно, можно контраргументировать, мол, а поисковику ты верил слепо на 100%? Нет, конечно. Но выдачу поисковика можно было хотя бы навскидку ранжировать визуально. Скажем, ответы на Стэковерфлоу, Киберфоруме, MSDN - три по сути разные вещи. И глаз был наметан.
Впрочем, поиск в последнее время (5+ лет) тоже неплохо сломан. И выбор инструмента для поиска - условный жабогадюкинг.thethee
02.09.2025 10:15Я для исправления подобных ситуаций (враньё/галлюцинации) сделал себе систему, которая несколько раз выполняет задачу и затем собирает результаты разных выполнений воедино, примерно как работает Deep Research функциональность. Несколько запусков позволяют рассмотреть проблему с разных сторон, и потом собрать воедино результаты. Для кода тоже работает, но дорого выходит по времени выполнения.
Также на редкость хорошо работает ревью кода модели, причем той же моделью, но с очищенным контекстом. Первая всю "версия" пишет код, читает файлы, захламляет свой контекст и скорее всего допускает ошибки, постепенно изменяя код. Вторая версия сразу получает diff готовых изменений, результат выполнения автотестов (если есть), документы по качеству и стилю кода и уже относительно этих изменений формирует инструкции к следующему запуску. Третья версия (снова чистая) получает diff, требуемые исправления, применяет их, и только потом зовётся человек для проверки. В процентах не скажу, но сильно снизилось ощущение недовольства среди знакомых, попробовавших такое, простенькие баги качественно правятся, в некоторых случаях не придраться было. Изъяны остаются, до сложных задач допускают только истинные вайб-кодеры, но и от них тоже положительный фидбэк - меньше итераций вручную проходит фича.
Это все не отменяет ревью и ручного тестирования, но повышает шансы получить качественный результат. Иногда модель может автотесты поправить потому что сдалась, и на третьем этапе опять сдаться и опять внести изменения в тесты - одна из причин почему до сложных задач нельзя допускать. Код будет казаться адекватным, но по факту нерабочий.
0Bannon
02.09.2025 10:15Я тут спросил сравнение часов casio у deepseek. Он мне модель braun bn какую-то назвал. Я удивлся, а это бритва для бритья оказалась.
VenbergV
02.09.2025 10:15Скорее, смесь поисковика, документации
Скорее коллектор часто встречающихся ответов на запросы в поисковике.
На примере отключения IPv6 в Proxmox, в официальную документацию некоторые LLM точно не заглядывают.
Ioanna
02.09.2025 10:15ИИ хорошо помогает писать код, когда технология совершенно не знакомая или, наоборот, отлично знакомая. В первом случае хорошо сочетается с учебником, потому что учебнику нельзя задать вопросы, а ИИ можно. Во втором случае можно одним взглядом оценить правильность сгенерированного кода и сразу сказать, что поправить.
EmCreatore
02.09.2025 10:15Да что он такое несёт ?!
AI ускоряет невероятно.
Мало того, он снизил или почти убрал необходимость в таких инструментах, как аппаратные отладчики и статические анализаторы типа Understand for C.
А как он пишет комментарии — просто сказка. Мало того, что он правит код, он правит и комментарии. Такого объёма комментарии ни один живой программист писать не будет. А ведь именно комментарии делают всё понятным и простым.
Что он может там такого писать, что ему не нравится код от AI? Пусть покажет. А то придумал какое-то абстрактное программирование. О какой производительности идёт речь, какого порядка метрики, какими цифрами выражается? Например, сколько раз он делает исправления синтаксических ошибок после себя и после AI на текстах в 1000 строк. AI их вообще не делает, работая через агентов.
Green__Hat
02.09.2025 10:15Поддерживаю.
Почитаешь, так каждый первый - мегакодер с суперпаттернами, неповторимыми до безобразия, уникальными и да, ИИ и рядом не валялся. Пока он там будет байты переставлять мы тут быстренько ручкаии раз-два раз-два
Напоминает холивары на девианте, бурлившие года три назад. Тоже каждый первый Дали и через одного Айвазовские.
panzerfaust
02.09.2025 10:15Напоминает холивары на девианте, бурлившие года три назад
Ну так давайте подведем итоги, раз уже 3 года прошло. Живые иллюстраторы, может, не Дали и не Айвазовские, но в них была индивидуальность. Сейчас же все завалено одинаковым до тошноты ИИ-слопом. Большинству дали мощный инструмент, но только выяснился нюанс, что у большинства нет ни фантазии ни вкуса.
Green__Hat
02.09.2025 10:15Ну то есть все пучком? Девиант в тонусе, заказы косяком, художники наглаживают пузики?
А как там на Стаковерфлоу?panzerfaust
02.09.2025 10:15Я вам про то, что качество контента ушло ниже плинтуса, а вы радуетесь, что кто-то остался без работы. Ну каждому своё.
thethee
02.09.2025 10:15Только вы не сравнивайте абсолютное большинство и профессионалов своего дела. Большинство и Thinking режимом у моделей до обновы на GPT-5 никогда не пользовалось, и общались с тупейшей моделью на рынке используя термины "бро" и "чувак". С картинками тоже самое, большинство использует как умеет, не собираясь разбираться, а как сделать лучше, в то время как профессиональные иллюстраторы сообщали, что если заказчик согласен смотреть на ИИ картинки, они получали невероятный буст для прототипирования и подгонки идей и общее время выполнения заказа сокращалось, даже если в конце надо было от руки все переделать со строгим запретом на использование ИИ. Просто первый этап из карандашных зарисовок превратился в очень быстрый просмотр качественных примеров.
С ИИ в коде/технике тоже самое. Средний пользователь будет плодить идентичные по виду и вкусу (точнее его отсутствию) веб приложения с судоку/змейкой/аналогом notion и прочими банальными идеями. А профессионалы, разобравшиеся в технологии получат приличный буст в прототипировании, даже если потом от руки нужно будет все переписать.
Green__Hat
02.09.2025 10:15Каждому свое, факт. И факты говорят, что львиная доля кдпв на хабре и вообще везде сделано ии. Понадобится картинка - возьметесь за генератор, а остальное - вранье.
Так и с кодингом.
Вот цитата из автора
Проверка чужого кода у меня занимает как минимум столько же времени, сколько написание собственного, а то и больше. В нашей сфере даже есть известная фраза: «читать код труднее, чем писать».
Вранье и пафос в чистом виде. Если бы это было правдой, то проекты бы делали в одну каску от начала и до кончала, но это не так. Ложь самому себе и окружающим в природе людей.
ИИ же — это стажёр с антероградной амнезией: каждый раз начинает с нуля, не помня предыдущего опыта. Такой «стажёр» бесполезен.
Вот вторая ложь. На самом деле оно учится и становится лучше из коробки, а джуны идут каждый с нуля.
Люди врут самим себе и окружающим, как автор в двух примерах выше. Пользуются и лгут. Природа человека такова
fixikus
02.09.2025 10:15Это вы нагло врете, автор все правильно сказал, читать код труднее - это факт, особенно, если это сгенерированные вермишели, но даже сеньорный код не всегда красиво и понятно выглядит.
Вот вторая ложь. На самом деле оно учится и становится лучше из коробки, а джуны идут каждый с нуля
Опять вы врете. Оно один раз обучилось и все, дальше вы его юзайте. Оно не станет осведомленнее в ваших задачах, так как опыт не накапливает, в отличие от живого специалиста. Новые модели также умнее не станут, так как данные для обучения уже заюзаны в полном объеме, наоборот, качество моделей будет уменьшаться, так как качество данных для обучения снижается из-за самих llm.
holgw
02.09.2025 10:15Пока он там будет байты переставлять мы тут быстренько ручкаии раз-два раз-два
И что, это неправда? Хотите сказать, что выделить весь необходимый контекст и сформулировать задачу для LLM гораздо проще, чем внести незначительные изменения руками при условии что уже знаешь что именно надо сделать?
EmCreatore
02.09.2025 10:15Тут, конечно, есть нюанс. Да, иногда попросить просто заменить одну строчку на другую и просто удалить строчку знаимает у AI больше пары минут. Думаю это просто из-за недостаточности списка агентских инструментов. Но он недостаточен просто потому что это не напрягает. Я и не пытаюсь этот спиок калибровать под свой рабочий процесс. Я отдыхаю в эти минуты. Потому что успевать за генерацией AI реально устаешь как после качалки.
bromzh
02.09.2025 10:15Зачастую - да. Написать тесты? Контекст - сервис, но писанины кода очень много. Просто добавляешь файл и "напиши тесты". Ты точно знаешь, что надо сделать, но LLM точно быстрее напишет тебе тесты. Тоже самое про рефакторинг (вынести общие части в отдельный компонент/сервис), добавление адаптивности верстки и прочее.
IUIUIUIUIUIUIUI
02.09.2025 10:15Просто добавляешь файл и "напиши тесты". Ты точно знаешь, что надо сделать, но LLM точно быстрее напишет тебе тесты.
А вам тесты для того, чтобы метрики покрытия кода не упали и git-хук не заругался, или для дела?
Ilusha
02.09.2025 10:15Если в контекстное окно llm влезает набор файлов, то получается очень классно.
Если не влезает, то становится мучительно больно.
Я игрался с тем, чтобы создавать с нуля сервис. Вот пока llm могла удерживать кодовую базу в контексте - была магия. Но как только я вылез за её пределы - всё, любое стратегическое решение - ужас.
proxy3d
02.09.2025 10:15А теперь про управляемость генерации картинок. Когда вы просто хотите бесполезную ерунду - отлично он вам сгенерирует. Но когда вам нужно решить реальную задачу связанную с изображения - генераторы изображений становятся бесполезными.
То есть - сгенерировать мусорную картинку к статье не несущую смысла - да. Но полезную цельную задачу - нет, они выдают мусор.
Единственный удобный инструмент в плане генерации изображений - это генерация отдельных объектов вместо их поиска и дальше ручками. Например подходит для игр, иконки сгенерировать, фоновые объекты и так далее.
Для примера, мне надо было по детальному описанию (которое расписала сама же сетка, вплоть до цветов, расположения и прочего) сгенерировать изображение, чтобы наглядней объяснить текст.
Вот Grok и ChatGpt
Grok 
ChatGPT Красиво? да наверное красочно, Айвазовский завидует. Мусор? Однозначно - полный бред. Все попытки ни к чему не приводили. В итоге приходилось делать самостоятельно.
То есть в итоге приходится делать вручную
Я уже молчу про такое. Тут сетки вообще плыли при генерации. При том, что я просил только изображения без текста. Приходилось делать ручками, генерируя отдельно каждое изображение в Qwen и дальше вырезая, дорисовывая, меняя палитру и так далее. То есть от монотонной нудной части, когда одна такая картинка требует часа 2-4 не избавляет.
Как итог, самым лучшим решением было использовать Qwen для генерации отдельных изображений на белом фоне и дальше ручками через фотошоп уже желать картинку. Так как все остальные сетки выдавали Айвазовского и Дали - то есть бесполезный шлак, который имеет 0 пользу.
А когда нужно реально что-то полезное. Например, я хотел изобразить как была доработана SSM модель в нейронках. Код программы сетки видели, описание было подробнейшее в виде текста и так же специального промта. Результат - египетские записи, стрелки не туда, вообще хаотично. Где вход, где реально выход, что за некоторые объекты не ясно.
Были у меня попытки и поэтапно генерировать. Сначала базовую, потом просишь дополни тем то.. а он тебе просто качество улучшает.
Поэтому в реальности - генерация мусора, да отлично справляются. А вот для остального ряд ограничений, и я практически не припомню случаев, когда потом н приходилось вручную что-то еще доделывать.
Ты хочешь нарисовать схему, а он тебе Айвазовского рисует.
thethee
02.09.2025 10:15
Не знаю точных промптов, но это вот выдает гугловая Gemini 2.5 Flash Image (а-ля nano banana), в приложении Gemini на телефон. Ещё доступно бесплатно (с трёхбуквенным сервисом) в google ai studio.
Схему тоже рисует если попросить. Я просил в стиле whitepaper по нейросетям. Не без изъянов конечно, но намного лучше других попсовых генераторов. Мне лень было искать статью с точным описанием/кодом, поэтому на наполнение схемы лучше не обращать внимание, но стилистика правильная.
Из плюсов это чат-модель, можно попросить отредактировать фото. Из минусов - тоже не идеальный инструмент, может начать путаться, тогда лучше забрать последний успешный чекпоинт в новый чат и в нем доделывать.
По времени для сложных вещей получается примерно столько же как рисовать самому, только вот если я сам нарисую будут каракули из paint, а тут вроде адекватно получается.
proxy3d
02.09.2025 10:15Супер, вы подтвердили мои слова, что на выходе получается полный мусор.
Сделай даже проще. Вот код SSM, который нужно было визуализировать и первый запрос, поле которого была множество попыток детального описания и рисования:
Опиши, что нарисовать, чтобы объяснить математический и физический принцип LinOSS_IM_Attn_Hysteresis? Чтобы не запутать человека математическими формулами, а объяснить на ней общие принципы.
Я думаю, правильно будет не рисовать формулу и математические операции. А рисовать блоки с названиями и изображениями, которые отражают физические процессы реализуемые блоком.class LinOSS_IM_Attn_Hysteresis(nn.Module): """ LinOSS_IM_Attn_Hysteresis: Linear Operator-based State Space Model with Implicit Integration, Attention Modulation, and Hysteresis Dynamics. --- ОБЩАЯ ИДЕЯ --- Эта модель реализует линейную комплексную систему (SSM) с имплицитной интеграцией (implicit midpoint), расширенную тремя компонентами: 1. **Механизм внимания (attention)** — модулирует вход через взвешивание по матрице внимания `M`. 2. **Гистерезис** — добавляет память предыдущих приращений и колебаний входного сигнала. 3. **Имплицитная интеграция** — устойчивая дискретизация дифференциальной системы с комплексным оператором A. Результат — мощная и устойчивая архитектура для обработки длинных зависимостей, обладающая способностью извлекать и временные колебания, и асимметричные отклонения. --- МАТЕМАТИЧЕСКАЯ ФОРМУЛИРОВКА --- Обозначения: - `x_t ∈ ℝ^D`: входной вектор в момент времени t - `M ∈ ℝ^{L×L}`: матрица внимания (например, Zipf-локальное внимание) - `u_t`: оригинальный вход `x_t` - `w_t`: модифицированный вход (взвешен по вниманию) - `v_t`: итоговый вход для SSM (включает гистерезис) - `y_t, z_t ∈ ℂ^m`: скрытые состояния ### Attention: w(t) = Σ_j softmax(M(t,j)) * u(j) v_mod = B_mod @ w(t) ### Гистерезис: Δu(t) = u(t) - u(t-1) Δ²u(t) = u(t) - 2u(t-1) + u(t-2) h(t) = γ·h(t-1) + α·Δu(t) + β·Δ²u(t) v_hyst = B_hyst @ h(t) ### Объединённый вход: v(t) = B @ u(t) + v_mod + v_hyst ### Оператор A (комплексный, диагональный): A = diag(λ_k + i·ω_k), где Re(λ_k) < 0 ### Имплицитная интеграция (implicit midpoint): y(t) = (y(t-1) + dt·z(t-1) + dt²·v(t)) / (1 + 0.5·dt²·A) z(t) = (y(t) - y(t-1)) / dt ### Выход: o(t) = C @ Re(y(t)) + D ⊙ u(t) --- ОСОБЕННОСТИ И РЕАЛИЗАЦИЯ --- - `A_log` и `A_im` задают комплексный оператор A = -softplus(A_log) + i·A_im (обеспечивает устойчивость: Re(A) < 0). - Используется softmax-альтернатива `ZipfLagrangeLocalActivation` для локального внимания. - Гистерезис реализован как рекуррентное обобщение производных 1-го и 2-го порядка. - Метод интеграции — implicit midpoint (устойчивый при больших dt). - `C` — выходная проекция скрытых состояний, `D` — скип-коннект с входом. - `log_dt` — обучаемый логарифм временного шага (в диапазоне [dt_min, dt_max]). --- ПЛЮСЫ --- - Обработка **длинных временных зависимостей** (через SSM). - Устойчивость при больших шагах `dt` (через имплицитную схему). - Захват **локальных резонансов и осцилляций** (через комплексный спектр A). - Выделение **асимметричных паттернов и резких изменений** (через гистерезис). - Улучшение **селективности и контекста** (через attention-модуляцию). --- ОТЛИЧИЯ ОТ КЛАССИЧЕСКОГО SSM --- | Компонент | Классический SSM | LinOSS_IM_Attn_Hysteresis | |--------------------|----------------------------------|--------------------------------------------------| | Оператор A | Вещественный | Комплексный, спектральный | | Дискретизация | Явная (например, Euler) | Имплицитная (midpoint) | | Внимание | Отсутствует | Взвешенный контекст через матрицу M | | Гистерезис | Нет | Механизм памяти изменений сигнала | | Выходной слой | Только скрытое состояние | Skip-соединение с входом через `D` | --- ПРИМЕНЕНИЕ --- Модель особенно эффективна для задач: - моделирования последовательностей с медленной или гистеретической динамикой, - обработки сигналов с фазовой структурой (например, речь, музыка), - извлечения устойчивых и редких признаков в потоке (например, в видео/аудио). """ def __init__(self, d_model, d_state, dt_min=1e-3, dt_max=1e-1, modulation=True, dropout=0.1): super().__init__() self.d_model = d_model # Размерность входного сигнала (D) self.d_state = d_state # Размерность скрытого состояния (m) self.modulation = modulation # --- Спектральный оператор A = diag(−λ + iω), λ > 0 для устойчивости --- self.A_log = nn.Parameter(torch.rand(d_state)) # Реальная часть λ (логарифмирована и подавляется через softplus) self.A_im = nn.Parameter(torch.randn(d_state)) # Мнимая часть ω # --- Матрицы входа --- self.B = nn.Parameter(torch.randn(d_state, d_model) / math.sqrt(d_model)) # Прямой вход B * u_t if modulation: self.B_mod = nn.Parameter(torch.randn(d_state, d_model) / math.sqrt(d_model)) # Модулированный вход B_mod * w_t self.B_hyst = nn.Parameter(torch.randn(d_state, d_model) / math.sqrt(d_model)) # Вклад от гистерезиса # --- Матрицы выхода --- self.C = nn.Parameter(torch.randn(d_model, d_state) / math.sqrt(d_state)) # Проекция из скрытого состояния self.D = nn.Parameter(torch.ones(d_model)) # Скип-коннект (u_t * D) # --- Шаг интегрирования --- self.log_dt = nn.Parameter(torch.empty(1)) # Обучаемый логарифм шага self.log_dt.data.uniform_(math.log(dt_min), math.log(dt_max)) # Начальная инициализация self.dt_min = dt_min self.dt_max = dt_max self.dropout = nn.Dropout(dropout) # --- Нелинейная активация для внимания --- if modulation: self.softmax = ZipfLagrangeLocalActivation() # Модуляция входа через внимание # --- Параметры гистерезиса --- self.alpha = nn.Parameter(torch.tensor(0.0)) # Чувствительность к скорости (du) self.beta = nn.Parameter(torch.tensor(0.0)) # Чувствительность к ускорению (ddu) self.gamma = nn.Parameter(torch.tensor(0.0)) # Инерция памяти self.damping = nn.Parameter(torch.tensor(0.2)) # демпфирование, по скорости self.stiffness = nn.Parameter(torch.tensor(0.5)) # обратная связь, по положению # Сырой параметр демпфирования ζ (приводится в диапазон [0, 1] через сигмоиду) self.raw_zeta = nn.Parameter(torch.tensor(0.0)) # обучаемый параметр: zeta ∈ (0, 1) # Логарифм собственных частот ω (обеспечивает положительность частоты) self.log_omega = nn.Parameter(torch.tensor(0.0)) # обучаемый параметр: log(omega) self.beta_softmax = nn.Parameter(torch.tensor(1.0)) # --- Хранилище состояний --- self.register_buffer("y_state", None, persistent=False) # Состояние y(t) self.register_buffer("z_state", None, persistent=False) # Производная состояния z(t) = dy/dt self.register_buffer("u_prev_state", None, persistent=False) # u(t-1) self.register_buffer("u_prev2_state", None, persistent=False) # u(t-2) self.register_buffer("h_state", None, persistent=False) # внутреннее состояние гистерезиса def forward(self, x, M=None, reset_state=False): """ x: [B, L, D] — входная последовательность M: [B, L, L] — матрица внимания (например, подобная self-attention) """ B, L, D = x.shape # B — batch size, L — длина последовательности, D — размерность device = x.device if reset_state or self.y_state is None: self.reset_state(B, device) # --- Построение комплексного оператора A --- lambda_t = -F.softplus(self.A_log) # Re(A) < 0 для устойчивости omega_t = self.A_im # Im(A) A = torch.complex(lambda_t, omega_t) # [B, d_state] # --- Расчёт шага dt ∈ [dt_min, dt_max] --- dt_t = torch.exp(self.log_dt).clamp(self.dt_min, self.dt_max) # Скаляр # Cross-attention modulation # --- Взвешивание входа по вниманию --- if self.modulation: # M_sm = F.softmax(M, dim=-1) # [B, L, L] M_sm = self.softmax(M) # [B, L, L] — локализованная softmax или иная функция U_mod = M_sm @ x # [B, L, D] — w(t) = sum(j) softmax(M(t, j)) * u(j) # --- Инициализация скрытых переменных --- y = self.y_state # Состояние y(t) z = self.z_state # Производная состояния z(t) = dy/dt # --- Переменные для гистерезиса --- u_prev = self.u_prev_state # u(t-1) u_prev2 = self.u_prev2_state # u(t-2) h_t = self.h_state # внутреннее состояние гистерезиса # --- Имплицитное обновление состояния через метод среднего шага --- A_b = A.unsqueeze(0).expand(B, -1) # [B, d_state] расширение A на батч # implicit-midpoint update dt_sq = dt_t * dt_t denom = 1.0 + 0.5 * dt_sq * A_b # [B, d_state] outputs = [] for t in range(L): u_t = x[:, t, :] # [B, D] текущий вход # --- Гистерезис: h(t) = γ * h(t-1) + α * Δu + β * Δ²u --- du = u_t - u_prev # Δu(t) = u(t) − u(t-1) ddu = u_t - 2 * u_prev + u_prev2 # Δ²u(t) = u(t) − 2u(t-1) + u(t-1) h_t = self.gamma * h_t + self.alpha * du + self.beta * ddu u_hyst = F.linear(h_t, self.B_hyst) # [B, d_state] = вклад от гистерезиса # linear transforms B_u = F.linear(u_t, self.B) # [B, d_state] = B * u(t) if self.modulation: # --- Прямой и модулированный вход --- u_mod_t = U_mod[:, t, :] # [B, D] взвешенный по вниманию вход w(t) B_u_mod = F.linear(u_mod_t, self.B_mod) # [B, d_state] = B_mod * w(t) inp = B_u + B_u_mod + u_hyst # [B, d_state] = полный вход в SSM else: inp = B_u + u_hyst # [B, d_state] = полный вход в SSM inp_eff = inp - self.damping * z - self.stiffness * y numer = y + dt_t * z + dt_sq * inp_eff # [B, d_state] numer = torch.sigmoid(numer) # numer = self.softmax_complex(numer) y_next = numer / denom # y(t) = (y(t-1) + dt*z(t-1) + dt²*v(t)) / (1 + 0.5*dt²*A) # Спектральное преобразование: затухание + фаза z_next = self.spectral_damped_derivative(y_next, y, dt_t) y, z = y_next, z_next # --- Выход: проекция + skip-связь --- out = F.linear(y.real, self.C) + u_t * self.D # [B, D] — C*Re(y(t)) + D*u(t) outputs.append(out) # --- Обновление истории для гистерезиса --- u_prev2 = u_prev u_prev = u_t # Сохраняем состояния для следующего вызова self.y_state = y.detach() self.z_state = z.detach() self.u_prev_state = u_prev.detach() self.u_prev2_state = u_prev2.detach() self.h_state = h_t.detach() y_seq = torch.stack(outputs, dim=1) # [B, L, D] — итоговая последовательность y_seq = self.dropout(y_seq) return y_seq def softmax_complex(self, z): amp = torch.abs(z) phase = z / amp.clamp(min=1e-6) # нормированный вектор (unit phase) weights = F.softmax(-amp / self.beta_softmax, dim=-1) # softmax по модулю output = weights * phase # вернёт комплексный результат return output """ Спектральный демпфированный производный метод, вычисляющий приближение производной с демпфированием и фазовым сдвигом в комплексной форме. Использует параметры, которые обучаются (dt, ζ, ω), чтобы гибко моделировать производные сигналов во временной области с учётом колебательных и затухающих компонентов. """ def spectral_damped_derivative(self, y, y_prev, dt_t): """ Аргументы: y (Tensor): текущее значение входного сигнала y_prev (Tensor): предыдущее значение сигнала (на шаге назад) dt_t (Tensor): текущий шаг времени dt Возвращает: z (Tensor): комплексное приближение производной сигнала с затуханием и фазой """ # Демпфирующий коэффициент ζ ∈ [0, 1] zeta = torch.sigmoid(self.raw_zeta) # Собственная частота ω > 0 omega = torch.exp(self.log_omega) # Демпфированная частота: ω_d = ω * sqrt(1 - ζ²) # Добавляем 1e-6 для численной устойчивости при ζ → 1 omega_d = omega * torch.sqrt(1 - zeta ** 2 + 1e-6) # Амплитудное затухание: exp(-ζωdt) decay = torch.exp(-zeta * omega * dt_t) # Фазовый множитель: exp(i * ω_d * dt), где i = sqrt(-1) phase = torch.complex( torch.cos(omega_d * dt_t), torch.sin(omega_d * dt_t) ) # Спектрально-демпфированное приближение производной: # z = exp(-ζωdt) * exp(iω_d dt) * (y - y_prev) / dt # Оно имеет и амплитудное затухание, и вращение в комплексной плоскости z = decay * phase * (y - y_prev) / dt_t if torch.isnan(z).any(): print("Есть хотя бы одно значение NaN.") print(z) print(y) print(y_prev) print(dt_t) sys.exit() return zТеперь по поводу изображения островов:
Основная геометрия
Река идёт горизонтально или диагонально, чтобы можно было разместить несколько «островов» слева направо.Острова — это сегменты: S1, S2, S3, S4 (можно подписать так же, как в теоремах).
Между соседними островами есть короткие прямые мосты — это классические марковские связи (локальные зависимости).
Дополнительно есть длинные диагональные мосты — это ранговые связи (сильные глобальные зависимости).
Общее оформление
Две горизонтальные части: верхняя — классическая марковская цепь, нижняя — ранговая цепь.
В каждой части три острова.
Движение слева направо — передача информации от Отправителя к Получателю.
На каждом острове — Отправитель (в начале, середине и конце пути).
На третьем острове — Получатель.
Верхняя часть — Классическая марковская цепь
Общий вид:
Три острова, соединённые только последовательными мостами.
Мосты тонкие, над водой падают коробки.
Передача информации с потерями.
Элементы:
-
Первый остров (начало пути)
Отправитель с тремя коробками.
Мост к среднему острову.
-
Второй остров (середина пути)
Отправитель с двумя коробками, третья падает в воду с моста.
Мост к третьему острову.
-
Третий остров (конец пути)
Получатель с одной коробкой в руках.
Лицо грустное, поза разочарованная — символ потери информации.
Нижняя часть — Ранговая цепь
Общий вид:
Те же три острова, короткие последовательные мосты остаются, как в верхней части.
Добавлен дальний арочный мост от первого к третьему острову.
Отправитель идёт по дальнему мосту, но короткие мосты визуально присутствуют.
Коробки не теряются.
Элементы:
-
Первый остров (начало пути)
Отправитель с тремя коробками.
Начинает путь по дальнему мосту, короткий мост к среднему острову также виден.
-
Второй остров (середина пути)
Отправитель с тремя коробками, ничего не падает.
Короткий мост к третьему острову виден, но путь идёт по дальнему мосту.
-
Третий остров (конец пути)
Получатель с тремя коробками в руках.
Улыбка и радостная поза — символ сохранения всей информации.
Смысл визуализации
Классическая цепь — только последовательные мосты → часть коробок падает → получатель получает меньше.
Ранговая цепь — есть дальний мост (глобальная зависимость) → информация доходит целиком, короткие мосты показывают, что связь с промежуточными островами сохраняется.
Эмоции Получателя подчёркивают результат: грусть при потерях и радость при полной доставке.
panzerfaust
02.09.2025 10:15Напишите статью. Интересный же разбор получается. Нет смысла в комментах такие портянки раскатывать.
holgw
02.09.2025 10:15он снизил или почти убрал необходимость в таких инструментах, как аппаратные отладчики и статические анализаторы
Использовать LLM вместо статического анализатора это как на космическом корабле в ближайшую булочную летать. LLM же для анализа придется через себя всю кодовую базу прогнать -- колоссальное потребление вычислительных мощностей по сравнению с статическим анализатором.
Что-то я сомневаюсь что такой подход будет работать на нормальном энтерпрайзном проекте -- после переполнения контекстного окна пойдут галлюцинации и потеря деталей. Зачем нужен анализатор у которого надежность понижается с объемом анализируемого проекта? Если не секрет, на проектах какого размера вы подобный подход практикуете?
EmCreatore
02.09.2025 10:15Вы вообще видели, как агенты работают?
Зачем им вся ваша кодовая база? Наполовину набитая API, которое никогда не используется.
Он сначала дает команды поиска, но гораздо изощрённее, чем человек, потом ищет там, где поиск дал результат. В итоге ему хватает прочитать десяток файлов, и он в курсе всего нужного контекста.
Это, кстати, ещё один козырь AI — он удаляет мусорный API, сделанный впрок или не для вашего применения. А это просто классно: вычищает код и делает его понятным.holgw
02.09.2025 10:15Зачем им вся ваша кодовая база?
Вы же сами сказали, что LLM заменяет статический анализатор. Разве API не надо анализировать?
Наполовину набитая API, которое никогда не используется.
Ужас какой-то. К счастью, ни разу с таким не сталкивался. Если вы имеете ввиду какие-то внутренние методы сервиса, то с этим и статический анализатор прекрасно справится -- подсветить неиспользуемые методы тривиальная задача, для этого не нужна LLM.
Он сначала дает команды поиска, но гораздо изощрённее, чем человек, потом ищет там, где поиск дал результат. В итоге ему хватает прочитать десяток файлов, и он в курсе всего нужного контекста.
Да ладно вам, агенты -- это просто обертка над LLM с набором команд для работы с файловой системой и набором харкод промптов. Просто посмотрите что агент шлет по сети в LLM, чтобы понимать как он работает.
Ну и как же агент узнает конкретный кусок кода -- это именно API и что именно этот эндпоинт никогда не используется? Наверное, агенту придется в LLM этот вопрос закинуть вместе с куском кода, вы так не думаете?
Ну и опять же, если мы говорим об альтернативе для статического анализа, то LLM в любом случае придется анализировать ВСЕ файлы, как бы сильно вы не верили в сверхъестественные возможности агента.
Это, кстати, ещё один козырь AI — он удаляет мусорный API, сделанный впрок или не для вашего применения. А это просто классно: вычищает код и делает его понятным.
Понял вас, это просто потрясающе, теперь моё отношение к кодинг ассистентам полностью поменялось. Удаление неиспользуемых методов это ведь такая частая и сложная инженерная задача. Жаль, что раньше не существовало инструментов которые могли бы прямо в среде разработки автоматизировать эту рутину, да?
X-P0rt3r
02.09.2025 10:15Удаление неиспользуемых методов это вдеь такая частая и сложная инженерная задача. Жаль, что раньше не существовало инструментов которые могли бы прямо в среде разработки автоматизировать эту рутину, да?
Мало ли... Вдруг человек кодит в Блокноте? Там точно нет рефакторинга. Если только имена переменных менять через Ctrl+H.
Тогда ему AI и впрямь будет чистым подспорьем.
EmCreatore
02.09.2025 10:15Мне нравится вот такое
Да ладно вам, агенты -- это просто обертка над LLM с набором команд для работы с файловой системой и набором харкод промптов
Как будто это что-то объясняет. Но это только эмоция, и еще непонятно к чему обращенная.
На самом деле агенты все меняют. И это уже не ассистенты.
Трафик там мегабайтный. А сегодня мне пришло сообщение от Claude, что они будут учится на моем чате с ними. И я конечно соглашусь.
Потому что то, что делают вручную, поскольку "статический анализатор прекрасно справится", то мне не надо будет даже иметь это анализатор. Это мало того что экономит время, но и сразу экономит деньги.
И опять же по поводу неуместного сарказмаУдаление неиспользуемых методов это ведь такая частая и сложная инженерная задача.
Это часть рефакторинга. После того как AI избавил меня от изнурительных циклов отладки по поводу сбоев внимания и синтаксических ошибок, основное время начинает занимать рефакторинг. Причем старого кода и сторонних библиотек. Оно конечно Ctrl+H великая операция. Но она просто примитивна и рутинна. AI избавляет от этой рутины. Теперь я могу себе позволить рефакторить ядро RTOS и всех драйверов не думая о переносимости. Призрак потери переносимости теперь больше не волнует, также как и стремление к унификации.
Разве не об этом мечтали наши предки?holgw
02.09.2025 10:15Весь мой скепсис исключительно из-за того что в комментариях я вижу, что "ai ассистенты меняют разработку от и до", а на практике я ничего подобного не наблюдаю.
Если проект большой, если изменения затрагивают больше одного сервиса, если бизнес логика чуть сложнее перекладывания json'ов, то вся помощь ассистента превращается в тыкву.
Да, оно и мне иногда экономит время, если приходится писать много boilerplate кода для тестов, например. Да, иногда помогает разобраться с какой-то новой технологией. Да, отличный автокомплит на стероидах. Но прям такого чтобы можно было сказать "офигеть, кодинг ассистент мне экономит кучу времени" я не могу.
Поэтому мне банально очень интересно, кто все эти люди, которым ассистенты так сильно бустят разработку и какие задачи они решают.
Вот вы, как я понял, занимаетесь embedded разработкой. Там своя специфика, своя структура решений и, вероятно, гораздо меньшие объемы кода чем в посовой разработке каких-нибудь веб-сервисов. И, вероятно, в этом и кроется причина того, что для ваших задач кодинг ассистенты отлично подходят.
Но вы экстраполируете свой опыт на всю разработку целиком, с чем я никак не могу согласиться. В этом и причина моего скепсиса ¯\_(ツ)_/¯
EmCreatore
02.09.2025 10:15В моем текущем проекте 5559 файлов, 1296159 строк кода.
Это спортивный гаджет.
AI в день мне генерит под 3 тысячи и больше строк кода. Ну не каждый день конечно, надо же и о красоте думать. Тогда только форматирую уже существующий код и украшаю HMI по мелочам.
В основном код - это вспомогательные модули для диагностики, исследований, логирования и тестирования фичей. Поскольку очень сложно добиьтся хороших воспроизводимых результатов в этой области, а набор доступных сенсоров и возможности HMI ограничены. Очень много кода уходит на тестирование и диагностику сетевых протоколов и взаимодействий.
Может быть секрет успеха в том что весь код у меня открыт для AI. Нигде не применяются закрытые библиотеки (не может только для модулей).
Поэтому агент свободно ориентируется во всем коде. Не без ошибок конечно. Подсказки требуются , итерации.
Но ускорение не менее чем раз 5 по сравнению с обычной моей производительностью.
Меня наоброт удивляет, когда говорят что используют AI только как ассистента для дополнения кода. Я этой фичой с самого начала не пользовался. В ней нет никакого смысла при наличии агентов. Среда VS Codeholgw
02.09.2025 10:155559 файлов, 1296159 строк кода
Окккей, это явно не тот объем чтоб за раз влезть в контекстное окно.
Может быть секрет успеха в том что весь код у меня открыт для AI.
Да, это наверняка сильно помогает агенту. Но все равно, если честно, не объясняет мне такое сильное отличие вашего опыта от моего при схожем объеме кода. Может, роляет специфика языка.
Спасибо за ответ.
thethee
02.09.2025 10:15Первое правило машинного обучения (и нейросетей). Если в задаче можно обойтись без нейросетей, её нужно выполнять без нейросетей.
JuryPol
02.09.2025 10:15AI ускоряет невероятно
...
Что он может там такого писать, что ему не нравится код от AI? Пусть покажет. А то придумал какое-то абстрактное программирование. О какой производительности идёт речь, какого порядка метрики, какими цифрами выражается?
А «невероятно ускоренные свидетели ИИ», наверное, могут показать невероятно быстро созданный продукт, которым можно пользоваться? Который можно даже посмотреть и оценить?
Вот это была бы лучшая метрика. И очень впечатляющий аргумент.
EmCreatore
02.09.2025 10:15Автор материала не удосужился даже намекнуть в какой области он программирует.
Нет уж, будем играть по принятым правилам - на чистой логике и общепризнанных мнениях.
lazy_val
02.09.2025 10:15А «невероятно ускоренные свидетели ИИ», наверное, могут показать невероятно быстро созданный продукт, которым можно пользоваться? Который можно даже посмотреть и оценить?
Они не могут. У них всегда "код под NDA", "код принадлежит заказчику/работодателю", "код коммерческого проекта никто не будет выкладывать в открытый доступ" и так далее. То есть такой из себя замечательный код, но показать его ну никак нельзя.
Единственное, что есть в открытом доступе - это издевательства копилота над разработчиками dotnet runtime. Впечатляет, кстати ))
aragaer
02.09.2025 10:15Мой подход -- "парное программирование c LLM". Правда приходится отдельно оговаривать "не надо мне писать портянки кода", плюс не всегда я готов вообще ему показывать свой реальный production код, поэтому приходится пересказывать и упрощать.
Поскольку не всем парное программирование нравится, то и мой способ тоже не универсальный.
Hivemaster
02.09.2025 10:15Парное программирование - это для тех, кто не умеет работать в состоянии потока.
Vitaly_js
02.09.2025 10:15Любопытная статья. Но по ощущениям, риски обозначенные в статье уже давно, и до ИИ, пренебрегаются бизнесом. Поэтому даже в том виде, который обозначен в статье, ИИ является рабочим вариантом.
Тут можно провести параллель с индустрией развлечений. Последняя получила колоссальные возможности создавать потрясающие продукты. Но как всем этим распорядился бизнес? Конвейера по созданию качественных Цельных продуктов так и не случилось. Да и даже то, что сделано качественно плохо встроено в продукт. От чего сам продукт даже средним может не получится.
И даже не важно, что люди, профессионалы своего дела, могут и хотят принимать участие в создание отличного продукта. Их воля и желание как показал реальный мир не приводят к появлению качественных вещей.
Он считает, что ИИ не для него? Имеет право. Имеет возможность сам выбирать и диктовать бизнесу технологии, подходы? Классно. Но в тот же момент будет 10х проектов, где все это будет спускаться сверху и работник Должен будет всем этим пользоваться.
Vplusplus
02.09.2025 10:15На мой взгляд, описание задачи для ИИ это и есть самая сложная задача. Когда мы пишем программу сами, то постепенно выгружаем контекст из головы в код, который имеет однозначную трактовку.
В случае ИИ мы должны использовать естественный язык, который многосмысленный, и получается, что ИИ за нас додумывает многие моменты. То есть надо тратить время на уточнение каждого понятия исходного промпта, что приводит к экспоненциальному росту его сложности. Это путь в никуда.
Suor
02.09.2025 10:15Нужно уточнять только когда оно тебя неправильно поняло, в зависимости от задачи таких моментов может вообще не быть. Ну и есть задачи с которыми ИИ просто не справляется.
gun_dose
02.09.2025 10:15Я пользуюсь ИИ, причём со временем всё больше и больше. Правда я не использую инструменты вроде Claude Code. В основном пользуюсь AI Assistant от Jetbrains, для автокомплита, генерации каких-то кусков кода на 5-50 строк. Иногда в агентном режиме делаю сразу несколько файлов.
Так вот, что я могу сказать, это очень крутой инструмент, и пользоваться им мне очень нравится. В большинстве случаев мне удаётся добиться нужного результата с первого раза. Когда у меня заканчивается квота, приходится ждать несколько дней, иногда неделю, пока она обновится. И пользоваться ИИ в это время нельзя. Поэтому я могу легко сравнить свою продуктивность с ИИ и без в рамках одного временно́го промежутка и на одном и том же проекте. И что самое интересное, никакой существенной разницы нет. То есть автор абсолютно прав в том, что ИИ не даёт никакого ускорения в работе. Ну во всяком случае сейчас. Да, ИИ может написать за меня кусок кода. И даже чаще всего делает это без ошибок (хоть и не всегда). И это очень интересно - сидеть и смотреть, как ИИ рассуждает и решает задачу. Но чаще всего за то время, что я трачу на ввод промпта, ожидание ответа и его проверку, я бы успел набрать этот код сам
Однако, учитывая темпы развития и улучшения этих инструментов, перспективы у них однозначно хорошие. И тот факт, что работать с ними - это в каком-то смысле развлечение, это тоже очень круто, т.к. позволяет втягиваться в технологию без каких-то сложностей.
lazy_val
02.09.2025 10:15Когда у меня заканчивается квота, приходится ждать несколько дней, иногда неделю, пока она обновится.
Можете пожалуйста уточнить - об этих квотах речь идет? На сколько (условно говоря) строк кода хватает AI Pro / AI Ultimate?
gun_dose
02.09.2025 10:15Да, именно об этих. Я использую бесплатный тарифный план. Думал переключиться на Pro, но передумал, т.к. не чувствую себя как без рук, когда квота заканчивается. Кроме того, квоту помогает экономить Github Copilot - он значительно более тупой, но можно более простые вопросы спрашивать у него.
Что касается того, насколько хватает. Во-первых, автокомплит продолжает работать даже если квота закончилась. Основной расход квоты - это вопросы в чате. В Chat mode квота расходуется довольно медленно. Если задавать порядка 10 вопросов в день, квоты должно хватить. Но в Edit Mode квота просто тает на глазах. Говорю создай мне тут плагин валидации, который делает то и то, и сам валидатор для плагина, и подключи его тут. Суммарно это 200-300 строк кода. Два файла создать один подправить. За этот запрос полоска квоты сокращается где-то на 1/8 длины.
Но Edit Mode не всегда нужен. Допустим есть большой файл, можно в чате просто попросить отрефакторить или там что-то добавить. И когда будет готовое решение, там может быть много фрагментов кода для правки. Есть опция Apply, которая одним разом всё это применяет. Получается подобие Edit Mode, но со значительно меньшим расходом токенов.
В общем, я думаю, что AI Ultimate реально нужен только тем, кто очень много использует Edit Mode.
lazy_val
02.09.2025 10:15Спасибо!
Можете пожалуйста уточнить - Edit Mode с Junie как-то связана?
gun_dose
02.09.2025 10:15Нет, не связана. Junie - это полноценный агент, который умеет не только править код, но и запускать в принципе любые команды. Например запуск тестов, компиляторов, может даже сам запушить изменения в репозиторий, если настроить. Но я этим не пользовался, пока не вижу в этом для себя смысла.
Вообще, если интересно пощупать именно агентные ИИ, то во-первых, лучше сперва почитать какую-то литературу о них, потому что там всё значительно сложнее, чем просто написал промпт и получил код. В качестве знакомства с агентным ИИ можно попробовать Github Copilot в Agent Mode. Я не знаю, насколько он хорош, но во всяком случае он бесплатен (в определённых пределах).
lazy_val
02.09.2025 10:15Copilot в агентском режиме пробовал. Не уверен что солевые наркоманы в процессе прихода изъясняются ровно так, но ощущение именно такое ))
Возможно что проблема в ограничении ресурсов для бесплатной версии. Хотя по открытым данным он и на максималках зажигает
Я сейчас пытаюсь сравнить цены, по которым OpenAI и Anthropic продают токены напрямую своим пользователям, и сколько оно стоит у "перекупщиков" (Cursor и JetBrains, к примеру). Ощущение такое что у Cursor после введения новых цен токены стали дороже чем у OpenAI/Anthropic, а вот JB пока перепродает с существенным дисконтом. Поэтому и интересно как быстро AI Credits расходуются при выполнении обычных задач. Спасибо за пример в предыдущем сообщении, он кстати почти сходится с тем что сам поставщик заявляет. Редкий случай, как по мне ))
gun_dose
02.09.2025 10:15В ценообразовании там точно чёрт ногу сломит. Максимально непрозрачно всё сделано
anshdo
02.09.2025 10:15Не, есть на самом деле задачи, где LLM-ки реально помогают. Задачи, которые не особо сложные, но нудные. Всякое там перекладываете джейсонов и тому подобное, что мы все не любим. Или перенос с одной платформы на другую. Где надо нагенерить кучу однотипного кода по ТЗ в две строчки. В остальных же случаях как правило проще написать самому, чем добиться от LLM того, что тебе нужно.
panzerfaust
This. Для меня утверждение "ИИ уже заменяет джунов" стало универсальным маркером того, что передо мной просто ИИ-гик или ИИ-пропагандон, который джунов только на картинке видел. Ну или у него были очень специфичные джуны.
MaxKitsch
ИИ приемлемо решает задачи, которые обычно скидывают на джунов, но безопаснее к нему относится, как к автокомплиту на стероидах.