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