Вчера собрал скрипт.
Он прогоняет 500 mp3-записей звонков сейлзов, делает транскрибацию, определяет говорящих (не просто speaker_01, а роль говорящего - по контексту) и вытаскивает инсайты и возражения. Использовал ML модели: модель Whisper (через replicate API) и OpenAI 4o. Вместо 20 часов ковыряния в n8n я потратил всего 3 часа в Claude Code - и получил куда более качественный результат. Два года назад на такую штуку ушла бы неделя разработки.

Становится очевидно: Codex и Claude Code доросли до уровня, где сложные ноу-код платформы теряют смысл. Зачем тратить недели в вендорлокнутой среде, если то же время можно вложить в то, чтобы стать лучше как инженер, и начать делать вещи на более подходящих технологиях? n8n, конечно, никуда не исчезнет - он по-прежнему очень крут для простых сценариев, и его основные преимущества -
1. не надо морочиться с деплоем
2. всегда можно зайти и посмотреть все сценарии, их логи и ошибки в удобном интерфейсе.

Но ставка SMB-компаний может скоро сместиться: для мало-мальски нетиповых/сложных задач есть всё больше смысла не учиться мастерски работать с no/low-code, а писать маленькие приложения на «настоящих» языках вроде Python и серверного JS. Это дает принципиально более качественный и гибкий результат, чем ковыряние мышкой в четко очерченной песочнице n8n. Но из этого следует логичный вывод: кому-то придется наводить порядок в этом внутреннем зоопарке - теперь надо управлять десятками микроприложений и доступами к данным и пользователям внутри компании. Как управлять этим бардаком, если до k8s еще команда не доросла? Думаю, вот эти (и аналогичные) продукты ждет мощный рост в ближайшее время- это self-hosted PAAS, heroku-like продукты: Dokku, Portainer, Dokploy, Coolify

Каждый раз, когда какая-то уважаемая компания покупает ниндзю, я, конечно, сначала радуюсь. Но потом, после истории с cease&desist письмом от Меты поневоле задумываюсь - уж не контрольная ли это закупка, чтобы чего-нибудь предъявить?!!

Помните, как в древности (полгода назад) говорили: Anthropic - заточены про программирование, а OpenAI - для общих задач?
Скорее всего, даже внутри самой OpenAI тогда думали так же и транслировали это:

«Мы тут делаем лучшие LLM, а Антропики ковыряются там че-то в программировании - ну пусть ковыряются, это просто один из кейсов применения моделей».

Но в какой-то момент всё перевернулось. Реальная гонка сместилась именно в сторону программирования. Claude Code задал стандарт, и OpenAI внезапно ощутили, как под ними зашатался трон. Вдруг оказалось, что программирование - это не «еще один кейс», а, пожалуй, самый главный кейс.

OpenAI в спешке пробуют запустить веб-клиент Codex (тот, что в браузере с подключением к Git-репо). Я тестировал - оказалось сырым и бесполезным для моих задач. Пытаются купить Windsurf. Потом выкатывают Codex CLI - и вот это уже совсем другой уровень. Сейчас я пользуюсь им наравне с Claude Code. Цена та же (20$ в месяц), но условия по лимитам - гораздо приятнее. Сейчас ситуация выглядит так: три гиганта (OpenAI, Anthropic, Google) дотируют свои тарифные планы и стремительно улучшают агентское взаимодействие своих CLI утилит, чтобы посадить всех именно на свою допаминовую иглу вайб-кодинга, Cursor глотает пыль где-то сзади. Google сжигает меньше всего денег за счет своих TPU, скорее всего.


Почему именно программирование?

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

Что может сделать человек, владеющий ChatGPT, Claude Desktop или Sora? Создать презентацию, сгенерировать картинку, написать бизнес-план или письмо. Результаты деятельности - всё это тоже “продукты”, но самого нижнего уровня. Фастфуд AI-эры. Джедаи первого уровня работают именно так.

А вот создание инструмента (SaaS, например) с помощью “вайб-кодинга” - это уже мастерство более высокого порядка. Человек пользуется
Claude Code / Cursor (мета-продукт) ->
чтобы создать свой продукт, который ->
помогает другим пользователям (и агентам) эффективнее решать свои задачи (производить продукты базового уровня). Это второй уровень.

А есть ли уровень повыше?

Есть. Это создание инструментов для создания инструментов.
Здесь мы говорим про авторов Claude Code, Cursor, Lovable, Bolt, Base44, Replit, v0 и сотен других, не таких распиаренных и более нишевых решений - про джедаев третьего уровня, которые строят мета-продукты (используя мета-продукты - а вы как думали, чем пользуются авторы Claude Code, когда пишут новую фичу в Claude Code?).

Достаточно открыть Reddit и почитать восторженные, а сразу следом - ругательные и отчаянные посты про Cursor или Claude Code. Так не пишут посты про еще один инструмент из арсенала работника. Там настоящая движуха, в которую вливаются внимание пользователей и деньги. (То, что прямо сейчас они сжигают миллионы в топке GPU - лишь побочный и временный эффект.)

Итого
- Первый уровень: использование AI как «фастфуда» - тексты, картинки, презентации, использование Comet и AI бизнес-ассистентов.
- Второй уровень: создание собственных продуктов и инструментов при помощи кодинга.
- Третий уровень: создание экосистем и мета-инструментов, которые позволяют другим творить и строить своё.

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

А ты сам на каком уровне AI-мастерства?

AI-кодинг - коварная фигня. Самый мощный AI не справится с инфляцией ожиданий пользователей - кодер-предприниматель тут выступает в роли героинового наркомана, у которого стремительно выжигаются дофаминовые рецепторы. Увеличение производительности очень легко профукать, если вдруг для инди-проекта решить взять кубик и “взрослые микросервисы”. По себе постоянно замечаю - с AI, прогресс в проектах нормальный идет, только если “бью себя по рукам”, и концентрируюсь на одной очень конкретной задаче, использую минимальное количество новых технических решений, когда беру старые добрые фреймворки, которые я знаю вдоль и поперёк. Фокус решает - и тут ничего не поменялось за последние годы.

Когда пора уходить с no‑code?
n8n уничтожил Zapier в Google Trends и занял умы пользователей в 24-25 годах - во многом, благодаря self-hosted модели и армии инфлюэнсеров, которые “запускали чатбота за 5 минут” в Ютубе. На нём теперь делают все что можно и кто угодно. Это отлично работает во многих случаях, но тем важнее знать, в каких случаях n8n - не очень хорошая затея!
Коротко: n8n превосходен для прототипов, внутренних автоматизаций и «склейки» сервисов. Но как только появляется продуктовая ответственность (UX, биллинг, аптайм, больше пяти юзеров), быстрее и дешевле становится маленький сервис на “настоящем” ЯП - особенно это актуально с современными AI‑инструментами, когда экономия времени/усилий по запуску проекта в no-code - уже не в 1-2 порядка, как раньше, а поддерживать и развивать - код всё так же на порядок проще, чем no-code.

Где n8n упирается в потолок
- UX: веб‑хуки и встроенные формы и интерфейс чат-агенты в n8n подходят для внутренних задач, но в реальных продуктах нужен реальный фронтенд.
- Платежки: «Stripe‑нода + веб‑хук» хороши для MVP. Для нормальных подписок, идемпотентности, ретраев, мультивалюты нужен код и развесистый Stripe API.
- Лицензия: Недавно один парнишка рассказал что они разрабатывают AI чатбот где под капотом n8n. Мало кто знает, но CE (Community Edition в n8n) не рассчитан на продажу SaaS поверх n8n; если ваши клиенты вбивают свои креды (api ключи, etc) - это уже коммерческая лицензия/ или лицензия Embed в n8n. Стоит Embed лицензия, например, от 50K USD/год. Почитать что можно, а что нельзя - тут.
- Версионирование: JSON‑экспорт и «история» и близко не заменяют Github / Git Flow и все нормальные инструменты контроля кода. Мёрдж больших воркфлоу — боль.
- Архитектура: сценарий на 40+ нод — это красиво на картинке, но это жопа в продакшне. Тесты, трейсинг, DLQ, идемпотентность проще в коде.
- Производительность: длинные цепочки нод, поколоночные вызовы внешних API, большие пэйлоады и сохранение всех исполнений — гарантированные тормоза даже при средней нагрузке. Слава богам, в 2025 году n8n запустил Data Tables - пишут в локальную базу, это уже намного лучше чем Google Sheets / Airtable!
- Деплой и observability: сила n8n — «DevOps не нужен». Но при росте нужны инструменты скейлить это все в мультипоточном исполнении, нужна нормальная БД, нормальные бэкапы, менеджмент секретов, свой SSO/RBAC, и взрослые централизованные логи/метрики (Loki/ELK, Prometheus/Grafana). Встроенный в n8n Execution Log шикарен для дебага, но не масштабируется.

Мой кейс с Code‑нодой в n8n
Надо было сделать выплаты в крипте по списку, из Google Sheets где указаны хеши кошельков и суммы - такой несложный mass-payout сервис на коленке. Потребовались npm‑библиотеки (ethers и т. п.) а как их в n8n подключить? Собираешь свой Docker‑образ n8n с зависимостями. Работает, но по ощущениям это уже «самописный бэкенд» с обновлениями образа и патчами безопасности, где код надо писать в textarea в браузере, блин.

Самое главное: в self‑hosted нет AI‑помощников для написания кода - это для меня так дико уже. Например, в той же Code‑ноде (AI assistant там есть только в n8n Cloud). Писать код - архаично в 2025, а уж писать его в текстовое поле без автокомплита - выглядит еще более странно :)

Почему «код» сегодня — не страшно
- Claude Code, Cursor, Codex пишут код, тесты, рефакторят и помнят контекст. Из визуального воркфлоу за часы получается маленький сервис с типами, логами и ретраями. Все эти помощники отлично помогают с архитектурой и DevOps.

Практические подсказки
- Держите n8n для внутренней автоматики и «клея». Для проверки гипотез и MVP.
- Как только появились: клиентские креды, платёжка, жёсткие SLA — вынесите ядро в сервис (очередь, БД, тесты). n8n оставьте на веб‑хуки/оркестрацию.
- Если глубоко «вросли» во внешние SDK/блокчейн/большие батчи — это верный сигнал к миграции на код.

Итог: n8n — отличный трамплин и рабочая лошадка для внутрянок. Но для продуктовой разработки на масштабе код с AI‑инструментами чаще оказывается быстрее, надёжнее и… проще.

Зарегистрировался на ERC3 - AI хакатон от Рината (канал @llm_under_hood). Так получилось, что это единственное “AI соревнование”, в котором я участвую в течение года. Предыдущий хакатон, кстати, был в марте, там я каким-то чудом занял 5ое место и узнал как готовить качественный AI enhanced OCR - распознавание сложных табличных данных и векторный поиск по ним, для ответов на сложные вопросы по сотням страниц PDFок - тогда всех нас порадовала модель Gemini Flash 2.5 своей чудовищной эффективностью в пересчете на один доллар. В новом хакатоне задача соответствует духу времени - пишем настоящий агентский AI для реальных задач типа “вот API магазина, надо пользуясь этим API выбрать самый лучший купон на покупку вот такого товара”. Победит AI агент, который как бультерьер будет цепляться в конкретную задачу, и методично ее решать, иногда в десятки сложных шагов. Ринат запилил специально под хакатон целый личный кабинет, где сразу видно, насколько хорошо работает ваш тестовый агент.

Почему именно ERC3? Мы сейчас окружены облаками хайпа и телеграм инфлюэнсерами, которые репостят новости о новых моделях и прогрессе в LLM. Поглощение этой информации не сильно отличается от бездумного листания ленты с фотками в любой соцсети - “AI фаст-фуд”, который не задерживается в памяти. А кто на практике вредряет сложный AI в больших и маленьких организациях? LLM под капотом - это редкий пример канала про применение LLM в реальных бизнесовых задачах с _измеримым_ результатом, и я возьму на себя смелость сказать, что конкретно этот хакатон - даже интереснее, чем решение бизнес задачи в реальном боевом проекте - потому что тут за вас
1. подготовят задачи и дадут одинаковый сет задач с очень конкретным ожидаемым результатом, нескольким командам
2. посчитают настоящую эффективность вашей реализации
3. наглядно сравнят вашу реализацию AI агента относительно еще десятков других.

Эта обвязка, в виде подготовки хорошего объема проверочных данных (а это сейчас единственный способ ответить на экзистенциальный вопрос - “а не хуйню ли мой агент посчитал/написал?”), и измерения качества AI агента - вообще сейчас самая нудная и трудоемкая часть в AI проектах, кто же своего AI агента будет по собственному желанию замерять на _достаточном_ объеме тестов, это же такой геморрой? Так что - рекомендую поучаствовать. Это, на всякий случай, не реклама, а рекомендация от души.

Аналитики HSBC прикинули, что OpenAI нужно поднять минимум $207 млрд к 2030 году, чтобы продолжать работать в минус. Причина проста - гигантские контракты на аренду вычислений у Microsoft и Amazon: уже подписано мощности на 36 ГВт и до $1.8 трлн совокупной стоимости. Только аренда дата-центров к концу десятилетия - около $620 млрд в год.

И это очень оптимистичный сценарий:
- 3 млрд пользователей к 2030
- 10% платящих
- 2% мирового digital-ads рынка
Но даже в этом раю уравнение не сходится: между доходами и затратами - дыра в $207 млрд.

При том, что LLM нужен всем, есть проблемка: OpenAI пока только придумывает, как забрать высокомаржинальные юзкейсы и начать генерировать деньги:

• Агенты – у Google есть Chrome, у Microsoft Office, у Apple ОС. У OpenAI - есть только клиент ChatGPT как интерфейс взаимодействия с пользователем. Кодинг-ассистенты превращаются в низкомаржинальную гонку моделей.
• Фарма - зачем Big Pharma делиться заработками с “коммодити-интеллектом”, а еще ведь есть DeepMind?
• Генерация медиа/рекламы - рынок под контролем Google/Meta/Amazon

Видится (кроме кодинга и создания вендор-локнутой экосистемы для больших и мелких игроков) еще один вполне реальный шанс - ритейл, где OpenAI мог бы зарабатывать на рекомендациях товаров.

HSBC при этом остаётся ультра-бычьим: “AI проникнет во все процессы, и дополнительная пара bps к мировому ВВП оправдывает любые капексы” (capex - capital expenditure).

Но если отбросить розовые очки, история выглядит так: OpenAI быстро растёт, но стоит на модели, в которой каждый новый доллар ревеню сгорает в дата-центрах. И без постоянных раундов в десятки миллиардов эта экономика не взлетает. При этом Google все инновации быстро копирует и делает на своих TPU все эффективнее чем OpenAI на GPU Nvidia. Пойду дальше жечь инвесторские бабки в Codex CLI и Claude Code, чего и вам желаю!

Пообщались с хорошим другом по поводу того, что на Youtube каждый час заливаются тысячи странных и часто поверхностных AI роликов. Стало интересно - а возможно ли сделать около-историческую научпоп аудио-книгу, которую я сам захочу послушать, с достаточно глубоким и интересным контентом, хорошей озвучкой, с иллюстрациями, и себестоимостью генерации меньше чем в доллар? Потратил два дня, и могу сказать, что самые свежие LLM не хуже Минаева могут осветить исторические события. Оговорюсь, что я не очень в контексте, чего там творится среди существующих решений для генерации длинных видосов и написания книг - не сомневаюсь, что их там уже куча разных есть. Скорее, хотелось применить свои знания в построении универсальных AI агентов на очень прикладном примере, но с использованием самых современных решений для написания текста, создания озвучки, и создания иллюстраций под текст. За сутки запилил MVP: AI агент для генерации качественных исторических аудио-книг для Youtube. Еще сутки ушли на эксперименты и вычитку текста. Помогло, что я большой фанат инженерии и технических открытий Второй Мировой - мне эта вычитка доставляет много удовольствия. Первая главая про B24 Liberator вышла короткая и не самая интересная. К третьей части “книги” про Пантеру и немецкие танковые двигатели я уже вошел во вкус, использую gemini cli и отдельные .md файлы для каждой главы и для оглавления. Кодовый агент великолепно умеет работать с файлами и инструментами, которые сам же и настрогал. Мой AI агент умеет дергать Replicate API и Google API для озвучки, создания изображений, и делать прикладные вещи через консольные утилиты, такие например, как компиляция всей части книги из кучки .md файлов в один, или сложного рендеринга через ffmpeg, где анимируются фотки из папки и на начитку накладывается музыка.
Сейчас работа над часовым транскриптом аудио-книги у меня выглядит примерно так:
"Так, давай проверь что главы 3 и 4 не повторяются со второй. Добавь интересные исторические моменты про производителей подшипников в Германии во время бомбежек. Создай интересные промпты для генерации трех релевантных картинок и сгенерируй изображения. Потом сгенерируй озвучку на книгу, генерацию видео я сам запущу."

Третья глава получается на час интересного контента, уже залип пока слушал. БОльшая часть костов на один ролик - это Nano Banana Pro. Flux 2 тоже хорош, но заметно хуже. Обложку прикладываю - зацените. Суммарно примерно в доллар на все модели уложился (текст условно бесплатный, картинки - дорого и качественно, озвучка - умеренно), но пришлось поэкспериментировать.

Если бы хотелось сделать отличную по качеству озвучку на 5 минут - можно было бы взять 11labs и не париться, но это вообще не решение для генерации часовых аудиокниг - останешься без штанов.

Через год на Youtube будет заливаться в сто раз больше контента, чем сейчас. Одно дело, когда про это говорят фантасты и журналисты BBC, другое дело - погрузиться в индустрию и руками создать такой контент и понять, что он очень даже "съедобный". Те, кто зарабатывал 1000 долларов в месяц на показах в Youtube на среднем качестве роликов, с большой вероятностью будут зарабатывать 100 долларов - рекламодателей и зрителей больше не станет, а контента будет невероятно много. У уникальных авторов, так же как у хороших сеньор программистов, все будет хорошо. Наверное :)

Ссылка на 3 часть про немецкие танки и их двигатели: https://youtu.be/OBsqkkWd7c8 (озвучка на английском)

Как задачка на 15 минут превращается в издевательство над AI агентами, на 4 часа?
Ситуация: требуется переделать секцию “Billed To” в 7 тысячах pdf инвойсов на новую компанию. Инвойсы сгенерированы в SaaS сервисе, это не картинка воткнутая в пдфку, а нормальные векторные шрифты, все инвойсы по одному шаблону и очень похожи друг на друга, но есть нюанс - высота шапки у всех разная (потому что разные контрагенты в "Billed From" указывают разное количество данных и у них разные логотипы по высоте). Claude Code бодро попытался использовать самый очевидный способ - использовал консольные утилиты типа pdftk и замену строк через sed. Не сработало - новый текст, внедренный на место старого, обрезался визуально (PDF очень сложный формат - мешанина картинок, шрифтов, форматирования, тексты все "заархивированы"). Я подсказал использовать convert (imagemagick) через CLI для визуального контроля результатов подмены (когда pdf страничка конвертится в png и изучается уже самой ллмкой). В третьей итерации Claude попытался написать низкоуровневый nodejs код который декодирует (uncompress) PDF и заменяет HEX символы, по словам. На двух строках из адреса работает, на третьей - строчка обрезается визуально из-за особенностей верстки.

В итоге CC сдался и превысил лимиты тарифного плана за $20/mo примерно через час мучений и подсказок.

Переходим в Gemini CLI. Предлагаю попробовать вариант с работой PDF как с картинкой - нарисуем оверлей и сверху новый текст. В принципе, оно сработало на 75% инвойсов, но увы - на 25% из-за смещения по вертикали самой секции - часть старого адреса не перекрывалась надежно, или наоборот перекрывала основную часть инвойса. Проверять результаты пришлось кожаному мне - у Gemini CLI оказалось все плохо с визуальным контролем нюансов скриншотов, она совершенно не понимала что мне не нравится в торчащем на скриншоте старом адресе, на который был криво “наляпан" новый адрес сверху. У Клода Sonnet 4.5 тоже с пониманием было не все гладко, но, кажется, получше.

Конечно, если бы у меня было 100 инвойсов, или 500, я бы плюнул и сделал бы все через чистый OCR подход - конвертим PDF в PNG, находим координаты bounding box для нужной секции в инвойсе - не очень сложно. Но, блин, для 7к файлов это очень много процессорного времени и денег!

Решил попробовать следующий вариант - вырезал кусочек с текстом "Billed To" из инвойса, в .png формате, предложил скриптом искать координаты вхождения этой картинки в картинке страницы инвойса. Gemini попыхтел на тестовой выборке, почему-то ничего не нашел - видимо, из-за разностей рендеринга в разных DPI. Тут уже наступила ночь, и я уже совсем не вчитывался в генерируемый код, хотелось просто уже запустить скрипт и пойти спать. Я уже был близок к совершенно чудовищному способу решения задачи - отконвертировать PDF -> HTML, заменить строчки, отрендерить новый PDF. Но это было бы долго, и скучно, и была вероятность поломать неочевидные вещи в визуале инвойсов.

И итоге победил Cursor и GPT 5.1 Codex Max.

У него получилось найти слова "Billed" и "To" в сорсах пдфки, и вытащить их координаты. Потом пересчитать "пункты" этих векторных координат в пиксельные координаты, и наложить новый сгенерированный кусок в правильное месте в PNG картинке. Дальше сделать новый PDF - уже растеризованный. Написали с ним тестовый скрипт, который берет десяток рандомных пдфок и проверяет, что наложение корректно рассчитывается.

Такой гибридный подход (детектим координаты по тексту пдфки без вовлечения тяжелых ocr решений, а рисуем уже как на картинке) позволил добиться приемлемой скорости и 100% успеха на всех 7к инвойсах - Макбук перерисовал их примерно за 10 часов скриптом работающим в три потока. Думаю, подход с OCR занял бы в 10 раз больше ресурсов и времени. Оптимальный ли это вариант? Сомневаюсь, но он неплохо сработал.

Если я хочу продать бизнесу 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.

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 лет?

В апреле уже писал, что Гугл задушит 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 оптимизирует под свои собственные масштабы.

Зарисовка из мира современного “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.

В 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 кода должен победить!

Еще про 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 версию, возможно, тут есть нюансы или сложности с лицензией.

Я сейчас подбираю 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-правил на странице логина.

Купил 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д модели аниме женщин или пикачу, умеет только строгую инженерную геометрию, но он уже доставляет мне и близким немало удовольствия - генерируем коробочки и совершенно рандомную фигню вместо того чтобы работать.

Что делать, если твой 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

Вышел с постом о ModelRift в OpenSCAD коммьюнити в Реддите. Коммьюнити образцовое - небольшое, техническое, олд-скульное, ценит core продукт. Первый же комментарий - “иди ты в жопу со своим AI, заманали вы со своим AI, ВЕЗДЕ ЭТОТ AI”. 2026 год - лучший год, чтобы построить что-то свое с помощью AI, но не обольщайтесь - это еще и худший год, чтобы это потом кому-то продать :)

К счастью, сразу нашлись и люди, понимающие разницу между вайб-кодингом, и нормальным продуктом.
Полагаю, это будет настоящим ключом к успеху в ближайший год - мастерство доводки продукта и наведения лоска. Эстетичный и уникальный дизайн. Грамотные тексты без AI булшита. Уместные и аккуратные анимации. Продуманный UX. Ну и умное, эффективное продвижение, естественно. Это все не купить даже в 200 долларовом плане Claude Code. Пока :)

Наткнулся на свежий исчерпывающий пост про песочницы для исполнения кода, в частности, для AI агентов. Все разложено по полочкам, супер плотно, без воды, написано простым языком. Главная польза - пост учит задавать правильные вопросы, для определения, какая конкретно песочница на какой технологии изоляции нужна в конкретном случае (для долгоживущих процессов типа сессии claude code - один подход, для эфемерных процессов живущих 5 секунд - другой)

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`;