Требовать маркировку тем и плагинов, сгенерированных LLM

Внести вклад Обратная связь по сайту
41

Это довольно большой скачок в вашем рассуждении.

  • Если бы вы наняли стажёра или сами потратили 10 ночей, вы тоже могли бы добавить FLAC-плеер в ваше воображаемое приложение. Принятие плохих продуктовых решений не является присущим использованию LLM, и вопрос о том, является ли добавление бесполезной функции потерей усилий на разработку, всегда был предметом обсуждения.

  • Дополнительные функции не обязательно делают ваше приложение медленнее и тяжелее по потреблению RAM, эта проблема была решена концепцией динамической загрузки — 40 лет назад.

Именно так. Подчёркивание моё :slight_smile:

3 лайка
42

Нет, это различие не следует обозначать.

  • Обеспечена ли безопасность программного обеспечения?
  • Решает ли оно мою проблему?

Возвращаюсь к своей первоначальной мысли.

Если у нас есть проблемы с безопасностью в темах, давайте обсудим систему их проверки.

Если у нас есть проблемы с качеством в темах, давайте обсудим системы их проверки.

Но нет, я не буду вводить в темах наклейки вроде «разработано на Mac», «разработано на красной клавиатуре» или «разработано с использованием 93,2% ИИ» — этого не будет.

Сколько я использую ИИ? С удовольствием поделюсь своими рабочими процессами в отдельной теме, но я больше не пишу код вручную в vim.

7 лайков
43

Отвергать все плагины, созданные с помощью ИИ, исключительно по причине их происхождения, было бы генетической ошибкой. То, что контент создан ИИ, раньше могло быть неплохим эвристическим критерием для определения низкокачественного мусора, но по мере улучшения моделей становится всё труднее отличить результат работы человека от результата работы ИИ. Если вас беспокоят качество или безопасность, я считаю, что безопаснее исходить из предположения, что любой код небезопасен, пока он не будет проверен в рамках какой-либо системы рецензирования сообществом.

44

Я думаю, что многим было бы интересно узнать, как команды используют ИИ сегодня — от дизайнеров и разработчиков до юристов, маркетологов и специалистов в других областях.

Знать немного об ИИ, как и я, не значит понимать и осознавать, как компания на самом деле работает с ИИ в повседневной деятельности.

6 лайков
45

Я внимательно изучил всё, что здесь написано, и вижу обе стороны медали. С одной стороны, хорошо, что люди могут просто создавать плагины здесь и публиковать их, но с другой — это плохо, если они содержат «потенциальные» уязвимости безопасности, которые могут поставить под угрозу установку Discourse.

Чуть в сторону.

Существует другой провайдер форумного ПО (WoltLab), у которого, например, есть магазин плагинов. Перед каждым релизом плагины и темы проходят проверку командой. Возможно, стоит подумать о внедрении чего-то подобного и здесь. Однако всегда возникает вопрос о том, кто будет проводить эту проверку, и я предполагаю, что это потребует значительных затрат времени и персонала.

2 лайка
46

Я могу с уверенностью в 100% сказать, что это абсолютно нежизнеспособная идея — проверять каждый плагин и тему сторонних разработчиков. (Хотя бы не вручную, силами человека)

47

А что насчёт специально подобранного набора инструментов для тестирования плагинов или TC, сгенерированных LLM, под наблюдением, поддержкой и обновлением со стороны команды?

Я понимаю, что каждый может запускать тесты самостоятельно, но, честно говоря, не все знают, как это делать.

Простой и надёжный метод для этого, на мой взгляд, — это лучшее из двух миров.

48

В этом и заключается главная цель данной темы:

Было интересно наблюдать, как каждый высказывает своё мнение о том, почему эта прозрачность может быть важна, как с моральной, так и с точки зрения безопасности. Лично мне безразлично, создано ли что-то инженером-программистом с 30-летним стажем, пишущим на Ruby с самого начала, или маленьким Тимми, не имеющим никакого опыта в программировании. Если это на 100% «сгенерированный мусор»[1], я не буду этим пользоваться, и в противном случае я буду лицемером. Я понимаю, почему это популярно, но я просто не собираюсь поддерживать этот подход. Если бы эти модели обучались этичным путём и не вызывали дефицит компонентов, а также эпидемию медиа, сгенерированных ИИ, моё отношение к ним могло бы быть менее негативным, но таков не мир, в котором мы живём.

Беспокойство о безопасности плагинов в целом также обосновано и не ограничивается лишь тем, что «это создано ИИ». Это сложная проблема, которая выходит за рамки данной темы; здесь лишь предлагается ввести требование об обязательных тегах для активов, полностью сгенерированных LLM.

  1. «vibe-coding» или «agentic development» — термины, которые я отказываюсь использовать ↩︎

1 лайк
49

Я по-прежнему не понимаю, какую проблему решает этот подход. Может, кто-нибудь приведёт пример плагина, написанного «на интуиции» (vibe-coded), который оказался мусором, небезопасным или чрезмерно нагружал систему? Такой, который вообще не следовало рекламировать здесь, потому что он был полным хламом и тратой времени всех?

И если такие примеры действительно есть, то достаточно ли их, чтобы считать это проблемой?

1 лайк
50

Мне кажется, было бы полезно ввести某种 самопроверяемый чек-лист для тем: сколько тестирования вы провели, готовы ли вы получать отчеты о качестве и безопасности, будете ли вы оперативно реагировать на обратную связь.

Или, например, опишите ваш процесс разработки не более чем в трех предложениях.

Истинность ответов не будет иметь большого значения, но разница между теми темами, которые прошли самопроверку, и теми, которые этого не делали, может стать ценным сигналом для того, кто рассматривает возможность установки.

4 лайка
51

Лично я никогда не использую «vibe-coding» ни в одном приложении, проекте или программном обеспечении, которое создаю. Я использую чаты с ИИ для генерации идей или уточнения деталей, но никогда не отдаю ИИ весь проект целиком. Это, безусловно, более ручной процесс, но хотя бы я знаю, что делаю, и не слепо доверяю всё это другой сущности.

Но я наблюдал, как за последние несколько месяцев сильно выросло качество кода, созданного с помощью ИИ. Возможно, изначально он писался плохо или был усеян уязвимостями, но я бы сказал, что с тех пор он улучшился на порядок. Дизайн, созданный в стиле «vibe-coding», всё ещё довольно узнаваем (градиенты, рамки, эмодзи и т. д.), даже в некоторых плагинах, которые я видел на Meta. Но важно то, что автор поделился этим из личных интересов и интересов сообщества. Не для того, чтобы кто-то затоптал это и назвал «мусором», а потому что он добился реального успеха с этим плагином и хочет поделиться им с другими форумами, которые ищут аналогичный функционал.

Я понимаю ваши опасения по поводу этики использования ИИ, но они, кажется, направлены на ИИ в целом: компании, которые «разрезают» книги, массовое потребление воды и электроэнергии и т. д. Вы упомянули:

Но как это соотносится с использованием плагинов или TC, созданных с помощью ИИ? Если вам не нравится ИИ, ладно, не используйте его. Но ландшафт программирования радикально изменился с появлением ИИ, и такие вещи, как плагины и TC, тоже изменятся. Перестанете ли вы полностью использовать Discourse, зная, что часть кода была написана с помощью ИИ? Я бы не стал, потому что знаю, что за этим всё ещё стоят люди.

Так стоит ли всё ещё называть это «мусорным кодом» и бойкотировать использование термина «vibe-coding» (лично я не вижу в этом последнем выражении ничего плохого)? Возможно, нет. Это слишком резко? Да. Насколько бы вам это ни не нравилось, иногда нам приходится адаптироваться. Означает ли это, что теперь я буду создавать TC с помощью ИИ и делиться ими? Для меня — нет. Но означает ли это, что я буду рассматривать это как альтернативу, которую не следует отвергать или презирать? Да. И я стараюсь именно так и поступать. Надеюсь, вы тоже сможете.

5 лайков
52

Просто делюсь отобранной статьёй, связанной с этой темой:

Trail of Bits утверждает, что ИИ-агенты наиболее полезны в аудите для создания специализированных инструментов, а не только для поиска уязвимостей. При аудите zkVM Miden они использовали Claude и Codex для создания LSP-сервера, дизассемблера, статического анализатора и модели Lean, что позволило выявить уязвимость высокой критичности, связанную с подделкой подписи, и 95 доказательств на языке Lean, обнаруживших две тонкие проблемы.

Поскольку агенты делают амбициозные побочные проекты дешевле, экономика аудита сместилась в сторону инструментально-ориентированных проверок, способных обеспечить защиту сложных систем гораздо более тщательно, чем прежде.

53

я использую ии, чтобы помогать мне в разработке моих плагинов и компонентов. используйте их на свой страх и риск, но я не буду помечать их какими-либо предупреждениями или тегами, точно так же, как это делает ядро discourse. я управляю агентами, проверяю код (иногда с помощью другого агента или набора «глаз» llm) и тестирую их. вы свободны не использовать их, но я чаще видел плохо написанный код, созданный полностью человеком, чем ии.

5 лайков
54

Действительно, я думаю, что традиционный подход к оценке качества чего-либо — это проверка репутации сущности, которая это создала. Личная репутация хорошо работает, когда человек активен в open source. Как правило, если кто-то ранее делал хорошую работу и был отзывчив, он будет продолжать в том же духе.

2 лайка