Comments 72
Многие сторонники ИИ говорят: относитесь к инструменту как к стажёру. Но те, кто так считает, видимо, никогда не работали со стажёрами.
This. Для меня утверждение "ИИ уже заменяет джунов" стало универсальным маркером того, что передо мной просто ИИ-гик или ИИ-пропагандон, который джунов только на картинке видел. Ну или у него были очень специфичные джуны.
Ну если не уметь пользоваться - то да, всё плохо.
Дело даже не в умении, луддиты неспособны мыслить в перспективе, у них память золотой рыбки. Никто уже не помнит, что лишь несколько лет назад никто тоже всерьёз не воспринимал каракули Dalle 1, а сейчас ИИ обманывает ценителей искусства на выставках. То же самое будет и здесь, со временем.
И почему конкретно здесь будет то же самое, что и с dall-e, а не то же самое, что с SQL (который обещал дать возможность каждому менеджеру гонять отчёты), или с UML (который обещал дать возможность каждому аналитику создавать приложения без кодинга), или с визуальным программированием (то же), или с $current-year-no/low-code-платформой (то же), причём $current-year начинается очень давно, минимум от informix 4gl из бородатых 80-х?
Я бы скорее сравнивал как раз с SQL и UML, а не с «каракулями dall-e», потому что, упрощая, код либо компилируется, либо нет, тогда как Высокое Искусство — это кругодроч тех самых «ценителей» на ощущение причастности к «понимающим» каракули Пикассо или вообще что-то такое:
... Почему будет тоже самое что и с dalle, а не как с SQL/UML?
Потому что эти технологии не имеют способности к саморазвитию. Ну "типа" саморазвитию, сейчас поясню. В SQL нельзя накидать побольше компьюта (железа/бабок) и сделать его сильно лучше, а в нейронки можно. И пока не достигнут реального потолка улучшения будут. Будут казаться минимальными, но каждая доля процента в бенчмарках - это очередная успешно выполненная задача для бизнеса.
Код это на низком уровне это логика, описанная специальным языком. Но на более высоком уровне его можно сравнивать с искусством, т.к. он требует значительной фантазии, если это не дефолтное перекладывание json. Решить вопрос галлюцинаций тем или иным способом, и качество уже приемлемое на сегодняшний день в некоторых задачах.
И технические задачи не ограничиваются только лишь кодом, современные агенты, при наличии инструментов, могут самостоятельно залезть в базу, прочитать значения и порядочно так отдебажить проект, пусть и относительно небольшой, но ещё пару лет назад это казалось сказкой, при том что GPT-3 была прорывом, а GPT-4 - прорывом относительно GPT-3. Но ни та ни другая модель не смогут сделать подобное ни при каких промптах, настройках, линтерах, тестах и прочем. Просто не хватает вычислительной мощности, даже при том что GPT-4 обучалась чуть ли не на всем гитхабе. А современные могут.
Пока нет причин заявлять об AGI/ASI и прочих единорогах, но в правильных руках и с правильной настройкой эта технология уже выглядит как магия - машина с переменным успехом самостоятельно действует в среде с большой неопределенностью. Так что как нет причин верить в безудержный успех, но также и нет причин заявлять о неминуемом крахе/провале.
На мой взгляд это просто очередной инструмент, который в некоторой степени изменит то как ведётся разработка. SQL полезен? Полезен. Не так как предсказывали ведуны, но полезен. UML диаграммы полезны? Наверное, не берусь оценивать то что не знаю, но слышал, что системные аналитики пользуются. Так что и нейросети будут полезны. Вполне возможно, что ни вы, ни я, ни комментатор выше не правы и они найдут свою нишу в какой то конкретной сфере деятельности, а писать код с их помощью будет считаться моветоном. Загадывать на долгосрок бесполезно.
Если не уметь пользоваться компилятором и вместо понимаемого самостоятельно колонна поручать нейронке делать то, чего сам не понял, то да, очень плохо... Или речь про "не уметь" в отношении чего-то другого?
А в чём заключается это умение? Какие уникальные навыки нужны?
Не сеньор, не джун и не стажёр. Скорее, смесь поисковика, документации и IDE с командной строкой на естественном языке. Всё, о чём вы могли только мечтать как программист любого уровня. Супер-инструмент для одних задач и полная хрень для других, как и любой другой инструмент.
Согласен.
Хотя и - тоже приходится ревьювить код от AI, выполняя свои проекты.
Бывает и откровенная лажа. Вот здесь-то и пригождается белковый интеллект.
Потому моя оценка этого инструмента - весьма неплохая. Хоть и требующая, порой, детального анализа,
что это здесь получаем/делаем.
Примерно так. Но с одной оговоркой: ответ этого мега-IDE-поисковика-CLI имеет до некоторой степени вероятности характер! Это тот принципиальный момент, который совсем нельзя игнорировать.
Вот я - тот самый консерватор-ретроград, луддит и хейтер-ИИ. И вообще не разработчик. Но даже мне приходилось ловить DeepSeek на вранье уже несколько раз. Причем на довольно несложных вопросах типа "Какая последняя версия %IDE% поддерживает %OS%?" Задавалось на английском - What is the latest...
Тут, конечно, можно контраргументировать, мол, а поисковику ты верил слепо на 100%? Нет, конечно. Но выдачу поисковика можно было хотя бы навскидку ранжировать визуально. Скажем, ответы на Стэковерфлоу, Киберфоруме, MSDN - три по сути разные вещи. И глаз был наметан.
Впрочем, поиск в последнее время (5+ лет) тоже неплохо сломан. И выбор инструмента для поиска - условный жабогадюкинг.
Я для исправления подобных ситуаций (враньё/галлюцинации) сделал себе систему, которая несколько раз выполняет задачу и затем собирает результаты разных выполнений воедино, примерно как работает Deep Research функциональность. Несколько запусков позволяют рассмотреть проблему с разных сторон, и потом собрать воедино результаты. Для кода тоже работает, но дорого выходит по времени выполнения.
Также на редкость хорошо работает ревью кода модели, причем той же моделью, но с очищенным контекстом. Первая всю "версия" пишет код, читает файлы, захламляет свой контекст и скорее всего допускает ошибки, постепенно изменяя код. Вторая версия сразу получает diff готовых изменений, результат выполнения автотестов (если есть), документы по качеству и стилю кода и уже относительно этих изменений формирует инструкции к следующему запуску. Третья версия (снова чистая) получает diff, требуемые исправления, применяет их, и только потом зовётся человек для проверки. В процентах не скажу, но сильно снизилось ощущение недовольства среди знакомых, попробовавших такое, простенькие баги качественно правятся, в некоторых случаях не придраться было. Изъяны остаются, до сложных задач допускают только истинные вайб-кодеры, но и от них тоже положительный фидбэк - меньше итераций вручную проходит фича.
Это все не отменяет ревью и ручного тестирования, но повышает шансы получить качественный результат. Иногда модель может автотесты поправить потому что сдалась, и на третьем этапе опять сдаться и опять внести изменения в тесты - одна из причин почему до сложных задач нельзя допускать. Код будет казаться адекватным, но по факту нерабочий.
Я тут спросил сравнение часов casio у deepseek. Он мне модель braun bn какую-то назвал. Я удивлся, а это бритва для бритья оказалась.
Скорее, смесь поисковика, документации
Скорее коллектор часто встречающихся ответов на запросы в поисковике.
На примере отключения IPv6 в Proxmox, в официальную документацию некоторые LLM точно не заглядывают.
ИИ хорошо помогает писать код, когда технология совершенно не знакомая или, наоборот, отлично знакомая. В первом случае хорошо сочетается с учебником, потому что учебнику нельзя задать вопросы, а ИИ можно. Во втором случае можно одним взглядом оценить правильность сгенерированного кода и сразу сказать, что поправить.
Да что он такое несёт ?!
AI ускоряет невероятно.
Мало того, он снизил или почти убрал необходимость в таких инструментах, как аппаратные отладчики и статические анализаторы типа Understand for C.
А как он пишет комментарии — просто сказка. Мало того, что он правит код, он правит и комментарии. Такого объёма комментарии ни один живой программист писать не будет. А ведь именно комментарии делают всё понятным и простым.
Что он может там такого писать, что ему не нравится код от AI? Пусть покажет. А то придумал какое-то абстрактное программирование. О какой производительности идёт речь, какого порядка метрики, какими цифрами выражается? Например, сколько раз он делает исправления синтаксических ошибок после себя и после AI на текстах в 1000 строк. AI их вообще не делает, работая через агентов.
Поддерживаю.
Почитаешь, так каждый первый - мегакодер с суперпаттернами, неповторимыми до безобразия, уникальными и да, ИИ и рядом не валялся. Пока он там будет байты переставлять мы тут быстренько ручкаии раз-два раз-два
Напоминает холивары на девианте, бурлившие года три назад. Тоже каждый первый Дали и через одного Айвазовские.
Напоминает холивары на девианте, бурлившие года три назад
Ну так давайте подведем итоги, раз уже 3 года прошло. Живые иллюстраторы, может, не Дали и не Айвазовские, но в них была индивидуальность. Сейчас же все завалено одинаковым до тошноты ИИ-слопом. Большинству дали мощный инструмент, но только выяснился нюанс, что у большинства нет ни фантазии ни вкуса.
Ну то есть все пучком? Девиант в тонусе, заказы косяком, художники наглаживают пузики?
А как там на Стаковерфлоу?
Я вам про то, что качество контента ушло ниже плинтуса, а вы радуетесь, что кто-то остался без работы. Ну каждому своё.
Только вы не сравнивайте абсолютное большинство и профессионалов своего дела. Большинство и Thinking режимом у моделей до обновы на GPT-5 никогда не пользовалось, и общались с тупейшей моделью на рынке используя термины "бро" и "чувак". С картинками тоже самое, большинство использует как умеет, не собираясь разбираться, а как сделать лучше, в то время как профессиональные иллюстраторы сообщали, что если заказчик согласен смотреть на ИИ картинки, они получали невероятный буст для прототипирования и подгонки идей и общее время выполнения заказа сокращалось, даже если в конце надо было от руки все переделать со строгим запретом на использование ИИ. Просто первый этап из карандашных зарисовок превратился в очень быстрый просмотр качественных примеров.
С ИИ в коде/технике тоже самое. Средний пользователь будет плодить идентичные по виду и вкусу (точнее его отсутствию) веб приложения с судоку/змейкой/аналогом notion и прочими банальными идеями. А профессионалы, разобравшиеся в технологии получат приличный буст в прототипировании, даже если потом от руки нужно будет все переписать.
Каждому свое, факт. И факты говорят, что львиная доля кдпв на хабре и вообще везде сделано ии. Понадобится картинка - возьметесь за генератор, а остальное - вранье.
Так и с кодингом.
Вот цитата из автора
Проверка чужого кода у меня занимает как минимум столько же времени, сколько написание собственного, а то и больше. В нашей сфере даже есть известная фраза: «читать код труднее, чем писать».
Вранье и пафос в чистом виде. Если бы это было правдой, то проекты бы делали в одну каску от начала и до кончала, но это не так. Ложь самому себе и окружающим в природе людей.
ИИ же — это стажёр с антероградной амнезией: каждый раз начинает с нуля, не помня предыдущего опыта. Такой «стажёр» бесполезен.
Вот вторая ложь. На самом деле оно учится и становится лучше из коробки, а джуны идут каждый с нуля.
Люди врут самим себе и окружающим, как автор в двух примерах выше. Пользуются и лгут. Природа человека такова
Это вы нагло врете, автор все правильно сказал, читать код труднее - это факт, особенно, если это сгенерированные вермишели, но даже сеньорный код не всегда красиво и понятно выглядит.
Вот вторая ложь. На самом деле оно учится и становится лучше из коробки, а джуны идут каждый с нуля
Опять вы врете. Оно один раз обучилось и все, дальше вы его юзайте. Оно не станет осведомленнее в ваших задачах, так как опыт не накапливает, в отличие от живого специалиста. Новые модели также умнее не станут, так как данные для обучения уже заюзаны в полном объеме, наоборот, качество моделей будет уменьшаться, так как качество данных для обучения снижается из-за самих llm.
Пока он там будет байты переставлять мы тут быстренько ручкаии раз-два раз-два
И что, это неправда? Хотите сказать, что выделить весь необходимый контекст и сформулировать задачу для LLM гораздо проще, чем внести незначительные изменения руками при условии что уже знаешь что именно надо сделать?
Тут, конечно, есть нюанс. Да, иногда попросить просто заменить одну строчку на другую и просто удалить строчку знаимает у AI больше пары минут. Думаю это просто из-за недостаточности списка агентских инструментов. Но он недостаточен просто потому что это не напрягает. Я и не пытаюсь этот спиок калибровать под свой рабочий процесс. Я отдыхаю в эти минуты. Потому что успевать за генерацией AI реально устаешь как после качалки.
Зачастую - да. Написать тесты? Контекст - сервис, но писанины кода очень много. Просто добавляешь файл и "напиши тесты". Ты точно знаешь, что надо сделать, но LLM точно быстрее напишет тебе тесты. Тоже самое про рефакторинг (вынести общие части в отдельный компонент/сервис), добавление адаптивности верстки и прочее.
Просто добавляешь файл и "напиши тесты". Ты точно знаешь, что надо сделать, но LLM точно быстрее напишет тебе тесты.
А вам тесты для того, чтобы метрики покрытия кода не упали и git-хук не заругался, или для дела?
Для дела
Ну вы остановитесь на 30 минут и подумайте чутка, как именно тесты работают... Подсказываю — за счёт частичной избыточности информации.
Ну я рад за них. А к чему это?
Не подумали... Жаль.
Нет смысла писать тесты для кода, имея в качестве источника истины только этот самый код. Ну если вы для дела пишете.
Тесты должны тестировать не только положительный сценарий, но и исключительные ситуации. А это избыточная информация. Если в исходном коде не предусмотрена обработка таких ситуаций, то откуда возьмутся тесты на это? LLM их придумает?
Если в контекстное окно llm влезает набор файлов, то получается очень классно.
Если не влезает, то становится мучительно больно.
Я игрался с тем, чтобы создавать с нуля сервис. Вот пока llm могла удерживать кодовую базу в контексте - была магия. Но как только я вылез за её пределы - всё, любое стратегическое решение - ужас.
А теперь про управляемость генерации картинок. Когда вы просто хотите бесполезную ерунду - отлично он вам сгенерирует. Но когда вам нужно решить реальную задачу связанную с изображения - генераторы изображений становятся бесполезными.
То есть - сгенерировать мусорную картинку к статье не несущую смысла - да. Но полезную цельную задачу - нет, они выдают мусор.
Единственный удобный инструмент в плане генерации изображений - это генерация отдельных объектов вместо их поиска и дальше ручками. Например подходит для игр, иконки сгенерировать, фоновые объекты и так далее.
Для примера, мне надо было по детальному описанию (которое расписала сама же сетка, вплоть до цветов, расположения и прочего) сгенерировать изображение, чтобы наглядней объяснить текст.
Вот Grok и ChatGpt
Красиво? да наверное красочно, Айвазовский завидует. Мусор? Однозначно - полный бред. Все попытки ни к чему не приводили. В итоге приходилось делать самостоятельно.
То есть в итоге приходится делать вручную
Я уже молчу про такое. Тут сетки вообще плыли при генерации. При том, что я просил только изображения без текста. Приходилось делать ручками, генерируя отдельно каждое изображение в Qwen и дальше вырезая, дорисовывая, меняя палитру и так далее. То есть от монотонной нудной части, когда одна такая картинка требует часа 2-4 не избавляет.
Как итог, самым лучшим решением было использовать Qwen для генерации отдельных изображений на белом фоне и дальше ручками через фотошоп уже желать картинку. Так как все остальные сетки выдавали Айвазовского и Дали - то есть бесполезный шлак, который имеет 0 пользу.
А когда нужно реально что-то полезное. Например, я хотел изобразить как была доработана SSM модель в нейронках. Код программы сетки видели, описание было подробнейшее в виде текста и так же специального промта. Результат - египетские записи, стрелки не туда, вообще хаотично. Где вход, где реально выход, что за некоторые объекты не ясно.
Были у меня попытки и поэтапно генерировать. Сначала базовую, потом просишь дополни тем то.. а он тебе просто качество улучшает.
Поэтому в реальности - генерация мусора, да отлично справляются. А вот для остального ряд ограничений, и я практически не припомню случаев, когда потом н приходилось вручную что-то еще доделывать.
Ты хочешь нарисовать схему, а он тебе Айвазовского рисует.
Не знаю точных промптов, но это вот выдает гугловая Gemini 2.5 Flash Image (а-ля nano banana), в приложении Gemini на телефон. Ещё доступно бесплатно (с трёхбуквенным сервисом) в google ai studio.
Схему тоже рисует если попросить. Я просил в стиле whitepaper по нейросетям. Не без изъянов конечно, но намного лучше других попсовых генераторов. Мне лень было искать статью с точным описанием/кодом, поэтому на наполнение схемы лучше не обращать внимание, но стилистика правильная.
Из плюсов это чат-модель, можно попросить отредактировать фото. Из минусов - тоже не идеальный инструмент, может начать путаться, тогда лучше забрать последний успешный чекпоинт в новый чат и в нем доделывать.
По времени для сложных вещей получается примерно столько же как рисовать самому, только вот если я сам нарисую будут каракули из paint, а тут вроде адекватно получается.
Супер, вы подтвердили мои слова, что на выходе получается полный мусор.
Сделай даже проще. Вот код 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 (можно подписать так же, как в теоремах).
Между соседними островами есть короткие прямые мосты — это классические марковские связи (локальные зависимости).
Дополнительно есть длинные диагональные мосты — это ранговые связи (сильные глобальные зависимости).
Общее оформление
Две горизонтальные части: верхняя — классическая марковская цепь, нижняя — ранговая цепь.
В каждой части три острова.
Движение слева направо — передача информации от Отправителя к Получателю.
На каждом острове — Отправитель (в начале, середине и конце пути).
На третьем острове — Получатель.
Верхняя часть — Классическая марковская цепь
Общий вид:
Три острова, соединённые только последовательными мостами.
Мосты тонкие, над водой падают коробки.
Передача информации с потерями.
Элементы:
Первый остров (начало пути)
Отправитель с тремя коробками.
Мост к среднему острову.
Второй остров (середина пути)
Отправитель с двумя коробками, третья падает в воду с моста.
Мост к третьему острову.
Третий остров (конец пути)
Получатель с одной коробкой в руках.
Лицо грустное, поза разочарованная — символ потери информации.
Нижняя часть — Ранговая цепь
Общий вид:
Те же три острова, короткие последовательные мосты остаются, как в верхней части.
Добавлен дальний арочный мост от первого к третьему острову.
Отправитель идёт по дальнему мосту, но короткие мосты визуально присутствуют.
Коробки не теряются.
Элементы:
Первый остров (начало пути)
Отправитель с тремя коробками.
Начинает путь по дальнему мосту, короткий мост к среднему острову также виден.
Второй остров (середина пути)
Отправитель с тремя коробками, ничего не падает.
Короткий мост к третьему острову виден, но путь идёт по дальнему мосту.
Третий остров (конец пути)
Получатель с тремя коробками в руках.
Улыбка и радостная поза — символ сохранения всей информации.
Смысл визуализации
Классическая цепь — только последовательные мосты → часть коробок падает → получатель получает меньше.
Ранговая цепь — есть дальний мост (глобальная зависимость) → информация доходит целиком, короткие мосты показывают, что связь с промежуточными островами сохраняется.
Эмоции Получателя подчёркивают результат: грусть при потерях и радость при полной доставке.
он снизил или почти убрал необходимость в таких инструментах, как аппаратные отладчики и статические анализаторы
Использовать LLM вместо статического анализатора это как на космическом корабле в ближайшую булочную летать. LLM же для анализа придется через себя всю кодовую базу прогнать -- колоссальное потребление вычислительных мощностей по сравнению с статическим анализатором.
Что-то я сомневаюсь что такой подход будет работать на нормальном энтерпрайзном проекте -- после переполнения контекстного окна пойдут галлюцинации и потеря деталей. Зачем нужен анализатор у которого надежность понижается с объемом анализируемого проекта? Если не секрет, на проектах какого размера вы подобный подход практикуете?
Вы вообще видели, как агенты работают?
Зачем им вся ваша кодовая база? Наполовину набитая API, которое никогда не используется.
Он сначала дает команды поиска, но гораздо изощрённее, чем человек, потом ищет там, где поиск дал результат. В итоге ему хватает прочитать десяток файлов, и он в курсе всего нужного контекста.
Это, кстати, ещё один козырь AI — он удаляет мусорный API, сделанный впрок или не для вашего применения. А это просто классно: вычищает код и делает его понятным.
Зачем им вся ваша кодовая база?
Вы же сами сказали, что LLM заменяет статический анализатор. Разве API не надо анализировать?
Наполовину набитая API, которое никогда не используется.
Ужас какой-то. К счастью, ни разу с таким не сталкивался. Если вы имеете ввиду какие-то внутренние методы сервиса, то с этим и статический анализатор прекрасно справится -- подсветить неиспользуемые методы тривиальная задача, для этого не нужна LLM.
Он сначала дает команды поиска, но гораздо изощрённее, чем человек, потом ищет там, где поиск дал результат. В итоге ему хватает прочитать десяток файлов, и он в курсе всего нужного контекста.
Да ладно вам, агенты -- это просто обертка над LLM с набором команд для работы с файловой системой и набором харкод промптов. Просто посмотрите что агент шлет по сети в LLM, чтобы понимать как он работает.
Ну и как же агент узнает конкретный кусок кода -- это именно API и что именно этот эндпоинт никогда не используется? Наверное, агенту придется в LLM этот вопрос закинуть вместе с куском кода, вы так не думаете?
Ну и опять же, если мы говорим об альтернативе для статического анализа, то LLM в любом случае придется анализировать ВСЕ файлы, как бы сильно вы не верили в сверхъестественные возможности агента.
Это, кстати, ещё один козырь AI — он удаляет мусорный API, сделанный впрок или не для вашего применения. А это просто классно: вычищает код и делает его понятным.
Понял вас, это просто потрясающе, теперь моё отношение к кодинг ассистентам полностью поменялось. Удаление неиспользуемых методов это ведь такая частая и сложная инженерная задача. Жаль, что раньше не существовало инструментов которые могли бы прямо в среде разработки автоматизировать эту рутину, да?
Удаление неиспользуемых методов это вдеь такая частая и сложная инженерная задача. Жаль, что раньше не существовало инструментов которые могли бы прямо в среде разработки автоматизировать эту рутину, да?
Мало ли... Вдруг человек кодит в Блокноте? Там точно нет рефакторинга. Если только имена переменных менять через Ctrl+H.
Тогда ему AI и впрямь будет чистым подспорьем.
Анализировать нужно только новый код и то, с чем он связан. Зачем всё то?
Мне нравится вот такое
Да ладно вам, агенты -- это просто обертка над LLM с набором команд для работы с файловой системой и набором харкод промптов
Как будто это что-то объясняет. Но это только эмоция, и еще непонятно к чему обращенная.
На самом деле агенты все меняют. И это уже не ассистенты.
Трафик там мегабайтный. А сегодня мне пришло сообщение от Claude, что они будут учится на моем чате с ними. И я конечно соглашусь.
Потому что то, что делают вручную, поскольку "статический анализатор прекрасно справится", то мне не надо будет даже иметь это анализатор. Это мало того что экономит время, но и сразу экономит деньги.
И опять же по поводу неуместного сарказма
Удаление неиспользуемых методов это ведь такая частая и сложная инженерная задача.
Это часть рефакторинга. После того как AI избавил меня от изнурительных циклов отладки по поводу сбоев внимания и синтаксических ошибок, основное время начинает занимать рефакторинг. Причем старого кода и сторонних библиотек. Оно конечно Ctrl+H великая операция. Но она просто примитивна и рутинна. AI избавляет от этой рутины. Теперь я могу себе позволить рефакторить ядро RTOS и всех драйверов не думая о переносимости. Призрак потери переносимости теперь больше не волнует, также как и стремление к унификации.
Разве не об этом мечтали наши предки?
Весь мой скепсис исключительно из-за того что в комментариях я вижу, что "ai ассистенты меняют разработку от и до", а на практике я ничего подобного не наблюдаю.
Если проект большой, если изменения затрагивают больше одного сервиса, если бизнес логика чуть сложнее перекладывания json'ов, то вся помощь ассистента превращается в тыкву.
Да, оно и мне иногда экономит время, если приходится писать много boilerplate кода для тестов, например. Да, иногда помогает разобраться с какой-то новой технологией. Да, отличный автокомплит на стероидах. Но прям такого чтобы можно было сказать "офигеть, кодинг ассистент мне экономит кучу времени" я не могу.
Поэтому мне банально очень интересно, кто все эти люди, которым ассистенты так сильно бустят разработку и какие задачи они решают.
Вот вы, как я понял, занимаетесь embedded разработкой. Там своя специфика, своя структура решений и, вероятно, гораздо меньшие объемы кода чем в посовой разработке каких-нибудь веб-сервисов. И, вероятно, в этом и кроется причина того, что для ваших задач кодинг ассистенты отлично подходят.
Но вы экстраполируете свой опыт на всю разработку целиком, с чем я никак не могу согласиться. В этом и причина моего скепсиса ¯\_(ツ)_/¯
В моем текущем проекте 5559 файлов, 1296159 строк кода.
Это спортивный гаджет.
AI в день мне генерит под 3 тысячи и больше строк кода. Ну не каждый день конечно, надо же и о красоте думать. Тогда только форматирую уже существующий код и украшаю HMI по мелочам.
В основном код - это вспомогательные модули для диагностики, исследований, логирования и тестирования фичей. Поскольку очень сложно добиьтся хороших воспроизводимых результатов в этой области, а набор доступных сенсоров и возможности HMI ограничены. Очень много кода уходит на тестирование и диагностику сетевых протоколов и взаимодействий.
Может быть секрет успеха в том что весь код у меня открыт для AI. Нигде не применяются закрытые библиотеки (не может только для модулей).
Поэтому агент свободно ориентируется во всем коде. Не без ошибок конечно. Подсказки требуются , итерации.
Но ускорение не менее чем раз 5 по сравнению с обычной моей производительностью.
Меня наоброт удивляет, когда говорят что используют AI только как ассистента для дополнения кода. Я этой фичой с самого начала не пользовался. В ней нет никакого смысла при наличии агентов. Среда VS Code
5559 файлов, 1296159 строк кода
Окккей, это явно не тот объем чтоб за раз влезть в контекстное окно.
Может быть секрет успеха в том что весь код у меня открыт для AI.
Да, это наверняка сильно помогает агенту. Но все равно, если честно, не объясняет мне такое сильное отличие вашего опыта от моего при схожем объеме кода. Может, роляет специфика языка.
Спасибо за ответ.
Первое правило машинного обучения (и нейросетей). Если в задаче можно обойтись без нейросетей, её нужно выполнять без нейросетей.
AI ускоряет невероятно
...
Что он может там такого писать, что ему не нравится код от AI? Пусть покажет. А то придумал какое-то абстрактное программирование. О какой производительности идёт речь, какого порядка метрики, какими цифрами выражается?
А «невероятно ускоренные свидетели ИИ», наверное, могут показать невероятно быстро созданный продукт, которым можно пользоваться? Который можно даже посмотреть и оценить?
Вот это была бы лучшая метрика. И очень впечатляющий аргумент.
Автор материала не удосужился даже намекнуть в какой области он программирует.
Нет уж, будем играть по принятым правилам - на чистой логике и общепризнанных мнениях.
А «невероятно ускоренные свидетели ИИ», наверное, могут показать невероятно быстро созданный продукт, которым можно пользоваться? Который можно даже посмотреть и оценить?
Они не могут. У них всегда "код под NDA", "код принадлежит заказчику/работодателю", "код коммерческого проекта никто не будет выкладывать в открытый доступ" и так далее. То есть такой из себя замечательный код, но показать его ну никак нельзя.
Единственное, что есть в открытом доступе - это издевательства копилота над разработчиками dotnet runtime. Впечатляет, кстати ))
Мой подход -- "парное программирование c LLM". Правда приходится отдельно оговаривать "не надо мне писать портянки кода", плюс не всегда я готов вообще ему показывать свой реальный production код, поэтому приходится пересказывать и упрощать.
Поскольку не всем парное программирование нравится, то и мой способ тоже не универсальный.
Любопытная статья. Но по ощущениям, риски обозначенные в статье уже давно, и до ИИ, пренебрегаются бизнесом. Поэтому даже в том виде, который обозначен в статье, ИИ является рабочим вариантом.
Тут можно провести параллель с индустрией развлечений. Последняя получила колоссальные возможности создавать потрясающие продукты. Но как всем этим распорядился бизнес? Конвейера по созданию качественных Цельных продуктов так и не случилось. Да и даже то, что сделано качественно плохо встроено в продукт. От чего сам продукт даже средним может не получится.
И даже не важно, что люди, профессионалы своего дела, могут и хотят принимать участие в создание отличного продукта. Их воля и желание как показал реальный мир не приводят к появлению качественных вещей.
Он считает, что ИИ не для него? Имеет право. Имеет возможность сам выбирать и диктовать бизнесу технологии, подходы? Классно. Но в тот же момент будет 10х проектов, где все это будет спускаться сверху и работник Должен будет всем этим пользоваться.
На мой взгляд, описание задачи для ИИ это и есть самая сложная задача. Когда мы пишем программу сами, то постепенно выгружаем контекст из головы в код, который имеет однозначную трактовку.
В случае ИИ мы должны использовать естественный язык, который многосмысленный, и получается, что ИИ за нас додумывает многие моменты. То есть надо тратить время на уточнение каждого понятия исходного промпта, что приводит к экспоненциальному росту его сложности. Это путь в никуда.
Я пользуюсь ИИ, причём со временем всё больше и больше. Правда я не использую инструменты вроде Claude Code. В основном пользуюсь AI Assistant от Jetbrains, для автокомплита, генерации каких-то кусков кода на 5-50 строк. Иногда в агентном режиме делаю сразу несколько файлов.
Так вот, что я могу сказать, это очень крутой инструмент, и пользоваться им мне очень нравится. В большинстве случаев мне удаётся добиться нужного результата с первого раза. Когда у меня заканчивается квота, приходится ждать несколько дней, иногда неделю, пока она обновится. И пользоваться ИИ в это время нельзя. Поэтому я могу легко сравнить свою продуктивность с ИИ и без в рамках одного временно́го промежутка и на одном и том же проекте. И что самое интересное, никакой существенной разницы нет. То есть автор абсолютно прав в том, что ИИ не даёт никакого ускорения в работе. Ну во всяком случае сейчас. Да, ИИ может написать за меня кусок кода. И даже чаще всего делает это без ошибок (хоть и не всегда). И это очень интересно - сидеть и смотреть, как ИИ рассуждает и решает задачу. Но чаще всего за то время, что я трачу на ввод промпта, ожидание ответа и его проверку, я бы успел набрать этот код сам
Однако, учитывая темпы развития и улучшения этих инструментов, перспективы у них однозначно хорошие. И тот факт, что работать с ними - это в каком-то смысле развлечение, это тоже очень круто, т.к. позволяет втягиваться в технологию без каких-то сложностей.
Когда у меня заканчивается квота, приходится ждать несколько дней, иногда неделю, пока она обновится.
Можете пожалуйста уточнить - об этих квотах речь идет? На сколько (условно говоря) строк кода хватает AI Pro / AI Ultimate?
Да, именно об этих. Я использую бесплатный тарифный план. Думал переключиться на Pro, но передумал, т.к. не чувствую себя как без рук, когда квота заканчивается. Кроме того, квоту помогает экономить Github Copilot - он значительно более тупой, но можно более простые вопросы спрашивать у него.
Что касается того, насколько хватает. Во-первых, автокомплит продолжает работать даже если квота закончилась. Основной расход квоты - это вопросы в чате. В Chat mode квота расходуется довольно медленно. Если задавать порядка 10 вопросов в день, квоты должно хватить. Но в Edit Mode квота просто тает на глазах. Говорю создай мне тут плагин валидации, который делает то и то, и сам валидатор для плагина, и подключи его тут. Суммарно это 200-300 строк кода. Два файла создать один подправить. За этот запрос полоска квоты сокращается где-то на 1/8 длины.
Но Edit Mode не всегда нужен. Допустим есть большой файл, можно в чате просто попросить отрефакторить или там что-то добавить. И когда будет готовое решение, там может быть много фрагментов кода для правки. Есть опция Apply, которая одним разом всё это применяет. Получается подобие Edit Mode, но со значительно меньшим расходом токенов.
В общем, я думаю, что AI Ultimate реально нужен только тем, кто очень много использует Edit Mode.
Спасибо!
Можете пожалуйста уточнить - Edit Mode с Junie как-то связана?
Нет, не связана. Junie - это полноценный агент, который умеет не только править код, но и запускать в принципе любые команды. Например запуск тестов, компиляторов, может даже сам запушить изменения в репозиторий, если настроить. Но я этим не пользовался, пока не вижу в этом для себя смысла.
Вообще, если интересно пощупать именно агентные ИИ, то во-первых, лучше сперва почитать какую-то литературу о них, потому что там всё значительно сложнее, чем просто написал промпт и получил код. В качестве знакомства с агентным ИИ можно попробовать Github Copilot в Agent Mode. Я не знаю, насколько он хорош, но во всяком случае он бесплатен (в определённых пределах).
Copilot в агентском режиме пробовал. Не уверен что солевые наркоманы в процессе прихода изъясняются ровно так, но ощущение именно такое ))
Возможно что проблема в ограничении ресурсов для бесплатной версии. Хотя по открытым данным он и на максималках зажигает
Я сейчас пытаюсь сравнить цены, по которым OpenAI и Anthropic продают токены напрямую своим пользователям, и сколько оно стоит у "перекупщиков" (Cursor и JetBrains, к примеру). Ощущение такое что у Cursor после введения новых цен токены стали дороже чем у OpenAI/Anthropic, а вот JB пока перепродает с существенным дисконтом. Поэтому и интересно как быстро AI Credits расходуются при выполнении обычных задач. Спасибо за пример в предыдущем сообщении, он кстати почти сходится с тем что сам поставщик заявляет. Редкий случай, как по мне ))
.
Не, есть на самом деле задачи, где LLM-ки реально помогают. Задачи, которые не особо сложные, но нудные. Всякое там перекладываете джейсонов и тому подобное, что мы все не любим. Или перенос с одной платформы на другую. Где надо нагенерить кучу однотипного кода по ТЗ в две строчки. В остальных же случаях как правило проще написать самому, чем добиться от LLM того, что тебе нужно.
Есть решения, которые могут работать параллельно с вами, например Codex или локальные фоновые агенты.
Лично у меня отношение к генерации кода нейронки, как к инструменту. Они ускоряют рутинную работу или помогают искать баги, предлагая разные идеи решения. Идеально подходят, чтобы собрать прототип и пощупать его, а так же накидать бойлерпейты, при этом он явно не замена тем же джунам.
О боже вы вообще пробовали ии? Я работаю с ии на 5 проектах. Он мне закрывать задачи на всех 5 энтерпрайз проектах. Проблема того что ии не справляется не в том что он все забывает а в том насколько архитектурно сложен проект. Если из г и палок то ии его развалит. Если из мрамора то отточит каждую грань. Обучается не ии а ваш скилл описывать для него задачу правильно и предсказывать справится ли ии или нет и насколько хорошо. Для этого нужно знать механизм работы ллм и не до токенов а вплоть до логитов. Я работаю в связке cursor+gpt5. Сам же проект изначально формируется не через llm, а dsl и задает четкую структуру проекту вплоть до деталей. А ии просто инструмент достройки такого красивого здания.
Почему генеративные ИИ-агенты в программировании — не для меня