обновил UI для инструмента, который неизменно пользуется большой популярностью у реддитовцев: OakPDF Signature Extractor. Все ещё не доволен визуалом, надо будет переделать на shadcn, как появится больше времени. Перенес на новый сервер (ubuntu 16 -> ubuntu 22, давно было пора, но как же было лень это делать руками!) . Переношу/мигрирую/девопсю теперь свои проекты с помощью Claude Code - в .env сохраняем ипы старого и нового сервера и API ключ для управления Cloudflare, и просим перенести сайт через rsync, настроив nginx хосты и Cloudflare записи сначала на дополнительный субдомен, например new.example.com, потом, после тестов через curl и сверок <title> (тесты тоже проводит CC - убеждается, что нет явных деградаций, и что открывается правильная страница правильного хоста) - прошу переключить основной домен на новый сервер. Работает на удивление хорошо, и никакие MCP не нужны! А вот еще злободневный юзкейс - надо было зачистить 40 древних сабдоменов из Cloudflare с дополнительной верификацией что эти хосты уже не работают - опять Claude Code через API Cloudflare великолепно справился.

Вообще, за последний месяц я стал считать зашкваром постоянное тыкание каких-то кнопок в веб-интерфейсах, в нормальном мире всё должно работать через API и агентские LLM.
Вот по этому поводу обалденный свежий бенчмарк моделей: https://accounting.penrose.com/ - тут LLM использует агентский режим, чтобы работать с бухгалтерией - делает сведение балансов. Крутая, прикладная задача из сложного реального мира. Anthropic модели в лидерах.

Зарисовка “обычный день AI кодера” - в терминале Курсора (это панель снизу), на удаленной машине в Хетцнере, запущен Claude Code, который пишет скрипт классификации FAQ вопросов - использует этот скрипт OpenAI API, пишет в sqlite. Получается, Claude Code пишет промпты для OpenAI. Справа - происходит анализ данных, уже через сам Cursor - свои лимиты на Sonnet 4 там я уже сжег, поэтому делаю на модели Auto.

Задача, которую решаю - оптимизация работы поддержки в сложной предметной области (логистика). Анализ гипотез. Анализ уже закрытых тикетов с оценкой скорости и качества работы (человеческого) оператора поддержки. Кластеризация запросов на большие группы, чтобы в дальнейшем скормить разным AI агентам разный контекст и разный список инструментов работы с БД, на базе классификации - к какому кластеру базы знаний относится конкретный вопрос пользователя. Кластеризация пользователей на классы. Вообще, исследовательская работа тут сводится к работе с БД напрямую (естественно, read-only mysql юзером с ограниченным количеством полей в бд - никакого доступа до персональных данных и вообще sensitive данных), и генерации маркдаун файлов с выводами.

Если все умеют круто программировать и запускать с AI, то какие преимущества останутся лично у тебя через год? Всё так же будет важна экспертность в конкретной нише, энергетика, финансовый капитал, и конечно нетворк. Мой нетворк - на видео:

Курсор только что удалил продакшн базу данных mysql на моем проекте apiroad.net. Спасибо программированию фич на проде - я попросил сделать тест моего нового ботодетектора (много фейковых аккаунтов регается на APIRoad), он сделал тест и запустил. Не забыв зачистить прод базу для seed файла. Сразу всплеск адреналина, стук сердца, ладони вспотели - проектом пользуются сотни платящих кастомеров. “Бля, а когда я проверял бекапы последний раз?” Не будем душнить про то, что только дурачки на проде программируют - если у тебя 10+ старых проектов, где ты один работаешь, эта фигня происходит постоянно - потому что переключение контекстов и проектов хочется минимизировать до микросекунд.

Ок, так что делаем дальше? У меня бекапы этого проекта хранятся в двух местах - restic+s3 и бекапы хетцнера. Сначала лезу в рестик, чтобы выяснить, что s3 доступ там похерился полгода назад. На всякий случай лезу в Страйп и дампаю оттуда полный список кастомеров с емейлами - во всяком случае, это сейчас самое важное, если вдруг и бекапы хетцнера подведут. Пока экспортируется файлик, проверяю хетцнер - последний дамп этой машины сделан полтора часа назад. Начинаю разворачивать в отдельную машину этот бекап. Тут самый стремный момент был - а что, если не развернется автоматикой? Развернулась. Фух. Что дальше делал бы я год назад? начал бы гуглить флаги mysqldump и дампать базу из ресторнутого сервера руками. Потом гуглить флаги rsync, десять раз перепроверять что там в бд на старой и новой машине. Это заняло бы все минут 20-30.

Вот что сделал я:
Делаю на локальной машине папку apiroad-restore и там - CLAUDE.md файл с описанием ситуации, ипами обех машин, и пошаговыми действиями:
1. У тебя уже есть ssh доступ на обе машины.
2. Останови все crontab и pm2 на восстановленной машине (чтобы не было конфликтов данных и случайных емейлов или пушей оттуда)
3. Переверь бд на обеих машинах, проверь количество кастомеров в таблицах
4. Дампани старую бд,
5. Дампани восстановленную бд, rsync-ни с восстановленного сервера дамп на старый сервер, восстанови его
6. Перепроверь что количество юзеров теперь нормальное


Клод справляется за 5 минут. База восстановлена с потерей 2 часов данных, но для APIroad это не критично - там реалтайм данные все в Clickhouse - его я пока еще ебнуть не успел.

Короче, не делайте так.
А если делаете - перепроверьте свои бекапы. Заведите отдельного readonly юзера БД, если вам надо делать аналитику БД в проде через LLM (а писать в БД на проде через LLM никогда не надо). А я пошел чинить рестик, да и dev окружение надо освежить.

Запилил свой селф-хостед Lovable с блекджеком на базе бесплатного API Cerebras.AI. Пишем промпт - получаем работающий развернутый апп с персистентностью в sqlite. Под капотом - модель Qwen3-480B Coder . Средняя приложуха создается за 2.5 секунды (2K токенов в секунду скорость отдачи у ребят, OMFG), деплоится в докер контейнеры. Представляете, сколько рандомных аппов я успел нагенерить за 5 минут? Конечно, пока еще сыро и дыряво, work in progress, но что думаете?

Github: https://github.com/restyler/poor-mans-lovable (дайте звездочку)
Reddit пост: https://www.reddit.com/r/LocalLLaMA/comments/1mg0uw8/i_have_built_my_own_poor_mans_lovable_testing_out/ (дайте лайкосик)

Знаете ли вы людей, которые, не имея опыта в стройке и не нанимая большую компанию с пятью прорабами, построили крутой дом без значительных проблем со сроками и проектом, за счет системного подхода и грамотного планирования и менеджмента? Это вам не saas навайбкодить. Я знаю только одного такого человека. Мой хороший друг Илья Макаров - крутой управленец в IT, ex-CEO серьезного e-commerce движка, ментор, позитивный и насмотренный, сейчас ищет проекты где можно нанести пользу - если что, скажите что от @pixeljetter

https://xn--r1a.website/makarov_way/221

Крутые фишки Claude Code, которые не все знают:
- Он умеет принимать скриншоты - на макбуке, Cmd+V прямо в терминале вставляет картинку из буфера обмена. Если я работаю в CC на удаленной машине через ssh remote, в запущенном терминале Курсора - то напрямую вставка из буфера не работает, в этом случае я переношу драгндропом файл скриншота из файндера в Курсор, а потом уже перетаскиваю файл из эксплорера Курсора - в терминал Курсора, в поле промпта CC. Без скриншотов (где стрелками рисую что не так, и нумерую прямо в скрине проблемы) не представляю уже как делать работу.

- CC теперь (НАКОНЕЦ) умеет работать с долгоживущими процессами - например, запускает в отдельном процессе npm run dev, который собирает фронтенд, и "видит" его - этот процесс не блокирует работу. Это свежая фича, см. видео

- СС можно направлять в процессе агентской работы - если Cursor иногда напоминает бешеную лошадь которую хочется срочно остановить, а новый промпт встает в "очередь" - то CC всегда рад принять дополнительный промт "э, я забыл, вот еще одна важная деталь" и умно внедряет ее в свой план исполнения задачи. Я вообще ленюсь и хреново формулирую промты, и вот такой аналог "докинуть носки когда уже стиралку запустил" - это очень удобно!

На HN вирусится ругательный пост про Next.js (комментарии). Автор жалуется на излишнюю сложность и магию внутри фреймворка, которая на деле нужна лишь малому числу проектов. Поддерживающие комментарии тоже говорят: Next.js плодит абстракции и подталкивает к использованию Vercel, а без него деплой превращается в головную боль. Это явный vendor lock-in: всё сделано так, чтобы разработчик в итоге махнул рукой и отдал проект на Vercel. При этом ошибки и баги вне Vercel решаются плохо - документация отстаёт, а GitHub-issues годами без ответов.

Отдельный пласт критики касается того, что Next.js уже не про простоту. Когда-то он был «React-фреймворком с SSR», а сейчас - это сложный комбайн с App Router, Server Components и кучей «магии» под капотом. Для небольших и средних проектов это избыточно.

Что предлагают в качестве альтернатив? Самый часто упоминаемый вариант - SvelteKit. Он проще, его легко запускать где угодно, а не только в «родном» облаке. Плюс в нём меньше слоёв абстракции, поэтому поведение приложения прозрачнее. Другой путь - собрать стек вручную: Express + React (или Vite). Из близких по духу решений вспоминали React Router v7 (в Remix-режиме), который даёт многие возможности Next.js, но без тяжёлого обвеса.

От себя добавлю: я никогда серьёзных проектов на Next.js не запускал, но уверен, что на нём можно отлично жить, особенно в большой компании, где ты на зарплате. Но для индихакинга?.. Для статических лендингов я сейчас предпочитаю Astro.js. Это всё ещё React-экосистема (можно и без нее, но все нормальные темы под Astro - на серверном React), но с последними обновлениями Vite его билды почти догнали по скорости мой любимый 11ty (который не очень развивается, и не очень хайпует). А для динамических приложений рекомендую присмотреться к TanStack Start - он уже (почти) стабилизировался - это по сути TanStack Router, но с хорошим DX для сервера, и с адекватным количеством магии.

Для любителей олдскула всегда есть отличные вариантики - Laravel + Inertia, а еще Rails или Django + HTMX/Alpine.js: надёжно, понятно, без скрытых сюрпризов. Тут ставка на проверенные временем практики и контроль инфраструктуры. Проект на Ларавеле, сделанный пять лет назад и запущенный на машине в Хетцнере, нормально работает и сейчас.

И ещё момент. Лично я предпочитаю Vue.js (например, на vue.js работает qwintry.com ), но в эпоху LLM/AI-интеграций, где нужно много UI-экспериментов и быстрой интеграции с экосистемой, стек React + Shadcn выглядит практичнее. Объективно говоря, все нормальные дизайнеры работают с React, а значит - нормальный набор Tailwind компонентов почти всегда будет под React! Здесь меньше магии и больше предсказуемости (проще дебажить ошибки в рантайме), хотя многословность никуда не делась.

На скриншоте - счет на 96К USD от Vercel (пост от 24 года, они вроде бы добавили какой-то контроль костов в админку уже - но serverless платформа - это все равно всегда риск или получить счет, или - что тебя выключат когда твой проект завирусился)

Вчера собрал скрипт.
Он прогоняет 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.