Лично я пару раз паподался на эту особенность. Залолго еще до пришестсия ИИ. Причем интересно, что это фишка железа (на ASM x86 она же есть), а не java. И потому встречается во множестве языков )
Эксперту, чтобы написать статью нужно очень много времени. Дни, недели, годы. С LLM эксперт быстрее - в разы, но не на порядок (вычитку результатов ни кто не отменял). ИИ-слоп генерируется за несколько минут (а то и секунд). При этом ИИ генерит статьи относительно неплохо. По крайней мере очень убедительно.
Но чтобы увидеть разницу надо самому достаточно хорошо разбираться в вопросе. И потратить много времени на внимательную вычитку.
Добавить сюда скорость работы ИИ, доступность ИИ (для не-экспертов в том числе) и получим ситуацию, что ИИ-слопа просто на несколько порядков больше, чем качественных статей. А статьи экспертов просто незаметны в потоке ИИ-слопа.
Поэтому и умирает экспертиза. И как будут на этом фоне появляться новые эксперты - большой вопрос. И еще больший вопрос - как эксперта отличить от ИИ для не-эксперта.
P.S. впрочем, я не сомневаюсь, что эксперты будут появляться. Если есть спрос - то будет и предложение. Их будет меньше, они будут дороже - но они будут.
Я не против разговоров. Я против глубоких разговоров с LLM.
С LLM сложно спорить - она или со всем согласна, или просто не обращает внимание на твои слова. А иногда эти факторы работают вместе - "Да, ты совершенно прав", но продолжает гнуть свою линию.
P.S. как раз чаты с ИИ мне очень сильно понравились как альтернатива поисковику. "Режим ИИ" у гугла - очень мощный инструмент. Но именно изучать новое я предпочитаю по статьям - для лучшего формирования целостной картины.
А вы уверены, что в "спрошу в любой момент" участвует запоминание? Доступность информации скорее негативно сказывается на запоминании - просто потому что в любой момент можно спросить снова, напрягать память нет необходимости.
Так и раньше поисковик можно было распрашивать сколько угодно. Да, информация в не таком удобном виде была - но она была. А главное - были разные мнения, которые ты видел и оценивал. И лично я сильно сомневмюсь, что повышение доступности информации в виде ИИ положительно скажется на обучении.
LLM уже поменяли мир. И этого не отнять. В разработке ПО всегда искали "серебренную пулю", которая решает все проблемы разом. Появился ИИ - и теперь все ищут "тот самый промт", который решит все проблемы.
Проблема ИИ скорее в том, что сильно стирается грань между хорошим кодов и плохим кодом. Нейро-слоп - не зря назвали словом года )
Проблема в том, что в реальной разработке написание кода — только начало пути. Дальше идут code review, тесты, сборки, релизы, проверки совместимости, инфраструктура, мониторинг. И отменять эти этапы никто не собирается - эти процессы позволяют делать тысячи локальных изменений миллионах строк кода. Кстати, AI-адоптеры не обещают, что кода станет меньше.
Вообще, написание кода - середина пути. Сбор и анализ требований, проектирование, планирование - не менее важная часть. Но при этом все процессы (а не только кодинг) может ускорить использование ИИ-инструментов.
Ускорит ли ИИ разработку? Не знаю. С одной стороны - да. Все процессы можно делать быстрее. С другой - нет. Результат требует проверки и осмысливания, а это не всегда быстрее написания.
Вопрос скорее в контроле. На сколько хватает контроля - настолько и можно ускориться. Но контроль - очень и очень эфемерное понятие.
В итоге выигрыш может и будет, но явно гораздо скромнее обещаний.
P.S. и да, LLM плохо "видят" свои же ошибки, если явно в них не ткнуть. P.P.S. галлюцинаци - очень и очень серьезный бич ИИ. И пока их не исправят лично я не верю в существенное ускорение разработки. Потому как требуется очень и очень тщательный контроль над результатами работы ИИ. P.P.P.S. прототипы и MVP - области, где ИИ может действительно сильно ускорить разработку. Просто потому что продукт еще небольшой и серьезного контроля не требует. А если что - можно просто начать с чистого листа.
Что 20 лет назад "Кроссплатформенная разработка - это больно", что 10 лет назад "Кроссплатформенная разработка - это больно", что сейчас "Кроссплатформенная разработка - это больно".
Не все игры позволяют выбрать монитор, на котором запускаться.
Обычно поведение я бы поделил на 3 категории:
С какого экрана запустили - на том и идет игра (сюда же - на каком экране был лаунчер, на том и запустится игра, это самый удобный вариант).
Игра запустится на основном мониторе (с панелью задач).
Игра запустится на 0м мониторе (он не всегда основной).
Но это скорее локальные нюансы системы (linux) и баги игр. C OpenMW помню боролся, но нюансов уже не помню.
Практически всегда можно найти решение - от правки конфига игры до "перейти в оконный режим -> перенести на нужный монитор -> перейти в полноэкранный режим".
В худшем случае практически все игры умеют в оконном режиме запускаться.
Я практически не играю, так что деталей особо не скажу.
Да. Фильмы/игры - только на одном экране, причем не всегда на том, что хотелось бы (игр касается). Но поэтому и сделал ремарку про рабочий ПК. Именно для рабочих задач, на мой взгляд, 2 монитора лучше себя показывают.
Это даже не детские ошибки, это "подвох возможен в любом слове". С опытом примерно понимаешь, где и как можно ошибиться - там и проверяешь в первую очередь. LLM же очень и очень правдоподобный код пишет с ошибками в самых неожиданных местах. Это не "детский" код. Это скорее код из серии "вредные советы"
"Забыли умножить" - это очень упрощенное представление. Там скорее "перепутали оракул" и он выдавал не те значения на выходе. Т.е. это ошибка конфигурации, а не арифметики.
Насколько мне известно, fancy zones из powertoys не позволяет перевести окно в "полноэкранный режим" (скрыв заголовки и оформление), но на пол окна. Именно об этом я и говорил - двух-мониторная конфигурация так умеет.
Так можно не строки сравнивать, а числа (коды), а то и хеши - в "нативные" 256 бит влазит.
Более того - если проблема уже встречалась (а сколько таких моментов успели "поймать" до релиза?), эту валидацию можно и вне сети делать, каким-нибудь статическим анализатором (самописным).
И да, нужно "нормализовать" имена активов, что может быть непросто. Но в рамках одной платформы это вполне посильная задача.
P.S. при чтении можно и не сравнивать. Я предлагаю именно при инициализации оракула проверять. А то и до инициализации, вне сети. P.P.S. может со строками и "дорого" работать а EVM, но конфиг оракула именно через строки задается )
На самом деле проблема решается относительно просто: нужно у оракулов ввести указание названий монет - что с чем сравнивается (если их еще нет). Как размерность в физике - если размерность не сходится, то в расчетах явно ошибка. Так и тут - если в конфигурации начинаем сравнивать ETH со слонами - то сразу можно падать в ошибку.
Это уже второй сбой оракулов у Moonwell: в ноябре 2025 года платформа теряла более $1 млн из-за похожей ошибки.
Это не вопрос к LLM. Это вопрос кривости кода и отсутствия строгого аудита.
P.S. я сильно сомневаюсь, что код контракта писался LLM - слишком много закоменченных кусков кода, LLM так не пишет. Скорее LLM применялась для написания документации.
Лично я пару раз паподался на эту особенность. Залолго еще до пришестсия ИИ.
Причем интересно, что это фишка железа (на ASM x86 она же есть), а не java. И потому встречается во множестве языков )
А в чем проблема преодолевать пределы в виде "эксперт + ИИ"?
Речь не про душевность, а про технические статьи.
Эксперту, чтобы написать статью нужно очень много времени. Дни, недели, годы. С LLM эксперт быстрее - в разы, но не на порядок (вычитку результатов ни кто не отменял).
ИИ-слоп генерируется за несколько минут (а то и секунд). При этом ИИ генерит статьи относительно неплохо. По крайней мере очень убедительно.
Но чтобы увидеть разницу надо самому достаточно хорошо разбираться в вопросе. И потратить много времени на внимательную вычитку.
Добавить сюда скорость работы ИИ, доступность ИИ (для не-экспертов в том числе) и получим ситуацию, что ИИ-слопа просто на несколько порядков больше, чем качественных статей. А статьи экспертов просто незаметны в потоке ИИ-слопа.
Поэтому и умирает экспертиза. И как будут на этом фоне появляться новые эксперты - большой вопрос. И еще больший вопрос - как эксперта отличить от ИИ для не-эксперта.
P.S. впрочем, я не сомневаюсь, что эксперты будут появляться. Если есть спрос - то будет и предложение. Их будет меньше, они будут дороже - но они будут.
Речь о том, что для контроля результатов LLM нужна собственная экспертиза в этой области.
Речь не про образование, корочки и прочие аттрибуты.
"В споре рождается истина".
Я не против разговоров. Я против глубоких разговоров с LLM.
С LLM сложно спорить - она или со всем согласна, или просто не обращает внимание на твои слова. А иногда эти факторы работают вместе - "Да, ты совершенно прав", но продолжает гнуть свою линию.
P.S. как раз чаты с ИИ мне очень сильно понравились как альтернатива поисковику. "Режим ИИ" у гугла - очень мощный инструмент. Но именно изучать новое я предпочитаю по статьям - для лучшего формирования целостной картины.
А вы уверены, что в "спрошу в любой момент" участвует запоминание?
Доступность информации скорее негативно сказывается на запоминании - просто потому что в любой момент можно спросить снова, напрягать память нет необходимости.
Так и раньше поисковик можно было распрашивать сколько угодно.
Да, информация в не таком удобном виде была - но она была. А главное - были разные мнения, которые ты видел и оценивал.
И лично я сильно сомневмюсь, что повышение доступности информации в виде ИИ положительно скажется на обучении.
LLM уже поменяли мир. И этого не отнять.
В разработке ПО всегда искали "серебренную пулю", которая решает все проблемы разом.
Появился ИИ - и теперь все ищут "тот самый промт", который решит все проблемы.
Проблема ИИ скорее в том, что сильно стирается грань между хорошим кодов и плохим кодом. Нейро-слоп - не зря назвали словом года )
Вообще, написание кода - середина пути. Сбор и анализ требований, проектирование, планирование - не менее важная часть.
Но при этом все процессы (а не только кодинг) может ускорить использование ИИ-инструментов.
Ускорит ли ИИ разработку?
Не знаю.
С одной стороны - да. Все процессы можно делать быстрее.
С другой - нет. Результат требует проверки и осмысливания, а это не всегда быстрее написания.
Вопрос скорее в контроле. На сколько хватает контроля - настолько и можно ускориться. Но контроль - очень и очень эфемерное понятие.
В итоге выигрыш может и будет, но явно гораздо скромнее обещаний.
P.S. и да, LLM плохо "видят" свои же ошибки, если явно в них не ткнуть.
P.P.S. галлюцинаци - очень и очень серьезный бич ИИ. И пока их не исправят лично я не верю в существенное ускорение разработки. Потому как требуется очень и очень тщательный контроль над результатами работы ИИ.
P.P.P.S. прототипы и MVP - области, где ИИ может действительно сильно ускорить разработку. Просто потому что продукт еще небольшой и серьезного контроля не требует. А если что - можно просто начать с чистого листа.
Что 20 лет назад "Кроссплатформенная разработка - это больно", что 10 лет назад "Кроссплатформенная разработка - это больно", что сейчас "Кроссплатформенная разработка - это больно".
Хоть что-то достаточно постоянно в этом мире.
"Навабкодили" там от силы документацию.
https://github.com/moonwell-fi/moonwell-contracts-v2/pull/578
Что вы, что вы. Человек не пишет код и не смотрит код - ИИ все за него сделает.
Человек просто несет ответственность за код.
Не все игры позволяют выбрать монитор, на котором запускаться.
Обычно поведение я бы поделил на 3 категории:
С какого экрана запустили - на том и идет игра (сюда же - на каком экране был лаунчер, на том и запустится игра, это самый удобный вариант).
Игра запустится на основном мониторе (с панелью задач).
Игра запустится на 0м мониторе (он не всегда основной).
Но это скорее локальные нюансы системы (linux) и баги игр. C OpenMW помню боролся, но нюансов уже не помню.
Практически всегда можно найти решение - от правки конфига игры до "перейти в оконный режим -> перенести на нужный монитор -> перейти в полноэкранный режим".
В худшем случае практически все игры умеют в оконном режиме запускаться.
Я практически не играю, так что деталей особо не скажу.
Да. Фильмы/игры - только на одном экране, причем не всегда на том, что хотелось бы (игр касается).
Но поэтому и сделал ремарку про рабочий ПК. Именно для рабочих задач, на мой взгляд, 2 монитора лучше себя показывают.
Это даже не детские ошибки, это "подвох возможен в любом слове".
С опытом примерно понимаешь, где и как можно ошибиться - там и проверяешь в первую очередь.
LLM же очень и очень правдоподобный код пишет с ошибками в самых неожиданных местах.
Это не "детский" код. Это скорее код из серии "вредные советы"
"Забыли умножить" - это очень упрощенное представление. Там скорее "перепутали оракул" и он выдавал не те значения на выходе.
Т.е. это ошибка конфигурации, а не арифметики.
Насколько мне известно, fancy zones из powertoys не позволяет перевести окно в "полноэкранный режим" (скрыв заголовки и оформление), но на пол окна.
Именно об этом я и говорил - двух-мониторная конфигурация так умеет.
Так можно не строки сравнивать, а числа (коды), а то и хеши - в "нативные" 256 бит влазит.
Более того - если проблема уже встречалась (а сколько таких моментов успели "поймать" до релиза?), эту валидацию можно и вне сети делать, каким-нибудь статическим анализатором (самописным).
И да, нужно "нормализовать" имена активов, что может быть непросто. Но в рамках одной платформы это вполне посильная задача.
P.S. при чтении можно и не сравнивать. Я предлагаю именно при инициализации оракула проверять. А то и до инициализации, вне сети.
P.P.S. может со строками и "дорого" работать а EVM, но конфиг оракула именно через строки задается )
На самом деле проблема решается относительно просто: нужно у оракулов ввести указание названий монет - что с чем сравнивается (если их еще нет). Как размерность в физике - если размерность не сходится, то в расчетах явно ошибка. Так и тут - если в конфигурации начинаем сравнивать ETH со слонами - то сразу можно падать в ошибку.
Это не вопрос к LLM. Это вопрос кривости кода и отсутствия строгого аудита.
P.S. я сильно сомневаюсь, что код контракта писался LLM - слишком много закоменченных кусков кода, LLM так не пишет. Скорее LLM применялась для написания документации.