Запретить скрипты на БХ которые были сделаны с помощью ИИ

[Tema05]

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

Я сравнивал не с нейронкой, а с вариантом где ты пишешь без неё. Т.е. необходимость быть компетентнее того уровня, которого бы хватало, чтоб написать тот код, что выдала нейронка, самостоятельно. Что я имею ввиду: Нейронка может выдавать определённые решения, код которых работает и он понятен, но неявно обоснование почему реализация именно такая. Это уже вопросы абстракций, архитектуры и в целом идеи какую задачу должен решает код. Когда ты пишешь сам, выбираешь методы, которые используешь, ты понимаешь почему написал так как написал. В голове по умолчанию есть обоснование. А для анализа этого в решении от нейронки уже нужен опыт, дабы суметь понять что какие-то реализации хоть и работают, не вписываются в кодовую базу и могут выстрелить в ногу в будущем.

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

То что код не хорошо копипастить это понятно. Тут я также проводил сравнение не между тем, чтоб проверять или копипастить код из нейронки, а между написание кода без и с нейросетью (в обоих случаях без копипаста). Мне кажется плохо использовать решения нейросети до которых ты бы не смог дойти сам. Это продолжение мысли выше. Можно полностью понять код, написать не копируя, но ты в этот момент не прошёл через путь, который привёл бы тебя к этой реализации. Тем самым как мне кажется упускается важный момент обучения и получения опыта, который позволяет тебе повышать свою профессиональную квалификацию. Это не относится к тем кто уже проектировал сложные системы и имеет эти знания, но для новичков желание использовать очень крутое решение от нейронки, которые они бы сами никогда не вывели, непреодолимо. Это как учиться решать примеры только по их готовым решениям. Ты можешь понимать всё что написано, оценить красоту решения, запомнить часты паттерны и применять их, но в голове не будут построены логические последовательные связи как к ним приходить. По итогу навык решать уникальные задачи, где требуется самому выводить решения, опираясь на специфику твоего проекта, не вырабатывается.

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

В основе своей я редко засиживаюсь на каких-либо библиотеках: старые уходят в небытие или обновляют свое API, новые приходят на замену старым. Мир не стоит на месте, чего нельзя сказать про какую-нибудь модель, которая выпускается условно раз в полгода и зачастую тащит за собой старые API и как морально, так и физически устаревшие библиотеки. Очень часто бывает такое, что нейронка либо не знает, что используемые ею методы уже давно помечены как "депрекейтед", либо они вообще вырезаны. На своем опыте мне крайне часто приходится с таким сталкиваться и просто скармливать ей весь талмуд доков, а это, опять же, засоряет контекст, и со временем она тупеет все сильнее и сильнее.

Насчет доков: я нередко прошу нейронку написать довольно специфический код, особенно если это затрагивает какое-нибудь системное API. По моему опыту, нейронка ни разу не написала код, который бы сразу завелся с первого раза: всегда были рантайм-ошибки либо ошибки, связанные с типами данных и тому подобное. И каждый раз, когда она выдает свое решение, я лезу в официальную документацию просто из-за того, что не знаю, какие "штуки" она использует - будь то MSDN или какая-нибудь некролиба, которую она зачем-то решила подтянуть в проект.

Теперь понял о чём ты. Сам сталкивался с этим, особенно весело когда автор библиотеки решил в новой версии перелопатить половину методов) И смотреть документацию очередного системного вызова, который использовала нейронка обычное дело. Я так понимаю речь про C++. Полностью согласен, что нейронке очень тяжело написать код, который сразу будет работать. Но скорее это специфика языка, где даже различия работы настроек компилятора между разными версиями могут всё сломать. Про агентов позже написали, они конечно справляются лучше, особенно в полностью навайбкоженных проектах, но вместить в себя колоссальный контекст для безошибочных изменений уже существующего всё ещё сложно. Не всегда есть возможность к полному тестированию и эмуляции реальной работы для поиска ошибок.

 

[Randy]

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

 

[kyrtion]

Как я понимаю. Есть 2 типа как люди относят к ИИ и её выделят:
Нуб - простой и маленький промпт, почти нет ограничения или неправильно фразирует. Пропитывает галлюцинация из-за недостаточной понимание как работает эта штука (например авто-обновление) и начнётся выдумываться (а должно: если не поймет пусть задаст тебе вопрос). Мало источники, документация. Нет реальные примеры (например, показать plugin-sdk) - Выйдет ужасный скрипт.
Профессионал - Все наоборот. Осознает что и как продукт должен улучшить. Ставит конкретные цели и много ограничений (строго в этой папке/подпапки, тд). Ревью с ИИ. ИИ пишет документацию и следует правила. Скиллы для ИИ (например после ревью запускать тесты и парсить в документацию что изменено/добавлено). Умеет договориться - разраб пишет бэкенд и администрирует бд, а ИИ делает фронтэнд и ревью кода, проходит тест и пишет документация. Также умеет составить ТЗ и ИИ должен соблюдать.

Я предлагаю - автоматически маркировать только если не заботят продукты после проделки с ИИ (говнокод, дерьма, дубликаты скрипты)