Comments 25
как только китай перестает играть роль "злых комунистов" в мире LLM, публикуя в открытом виде топовые сетки их иследования,то мир очень быстро (буквально пару лет) присядет на первый стул
нейронки бустят опенсорс пока эти самые нейронки условно открытые, как только картель сформируется в нейронки начнут напихивать ограничения и вшивать тригеры, что бы покупали дороже, лучше и тд.
Уже сейчас кодеры всего мира подсаживаются на оркестрацию агентов. Лягушку варят медленно и возможно через 20 лет уже никого не будет удивлять что сгенерированый код идет сразу с вшитой рекламой и трекерами. Если такое вообще на уровень "государственного стандарта ПО" не пропихнут законодательно во имя зашиты детей и тому подобного
Написать свою библиотеку теперь станет легче. Сделать её такой же надёжной, как успешный опенсорс проект, который используют тысячи разработчиков, — вряд ли.
is-even и is-odd останутся?
Ну, кроме шуток, я выкинул парочку матбиблиотек и библиотек структур данныз потому что нейронка нормально пишет прикладуху по месту.
Библиотеки полезны тем, что протестированы и их корректность доказана.
Но я тоже не люблю лишних зависимостей, особенно от тяжёлых фреймворков
Мы тут на днях скачали либу для управления режимами компортов с сайта производителя промкомпьютеров. Кодекс её дизасемблировал и выяснил, что в ней ошибка. Значения регистров для одного из портов неправильно выставлялись. Написали свою.
А теперь представьте, что в этой либе есть ещё один баг, который ваш LLM не заметил.
Если бы вы завели issue автору на починку бага, то он бы починил его и для вас, и для всех остальных пользователей либы. И тогда, вполне вероятно, кто нибудь заметил бы баг, который не заметили вы. И так же завёл бы issue. Соответственно починка второго бага стала бы для вас бесплатной.
А переписав либу вы взвалили на себя стоимость долгосрочной поддержки этой либы. Что вас не ускоряет, а замедляет.
Написали свою
Тоже неправильную
Закрытую, без исходников что-ли?
Правильный способ:
Берется открытая библиотека, ищется баг без геморроя. Если баг есть делается форк. Желательно форк публикуется, а автору либы присылается реквест.
Зачем качать библиотеку, если можно сгенерировать полностью схожую и не связываться с лицензиями и прочими сложными вопросами? Тебе это все становится не нужно.
Мысль интересная, но пока она бьется об одну важную стену. Стена называется "LLM генерит говнокод". Говнокод не в плане, красивый он или некрасивый, а в плане, что он неработоспособный. А скажешь агенту "вот бага, подправь" - он часто сделает еще хуже.
Попробуйте взглянуть на это с другой, немного парадоксальной стороны. Стоимость кода просто физически не может упасть, потому что код сам по себе ровным счётом ничего не стоит. Его стоимость и до появления ИИ равнялась нулю, и после появления ИИ так же равняется нулю - так как ноль, умноженный на 10 равен нулю.
Почему стоимость кода равна нулю? Представьте, что у вас есть 2 разные библиотеки, которые решают одну и ту же задачу. Обе библиотеки работают одинаково корректно, но, одна библиотека заброшена несколько лет назад, а вокруг второй сформировалось сообщество разработчиков, которое активно развивает и поддерживает библиотеку. Какую библиотеку вы выберете? Конечно вторую. Более того, даже если бы второй библиотеки не существовало, вы бы всё равно в боевой проект не подключили бы первую. А почему? Да потому что вам важен не просто код, который решает задачу, а гарантированно верное решение, которое со временем не утратит свою актуальность, несмотря на выход новых версий языков и сопутствующих библиотек. Более того, вам важна уверенность в том, что если в решении найдётся ошибка, то она будет исправлена. Т.е. получается, что второе решение обладает для вас ценностью не потому, что оно работает, а потому, что его поддерживает сообщество инженеров. Т.е. ценностью обладает не код, а техническая экспертиза инженеров, которые его развивают и поддерживают.
Хорошо, а может ли результат работы LLM представлять для меня такую же ценность, как техническая экспертиза сообщества? Предположим, я подробно описал решение в виде спецификации и сгенерировал по ней код. Вышли новые версии языков/библиотек - перегенерировал. Нашлась ошибка - снова перегенерировал. Что здесь не так? А то, что LLM не обеспечивает строго детерменированную кодогенерацию, и не несёт ответственности (даже репутационной) за результат своей работы. Результат кодогенерации может содержать некоторое множество ошибок. Результат повторной кодогенерации по той же спеке и с тем же набором версий языков/библиотек может содержать другое множество ошибок, не равное первому. Как обеспечить гарантию качества кодогенерации? Да только если вы самостоятельно проведёте качественное ревью кода и обеспечите полноценное тестирование результата. Т.е. если вы проинвестируете в результат кодогенерации LLM своё рабочее время и свою техническую экспертизу.
Так чем же отличается результат кодогенерации LLM от первой, неподдерживаемой библиотеки? Да ничем! И там и там вы вынуждены будете инвестировать своё время и свою техническую экспертизу в долгосрочную поддержку полученного решения. Соответственно результат кодогенерации LLM для вас ничем не выгоднее, чем неподдерживаемая библиотека.
Т.е. чем ценна скачанная Open Source библиотека? Кодом? Нет, не кодом! А ценна она поддержкой сообщества, которое инвестирует своё время и техническую экспертизу в поддержку этого решения. И которому вы делегируете свою ответственность за долгосрочную стабильность и корректность этого решения.
Позвольте практический пример.
Представьте, что у вас есть 1 библиотека, которая решает задачу. Она коммерческая и закрытая, заменить её нечем. Она заброшена 15 лет назад. Она ничуть не утратила свою актуальность, потому что нечем её заменить. Инженеров, которые её развивают и поддерживают, давно уволили.
Итак, нет поддержки сообщества. Никто не инвестирует время и экспертизу в поддержку библиотеки. А ценность у неё настолько велика, что производитель отказывается открывать исходники.
Здесь вы описали сценарий ночного кошмара пользователей vendor lock-in решений. Такая библиотека становится не вашим активом, а вашим пассивом. Техническим долгом. Расплатиться по которому рано или поздно придётся. И плата по этому долгу может в разы превышать стоимость разработки вашего проекта.
Именно этот сценарий стал причиной появления открытых open source решений.
За последние 25 лет в той отрасли, из которой взят мой пример, никаких open source решений нету.
Да, бывает такая специфика. Я в IoT с этим сталкивался. Там протоколы и библиотеки взаимодействия с железяками гвоздями прибиты к производителям этих железяк.
Но, такая ситуация в отдельно взятых отраслях это скорее исключение из правила, чем правило. Просто эти отрасли не сумели перестроиться на более эффективный формат доставки ценности.
И эта библиотека конечно же 32-х битная dll, а заказчику срочно понадобилость приложение на Android. Ваши действия? Пример кстати не выдуманный, но мне повезло, что библиотека была скомпилина из python, и удалось её декомпилировать в более-менее приличный код.
И какая связь вашего примера с будущим опенсорс?
Для стороннего пользователя библиотеки хорошее решение будет написать (навайбкодить) свой вариант и выложить в опенсорс, чтобы и другие разработчики по описанной выше схеме Дмитрия присоединились и поделились технической экспертизой.
Стараюсь избегать библиотек, которые требуют постоянной сложной поддержки. Всякие там развивающиеся стандарты...
Зачем качать библиотеку, если можно сгенерировать полностью схожую
И у каждого будет свой (изобретённый) велосипед.
Хорошо бы ТС привел примеры на базе OpenSource проектов, в которых он участвует.
А то пока выглядит "Рабинович по телефону напел".
OpenSource мертв, да здравствует OpenSource :)