Ночь, темно. Горит фонарь. Под фонарем на четвереньках ползает подвыпивший мужчина и что-то ищет. Прохожий спрашивает у него «Что потерял? – Ключи. - Здесь? - Нет, там, в стороне. - А чего же здесь ищешь? - Так здесь светло…»
Ревью планов - практически единственное, что может сделать человек с адекватными трудозатратами и с сохранением высокой скорости разработки. Но это не потому что “этого достаточно”, а потому что “иначе будет больно”.
Проблема в том, что мало “проверять и понимать код ИИ”, нужно знать “а какие были альтернативные варианты” и “почему был выбран именно этот вариант”.
Тут даже “сам продумываешь реализацию, а ИИ лишь помогает реализовать” не поможет - подводные камни встречается в реализации даже относительно простых вещей.
Там не просто размышления - там очень много вычислений )
P.S. Nemotron-3-Nano-30B-A3B у меня ответил неправильно, как и qwen3-30B-A3B (thinking/coder). Пробовал еще что-то этой же размерности, но уже и не помню, что именно. P.P.S. Qwen3-30B-A3B-coder дал несколько вариантов консольных команд и код на питоне для вычисления значения )
Позиция Amazon: это «user access control issue» - инженеры выдали агенту слишком широкие права, виноват не AI, а настройка. «A coincidence that AI tools were involved.»
Позиция FT (четыре источника): агент действовал автономно и выбрал деструктивное решение как оптимальное.
Лично я вижу тут 2 ошибки: агенту дали много прав, после чего агент выбрал деструктивное действие для решения проблемы. Так что верны обе версии.
Я изучал в свое время https://www.promptingguide.ai/ (как минимум базовые вещи), + статьи по теме что попадались. Основная польза - дало знание специфичной терминологии.
И я именно про промт-инженеринг, а не про вайб-кодинг.
И, как я уже говорил, сейчас промт-инженеринг отошел от "как вообще получить ответ от LLM в личной беседе" (1) к вопросам автоматизации работы с LLM (2) (RAG как раз отсюда).
Я говорю про (1) вариант - он отошел от дел, LLM значительно поумнели. Каких-то особых навыков для общения с LLM уже не нужно (кроме умения излагать свои мысли, без этого, понятное дело, никуда). Несомненно, для профессиональной работы с LLM есть свои нюансы.
(2) вариант - специфическое направление деятельности. Нужен, полезен - не спорю. Но это достаточно специфичное направление деятельности, всем его знать не надо. Вы именно про этот вариант говорите.
Сейчас промт инженеринг отшел от "как у LLM получить ответ" к автоматизации работы с LLM.
Раньше нужно было знать "заклинания" (например, думай шаг за шагом или я дам тебе 200$ чаевых), чтобы модель просто не тупила.
Сейчас модели стали умнее и хорошо работают без подобных ухищрений.
Так что сейчас, это просто навык из софт-скилов "внятно объяснять", который прокачивался у разработчиков и до прихода LLM.
А именно промт-ниженеринг остался у задач автоматизации - сформулировать промт так, чтобы надежно работало в любых ситуациях. Т.е. стал достаточно узким навыком для автоматизаторов работы с LLM.
P.S. более того, вышли исследования, которые показали, что подобные ухищрения помогают, но также увеличивают количество галлюцинаций. P.P.S. а еще видел исследование, которое показало что подобные ухищрения при генерации кода привели к увеличению количества дыр в безопасности (вольная интерпретация). P.P.P.S. и да, на эту тему пишут книги. Много материалов в сети, курсы и прочее-прочее-прочее. Но именно хайп вокруг темы уже прошел - LLM поумнели и лучше понимают что от них хотят.
Разве хайп вокруг промт-инженеринга не угас вместе с ростом возможностей LLM?
LLM сами по себе требуют "просто скажи по человечески, что тебе надо". А промт-инженеринг - скорее из серии "подгони запрос так, чтобы LLM ответила как тебе надо" и с развитием LLM эта необходимость трансформировалась в "дай достаточно контекста".
Т.е. все массово пойдут в техники по ремонту роботов.
Проблема с ИИ в том, что ИИ заменяет человека. Чем бы я не занимался - ИИ может это делать. Это просто вопрос стоимости и эффективности.
Пока эффективность на стороне человека. И сможет ли ИИ догнать человека - тоже большой вопрос. Но как только догонит и если останется дешевым - то быть беде.
Пока же LLM надо контролировать и направлять - человек остается необходимым звеном.
Согласно данным Jellyfish, качество кода, похоже, не снижается под тяжестью более высокой производительности. Показатели отката увеличиваются лишь незначительно по мере роста внедрения ИИ среди инженеров-программистов, с 0,61% в компаниях с низким уровнем внедрения до 0,65% в компаниях высшего уровня.
Только явный откат изменений - это всегда крайняя мера. Это не показатель качества кода. Лучше бы оценили время жизни новых строк в кодовой базе.
Размышления - это просто "мысли в тему", для наполнения контекста. В финальный ответ они могут и не войти (сталкивался с тем, что размышления и ответ были о совершенно разном).
Так что да, размышления помогают. Но зачастую без них ответ не сильно хуже. А главное - значительно быстрее (что имеет значение при локальном инференсе).
Действительно LLM можно представить как архив знаний человечества. И галлюцинации назвать артефактами сжатия. Здравая идея в этом есть.
Но все остальные размышления мало соотносятся с реальностью.
ИИ имеет склонность усложнять простые решения - про это надо всегда помнить )
Напомнило анекдот:
Ревью планов - практически единственное, что может сделать человек с адекватными трудозатратами и с сохранением высокой скорости разработки. Но это не потому что “этого достаточно”, а потому что “иначе будет больно”.
Проблема в том, что мало “проверять и понимать код ИИ”, нужно знать “а какие были альтернативные варианты” и “почему был выбран именно этот вариант”.
Тут даже “сам продумываешь реализацию, а ИИ лишь помогает реализовать” не поможет - подводные камни встречается в реализации даже относительно простых вещей.
Там не просто размышления - там очень много вычислений )
P.S. Nemotron-3-Nano-30B-A3B у меня ответил неправильно, как и qwen3-30B-A3B (thinking/coder). Пробовал еще что-то этой же размерности, но уже и не помню, что именно. P.P.S. Qwen3-30B-A3B-coder дал несколько вариантов консольных команд и код на питоне для вычисления значения )
Недавно нашел интересный “тест” для LLM на математику - попросить сконвертировать unixtimestamp в человеко-читаемый формат )
Хорошо справилась GLM-4.7-Flash - дала точную дату и время. Прочие протестированные модели (размерности 30B-A3B) показали гораздо худший результат.
Лично я вижу тут 2 ошибки: агенту дали много прав, после чего агент выбрал деструктивное действие для решения проблемы. Так что верны обе версии.
Только файлы с тестами должны быть вида
..._test.go. Все-таки “рядом с кодом” может быть и как в Rust - в том же файле.Странно, что в разделе "8. CAG (Context Augmented Generation)" не упоминули ни lost-in-the-middle, ни кеширование - очень актуальные для CAG вещи.
P.S. отличная подборка приемов )
На huggingface сказано, что 6.5B активных параметров (и 4 эксперта из 128):
Я изучал в свое время https://www.promptingguide.ai/ (как минимум базовые вещи), + статьи по теме что попадались.
Основная польза - дало знание специфичной терминологии.
И я именно про промт-инженеринг, а не про вайб-кодинг.
И, как я уже говорил, сейчас промт-инженеринг отошел от "как вообще получить ответ от LLM в личной беседе" (1) к вопросам автоматизации работы с LLM (2) (RAG как раз отсюда).
Я говорю про (1) вариант - он отошел от дел, LLM значительно поумнели. Каких-то особых навыков для общения с LLM уже не нужно (кроме умения излагать свои мысли, без этого, понятное дело, никуда). Несомненно, для профессиональной работы с LLM есть свои нюансы.
(2) вариант - специфическое направление деятельности. Нужен, полезен - не спорю. Но это достаточно специфичное направление деятельности, всем его знать не надо. Вы именно про этот вариант говорите.
Я где-то говорил о "понимают с полуслова"? Это, извините, не моя галлюцинация. Речь шла об актуальности промт-инженеринга для общения с LLM.
Сейчас промт инженеринг отшел от "как у LLM получить ответ" к автоматизации работы с LLM.
Раньше нужно было знать "заклинания" (например,
думай шаг за шагомилия дам тебе 200$ чаевых), чтобы модель просто не тупила.Сейчас модели стали умнее и хорошо работают без подобных ухищрений.
Так что сейчас, это просто навык из софт-скилов "внятно объяснять", который прокачивался у разработчиков и до прихода LLM.
А именно промт-ниженеринг остался у задач автоматизации - сформулировать промт так, чтобы надежно работало в любых ситуациях. Т.е. стал достаточно узким навыком для автоматизаторов работы с LLM.
P.S. более того, вышли исследования, которые показали, что подобные ухищрения помогают, но также увеличивают количество галлюцинаций.
P.P.S. а еще видел исследование, которое показало что подобные ухищрения при генерации кода привели к увеличению количества дыр в безопасности (вольная интерпретация).
P.P.P.S. и да, на эту тему пишут книги. Много материалов в сети, курсы и прочее-прочее-прочее. Но именно хайп вокруг темы уже прошел - LLM поумнели и лучше понимают что от них хотят.
Мой посыл был в том, что необходимости в промт-инженерах нет. Достаточно грамотного описания (для тех задач, которые LLM может решить).
Причем тут проектирование через LLM?
К слову, забыли 4ю группу, которая действительно мешает всем.
Не знают как работает ИИ, но хотят вкатиться на нём в IT.
Да, очень хорошо представляю.
В виде "просто скажи по человечески, что тебе надо" - невозможно для чего-либо достаточно серьезного.
Но речь шла о промт-инженерах же, а не о возможностях LLM? Или промт-инженер так может?
Разве хайп вокруг промт-инженеринга не угас вместе с ростом возможностей LLM?
LLM сами по себе требуют "просто скажи по человечески, что тебе надо". А промт-инженеринг - скорее из серии "подгони запрос так, чтобы LLM ответила как тебе надо" и с развитием LLM эта необходимость трансформировалась в "дай достаточно контекста".
Т.е. все массово пойдут в техники по ремонту роботов.
Проблема с ИИ в том, что ИИ заменяет человека. Чем бы я не занимался - ИИ может это делать. Это просто вопрос стоимости и эффективности.
Пока эффективность на стороне человека. И сможет ли ИИ догнать человека - тоже большой вопрос. Но как только догонит и если останется дешевым - то быть беде.
Пока же LLM надо контролировать и направлять - человек остается необходимым звеном.
Только явный откат изменений - это всегда крайняя мера. Это не показатель качества кода. Лучше бы оценили время жизни новых строк в кодовой базе.
Размышления - это просто "мысли в тему", для наполнения контекста. В финальный ответ они могут и не войти (сталкивался с тем, что размышления и ответ были о совершенно разном).
Так что да, размышления помогают. Но зачастую без них ответ не сильно хуже. А главное - значительно быстрее (что имеет значение при локальном инференсе).