Comments 51
Судя по тенденции голосования (пример настроек рабочего места не требуются), то в дальнейшей работе над проектом я не буду фиксировать значимые моменты для новой статьи, так как это отнимает время от основной продуктивной работы. Если что, просто напишу итоговый вывод, но без подробностей и скриншотов.
А чего у вас кнопка PrtScr сломалась?
Не понял вопроса :-(
Почему у вас фотографии монитора, а не снимки экрана?
Я решил фоткать только часть экрана, а не весь экран, чтобы потом не пришлось вырезать интересный фрагмент в графическом редакторе из всего принтскрина (я работаю на двух мониторах одновременно) .
Если вы на винде, то попробуйте Shift+Win+S
У меня Ubuntu и Logitech Mx Keys на которой нет отдельной кнопки Print Screen.
Я настроил себе функцию копирования части экрана в буфер (чтобы вставить скриншот в документ, письму или сообщение телеги), но чтобы сделать картинку для статьи нужно запускать графический редактор и сохранять снимок экрана как файл.
Есть же всякие аналоги lightshot на линуксах. Фотографировать экран звучит как моветон, если это не какой-нибудь BIOS.
Фотографировать экран звучит как моветон, если это не какой-нибудь BIOS.
Ну пусть это будет не моветон, а олдскул :-)
В олдскул если бы вы сфотографировали экран то вам пришлось бы потом проявлять фотопленку, печатать с неё и потом ещё и сканировать полученную фотку. И после этого вы бы обнаружили, что из-за особенностей работы затвора фотокамеры при фотографировании картинки с мониторов и телевизоров потом на фотографии появляются всякие странные светлые полосы.
Кажется кнопка слева умеет всё что нужно, сохраняя скриншот в буфер. Большинство WYSIWYG редакторов умеет загружать изображения из буфера. Хоть у меня нет Logitech Mx Keys, но третья клавиша справа в верхнем ряду выглядит как то что нужно.
Отличный кейс для вайб-кодинга, кстати.
размер буфера переменной
char filepath[128]может быть недостаточен при вызове функцииsnprintf
А вы знаете, что будет, если буфер вдруг действительно окажется недостаточен для snprintf ?
Я это узнал только недавно и после этого стандартную snprintf стараюсь не использовать.
"системный архитектор" не умеет в принтскрин...
Это почему вы сделали такой вывод?
Настолько лень для статьи сделать скрины? Видел Ваши комменты, что нет клавиши для скриншота, но на Вашей клавиатуре есть функциональные клавиши. Все биндится, если захочется, а если нет, то решается.
Да, все решается, и я эту проблему решил с помощью фотографии интересного фрагмента экрана.
Что же касается материала для статьи, то тут дело не в скринах, а контексте. Ведь важно не просто сделать скриншот, а еще иметь и дополнительное описание того, почему он был сделан. А это не просто время, но и переключение с одной задачи (программирование) на другую (документирование), что очень сильно выбивает из текущего рабочего состояния.
Что же касается материала для статьи, то тут дело не в скринах, а контексте.
Дело не в кронтексте, а в уважаении к читателю. А пока вышло только «да ладно, и так сойдёт». Хуже скриншотов с экрана камерой может быть только захват видео с экрана регистратора телефоном.
Неуважение автора к читателю, это приводить исходный код без форматирования или в виде картинки, если предполагается его последующее копирование, но вижу особой разницы между снимком на телефон и скриншотом.
Вы же позволяете себе выдвигать претензии к человеку, который вам ничем не обязан и приводить ссылки на заблокированные ресурсы?
Как я уже утверждал в соседнем топике: я, все таки склоняюсь к выводу, что наиболее точное определение включает утверждение о том, что разработчик принимает и использует код, не полностью понимая его.
Про эмоции в термине "вайб-кодинг" пишет тот, кто придумал и начал использовать этот термин. Точнее эмоции, ощущения, атмосфера и сопереживания как раз обозначает слово "вайб", и возникают вибрации от процесса, (от наблюдения за процессом), программирования с помощью генеративных моделей.
А вот что принципиально - это то, что повальное использование кода без полного его понимания, должно иметь какое-то название. Так как масштаб проблемы - катастрофический.
Проблема есть, но не думаю, что она серьезная. Если разработчики грамотные, то они будут не только код писать, но и тесты для него разрабатывать (я про это как раз писал). А если нет, ну тогда рынок и баг-баунти за них все равно это порешают.
AI-assisted development - это когда человек использует ИИ, чтобы сделать чужими руками то, что он вполне может делать своими. То есть, дополнительная пара рук, глаз и часов в сутках, чтобы работать существенно быстрее. Это офигенная вещь.
Я полностью согласен с вами насчет подобной трактовки (в том числе и с точки зрения разработки дополнительных тестов).
удобно использовать нейросеть для создания начального прототипа, особенно если задача из смежной области
Заметил примерно то же самое: не умею в bash и "навайбкодил" нужный мне функционал на одну страницу кода. Через множество ошибок и переделок, но функционал заработал...
Но беда в том что несмотря на то что он таки зараобтал, я как абсолютный ноль в баше не могу оценить насколько корректно LLM навайбкодила...
Не знаю, как с bash, но при обычном программировании подобные сомнения решаются тестами. Я про это тоже написал и сейчас переделываю структуру проекта для уменьшения связанности кода и упрощения разработки тестов с помощью вайб-кодинга (много мелких файлов для уменьшения связанности)
Все на свете тестами не покроешь, а разработка правильных тестов - это тоже своего рода искусство. Как простейший пример для баша - LLM не добавила кавычки "куда надо" (или, наоборот, добавила там где не надо), и в результате на одних данных скрипт будет работать, а на других нет. Нужно иметь представление о потенциальных подводных камнях, и разрабатывать тесты с их учётом, а это означает, что опять же нужны знания в предметной области.
Знания предметной области - да, но для этого не нужно знать детали реализации.
Вот например код тестов у парсера настроект. Он полностью сгенерирован LLM и на первый взгляд покрывает значительную часть потенциальных косяков. Когда тесты работали было заметно, что часть из них фейлилась после чего исходный код парсера исправлялся. Я не фиксировал промежуточные результаты, но общий итог мне понравился.
Как конкретно bash тестировать, я не знаю но наверно есть способы. И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).
И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).
Вот именно что "по идее". Сгенерированное все равно потом потребуется проверить как минимум на предмет полноты и адекватности, и результат проверки вас вполне может неприятно удивить.
Может удивить точно так же как и программист. Но если выбирать между галюцинирующей LLM и программистом, который может специально скрыть неправильно работающий код (были реальные прецеденты), я лучше выберу LLM.
У нее нет умысла, она не желает достижения своих личных целей, выдает результат значительно быстрее человека и не возмущается на задачу в 10 или 20 раз переписать один и тот же код с учетом тех или иных изменений в требованиях :-)
Ну я веду речь вообще-то про выбор между "написать самому или доверить LLM". LLM вряд ли принципиально лучше джуна или хитрожопого погромиста, а врать умеет даже, пожалуй, поубедительнее последнего. Впрочем, дело вкуса.
Она врет без умысла по глупости из-за системного промпта для подстройки ответов к ожидаемым, а такую ложь очень легко выявить тестами.
Что же кажется, доверять LLM или нет в случае реальной разработки, это вопрос трудозатрат, что кому выгоднее. Ведь для работы с LLM нужно орагнизовывать свое рабочее место, платить деньги провайдеру или ставить локальный сервер, ломать собственные сложившиеся привычки и пр. пр. пр.
Тут видимо действует принцип: работает — пользуемся, не работает — вайпкодим заново, хотя в обычной разработке тоже таких проблем не всегда удается избежать в силу отсутствия опыта или принципа ХХВП
Тестами чего?
чтобы оценить как навайбкодила нейросеть надо открыть получившийся скрипт в вашем случае баш.
следом, надо увидеть задачу в частях, и начать разговор с нейросетью в другом диалоге о том как сделать эту часть поговорив с ней, скорее всего она может рассказать базу - например распишет команду, мануал, вам надо посмотреть эту часть - тоесть запустить, и вот так частями в разных диалогах вы проходитесь по всем частям скрипта, к концу скрипта вы уже сами поймёте что делаете
в тот же момент из-за вашего погружения в части скрипта вы углубите уровень контекста и там уже увидите практики - например на sc и если повезет выберете лучшее, нейросеть всё равно будет что-то советовать, к тому моменту вы уже должны будете точно определиться что делаете
Как минимум лично у меня есть проблема: делать ревью чужого кода мне тяжелее, чем написать аналогичный свой, особенно если манера письма отличается от моей. В случае LLM дело усугубляется их склонностью к галлюцинациям и вранью в стиле "чёрное - это белое". И в любом случае, будь то написание кода или ревью, нужно сначала досконально разобраться в проблеме, а если уж разобрался, то написать код - это чуть ли не самое простое.
Есть такая проблема и у меня тоже. Но думаю, что тесты должны помочь в этом случае. Главное не делать код слишком сложным (чтобы LLM не пришлось его серьезно анализировать).
Кстати, пока отвечал на ваш комментарий, в голову пришла интерсная идея - попробовать сохранять промпт, а возможно и настройки LLM как комментарий к коду для его повторного воспроизведения. Нужно будет поэкспериментировать в этом направлении.
Ну да, всё оглупить. К этому и идёт.
Почему "оглупить"? Сама идея держать единый контекст для всех LLM - очень даже ничего.
По итогам этой статьи пришел к выводу, что для нормального использования LLM нужно менять вообще весь подход к разработке. Сейчас пробую переделать проект, но вылезает очень много не очевидных нюансов, которые не заметны для Hello world, но сильно мешают в реальном проекте.
Точно. Потыкали, и пришли к тому, что нейронка быстро пишет vba для подгонки документации под стандарты и правки в стиле "добавь запуск вот этого метода по вторникам в полтретьего". То есть нейронка заменила джуна как раз. Вопрос теперь, как джунам обучаться на практике... 😅
На фотках с экрана не увидел c++
Для профессиональной работы или для рефакторинга объемного кода, локальные сети подходят плохо. Все работает очень медленно, а небольшой размер контекста не позволяет учитывать информацию из рабочего окружения, которая только увеличивается по мере выполнения новых запросов.
Если профессиональная работа осуществляется в рамках организации и вы занимаетесь коммерческими проектами, то закупка оборудования с несколькими хорошими видеокартами и выполнение прочих условий для запуска топовых LLM (как правило, китайских), вполне реальна. Одна карта 4090 это маловато конечно.
Но такие локальные сетапы нужны не чтобы сэкономить денег или решить сложности с оплатой, а чтобы не передавать в облака чувствительную информацию. В некоторых случаях это может быть запрещено заказчиком или это может нарушить NDA с вендорами проприетарных библиотек
Вайб-кодинг и реальное программирование на С++