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

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

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

Конечно, это зависит от честности и прозрачности пользователей (и люди, у которых темы сгенерированы ИИ, могут не знать о них больше, чем указано в описании), но наличие тега вроде #ai-generated для активов, преимущественно созданных с помощью ИИ, было бы полезно для всех.

4 лайка
DiscourseSkill.md
2

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

Я всегда гордился программным обеспечением, которое разрабатывал на протяжении последних 40 лет, и внедрение LLM в мой рабочий процесс повысило качество моей работы, а не снизило его.

С другой стороны, я видел немало плагинов, написанных вручную, в которых полно уязвимостей безопасности, проблем с производительностью и плохих дизайнерских решений, и я искренне желал бы, чтобы их авторы использовали LLM. В конечном счёте, важна не степень участия LLM в написании кода, а качество разработчика и самого кода.

13 лайков
3

Мне интересно, как вы рекомендуете рецензировать и/или обновлять код, сгенерированный LLM, для тех из нас, кто начинает заниматься «вайб-кодингом», чтобы реализовывать новые функции или настраивать уже существующие.

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

Я согласен с предыдущим комментарием: я не против ИИ, но при этом осознаю, что ВСЁ, что они генерируют, должно быть проверено, верифицировано и обновлено людьми.

Что-то любопытное, связанное с этим:

2 лайка
4

Это вполне справедливо, и в конечном счёте я могу говорить только от своего имени. Мои наблюдения основаны на низкокачественных «мусорных» приложениях, которые все выглядят одинаково и в целом имеют низкое качество (как с точки зрения функциональности, так и безопасности), а также на существующих приложениях, качество которых резко упало после того, как они начали в значительной степени перекладывать работу на LLM (например, Visual Studio Code и Formbricks; оба этих продукта я перестал использовать). Даже если ваше приложение идеально, всё равно существуют этические опасения, поэтому было бы здорово, если бы существовала какая-то форма уведомления для таких созданий, как было предложено. Это не означает, что кто-то обязан основывать что-либо на этой метке, но если вы хотите, то наличие такой опции было бы приятно.

Как я уже сказал, это система, основанная на доверии, и ответственность за то, чтобы код был помечен как сгенерированный, лежит исключительно на разработчике. Конечно, есть случаи, когда LLM сама помечает себя в логах git (как это делают большинство), поэтому пользователь с уровнем TL3+ может предпринять необходимые действия, просмотрев GitHub, если сочтёт нужным.

1 лайк
5

Я ценю ваш ответ, спасибо. Мой вопрос также адресован всем и касается инструментов, которые в настоящее время существуют для верификации кода, сгенерированного LLM.

Я не разработчик, но мне удалось реализовать функции, которых не было в Discourse. И я хочу сделать всё возможное наилучшим образом.

Я подумаю о добавлении метки, если решу опубликовать свои репозитории; на данный момент они приватны именно потому, что я их тестирую, и мне важно всё сделать правильно, прежде чем распространять среди сообщества.

6

Я был бы крайне удивлён, если бы большая часть Core-кода (включая Core-плагины) сейчас не разрабатывалась с помощью кодинг-агентов — настолько сильно изменился процесс разработки.

На мой взгляд, сейчас очень трудно оправдать неиспользование кодинг-агентов в большинстве задач, так как потеря в эффективности просто не имеет бизнес-смысла.

4 лайка
7

Меня совершенно не волнует «как именно был создан плагин» и использовал ли разработчик карандаш или ручку.

Фраза «Здесь нет ИИ» не даёт мне ни малейшего дополнительного доверия при установке темы или плагина.

Однако… есть куда более серьёзная проблема, которую нам нужно решить в CDCK.

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

Третьесторонние плагины и темы здесь — это «Дикий Запад»: внести свой вклад может кто угодно, мы не проводим проверку безопасности и не гарантируем, что соблюдаются лучшие практики. Это ставит сообщество под угрозу.

Я хотел бы прийти к тому, чтобы хотя бы версия XYZ темы автоматически проходила сканирование, чтобы у тех, кто размещает серверы самостоятельно, было хотя бы минимальное доверие.

Так что моё видение здесь прямо противоположно :slight_smile: требовать, чтобы версии сторонних тем и плагинов проходили某种 сканирование ИИ перед тем, как их здесь рекламируют.

9 лайков
8

На мой взгляд, код-ревью с помощью LLM — это совсем не то же самое, что «Claude, собери мне это приложение и не делай ни одной ошибки», а затем публикация результата с минимальной или вообще отсутствующей валидацией и правками, выполненными лично вами. По крайней мере, с этической точки зрения. К сожалению, заставить конечного пользователя нести ответственность практически невозможно, и как бы вы ни старались, кто-то найдёт способ скачать что-то вредоносное. Но в любом случае, насколько этичны LLM — это отдельный разговор, который не слишком актуален для этой темы.

И это нормально! Я не призываю к тотальному запрету на всё, что так или иначе связано с ИИ, в разделе Customization. Я просто хотел бы, чтобы такие вещи были правильно помечены, чтобы те, кто не хочет открывать эту «пандорину коробку», не сделали этого случайно.

9

У меня много проблем с инструментами на базе LLM (и с их результатами). Не только с вопросами безопасности, юридическими, надёжности и экологии. Но это не главная тема здесь.

Безопасность в широком смысле — вот что важно. Неважно, сгенерирован ли код ИИ или нет.

Какие инструменты CDCK использует для проверок безопасности? Многие из них также важны для сторонних разработок.

Но есть и другие моменты, которые нужно проверять. С какими внешними системами взаимодействует сторонняя разработка? Большинство инструментов анализа безопасности допускают, что программное обеспечение общается с внешними серверами, без heartbeat. Но чисто косметическая тема не должна выполнять никаких обращений к внешним серверам. Так что сторонняя разработка может содержать уязвимости безопасности или проблемы, которые могут навредить доступности. Но она также может выводить данные наружу.

10

Я согласен с этим на 95%. И мы ведь говорим о Discourse, а представьте, что мы оказались в мире WordPress!

(Те 5%, с которыми я не согласен: я не думаю, что это «Дикий Запад» — проблемы безопасности сообщаются через meta тем разработчикам сторонних плагинов, и в целом они исправляются довольно быстро).

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

Я вручную проверял плагины на протяжении последнего десятилетия и видел многое: SQL-инъекции (со стороны людей, которые считали ActiveRecord слишком сложным), настройки ключей API с client: true, полное отсутствие авторизации и контроля доступа, отсутствие ограничения частоты запросов. LLM находят и исправляют все это в кратчайшие сроки и без особых усилий.

Итак, ещё раз: я считаю, что LLM сделали это лучше, а не хуже.

Вы по-прежнему связываете код, сгенерированный LLM, с «коробкой Пандоры», это слишком чёрно-белый подход.

5 лайков
11

Jack McDade применил такой подход к каталогу аддонов Statamic

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

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

4 лайка
12

Меня также беспокоят плагины и компоненты низкого качества, и я действительно им не доверяю, когда на 99% они написаны «на ощупь» (vibe-coded) кем-то, кто не разбирается в программировании.

Но я также верю опытным программистам, которые говорят, что плохие программисты существовали задолго до появления ИИ[1]. Небрежный, ненадёжный и дефектный код создавался вручную с давних времён.

Меня беспокоит, когда я вижу приложение/плагин/что-либо ещё, написанное «на ощупь», и подозреваю, что автор не просмотрел код.

Хотя у меня есть базовые знания в программировании, я не писал код уже долгое время и никогда в этом не был хорош. Я попробовал написать несколько проектов с помощью ИИ.

Сначала я очень неохотно публиковал их официально на meta, но в конце концов сделал это, потратив время на просмотр и понимание того, что делает каждый фрагмент кода, а также публично описав свой подход в своих темах. Не то чтобы я помнил всё, что читал перед публикацией этих плагинов, но хотя бы я мог убедиться в надёжности и безопасности на момент публикации этой работы.

У меня есть хороший пример, иллюстрирующий, как код, написанный «на ощупь», мог заставить меня выпустить очень небезопасный плагин.

Прежде чем работать над 🖼️ Topic Gallery, я создал концепт-доказательство (proof of concept) похожего плагина здесь: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Он отлично работал, и ИИ следовал моим инструкциям.

Но была одна проблема: хотя функция явно была функцией модерации, ИИ не учёл права доступа: любой пользователь, включая посетителей, мог открыть эту страницу и увидеть все файлы, загруженные всеми пользователями. Для меня было очевидно, что это должно быть доступно только администраторам, но ИИ об этом не «подумал». И поскольку я не попросил его об этом, по умолчанию была создана публичная страница.

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

Мнения о коде, созданном ИИ, в программном обеспечении сильно поляризованы. Достаточно взглянуть на любой популярный проект с открытым исходным кодом, где Claude указан соавтором последних коммитов, чтобы увидеть поток ненависти со стороны некоторых людей.
Я убеждён, что мы должны подходить к этим вещам с осторожностью и что наши мнения должны быть более нюансированными.

Я не особенно за то, чтобы иметь какой-либо тег vibe-coded, который мог бы ненужно навредить популярности хорошо написанных и безопасных кастомизаций и их авторов.

Я знаю, что теперь любой может создавать кастомизации, их может становиться всё больше с каждым днём, и людей для их проверки недостаточно.

Проверка ИИ, возможно, является решением. Мой инстинкт не очень любит эту идею по разным причинам, но я считаю, что если Сэм предлагает такое решение, то, вероятно, оно хорошее, потому что я очень доверяю его навыкам и суждениям. Тем более что я сам не знаю ничего. :laughing:

Возможно, некоторые разработчики здесь, которые знают о программировании и экосистеме Discourse, могли бы иметь титул, который явно показывает их экспертизу в этой области, чтобы их можно было рассматривать как доверенных разработчиков даже посетителями, которые просто ищут кастомизации здесь без регистрации. Это было бы противоположностью того, о чём вы просите, darkpxlz. Вместо того чтобы «позорить» потенциально недоверенные кастомизации, мы бы выделяли доверенные. :slight_smile:

Просто пища для размышлений. :person_shrugging:

  1. Я-то знаю, я был одним из них! ↩︎

6 лайков
13

Полностью возможно, что я нахожусь в эхо-камере, настроенной против ИИ, из-за потребляемых мной медиа и людей, с которыми я ежедневно взаимодействую. Я был почти уверен, что эта инициатива не вызовет такого отторжения, но если все здесь на самом деле любят кодить с помощью LLM и не хотят тег чисто ради прозрачности, то кто я такой, чтобы этому препятствовать? Обнаружение кода, сгенерированного LLM, по-прежнему довольно легко, так что если кто-то (например, я сам) действительно хочет его избегать, он может просто проверить список участников на наличие пометки LLM, как я ранее предлагал.

2 лайка
14

Учитывая, что тема спорная, я лично поддерживаю вашу изначальную просьбу, которая удовлетворит потребности той части сообщества, которая на данный момент настроена более скептически (что вполне понятно).

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

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

5 лайков
15

Я считаю, что тщательная проверка как людьми, так и ИИ — хорошая идея для любого важного программного обеспечения, независимо от того, было ли оно изначально написано человеком или ИИ. Было бы здорово, если бы существовали более удобные инструменты для ревью кода и отслеживания того, кто и какие версии каких пакетов проверил. Сейчас есть проекты, которые в какой-то степени делают это для Rust/Cargo: Crev, cargo-vet и Thirdpass. Я также запустил обсуждение на Swift-форуме.

1 лайк
16

Я на стороне тех, кто считает, что метки нужны. Спор о наличии или отсутствии меток — это, по сути, ложный след. Для меня ключевой вопрос — обеспечение качества кода и продуктов в каталоге плагинов, и это главное. В этой области конечная ответственность лежит на Discourse, но сообщество может помочь. В этой связи я и мой самый близкий друг (BFF) поработали над созданием файла DiscourseSkill.md. Изначально я планировал использовать его только внутри, но, возможно, он пригодится и другим. Так что загляните сюда: DiscourseSkill.md

1 лайк
17

Таким образом, авторам плагинов теперь придётся использовать ИИ, чтобы запускать эти тесты :thinking:

Это действительно решает реальную проблему? Сообщество действительно страдало от низкокачественных плагинов, и были ли они созданы с помощью LLM?

1 лайк
18

Я бы точно больше никогда не разрабатывал ничего для Discourse, если бы меня заставили использовать LLM-IDE (или как там сейчас называют эту хрень: :sparkles: агентное редактирование :sparkles: или что-то в этом роде) или иначе включать функции LLM в своём редакторе, чтобы тот ревьюил мой код. Когда, например, code rabbit отвечает на GitHub PR или локально размещённая CDCK модель проверяет что-то — это совсем другое дело, чем заставлять разработчика устанавливать такие инструменты для чего-то настолько простого, как ревью кода.

1 лайк
19

« Так что теперь авторам плагинов придётся реально использовать ИИ, чтобы запускать эти тесты» Почему вы так говорите? Ничто в моём сообщении не намекает на то, что кого-то будут или должны заставлять это делать.

1 лайк
20

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

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