Она врет без умысла по глупости из-за системного промпта для подстройки ответов к ожидаемым, а такую ложь очень легко выявить тестами.
Что же кажется, доверять LLM или нет в случае реальной разработки, это вопрос трудозатрат, что кому выгоднее. Ведь для работы с LLM нужно орагнизовывать свое рабочее место, платить деньги провайдеру или ставить локальный сервер, ломать собственные сложившиеся привычки и пр. пр. пр.
Может удивить точно так же как и программист. Но если выбирать между галюцинирующей LLM и программистом, который может специально скрыть неправильно работающий код (были реальные прецеденты), я лучше выберу LLM.
У нее нет умысла, она не желает достижения своих личных целей, выдает результат значительно быстрее человека и не возмущается на задачу в 10 или 20 раз переписать один и тот же код с учетом тех или иных изменений в требованиях :-)
Знания предметной области - да, но для этого не нужно знать детали реализации.
Вот например код тестов у парсера настроект. Он полностью сгенерирован LLM и на первый взгляд покрывает значительную часть потенциальных косяков. Когда тесты работали было заметно, что часть из них фейлилась после чего исходный код парсера исправлялся. Я не фиксировал промежуточные результаты, но общий итог мне понравился.
Как конкретно bash тестировать, я не знаю но наверно есть способы. И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).
Есть такая проблема и у меня тоже. Но думаю, что тесты должны помочь в этом случае. Главное не делать код слишком сложным (чтобы LLM не пришлось его серьезно анализировать).
Кстати, пока отвечал на ваш комментарий, в голову пришла интерсная идея - попробовать сохранять промпт, а возможно и настройки LLM как комментарий к коду для его повторного воспроизведения. Нужно будет поэкспериментировать в этом направлении.
Не знаю, как с bash, но при обычном программировании подобные сомнения решаются тестами. Я про это тоже написал и сейчас переделываю структуру проекта для уменьшения связанности кода и упрощения разработки тестов с помощью вайб-кодинга (много мелких файлов для уменьшения связанности)
Как я уже утверждал в соседнем топике: я, все таки склоняюсь к выводу, что наиболее точное определение включает утверждение о том, что разработчик принимает и использует код, не полностью понимая его.
Про эмоции в термине "вайб-кодинг" пишет тот, кто придумал и начал использовать этот термин. Точнее эмоции, ощущения, атмосфера и сопереживания как раз обозначает слово "вайб", и возникают вибрации от процесса, (от наблюдения за процессом), программирования с помощью генеративных моделей.
А вот что принципиально - это то, что повальное использование кода без полного его понимания, должно иметь какое-то название. Так как масштаб проблемы - катастрофический.
Проблема есть, но не думаю, что она серьезная. Если разработчики грамотные, то они будут не только код писать, но и тесты для него разрабатывать (я про это как раз писал). А если нет, ну тогда рынок и баг-баунти за них все равно это порешают.
AI-assisted development - это когда человек использует ИИ, чтобы сделать чужими руками то, что он вполне может делать своими. То есть, дополнительная пара рук, глаз и часов в сутках, чтобы работать существенно быстрее. Это офигенная вещь.
Я полностью согласен с вами насчет подобной трактовки (в том числе и с точки зрения разработки дополнительных тестов).
У меня Ubuntu и Logitech Mx Keys на которой нет отдельной кнопки Print Screen.
Я настроил себе функцию копирования части экрана в буфер (чтобы вставить скриншот в документ, письму или сообщение телеги), но чтобы сделать картинку для статьи нужно запускать графический редактор и сохранять снимок экрана как файл.
Я решил фоткать только часть экрана, а не весь экран, чтобы потом не пришлось вырезать интересный фрагмент в графическом редакторе из всего принтскрина (я работаю на двух мониторах одновременно) .
Пожалуйста, вы уж сами определитесь, кто пишет и отвечает за статью, вы сами или же Gemini Pro 2.5 :-)
Эта тема мне тоже интересна и я даже попробовал использовать вайб-кодинг в реальных проектах на С++. Однако результаты оказался не настолько радужные, как об этом пишут маркетологи (или LLM вместо них).
И хоть положительный эфект от применения вайб-кодинга есть, но это точно не "замена технарей на гуманитариев", так как все также требуется разбираться в используемых технологиях, так как "применить все правки" будет работать далеко не во всех случаях.
Не говоря уже про то, что формулировки промптов очень сильно зависят от используемой LLM модели, точно так же как SEO оптимизация подстраивалась под конкретную систему интернет-поиска.
По итогам конференции загорелся вайб-кодингом и решил повторить это дома. Результаты описал в статье Вайб-кодинг и реальное программирование на С++ с по итогам реального применения генеративных LLM моделей, но уже в "боевых условиях".
Только общие восторженные фразы без какой либо конкретики, да еще и написанные не на основе реального опыта, а под диктовку Gemini Pro 2.5 :-)
промпт-инжиниринг — искусство составления таких запросов, которые заставляют нейросеть работать максимально точно и эффективно ...
С таким же успехом можно сказать про SEO-инжиниринг. Это тоже про анализ запросов и из этой технологии выросли поисковые ИТ гиганты. Но во что это превратилось сейчас?
Судя по тенденции голосования (пример настроек рабочего места не требуются), то в дальнейшей работе над проектом я не буду фиксировать значимые моменты для новой статьи, так как это отнимает время от основной продуктивной работы. Если что, просто напишу итоговый вывод, но без подробностей и скриншотов.
Она врет без умысла
по глупостииз-за системного промпта для подстройки ответов к ожидаемым, а такую ложь очень легко выявить тестами.Что же кажется, доверять LLM или нет в случае реальной разработки, это вопрос трудозатрат, что кому выгоднее. Ведь для работы с LLM нужно орагнизовывать свое рабочее место, платить деньги провайдеру или ставить локальный сервер, ломать собственные сложившиеся привычки и пр. пр. пр.
Может удивить точно так же как и программист. Но если выбирать между галюцинирующей LLM и программистом, который может специально скрыть неправильно работающий код (были реальные прецеденты), я лучше выберу LLM.
У нее нет умысла, она не желает достижения своих личных целей, выдает результат значительно быстрее человека и не возмущается на задачу в 10 или 20 раз переписать один и тот же код с учетом тех или иных изменений в требованиях :-)
Написанного кода (класса, функции, bash скрипта и т.д.)
Знания предметной области - да, но для этого не нужно знать детали реализации.
Вот например код тестов у парсера настроект. Он полностью сгенерирован LLM и на первый взгляд покрывает значительную часть потенциальных косяков. Когда тесты работали было заметно, что часть из них фейлилась после чего исходный код парсера исправлялся. Я не фиксировал промежуточные результаты, но общий итог мне понравился.
Как конкретно bash тестировать, я не знаю но наверно есть способы. И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).
Есть такая проблема и у меня тоже. Но думаю, что тесты должны помочь в этом случае. Главное не делать код слишком сложным (чтобы LLM не пришлось его серьезно анализировать).
Кстати, пока отвечал на ваш комментарий, в голову пришла интерсная идея - попробовать сохранять промпт, а возможно и настройки LLM как комментарий к коду для его повторного воспроизведения. Нужно будет поэкспериментировать в этом направлении.
Не знаю, как с bash, но при обычном программировании подобные сомнения решаются тестами. Я про это тоже написал и сейчас переделываю структуру проекта для уменьшения связанности кода и упрощения разработки тестов с помощью вайб-кодинга (много мелких файлов для уменьшения связанности)
Про эмоции в термине "вайб-кодинг" пишет тот, кто придумал и начал использовать этот термин. Точнее эмоции, ощущения, атмосфера и сопереживания как раз обозначает слово "вайб", и возникают вибрации от процесса, (от наблюдения за процессом), программирования с помощью генеративных моделей.
Проблема есть, но не думаю, что она серьезная. Если разработчики грамотные, то они будут не только код писать, но и тесты для него разрабатывать (я про это как раз писал). А если нет, ну тогда рынок и баг-баунти за них все равно это порешают.
Я полностью согласен с вами насчет подобной трактовки (в том числе и с точки зрения разработки дополнительных тестов).
Я тоже их из тех самых 5%
Это почему вы сделали такой вывод?
Пленочное фото, это не олдскул, а раритет :-)
Ну пусть это будет не моветон, а олдскул :-)
У меня Ubuntu и Logitech Mx Keys на которой нет отдельной кнопки Print Screen.
Я настроил себе функцию копирования части экрана в буфер (чтобы вставить скриншот в документ, письму или сообщение телеги), но чтобы сделать картинку для статьи нужно запускать графический редактор и сохранять снимок экрана как файл.
У snprintf указывается максимальный размер буфера для выходной строки, чтобы не возникло его переполнения. Или вы что-то другое имели ввиду?
Я решил фоткать только часть экрана, а не весь экран, чтобы потом не пришлось вырезать интересный фрагмент в графическом редакторе из всего принтскрина (я работаю на двух мониторах одновременно) .
Если вам комфортнее общаться с Gemini Pro, то зачем вы генерируете LLM мусор, в виде ненужных даже вам статей на Хабре?
Не понял вопроса :-(
Пожалуйста, вы уж сами определитесь, кто пишет и отвечает за статью, вы сами или же Gemini Pro 2.5 :-)
Эта тема мне тоже интересна и я даже попробовал использовать вайб-кодинг в реальных проектах на С++. Однако результаты оказался не настолько радужные, как об этом пишут маркетологи (или LLM вместо них).
И хоть положительный эфект от применения вайб-кодинга есть, но это точно не "замена технарей на гуманитариев", так как все также требуется разбираться в используемых технологиях, так как "применить все правки" будет работать далеко не во всех случаях.
Не говоря уже про то, что формулировки промптов очень сильно зависят от используемой LLM модели, точно так же как SEO оптимизация подстраивалась под конкретную систему интернет-поиска.
По итогам конференции загорелся вайб-кодингом и решил повторить это дома. Результаты описал в статье Вайб-кодинг и реальное программирование на С++ с по итогам реального применения генеративных LLM моделей, но уже в "боевых условиях".
Только общие восторженные фразы без какой либо конкретики, да еще и написанные не на основе реального опыта, а под диктовку Gemini Pro 2.5 :-)
С таким же успехом можно сказать про SEO-инжиниринг. Это тоже про анализ запросов и из этой технологии выросли поисковые ИТ гиганты. Но во что это превратилось сейчас?
Судя по тенденции голосования (пример настроек рабочего места не требуются), то в дальнейшей работе над проектом я не буду фиксировать значимые моменты для новой статьи, так как это отнимает время от основной продуктивной работы. Если что, просто напишу итоговый вывод, но без подробностей и скриншотов.