Это, в частности, зависит ещё и от ЯП. Например, Go достаточно простой и код на нём выглядит плюс/минус одинаково у всех, поэтому, спроектировав в голове ожидаемый код и поставив задачу Claude я очень часто получаю практически ровно тот же код, который собирался написать сам - только намного быстрее. Проблемы чтения чужого кода в случае ИИ почти не возникает - особенно когда изменения вносятся в существующий проект и ИИ видит используемый стиль существующего кода.
Не синонимы. Впрочем, давайте согласуем термины (однозначного определения у них нет, так что мы вполне можем иметь в виду разное): чистый = ясный и поддерживаемый код покрытый юнит-тестами; хороший = чистый плюс учитывающий нефункциональные требования (производительность, безопасность, элегантность, оптимальность алгоритмов с учётом ожидаемой нагрузки конкретно на это место кода, заложенные заранее возможности развития в ожидаемом направлении, соблюдение определённого стиля логируемых сообщений и т.п.).
В абсолютном большинстве мест в коде достаточно чистого (потому что там реализуется типовой функционал типовым же способом, зачастую по аналогии с уже существующим кодом), равно как и от большинства разработчиков мы ничего большего не получим при всём желании. И такой код LLM вполне в состоянии выдавать.
А хороший код мы от LLM вряд ли получим. Максимум - точечно и после кучи уточнений, причём скорее всего быстрее будет написать вручную. Но и мест где такой код критичен - очень мало, так что это не отменяет значимой пользы от LLM по написанию достаточно чистого кода во всех остальных местах.
Потому что цель собеса понять, сможет ли сотрудник качественно решать задачи на своей позиции, а не получилось ли у него случайно/однократно получить от модели решение типового тестового.
Не знаю, в какой вселенной архитектор — руководитель
В стартапах, например. Но и в крупных компаниях, где архитект не является непосредственным руководителем, ему всё-равно требуются ровно те же навыки, только для мягкого убеждения тимлидов команд. Суть в том, что и там и там архитект должен уметь коммуницировать свои требования, и если делать это в сторону моделей примерно так же, как в сторону людей, то модель отлично под эти требования подстроится и будет выдавать весьма чистый код.
Судя по сказанному, лично Вы пока не научились получать адекватный результат от моделей - но это не значит, что это в принципе невозможно. Из моего опыта лучше всего получать качественный код от моделей получается у… руководителей (тимлидов/архитектов). Которые разговаривают с моделью примерно как с новым сотрудником, поясняя как именно и почему именно так требуется писать код на текущем проекте когда модель выдаёт что-то не то.
И да, бывают ситуации, когда быстрее написать самому. Но в этом нет ничего плохого или неправильного - никто же не ставит цель программеру (в отличие от вайб-кодеров) получить 100% кода генерацией в реальных задачах - если быстрее самому написать или что-то подчистить в результатах генерации, то надо это сделать вручную. Это же не отменяет экономии кучи времени и сил благодаря LLM в остальное время.
Для этого кандидат должен обладать способностью сам написать такой код, а значит — быть профессионалом.
Да. Вопрос был в том, как именно это проверить на собесе.
Экспертиза моделей всегда будет отражать среднее по больнице
Это правда, но не вся. Это - поведение модели по умолчанию, без дополнительных указаний. И этот средний уровень, будем откровенны, чуть сильнее среднего уровня обычных разработчиков по рынку (по крайней мере у моделей Claude) - т.е. вполне приемлемый. Да, если задача - нанять звезду, а не просто ещё несколько средних разработчиков, то модель звезде не конкурент, и, вполне возможно, никогда конкурентом звезде не станет - именно потому, что отражает "среднее по больнице" и показать более сильные результаты может исключительно под управлением более сильного разработчика, но никак не без него/вместо него.
Насчёт "пахнет генерацией" - я не соглашусь. Что выдаст LLM сильно зависит как от самой модели, так и от формулировки промпта. Получать качественный и адекватный код от моделей пока умеют не все разработчики, но это вполне реально - и такой код "генерацией" не пахнет. Более того, в сегодняшних реалиях это даже перестаёт быть важным вопросом - сам написал или сгенерировал, если результат годный. В работе это перестаёт быть вопросом, но не на собесе. Потому что по одной удачной генерации для мелкой типовой задачки невозможно сделать вывод "этот кандидат умеет получать от модели нормальный код для любых задач".
Я думаю, нужно менять подход собесов с "кандидат пишет свой код" на "кандидат ревьювит наш пример кода". Причём ревью кода должно включать не только критику, но и обсуждение что и как нужно изменить в существующем коде для решения каких-то задач (рефакторинг/добавить фичу-другую/починить баг).
Это в теории. А на практике качество звука временами паршивое в ситуации когда проблем с кодеками и каналом нет, будь то браузер или youtube-dl (yt-dlp), на бесплатном тарифе. Т.е. скорее это рандомно зависит от загруженности их серверов, нежели от канала и кодеков на клиенте. И следствием этого является наблюдаемое поведение: иногда звук норм, но часто говно, поэтому если нужен нормальный звук то ютуб как источник просто не рассматривается.
Тут немного в другом дело. Конкретно ютуб замечен в том, что качество аудио потока у него может сильно отличаться. Оригинал видео заливается с одним кодеком и качеством звука, а ютуб эту запись раздаёт с другим кодеком и/или качеством. От чего зависит и может ли это контролировать автор при заливании я не изучал, но сам факт того, что ютуб нередко выдавал к официальным качественным роликам аудиодорожку с сильно пониженным качеством звука - это факт. Поэтому все, кого волнует качество звука, стараются такие записи качать не с ютуба, а с тех же торрентов или официальных сайтов.
Ну, не исчезли, но да, их как-то совсем мало стало. Сейчас зашёл на агрегатор, и там для PCIe звуковух всего 5 вариантов: $60, $150, $250, $1000 и $1800. К профессиональным, надо полагать, относятся последние две.
Тесты проверяют на наличие любых изменений - а в новой версии изменения есть по определению, так что падение части тестов это норма. На совместимость должны проверять совершенно отдельные тесты, заточенные под это специально - что потребует, для начала, определить само понятие "совместимость" для конкретного продукта, а потом ещё и научиться его надёжно тестировать. На данный момент такого типа тесты если и встречаются, то это большая редкость.
Обычно "совместимость" контролируется либо формальными инструментами (которые проверяют только техническую совместимость API библиотеки или .proto-файла но не семантику/поведение этого API) либо вообще вручную (напр. для REST/OpenAPI мне такие линтеры как для proto пока не встречались). Тесты на семантику API написанные именно с целью контроля совместимости попадались редко и не были выделены в отдельную группу тестов совместимости, а были размазаны среди прочих (т.е. было крайне сложно понять что тестируется в этом плане, а что нет).
подбирать кабели на звук и менять ЦАПы ради едва уловимой разницы в тембре, которую остальные никогда не услышат даже при всем желании
В золотые кабели со стрелочками я лично не верю, но вот что касается "остальные никогда не услышат" - это сильно зависит как от того, на каких колонках/наушниках слушать, так и от собственно слуха. Если слуха нет либо колонки/наушники относительно дешёвые - разницу действительно услышать не получится, разве что чисто психологически она там померещится. Но если слух нормальный и колонки/наушники достаточно крутые, то разницу между встроенным в материнку звуком и отдельной звуковой картой услышать достаточно легко (особенно если слушать не mp3, а любой lossless формат).
Через час после всех тестов в ci получить ошибку типов при билде очень больно
Больно, да. Но все гошники дофига лет с этим жили, и, в целом, были довольны своим ЯП. Ну т.е. больно, но не так чтобы очень. Где это было неприемлемо - вендорили.
не все перешли
Честно, не знаю таких примеров. Есть устаревшие, не поддерживаемые проекты, которые никто не обновлял - это да. А вот актуальные, поддерживаемые, и продолжающие жить в GOPATH без версий - я не сталкивался. Наверное, пару исключений найдётся, если специально искать, но на фоне общего количества проектов на го - это погрешность, а не статистика.
и это всё равно ничего не доказывает
Почему не доказывает? Как по мне - это идеальное доказательство. Потому что у людей не просто был свободный выбор между несколькими вариантами (без версий, вендоринг, с версиями), но ещё и за много лет сформировавшаяся привычка жить без версий. Если в этой ситуации все дружно переходят на версионирование - это очень громкое и вполне однозначное заявление, как по мне.
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
По-моему общий консенсус в том, что лучше так, чем получать внезапные отличия в поведении просто из-за пересборки старой версии на CI через неделю после предыдущей, либо вообще сломанную сборку. Недостатки есть у всех подходов, но подход позволяющий обеспечить повторяемость сборки определённо выигрывает.
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Если не учитывать использование локального кеша - то всегда. Локально у разработчиков кеш обычно присутствовал, но вот на CI - наоборот. А поскольку сборка на CI обычно важнее - именно её результат релизится - то вполне корректно считать это version less, разве нет?
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
На версионирование перешли абсолютно все, не только большие компании, но и индивидуальные разработчики опенсорса, которых никто не принуждал. Так что, как по мне, это вполне доказывает.
На Go все писали без поддержки версий пакетов примерно 9 лет (до 2018). В целом, как ни странно, это было не так страшно, как выглядит на первый взгляд. Изредка использовали вендоринг, но большинство проектов и библиотек нормально жило без управления версиями - достаточно поддерживать стабильную работу в ветке master и избегать (по возможности) несовместимых изменений. Это доказывает, что без версий - жить можно. Но как только в 2018 появилась встроенная поддержка версионирования - все тут же начали её использовать. Это доказывает, что с версиями - жить лучше. ;-)
А это уже культура разработки, которой может не быть, человеческий фактор, не проставил, или проставил не то, не та версия инкрементнулась.
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
В этом плане календарное версионирование решает проблему.
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет.
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.
Это, в частности, зависит ещё и от ЯП. Например, Go достаточно простой и код на нём выглядит плюс/минус одинаково у всех, поэтому, спроектировав в голове ожидаемый код и поставив задачу Claude я очень часто получаю практически ровно тот же код, который собирался написать сам - только намного быстрее. Проблемы чтения чужого кода в случае ИИ почти не возникает - особенно когда изменения вносятся в существующий проект и ИИ видит используемый стиль существующего кода.
Не синонимы. Впрочем, давайте согласуем термины (однозначного определения у них нет, так что мы вполне можем иметь в виду разное): чистый = ясный и поддерживаемый код покрытый юнит-тестами; хороший = чистый плюс учитывающий нефункциональные требования (производительность, безопасность, элегантность, оптимальность алгоритмов с учётом ожидаемой нагрузки конкретно на это место кода, заложенные заранее возможности развития в ожидаемом направлении, соблюдение определённого стиля логируемых сообщений и т.п.).
В абсолютном большинстве мест в коде достаточно чистого (потому что там реализуется типовой функционал типовым же способом, зачастую по аналогии с уже существующим кодом), равно как и от большинства разработчиков мы ничего большего не получим при всём желании. И такой код LLM вполне в состоянии выдавать.
А хороший код мы от LLM вряд ли получим. Максимум - точечно и после кучи уточнений, причём скорее всего быстрее будет написать вручную. Но и мест где такой код критичен - очень мало, так что это не отменяет значимой пользы от LLM по написанию достаточно чистого кода во всех остальных местах.
Потому что цель собеса понять, сможет ли сотрудник качественно решать задачи на своей позиции, а не получилось ли у него случайно/однократно получить от модели решение типового тестового.
В стартапах, например. Но и в крупных компаниях, где архитект не является непосредственным руководителем, ему всё-равно требуются ровно те же навыки, только для мягкого убеждения тимлидов команд. Суть в том, что и там и там архитект должен уметь коммуницировать свои требования, и если делать это в сторону моделей примерно так же, как в сторону людей, то модель отлично под эти требования подстроится и будет выдавать весьма чистый код.
Судя по сказанному, лично Вы пока не научились получать адекватный результат от моделей - но это не значит, что это в принципе невозможно. Из моего опыта лучше всего получать качественный код от моделей получается у… руководителей (тимлидов/архитектов). Которые разговаривают с моделью примерно как с новым сотрудником, поясняя как именно и почему именно так требуется писать код на текущем проекте когда модель выдаёт что-то не то.
И да, бывают ситуации, когда быстрее написать самому. Но в этом нет ничего плохого или неправильного - никто же не ставит цель программеру (в отличие от вайб-кодеров) получить 100% кода генерацией в реальных задачах - если быстрее самому написать или что-то подчистить в результатах генерации, то надо это сделать вручную. Это же не отменяет экономии кучи времени и сил благодаря LLM в остальное время.
Да. Вопрос был в том, как именно это проверить на собесе.
Это правда, но не вся. Это - поведение модели по умолчанию, без дополнительных указаний. И этот средний уровень, будем откровенны, чуть сильнее среднего уровня обычных разработчиков по рынку (по крайней мере у моделей Claude) - т.е. вполне приемлемый. Да, если задача - нанять звезду, а не просто ещё несколько средних разработчиков, то модель звезде не конкурент, и, вполне возможно, никогда конкурентом звезде не станет - именно потому, что отражает "среднее по больнице" и показать более сильные результаты может исключительно под управлением более сильного разработчика, но никак не без него/вместо него.
Насчёт "пахнет генерацией" - я не соглашусь. Что выдаст LLM сильно зависит как от самой модели, так и от формулировки промпта. Получать качественный и адекватный код от моделей пока умеют не все разработчики, но это вполне реально - и такой код "генерацией" не пахнет. Более того, в сегодняшних реалиях это даже перестаёт быть важным вопросом - сам написал или сгенерировал, если результат годный. В работе это перестаёт быть вопросом, но не на собесе. Потому что по одной удачной генерации для мелкой типовой задачки невозможно сделать вывод "этот кандидат умеет получать от модели нормальный код для любых задач".
Я думаю, нужно менять подход собесов с "кандидат пишет свой код" на "кандидат ревьювит наш пример кода". Причём ревью кода должно включать не только критику, но и обсуждение что и как нужно изменить в существующем коде для решения каких-то задач (рефакторинг/добавить фичу-другую/починить баг).
Это в теории. А на практике качество звука временами паршивое в ситуации когда проблем с кодеками и каналом нет, будь то браузер или youtube-dl (yt-dlp), на бесплатном тарифе. Т.е. скорее это рандомно зависит от загруженности их серверов, нежели от канала и кодеков на клиенте. И следствием этого является наблюдаемое поведение: иногда звук норм, но часто говно, поэтому если нужен нормальный звук то ютуб как источник просто не рассматривается.
Тут немного в другом дело. Конкретно ютуб замечен в том, что качество аудио потока у него может сильно отличаться. Оригинал видео заливается с одним кодеком и качеством звука, а ютуб эту запись раздаёт с другим кодеком и/или качеством. От чего зависит и может ли это контролировать автор при заливании я не изучал, но сам факт того, что ютуб нередко выдавал к официальным качественным роликам аудиодорожку с сильно пониженным качеством звука - это факт. Поэтому все, кого волнует качество звука, стараются такие записи качать не с ютуба, а с тех же торрентов или официальных сайтов.
Ну, не исчезли, но да, их как-то совсем мало стало. Сейчас зашёл на агрегатор, и там для PCIe звуковух всего 5 вариантов: $60, $150, $250, $1000 и $1800. К профессиональным, надо полагать, относятся последние две.
Тесты проверяют на наличие любых изменений - а в новой версии изменения есть по определению, так что падение части тестов это норма. На совместимость должны проверять совершенно отдельные тесты, заточенные под это специально - что потребует, для начала, определить само понятие "совместимость" для конкретного продукта, а потом ещё и научиться его надёжно тестировать. На данный момент такого типа тесты если и встречаются, то это большая редкость.
Обычно "совместимость" контролируется либо формальными инструментами (которые проверяют только техническую совместимость API библиотеки или .proto-файла но не семантику/поведение этого API) либо вообще вручную (напр. для REST/OpenAPI мне такие линтеры как для proto пока не встречались). Тесты на семантику API написанные именно с целью контроля совместимости попадались редко и не были выделены в отдельную группу тестов совместимости, а были размазаны среди прочих (т.е. было крайне сложно понять что тестируется в этом плане, а что нет).
В золотые кабели со стрелочками я лично не верю, но вот что касается "остальные никогда не услышат" - это сильно зависит как от того, на каких колонках/наушниках слушать, так и от собственно слуха. Если слуха нет либо колонки/наушники относительно дешёвые - разницу действительно услышать не получится, разве что чисто психологически она там померещится. Но если слух нормальный и колонки/наушники достаточно крутые, то разницу между встроенным в материнку звуком и отдельной звуковой картой услышать достаточно легко (особенно если слушать не mp3, а любой lossless формат).
Больно, да. Но все гошники дофига лет с этим жили, и, в целом, были довольны своим ЯП. Ну т.е. больно, но не так чтобы очень. Где это было неприемлемо - вендорили.
Честно, не знаю таких примеров. Есть устаревшие, не поддерживаемые проекты, которые никто не обновлял - это да. А вот актуальные, поддерживаемые, и продолжающие жить в GOPATH без версий - я не сталкивался. Наверное, пару исключений найдётся, если специально искать, но на фоне общего количества проектов на го - это погрешность, а не статистика.
Почему не доказывает? Как по мне - это идеальное доказательство. Потому что у людей не просто был свободный выбор между несколькими вариантами (без версий, вендоринг, с версиями), но ещё и за много лет сформировавшаяся привычка жить без версий. Если в этой ситуации все дружно переходят на версионирование - это очень громкое и вполне однозначное заявление, как по мне.
По-моему общий консенсус в том, что лучше так, чем получать внезапные отличия в поведении просто из-за пересборки старой версии на CI через неделю после предыдущей, либо вообще сломанную сборку. Недостатки есть у всех подходов, но подход позволяющий обеспечить повторяемость сборки определённо выигрывает.
Если не учитывать использование локального кеша - то всегда. Локально у разработчиков кеш обычно присутствовал, но вот на CI - наоборот. А поскольку сборка на CI обычно важнее - именно её результат релизится - то вполне корректно считать это version less, разве нет?
На версионирование перешли абсолютно все, не только большие компании, но и индивидуальные разработчики опенсорса, которых никто не принуждал. Так что, как по мне, это вполне доказывает.
На Go все писали без поддержки версий пакетов примерно 9 лет (до 2018). В целом, как ни странно, это было не так страшно, как выглядит на первый взгляд. Изредка использовали вендоринг, но большинство проектов и библиотек нормально жило без управления версиями - достаточно поддерживать стабильную работу в ветке master и избегать (по возможности) несовместимых изменений. Это доказывает, что без версий - жить можно. Но как только в 2018 появилась встроенная поддержка версионирования - все тут же начали её использовать. Это доказывает, что с версиями - жить лучше. ;-)
Тема тестовых так и не раскрыта! Очевидно, сегодня просить такие тестовые смысла мало. Чем будем их заменять?
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
SemVer прекрасно рассчитывается автоматически на базе префиксов коммитов (feat!:, feat:, fix:, etc.).
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.