Если я хочу продать бизнесу AI агента, который будет копошиться в его документах, то первый вопрос, который мало-мальски серьёзный бизнес задаёт: “не утекут ли мои данные?”. Раньше у рынка было три компромиссных варианта.
Первый: чистое облако вроде OpenAI, Anthropic или OpenRouter. Максимально удобно: отправляем все наши данные по АПИ И ГОТОВО. Конфиденциальность держится только на доверии и ToS.
Второй вариант это гибридные платформы вроде Vast.ai, Together, Replicate или RunPod. Мы арендуем докер контейнер с доступом к видеокарте, почасово, запускаем любую модель и вроде бы контролируем окружение, но владелец сервера всё равно технически может добраться до памяти и данных.
Третий вариант это жужжащие видеокарты в своём шкафу. Максимальная приватность, но плохая масштабируемость, эксплуатационная боль - и жарковато. Все три варианта - хреновые, если подумать как бизнес, который беспокоится о своих данных(и штрафах от Евросоюза), но желает поменьше геморроя.
Теперь появился интересный четвёртый вариант - идея в том, чтобы дать бизнесам способ запускать GPU инференс (“исполнять свою LLM модель”) на чужом железе, без необходимости доверять владельцу этого железа. Конкретные реализации - Gonka AI от Либерманов и Cocoon от Дурова. Оба проекта со своими “особенностями” и привкусом дешевых криптопроектов времён ICO, но мне интересен не маркетинговый и инвестиционный булшит, витающий вокруг них, а технологии. Почему нельзя свою видеокарту 5080 сдать в аренду в Коконе? (в Гонке вроде можно RTX 4090 и RTX 3090 но никто их не использует по факту)
В основе подхода лежит Intel TDX - свежая технология. Это технология confidential computing, которая позволяет запускать виртуальные машины так, что их память аппаратно зашифрована и недоступна хосту. Даже администратор сервера или провайдер инфраструктуры физически не может заглянуть внутрь такой VM. Важный элемент здесь это attestation. Клиент может криптографически проверить, что внутри запущен именно ожидаемый код и что среда не была подменена, и только после этого отправить данные и модель.
Для инференса это критично, потому что защищать нужно не только CPU, но и GPU. Именно поэтому cocoon работает только с дорогущими свежими видеокартами, которые поддерживаются в confidential compute стеке, например NVIDIA H100 и другие серверные GPU. Они проектировались для мультиарендных облаков и могут работать в связке с TDX так, чтобы данные не утекали к хосту.
Потребительские карты вроде RTX 5080 сюда не подходят принципиально. Они не поддерживают confidential computing, не участвуют в attestation и полностью контролируются хостом. На таком GPU владелец сервера технически может читать память и данные, и вся идея доказуемой конфиденциальности просто ломается.
В итоге Intel TDX и его конкурент AMD SEV занимают, как мне кажется, золотую середину между видеокартой под столом и классическим AI облаком, конкретно для B2B сегмента. Получаем масштабируемость и удобство облака, но по модели безопасности гораздо ближе к собственному железу.
P.S. Предшественники кокона и гонки в идее децентрализованного GPU compute, но на старых технологиях, никак не решающие проблему конфиденциальности данных: Render Networks и Aethir - использовались, в основном, в задачах типа распределенного рендеринга 3D.
Первый: чистое облако вроде OpenAI, Anthropic или OpenRouter. Максимально удобно: отправляем все наши данные по АПИ И ГОТОВО. Конфиденциальность держится только на доверии и ToS.
Второй вариант это гибридные платформы вроде Vast.ai, Together, Replicate или RunPod. Мы арендуем докер контейнер с доступом к видеокарте, почасово, запускаем любую модель и вроде бы контролируем окружение, но владелец сервера всё равно технически может добраться до памяти и данных.
Третий вариант это жужжащие видеокарты в своём шкафу. Максимальная приватность, но плохая масштабируемость, эксплуатационная боль - и жарковато. Все три варианта - хреновые, если подумать как бизнес, который беспокоится о своих данных
Теперь появился интересный четвёртый вариант - идея в том, чтобы дать бизнесам способ запускать GPU инференс (“исполнять свою LLM модель”) на чужом железе, без необходимости доверять владельцу этого железа. Конкретные реализации - Gonka AI от Либерманов и Cocoon от Дурова. Оба проекта со своими “особенностями” и привкусом дешевых криптопроектов времён ICO, но мне интересен не маркетинговый и инвестиционный булшит, витающий вокруг них, а технологии. Почему нельзя свою видеокарту 5080 сдать в аренду в Коконе? (в Гонке вроде можно RTX 4090 и RTX 3090 но никто их не использует по факту)
В основе подхода лежит Intel TDX - свежая технология. Это технология confidential computing, которая позволяет запускать виртуальные машины так, что их память аппаратно зашифрована и недоступна хосту. Даже администратор сервера или провайдер инфраструктуры физически не может заглянуть внутрь такой VM. Важный элемент здесь это attestation. Клиент может криптографически проверить, что внутри запущен именно ожидаемый код и что среда не была подменена, и только после этого отправить данные и модель.
Для инференса это критично, потому что защищать нужно не только CPU, но и GPU. Именно поэтому cocoon работает только с дорогущими свежими видеокартами, которые поддерживаются в confidential compute стеке, например NVIDIA H100 и другие серверные GPU. Они проектировались для мультиарендных облаков и могут работать в связке с TDX так, чтобы данные не утекали к хосту.
Потребительские карты вроде RTX 5080 сюда не подходят принципиально. Они не поддерживают confidential computing, не участвуют в attestation и полностью контролируются хостом. На таком GPU владелец сервера технически может читать память и данные, и вся идея доказуемой конфиденциальности просто ломается.
В итоге Intel TDX и его конкурент AMD SEV занимают, как мне кажется, золотую середину между видеокартой под столом и классическим AI облаком, конкретно для B2B сегмента. Получаем масштабируемость и удобство облака, но по модели безопасности гораздо ближе к собственному железу.
P.S. Предшественники кокона и гонки в идее децентрализованного GPU compute, но на старых технологиях, никак не решающие проблему конфиденциальности данных: Render Networks и Aethir - использовались, в основном, в задачах типа распределенного рендеринга 3D.
gonka.ai
- Hardware specifications
Learn to configure and use Gonka network
🔥21👍7❤3🤔3🥴1
2012 год. Бандеролька - сервис по доставке посылок из США по всему миру - стремительно превращается из гаражного эксперимента в бизнес, который теперь оборачивает миллион долларов каждый месяц.
Я одной рукой программирую на PHP, другой записываю это видео, тут видно интерфейс - Drupal CMF, на которой работает Бандеролька. Кто помнит Друпал?
https://www.youtube.com/watch?v=sia6W5JAZ0k
Друпал - это система "low code" программирования, как сейчас такое называют. Мышкой в админке добавляешь на сущности поля, выбираешь тип данных, потом собираешь таблички (модуль для списков назывался views) и потом это все склеиваешь кусками PHP кода.
Задумали мы, например, сделать сущность "посылка". Добавили мышкой к ней десяток полей. Угадаете, сколько табличек в MySQL создаст Друпал седьмой версии для такой сущности?
Правильно, двадцать.
На каждое поле - 1 табличка для актуального значения поля, и еще одна для хранения истории изменений.
В принципе, архитектурное решение неплохое, если мы говорим об универсальности и one-size-fits-all - получше, чем запускать ALTER TABLE parcel .... когда кто-то в веб интерфейсе тыкнул на кнопку "добавить поле" (так оно работало в Drupal 5 - при пустой базе все отлично и красиво, при наполненной базе - на блокировках таблиц MySQL все падало).
Но такое дробление на таблицы работает, когда у тебя в день добавляется сто сущностей - а не пять тысяч каждый день, когда это уже настоящий продукт с кучей данных.
1 новая посылка - 20 x INSERT INTO parcel ...
Отрендерить список на 50 объектов - 3 секунды тяжелой работы, успели глотнуть чайку, и вот Апач, поднатужившись, выплевывает страничку.
Когда финансисты просят написать быстренько SQL для выгрузки данных - материмся и охереваем от количества JOIN-ов в простейшем запросе, писать такое руками было просто невыносимо.
Самое страшное творилось в наших кастомных PHP модулях, где надо было использовать Drupal API и сложную систему хуков. Задачка типа “добавить ajax автокомплит вот тут, и чтобы второе поле разворачивалось если первое заполнено” превращалась в двухдневный квест и не приносило никакой радости - то говно, которое ты написал, не обогащало тебя каким-то полезным или переносимым знанием для обычного, нормального мира веб-разработки, это больше напоминало заклинания для бога Друпала. Половина конфигов хранится в БД, половина - в коде. DEV / STAGING среды? Не сегодня, все равно на проде работает иначе!
Производительность подобной системы можно представить себе. Чтобы открывались страницы - надо закешировать ВСЕ. Кеш складывался в файлы и Redis. И этот кеш был очень большим. Иногда (часто) что-то внутри этого монстра крякало, и кеш надламывался под своим весом.
До сих пор помню липкое ощущение тревоги когда продакшн сайт просто начинает отдавать белую табличку на ломаном кеше.
Бежишь в админку, дергаешь Flush cache, монстр замирает секунд на 30. Посетители в этот момент грустно тыкают F5 в браузерах. Получится ли очистить кеш в этот раз? Жутко, непредсказуемо, и неприятно.
Когда мы наконец переехали с Друпала на Yii2 - это было самое чудесное чувство, когда наконец можно спать спокойно, а все странички открываются быстро и стабильно.
На фото - Аляска, Анкоридж, 2011 год. Первая моя поездка в США - я первый раз увидел синий лед настоящих ледников и огромного лося, переплываюшего протоку. Лоси в Анкоридже регулярно пасутся прямо перед окнами малоэтажных американских домиков. Там мы первый раз лично встретились с Павлом, идейным вдохновителем и основателем Бандерольки, который за год до этого нашел наше с братом "агентство по созданию Drupal сайтов" и попросил немного помочь ему в разработке. Кто знал, что эта работенка затянется на 15 лет?
Я одной рукой программирую на PHP, другой записываю это видео, тут видно интерфейс - Drupal CMF, на которой работает Бандеролька. Кто помнит Друпал?
https://www.youtube.com/watch?v=sia6W5JAZ0k
Друпал - это система "low code" программирования, как сейчас такое называют. Мышкой в админке добавляешь на сущности поля, выбираешь тип данных, потом собираешь таблички (модуль для списков назывался views) и потом это все склеиваешь кусками PHP кода.
Задумали мы, например, сделать сущность "посылка". Добавили мышкой к ней десяток полей. Угадаете, сколько табличек в MySQL создаст Друпал седьмой версии для такой сущности?
Правильно, двадцать.
На каждое поле - 1 табличка для актуального значения поля, и еще одна для хранения истории изменений.
В принципе, архитектурное решение неплохое, если мы говорим об универсальности и one-size-fits-all - получше, чем запускать ALTER TABLE parcel .... когда кто-то в веб интерфейсе тыкнул на кнопку "добавить поле" (так оно работало в Drupal 5 - при пустой базе все отлично и красиво, при наполненной базе - на блокировках таблиц MySQL все падало).
Но такое дробление на таблицы работает, когда у тебя в день добавляется сто сущностей - а не пять тысяч каждый день, когда это уже настоящий продукт с кучей данных.
1 новая посылка - 20 x INSERT INTO parcel ...
Отрендерить список на 50 объектов - 3 секунды тяжелой работы, успели глотнуть чайку, и вот Апач, поднатужившись, выплевывает страничку.
Когда финансисты просят написать быстренько SQL для выгрузки данных - материмся и охереваем от количества JOIN-ов в простейшем запросе, писать такое руками было просто невыносимо.
Самое страшное творилось в наших кастомных PHP модулях, где надо было использовать Drupal API и сложную систему хуков. Задачка типа “добавить ajax автокомплит вот тут, и чтобы второе поле разворачивалось если первое заполнено” превращалась в двухдневный квест и не приносило никакой радости - то говно, которое ты написал, не обогащало тебя каким-то полезным или переносимым знанием для обычного, нормального мира веб-разработки, это больше напоминало заклинания для бога Друпала. Половина конфигов хранится в БД, половина - в коде. DEV / STAGING среды? Не сегодня, все равно на проде работает иначе!
Производительность подобной системы можно представить себе. Чтобы открывались страницы - надо закешировать ВСЕ. Кеш складывался в файлы и Redis. И этот кеш был очень большим. Иногда (часто) что-то внутри этого монстра крякало, и кеш надламывался под своим весом.
До сих пор помню липкое ощущение тревоги когда продакшн сайт просто начинает отдавать белую табличку на ломаном кеше.
Бежишь в админку, дергаешь Flush cache, монстр замирает секунд на 30. Посетители в этот момент грустно тыкают F5 в браузерах. Получится ли очистить кеш в этот раз? Жутко, непредсказуемо, и неприятно.
Когда мы наконец переехали с Друпала на Yii2 - это было самое чудесное чувство, когда наконец можно спать спокойно, а все странички открываются быстро и стабильно.
На фото - Аляска, Анкоридж, 2011 год. Первая моя поездка в США - я первый раз увидел синий лед настоящих ледников и огромного лося, переплываюшего протоку. Лоси в Анкоридже регулярно пасутся прямо перед окнами малоэтажных американских домиков. Там мы первый раз лично встретились с Павлом, идейным вдохновителем и основателем Бандерольки, который за год до этого нашел наше с братом "агентство по созданию Drupal сайтов" и попросил немного помочь ему в разработке. Кто знал, что эта работенка затянется на 15 лет?
❤36🔥9👍6
В апреле уже писал, что Гугл задушит OpenAI и Anthropic на системном уровне, удушение переходит в основную фазу с выпуском Gemini 3 Pro и Gemini 3 Flash. Если кто пропустил результаты, третий Gemini Pro и Flash очень хорошие получились относительно их ценника - а еще Antigravity… Пока во всех AI чатах люди судорожно закупаются аккаунтами Google AI Studio на год за копейки, хочется сделать акцент на главном “нечестном” преимуществе Гугла - на железе, которое есть только у них.
TPU это классический ASIC, узкоспециализированный процессор, пожертвовавший универсальностью CPU и GPU ради одной задачи: матричных операций. В отличие от GPU, которые эволюционировали из графики и по-прежнему несут на себе груз универсальности, TPU изначально проектировались как вычислительный конвейер. Данные загружаются один раз и волнообразно проходят через систолический массив из тысяч ALU, передавая результаты соседям без постоянного обращения к памяти. Это резко снижает энергопотребление и задержки, особенно на плотных линейных алгебраических задачах.
Google начал идти по этому пути еще в 2015 году, когда стало ясно, что закон Мура больше не масштабируется под их нагрузки. TPU v1 был чисто инференсным чипом под int8 и именно на нем Google Translate пережил переход от статистического перевода к нейросетевому. Там же крутились пайплайны Google Photos для обработки миллиардов изображений. В 2016 году AlphaGo, запущенный на TPU, обыграл Ли Седоля - тут про TPU узнали за пределами Гугла. С v2 и v3 появилась поддержка обучения и плавающей точки, а в v4 в 2021 году добавили оптическую коммутацию между узлами.
К 2025 году Google представил Ironwood, TPU v7, и именно здесь разрыв с GPU становится особенно заметен в инференсе. Главная проблема современных LLM это уже не FLOPS, а пропускная способность памяти и удержание огромных KV кэшей. У Nvidia H100 это 80 ГБ HBM3 с пропускной способностью около 3.3 ТБ в секунду, у H200 141 ГБ и около 4.8 ТБ в секунду. Ironwood предлагает 192 ГБ памяти на чип и более 7 ТБ в секунду. Это позволяет держать более крупные шарды модели на одном ускорителе и гонять данные быстрее, при этом потребляя заметно меньше энергии. Физически чипы делаются на фабриках TSMC, кстати.
Второй важный элемент это интерконнект. Кластеры Nvidia обычно строятся на InfiniBand или Spectrum X по классической fat tree архитектуре. Это эффективно, но дорого и сложно. Google начиная с TPU v4 использует оптическую коммутацию каналов через MEMS зеркала. Свет физически перенаправляется между стойками без пакетной маршрутизации, буферов и сетевых стеков. Это дает минимальные задержки и позволяет динамически менять топологию суперкомпьютера, обходя сбои без перестройки всей сети.
Важно понимать, что эволюция TPU всегда шла строго под внутренние задачи Google. v5 разделили на две ветки, энергоэффективную для инференса и производительную для обучения. На v5p тренировались Gemini 1.0 и 1.5. Trillium стал промежуточным поколением, а Ironwood уже явно проектировался под инференс thinking моделей, где вычислений и памяти требуется не меньше, чем при обучении. В этом смысле Google не зависит от того, что можно купить на рынке. Он дизайнит железо под свои узкие места.
При этом у Nvidia есть фундаментальные сильные стороны, которые нельзя игнорировать. GPU давно перестали быть просто SIMD устройствами. Tensor Cores, NVLink, продвинутые memory модели, оптимизации под attention и KV cache сделали их полноценными AI процессорами. Главное же преимущество Nvidia не в железе, а в экосистеме. CUDA это пятнадцать лет инженерных инвестиций, тысячи библиотек, инструментов, профилировщиков и продакшен кода. Для большинства компаний GPU это не про максимальную эффективность, а про минимальный риск и скорость внедрения.
TPU почти идеальны для стабильных, масштабных и хорошо формализованных нагрузок Google. GPU выигрывают там, где архитектуры моделей меняются каждые полгода, где важна гибкость, быстрый ресерч и возможность запускать что угодно. Nvidia оптимизирует под неопределенность рынка и гетерогенные задачи. Google оптимизирует под свои собственные масштабы.
TPU это классический ASIC, узкоспециализированный процессор, пожертвовавший универсальностью CPU и GPU ради одной задачи: матричных операций. В отличие от GPU, которые эволюционировали из графики и по-прежнему несут на себе груз универсальности, TPU изначально проектировались как вычислительный конвейер. Данные загружаются один раз и волнообразно проходят через систолический массив из тысяч ALU, передавая результаты соседям без постоянного обращения к памяти. Это резко снижает энергопотребление и задержки, особенно на плотных линейных алгебраических задачах.
Google начал идти по этому пути еще в 2015 году, когда стало ясно, что закон Мура больше не масштабируется под их нагрузки. TPU v1 был чисто инференсным чипом под int8 и именно на нем Google Translate пережил переход от статистического перевода к нейросетевому. Там же крутились пайплайны Google Photos для обработки миллиардов изображений. В 2016 году AlphaGo, запущенный на TPU, обыграл Ли Седоля - тут про TPU узнали за пределами Гугла. С v2 и v3 появилась поддержка обучения и плавающей точки, а в v4 в 2021 году добавили оптическую коммутацию между узлами.
К 2025 году Google представил Ironwood, TPU v7, и именно здесь разрыв с GPU становится особенно заметен в инференсе. Главная проблема современных LLM это уже не FLOPS, а пропускная способность памяти и удержание огромных KV кэшей. У Nvidia H100 это 80 ГБ HBM3 с пропускной способностью около 3.3 ТБ в секунду, у H200 141 ГБ и около 4.8 ТБ в секунду. Ironwood предлагает 192 ГБ памяти на чип и более 7 ТБ в секунду. Это позволяет держать более крупные шарды модели на одном ускорителе и гонять данные быстрее, при этом потребляя заметно меньше энергии. Физически чипы делаются на фабриках TSMC, кстати.
Второй важный элемент это интерконнект. Кластеры Nvidia обычно строятся на InfiniBand или Spectrum X по классической fat tree архитектуре. Это эффективно, но дорого и сложно. Google начиная с TPU v4 использует оптическую коммутацию каналов через MEMS зеркала. Свет физически перенаправляется между стойками без пакетной маршрутизации, буферов и сетевых стеков. Это дает минимальные задержки и позволяет динамически менять топологию суперкомпьютера, обходя сбои без перестройки всей сети.
Важно понимать, что эволюция TPU всегда шла строго под внутренние задачи Google. v5 разделили на две ветки, энергоэффективную для инференса и производительную для обучения. На v5p тренировались Gemini 1.0 и 1.5. Trillium стал промежуточным поколением, а Ironwood уже явно проектировался под инференс thinking моделей, где вычислений и памяти требуется не меньше, чем при обучении. В этом смысле Google не зависит от того, что можно купить на рынке. Он дизайнит железо под свои узкие места.
При этом у Nvidia есть фундаментальные сильные стороны, которые нельзя игнорировать. GPU давно перестали быть просто SIMD устройствами. Tensor Cores, NVLink, продвинутые memory модели, оптимизации под attention и KV cache сделали их полноценными AI процессорами. Главное же преимущество Nvidia не в железе, а в экосистеме. CUDA это пятнадцать лет инженерных инвестиций, тысячи библиотек, инструментов, профилировщиков и продакшен кода. Для большинства компаний GPU это не про максимальную эффективность, а про минимальный риск и скорость внедрения.
TPU почти идеальны для стабильных, масштабных и хорошо формализованных нагрузок Google. GPU выигрывают там, где архитектуры моделей меняются каждые полгода, где важна гибкость, быстрый ресерч и возможность запускать что угодно. Nvidia оптимизирует под неопределенность рынка и гетерогенные задачи. Google оптимизирует под свои собственные масштабы.
Telegram
SaaS Founders
То, что ты сделал прорыв в AI первым - еще не значит, что ты победишь. Прямо сейчас мы наблюдаем, как Google неторопливо спустился с гор и окучивает всех барашков.
Вот вам три статьи:
https://www.cnbc.com/2025/04/09/google-will-let-companies-run-gemini-models…
Вот вам три статьи:
https://www.cnbc.com/2025/04/09/google-will-let-companies-run-gemini-models…
🔥28👍6❤2
Зарисовка из мира современного “open source”. Поставил тут docmost - корпоративный self-hosted notion, симпатичный интерфейс, неплохо работает, лицензия GPL v3. Быстро уткнулся в проблемку - семантический поиск (pgvector) за пейволлом в enterprise версии, в гитхабе только API методы, немного typescript типов и часть интерфейса. Примерно за 4 часа навайбкодил реализацию AI поиска для OpenAI. Написал в github issue, где люди слезно просят дать им возможность использовать AI, скинул ссылку на реализацию - авторы docmost очень быстро сориентировались и мой коммент грохнули примерно через три минуты :) Что характерно - у ребят даже нет прайса на платный тариф - все через Contact Sales! Жалко, когда open-source так откровенно используется лишь как воронка продаж. Начал гуглить, нашел Forkmost - форк docmost с работающим SSO. Написал автору форка, говорю, братишка, возьми мой код AI интеграции, вот код. Его ответ порадовал - “извини, код написанный через AI не мерджу”. Directed by Robert B. Weide.
😁32🗿4🔥2😢2👍1👏1
В 1830 году американский изобретатель Питер Купер построил паровоз Tom Thumb. Чтобы показать скептикам практическую пользу пара, он устроил гонку с лошадью. Паровоз уверенно шел впереди, но на подъеме порвался ремень передачи, двигатель заглох, Купер обжег руки, пытаясь все починить, и лошадь пришла первой. Газеты сделали удобный вывод: механические игрушки ненадежны, а лошадь проверена временем.
В комментариях к прошлому посту прозвучало мнение: AI-коду не место в open source, лучше писать руками. Это даже звучало разумно год назад и даже весной, когда все мы хихикали над программистами Microsoft, сходящими с ума при общении с тупыми AI агентами. Но за последний год инструменты сильно изменились. Claude Code пришел со своей элегантностью и эффективностью агентского подхода, и остальной рынок AI тулзов стремительно трансформировался вслед за ним. Я пробовал Cursor, Lovable, Bolt, позже Claude Code и Gemini CLI и вижу, как меняется не только качество кода, но и сам процесс разработки. Свежачок про эволюцию: https://xn--r1a.website/cryptoEssay/2738 - надо помнить, что эта эволюция чудовищная по скорости, она перемножается сама на себя - разработчики AI агентов пользуются AI агентами для улучшения AI агентов.
При этом иллюзий нет. Если не понимать архитектуру, AI легко генерирует хрупкий, плохой код. “Вайб-кодинг” это ругательное слово для мейнтейнеров опен-сорса, потому что легко можно любой реп заспамить бездумными пулл реквестами. В сложных проектах AI пока чаще помощник и исследователь, чем автор. Вокруг кода есть документация, ревью, миграции, операционка. Все это по-прежнему требует человека.
Так, интересно, что там у Microsoft в итоге? вот тут можно посмотреть на реп, над которым все смеялись: https://github.com/dotnet/runtime/pulls?q=is%3Apr+is%3Aclosed
Свежие примеры PR где Co-pilot закрывает таски (после аппрува человеком):
https://github.com/dotnet/runtime/pull/122615
https://github.com/dotnet/runtime/pull/122641
Есть и те, где PR закрываются без мерджа, и даже тут уже не так смешно читать обсуждение: https://github.com/dotnet/runtime/pull/122662
Скажу за себя - к концу 25го я уже пишу меньше 30% кода руками. Если задача - не очень сложная и сугубо исследовательская - я уже вообще не смотрю в код, а смотрю только в промпт и на выдаваемые кодом артефакты.
Вместо отрицания и пустого хейта от OSS мейнтейнеров “не буду мерджить AI код потому что видел там Claude Code иконка в коммитах засветилась” нужны современные решения для современных проблем - например, это может быть мощный AI модератор, который на каждый длинный PR будет писать коммент а-ля “этот код на 79% тупой и только на 37% подходит под наш code style guidelines, и это уже второй ваш PR за сегодня, вам бан на месяц, ДОСВИДАНИЯ”
Ладно, языками почесали, перейдем к делу. Продолжение истории с docmost/forkmost - сделал PR, мейнтейнер forkmost обещал посмотреть. Будем верить, что forkmost станет лучше, сплав человеческого интеллекта и AI кода должен победить!
В комментариях к прошлому посту прозвучало мнение: AI-коду не место в open source, лучше писать руками. Это даже звучало разумно год назад и даже весной, когда все мы хихикали над программистами Microsoft, сходящими с ума при общении с тупыми AI агентами. Но за последний год инструменты сильно изменились. Claude Code пришел со своей элегантностью и эффективностью агентского подхода, и остальной рынок AI тулзов стремительно трансформировался вслед за ним. Я пробовал Cursor, Lovable, Bolt, позже Claude Code и Gemini CLI и вижу, как меняется не только качество кода, но и сам процесс разработки. Свежачок про эволюцию: https://xn--r1a.website/cryptoEssay/2738 - надо помнить, что эта эволюция чудовищная по скорости, она перемножается сама на себя - разработчики AI агентов пользуются AI агентами для улучшения AI агентов.
При этом иллюзий нет. Если не понимать архитектуру, AI легко генерирует хрупкий, плохой код. “Вайб-кодинг” это ругательное слово для мейнтейнеров опен-сорса, потому что легко можно любой реп заспамить бездумными пулл реквестами. В сложных проектах AI пока чаще помощник и исследователь, чем автор. Вокруг кода есть документация, ревью, миграции, операционка. Все это по-прежнему требует человека.
Так, интересно, что там у Microsoft в итоге? вот тут можно посмотреть на реп, над которым все смеялись: https://github.com/dotnet/runtime/pulls?q=is%3Apr+is%3Aclosed
Свежие примеры PR где Co-pilot закрывает таски (после аппрува человеком):
https://github.com/dotnet/runtime/pull/122615
https://github.com/dotnet/runtime/pull/122641
Есть и те, где PR закрываются без мерджа, и даже тут уже не так смешно читать обсуждение: https://github.com/dotnet/runtime/pull/122662
Скажу за себя - к концу 25го я уже пишу меньше 30% кода руками. Если задача - не очень сложная и сугубо исследовательская - я уже вообще не смотрю в код, а смотрю только в промпт и на выдаваемые кодом артефакты.
Вместо отрицания и пустого хейта от OSS мейнтейнеров “не буду мерджить AI код потому что видел там Claude Code иконка в коммитах засветилась” нужны современные решения для современных проблем - например, это может быть мощный AI модератор, который на каждый длинный PR будет писать коммент а-ля “этот код на 79% тупой и только на 37% подходит под наш code style guidelines, и это уже второй ваш PR за сегодня, вам бан на месяц, ДОСВИДАНИЯ”
Ладно, языками почесали, перейдем к делу. Продолжение истории с docmost/forkmost - сделал PR, мейнтейнер forkmost обещал посмотреть. Будем верить, что forkmost станет лучше, сплав человеческого интеллекта и AI кода должен победить!
Reddit
From the ExperiencedDevs community on Reddit: My new hobby: watching AI slowly drive Microsoft employees insane
Explore this post and more from the ExperiencedDevs community
👍10🔥5😁2
Еще про open-source и тернистый путь монетизации open core продуктов. Мы уже много лет пользуемся Mattermost, self-hosted альтернативой слаку (и очень им благодарны за хороший продукт с golang на бекенде). К сожалению, Маттермосту теперь очень нужны деньги и, похоже, менеджмент в компании сильно поменялся, вместе с целями и подходами - они переделали сайт в какой-то клон министерства нападения США и явно пытаются продаваться оборонке - к примеру, в сайдбаре промо блог статейки с названиями типа “What is Sovereign Collaboration? Complete Guide for Defense & Intelligence Leaders”. Мы сидим на Teams open source, self-hosted плане. И видимо, так делают еще много сотен, если не тысяч, компаний. Ребята из моста думали, думали, и придумали новый тарифный план Entry. Цитата из блог поста - “мы вводим новый тарифный план Entry, потому что некоторые неблагонадежные компании, пользующиеся редакцией Team, плохо конвертировались в Enterprise кастомеров”. Чтобы помочь компаниям делать правильный выбор, в новой Entry редакции (self hosted!) можно читать только макс 10 тысяч сообщений в истории. Очень удобно, спасибо Mattermost! Но Team edition (open source) тоже осталась, и ее тоже надо улучшить. Вот улучшения: количество юзеров снижено до 250 (с 5 тысяч), SSO удаляем
Комьюнити, конечно, оценило, вот обсуждение на Github.
В обсуждении всплыл прикольный сайт - отвечающий на вопрос “как можно понять, open source настоящий у продукта, или нет?” Вот он: https://isitreallyfoss.com/ - на этом сайте можно быстро глянуть, сколько ограничений окажется в self-hosted версии.
Еще есть полезная страничка SSO Wall of Shame - продукты, которые вроде бы self-hosted и free, но SSO (логин) - только в платной версии. Тут две секции - компании, которые явно указывают стоимость версии с SSO (это еще норм ребята), и те, кто закрывают SSO совсем, вешают кнопку Call Us и ждут компании на разговор. “wall of shame” какая-то очень громкая и негативная формулировка, конечно - sso действительно самый простой способ отделить аудиторию “я и мой household” от корпоратов и других больших групп людей.
Было бы классно, если бы кто-то взялся и придумал некий “стандарт поведения” когда в README любого уважающего себя self-hosted проекта можно было найти информацию, какие конкретно фичи закрыты пейволлом - и это не требовало бы многодневного исследования и тестовых прогонов - мир бы сразу стал немного лучше. Примерно как у Apple и Google в каталогах “this app includes in-app purchases: aaa, bbb, ccc”
Логичный вопрос, возникающий у любого программиста - а что, нельзя просто пропатчить опен сорс версию? Конечно можно! Вот, например, форк Маттермоста с правильными лимитами: https://framagit.org/framasoft/framateam/mostlymatter
Я не до конца понимаю, почему никто еще не сделал SSO-enabled версию, возможно, тут есть нюансы или сложности с лицензией.
Комьюнити, конечно, оценило, вот обсуждение на Github.
В обсуждении всплыл прикольный сайт - отвечающий на вопрос “как можно понять, open source настоящий у продукта, или нет?” Вот он: https://isitreallyfoss.com/ - на этом сайте можно быстро глянуть, сколько ограничений окажется в self-hosted версии.
Еще есть полезная страничка SSO Wall of Shame - продукты, которые вроде бы self-hosted и free, но SSO (логин) - только в платной версии. Тут две секции - компании, которые явно указывают стоимость версии с SSO (это еще норм ребята), и те, кто закрывают SSO совсем, вешают кнопку Call Us и ждут компании на разговор. “wall of shame” какая-то очень громкая и негативная формулировка, конечно - sso действительно самый простой способ отделить аудиторию “я и мой household” от корпоратов и других больших групп людей.
Было бы классно, если бы кто-то взялся и придумал некий “стандарт поведения” когда в README любого уважающего себя self-hosted проекта можно было найти информацию, какие конкретно фичи закрыты пейволлом - и это не требовало бы многодневного исследования и тестовых прогонов - мир бы сразу стал немного лучше. Примерно как у Apple и Google в каталогах “this app includes in-app purchases: aaa, bbb, ccc”
Логичный вопрос, возникающий у любого программиста - а что, нельзя просто пропатчить опен сорс версию? Конечно можно! Вот, например, форк Маттермоста с правильными лимитами: https://framagit.org/framasoft/framateam/mostlymatter
Я не до конца понимаю, почему никто еще не сделал SSO-enabled версию, возможно, тут есть нюансы или сложности с лицензией.
Mattermost.com
Introducing Mattermost Entry: A Smarter Starting Point for Secure Collaboration
Mattermost Entry provides the full Enterprise feature set with lightweight usage limits for the complete Mattermost experience from day one.
🔥5👍3❤2
Я сейчас подбираю self-hosted IAM-платформу для внутренних нужд (логин во внутреннюю базу знаний, таскер, Mattermost, Metabase и так далее).
Много лет мы пользовались велосипедом на PHP, и он даже работал - но давно назрела необходимость перейти на стандартный OpenID Connect, чтобы бесшовно и быстро внедрять в наш внутренний стек инструментов все новые и новые self-hosted продукты - их столько красивых и классных появляется каждый месяц; а еще больше мы сами вайбкодим, и везде нужен унифицированный вход для сотрудников, и управление правами.
Self-hosted identity platform. Все знают правильный ответ:
Keycloak. Верно?
Верно. Но Keycloak выглядит настолько устаревшим и унылым, что я потратил много дней на поиск и оценку альтернатив: Authelia, TinyAuth, Authentik. И, кажется, нашел вариант, который закрывает все наши галочки: Zitadel. Я жертвую многими вещами, например накопленными знаниями сообщества, ради более качественного и быстрого UX - не для кастомеров даже, а для себя любимого, и для всей нашей внутренней команды. Почему?
Потому что я травмирован консолями AWS IAM и Google GCE - медленные, громоздкие интерфейсы с бесконечными спиннерами и лоадерами. Как вспомню, как настраивал права на какой-нибудь S3 бакет в AWS или искал как настроить ключи для Gemini CLI у Гугла в его панели GCE - вздрагиваю.
Но нужен ли вообще “красивый” UX для того, чтобы 30 человек пользовались внутренними инструментами с комфортом? Простой ответ: возможно, нет. Внутри меня борьба: ценитель хорошего интерфейса сражается с решателем проблем, которому надо просто закрыть задачу. Но я смотрю на долгосрок. Мы с командой будем смотреть на эти экраны годами. Быстрый, современный интерфейс реально меняет ощущение от каждодневной рутинной работы - а устаревший и медленный ворует наше время, внимание, и раздражает. Я ненавижу лагающие формы логина, особенно когда едешь где-нибудь в такси с нестабильным 4G. Любимый момент - вбиваешь пароль, смотришь на лоадер, и тут… вылезает его величество рекапча. Хотел посмотреть в документ? А не хочешь ли вместо этого выбрать все автобусы на картинке?
Скриншот: тест в режиме ограниченного 4G. Keycloak загружает 2 МБ CSS-правил на странице логина.
Много лет мы пользовались велосипедом на PHP, и он даже работал - но давно назрела необходимость перейти на стандартный OpenID Connect, чтобы бесшовно и быстро внедрять в наш внутренний стек инструментов все новые и новые self-hosted продукты - их столько красивых и классных появляется каждый месяц; а еще больше мы сами вайбкодим, и везде нужен унифицированный вход для сотрудников, и управление правами.
Self-hosted identity platform. Все знают правильный ответ:
Keycloak. Верно?
Верно. Но Keycloak выглядит настолько устаревшим и унылым, что я потратил много дней на поиск и оценку альтернатив: Authelia, TinyAuth, Authentik. И, кажется, нашел вариант, который закрывает все наши галочки: Zitadel. Я жертвую многими вещами, например накопленными знаниями сообщества, ради более качественного и быстрого UX - не для кастомеров даже, а для себя любимого, и для всей нашей внутренней команды. Почему?
Потому что я травмирован консолями AWS IAM и Google GCE - медленные, громоздкие интерфейсы с бесконечными спиннерами и лоадерами. Как вспомню, как настраивал права на какой-нибудь S3 бакет в AWS или искал как настроить ключи для Gemini CLI у Гугла в его панели GCE - вздрагиваю.
Но нужен ли вообще “красивый” UX для того, чтобы 30 человек пользовались внутренними инструментами с комфортом? Простой ответ: возможно, нет. Внутри меня борьба: ценитель хорошего интерфейса сражается с решателем проблем, которому надо просто закрыть задачу. Но я смотрю на долгосрок. Мы с командой будем смотреть на эти экраны годами. Быстрый, современный интерфейс реально меняет ощущение от каждодневной рутинной работы - а устаревший и медленный ворует наше время, внимание, и раздражает. Я ненавижу лагающие формы логина, особенно когда едешь где-нибудь в такси с нестабильным 4G. Любимый момент - вбиваешь пароль, смотришь на лоадер, и тут… вылезает его величество рекапча. Хотел посмотреть в документ? А не хочешь ли вместо этого выбрать все автобусы на картинке?
Скриншот: тест в режиме ограниченного 4G. Keycloak загружает 2 МБ CSS-правил на странице логина.
❤15👍3🔥1👀1
Купил 3D принтер. Быстро выяснилось, что это лучший подарок себе за много лет.
Попечатав немного чужие модели с makerworld и printables, погрузился в новый, чудный мир - построения инженерных CAD моделей. С каждым новым вопросом я проваливался глубже и глубже в кроличью нору. Быстро оказалось, что печатать и адаптировать чужие модели совсем не так интересно, как создавать новые модели для других людей. Открыл для себя параметрический дизайн, Fusion 360. Flanges, hinges, dovetail, chamfer, fillet, loft, sweep, extrude, revolve. Я этих слов не знал даже толком. Всё это стало частью лексикона, теперь я у мамы настоящий инженер-архитектор, а не этот программист, которых развелось!
Ладно... быстро выяснилось, есть модели, которые тяжело/неудобно рисовать статичными, пусть и параметрическими, чертежами - программно генерируемые штукенции. К примеру, всяческие формы со сложными ребрами с замысловатым синусоидальным распределением. Вспомнил тригонометрию и тангенс. Узнал такие абстрактные понятия, как Platonic Solids, открыл для себя что Эйлер, великий математик, в 1736 году пытался решить проблему "семи мостов" в Кёнигсберге (теперь Калининграде) (можно ли пройти по каждому из 7 мостов города, но по каждому только один раз?) - открыл новый раздел математики.
Теория графов - всегда для меня это звучало скучно. Я вообще слаб в алгоритмах, больше продукт и конечный результат меня интересует. И тут вдруг всё это засияло красками, и обрело вес и смысл, когда я задался простым вопросом: как спроектировать и напечатать рандомный лабиринт для шарика? Называется эта штука Гамильтонов путь в планаре.
На этом погружение не остановилось. Я узнал, что можно описывать 3D модели программным кодом. О, это уже знакомая среда, тут меньше тыкать мышкой! Есть великолепная штука - OpenSCAD. Фактически, DSL для 3д моделирования.
Понятное дело, сложную геометрию описать программно оказалось сложно. Сунулся в ChatGPT и Gemini - оказалось, что они сносно выдают базовый OpenSCAD "скелет". Но галлюцинируют жёстко, и типовой воркфлоу получился такой: просим ChatGPT выдать OpenSCAD код → несём код в OpenSCAD редактор → рендерим там модельку → ужасаемся результату → делаем скриншот → рисуем на скриншоте стрелки и выделяем проблемы → опять идём в ChatGPT, и так по кругу.
Увлекательнейшее занятие, скажу я вам, и даже неплохой результат выдавало (к десятой итерации).
Догадайтесь к чему это привело? “А что если дать мультимодальному AI агенту инструмент рендерить .scad код и видеть результат рендеринга в 3 проекциях?” Антон бросил все дела, забросил даже собственно печать на 3D принтере, и вместо этого начал собирать браузерный редактор - "Cursor для OpenSCAD" - который по промпту выдаёт .scad код и сразу рендерит его в 3D модель. И самое главное - позволяет быстро итерировать скриншотами.
Для архитектуры и сборки проекта использовал одновременно Claude Code, Codex, и Cursor - переключался между ними, максимально используя доступные тарифы за 20 баксов, и обычную доку в markdown, чтобы не лочиться на конкретного кодинг агента. Никаких скиллов и новых модных штук.
Стек: UI на Shadcn+React, деплой в докер, бекенд - Node.js + pg, очереди - pg-boss, LLM модель пока Gemini 3 Flash. Всем зарегистрированным даются бесплатные кредиты, stripe для доп закупок баллов (но базовых кредитов хватит на много попыток).
Что характерно, я максимально избегаю Gemini CLI, который все еще выглядит самым слабым CLI агентом из моего опыта (Antigravity многие хвалят, но у меня не завелся вообще). А вот сама модель Gemini 3 по API показалась оптимальной для конкретного кейса в плане цены-качества (генерация OpenSCAD кода с наименьшим количеством глюков).
Вот видео демо (англ). Проект называется ModelRift. ModelRift еще сырой, и он не заточен генерировать 3д модели аниме женщин или пикачу, умеет только строгую инженерную геометрию, но он уже доставляет мне и близким немало удовольствия - генерируем коробочки и совершенно рандомную фигнювместо того чтобы работать.
Попечатав немного чужие модели с makerworld и printables, погрузился в новый, чудный мир - построения инженерных CAD моделей. С каждым новым вопросом я проваливался глубже и глубже в кроличью нору. Быстро оказалось, что печатать и адаптировать чужие модели совсем не так интересно, как создавать новые модели для других людей. Открыл для себя параметрический дизайн, Fusion 360. Flanges, hinges, dovetail, chamfer, fillet, loft, sweep, extrude, revolve. Я этих слов не знал даже толком. Всё это стало частью лексикона, теперь я у мамы настоящий инженер-архитектор, а не этот программист, которых развелось!
Ладно... быстро выяснилось, есть модели, которые тяжело/неудобно рисовать статичными, пусть и параметрическими, чертежами - программно генерируемые штукенции. К примеру, всяческие формы со сложными ребрами с замысловатым синусоидальным распределением. Вспомнил тригонометрию и тангенс. Узнал такие абстрактные понятия, как Platonic Solids, открыл для себя что Эйлер, великий математик, в 1736 году пытался решить проблему "семи мостов" в Кёнигсберге (теперь Калининграде) (можно ли пройти по каждому из 7 мостов города, но по каждому только один раз?) - открыл новый раздел математики.
Теория графов - всегда для меня это звучало скучно. Я вообще слаб в алгоритмах, больше продукт и конечный результат меня интересует. И тут вдруг всё это засияло красками, и обрело вес и смысл, когда я задался простым вопросом: как спроектировать и напечатать рандомный лабиринт для шарика? Называется эта штука Гамильтонов путь в планаре.
На этом погружение не остановилось. Я узнал, что можно описывать 3D модели программным кодом. О, это уже знакомая среда, тут меньше тыкать мышкой! Есть великолепная штука - OpenSCAD. Фактически, DSL для 3д моделирования.
Понятное дело, сложную геометрию описать программно оказалось сложно. Сунулся в ChatGPT и Gemini - оказалось, что они сносно выдают базовый OpenSCAD "скелет". Но галлюцинируют жёстко, и типовой воркфлоу получился такой: просим ChatGPT выдать OpenSCAD код → несём код в OpenSCAD редактор → рендерим там модельку → ужасаемся результату → делаем скриншот → рисуем на скриншоте стрелки и выделяем проблемы → опять идём в ChatGPT, и так по кругу.
Увлекательнейшее занятие, скажу я вам, и даже неплохой результат выдавало (к десятой итерации).
Догадайтесь к чему это привело? “А что если дать мультимодальному AI агенту инструмент рендерить .scad код и видеть результат рендеринга в 3 проекциях?” Антон бросил все дела, забросил даже собственно печать на 3D принтере, и вместо этого начал собирать браузерный редактор - "Cursor для OpenSCAD" - который по промпту выдаёт .scad код и сразу рендерит его в 3D модель. И самое главное - позволяет быстро итерировать скриншотами.
Для архитектуры и сборки проекта использовал одновременно Claude Code, Codex, и Cursor - переключался между ними, максимально используя доступные тарифы за 20 баксов, и обычную доку в markdown, чтобы не лочиться на конкретного кодинг агента. Никаких скиллов и новых модных штук.
Стек: UI на Shadcn+React, деплой в докер, бекенд - Node.js + pg, очереди - pg-boss, LLM модель пока Gemini 3 Flash. Всем зарегистрированным даются бесплатные кредиты, stripe для доп закупок баллов (но базовых кредитов хватит на много попыток).
Что характерно, я максимально избегаю Gemini CLI, который все еще выглядит самым слабым CLI агентом из моего опыта (Antigravity многие хвалят, но у меня не завелся вообще). А вот сама модель Gemini 3 по API показалась оптимальной для конкретного кейса в плане цены-качества (генерация OpenSCAD кода с наименьшим количеством глюков).
Вот видео демо (англ). Проект называется ModelRift. ModelRift еще сырой, и он не заточен генерировать 3д модели аниме женщин или пикачу, умеет только строгую инженерную геометрию, но он уже доставляет мне и близким немало удовольствия - генерируем коробочки и совершенно рандомную фигню
Makerworld
Mori Series — Japandi Self-Watering Cube Planters - Free 3D Print Model - MakerWorld
Download this free 3D print file designed by Ikigaiform. Boost MeIf you enjoy my designs and want to support me, a Boost is always appreciated!The Mori Series is released as a curated set of six variations, each exploring a different expression of calm geometry…
🔥34❤13👍1
Что делать, если твой AI агент делает не то, что надо, на средне-сложной задаче, а подробно описывать/надиктовывать весь брейндамп, и думать о каких мелких и важных деталях мог забыть - уже нет сил? Конечно, самый лучший вариант - это plan mode в CC. Но он часто избыточен, и много токенов ест. Если хочется побыстрее все-таки и не тратить миллион токенов - вот простой способ облегчить агенту жизнь - описываю задачу средне-поверхностно, но обязательно напоминаю ему - “ask clarification questions if needed” - в конце промта. Намного удобнее, когда это он задает конкретные вопросы, а не ты вместо этого или 1. муторно описываешь все, или 2. планируешь тщательно сжигая много времени, или 3. напряженно следишь, чего он там решил делать, чтобы остановить на скаку эту бешеную лошадь. И работает универсально хорошо - что в codex-cli, что в claude code.
UPD: умные люди в комментах напомнили, что есть более правильный способ (но он же и более дорогой в плане токенов): https://github.com/obra/superpowers - совместим с CC / Codex / OpenCode
UPD: умные люди в комментах напомнили, что есть более правильный способ (но он же и более дорогой в плане токенов): https://github.com/obra/superpowers - совместим с CC / Codex / OpenCode
GitHub
GitHub - obra/superpowers: An agentic skills framework & software development methodology that works.
An agentic skills framework & software development methodology that works. - obra/superpowers
👍11
Вышел с постом о ModelRift в OpenSCAD коммьюнити в Реддите. Коммьюнити образцовое - небольшое, техническое, олд-скульное, ценит core продукт. Первый же комментарий - “иди ты в жопу со своим AI, заманали вы со своим AI, ВЕЗДЕ ЭТОТ AI”. 2026 год - лучший год, чтобы построить что-то свое с помощью AI, но не обольщайтесь - это еще и худший год, чтобы это потом кому-то продать :)
К счастью, сразу нашлись и люди, понимающие разницу между вайб-кодингом, и нормальным продуктом.
Полагаю, это будет настоящим ключом к успеху в ближайший год - мастерство доводки продукта и наведения лоска. Эстетичный и уникальный дизайн. Грамотные тексты без AI булшита. Уместные и аккуратные анимации. Продуманный UX. Ну и умное, эффективное продвижение, естественно. Это все не купить даже в 200 долларовом плане Claude Code. Пока :)
К счастью, сразу нашлись и люди, понимающие разницу между вайб-кодингом, и нормальным продуктом.
Полагаю, это будет настоящим ключом к успеху в ближайший год - мастерство доводки продукта и наведения лоска. Эстетичный и уникальный дизайн. Грамотные тексты без AI булшита. Уместные и аккуратные анимации. Продуманный UX. Ну и умное, эффективное продвижение, естественно. Это все не купить даже в 200 долларовом плане Claude Code. Пока :)
❤8😁6👍1
Наткнулся на свежий исчерпывающий пост про песочницы для исполнения кода, в частности, для AI агентов. Все разложено по полочкам, супер плотно, без воды, написано простым языком. Главная польза - пост учит задавать правильные вопросы, для определения, какая конкретно песочница на какой технологии изоляции нужна в конкретном случае (для долгоживущих процессов типа сессии claude code - один подход, для эфемерных процессов живущих 5 секунд - другой)
https://www.luiscardoso.dev/blog/sandboxes-for-ai
Буду скоро обновлять свой https://github.com/restyler/awesome-sandbox - он за полгода уже немножко устарел. Deno кстати выпустили свой сендбокс , но увы - только в облаке, нет self-hosted версии. У них есть интересная фишка из коробки - если вы запустили в песочнице какого-то зловреда, он не может так просто стащить ключи из ENV - так как они инжектятся во внешние API запросы из песочницы “на лету”:
https://www.luiscardoso.dev/blog/sandboxes-for-ai
Буду скоро обновлять свой https://github.com/restyler/awesome-sandbox - он за полгода уже немножко устарел. Deno кстати выпустили свой сендбокс , но увы - только в облаке, нет self-hosted версии. У них есть интересная фишка из коробки - если вы запустили в песочнице какого-то зловреда, он не может так просто стащить ключи из ENV - так как они инжектятся во внешние API запросы из песочницы “на лету”:
import { Sandbox } from "@deno/sandbox";
await using sandbox = await Sandbox.create({
root: "claude",
secrets: {
ANTHROPIC_API_KEY: {
hosts: ["api.anthropic.com"], // только в запрос к этому хосту будет добавлен ключ ANTHROPIC_API_KEY, на лету, внутри песочницы этот ключ не виден
value: process.env.ANTHROPIC_API_KEY!,
}
}
});
await sandbox.sh`claude -p hello`;
🔥3❤1👍1