Кажется, сейчас каждый час на гитхаб заливается по сотне новых MCP интеграций (правильно, там делов-то? Один промпт в курсоре!). Все только и говорят про этот MCP!

Если вы вдруг не в курсе что это такое - фактически, MCP это стандарт “API для LLM” - теперь любая LLM может вызывать любые API, получать оттуда данные, и использовать результаты вызова этих API в дальнейших своих действиях. “Инструменты” - это абстракция, чтобы через этот MCP протокол работать. https://modelcontextprotocol.io/docs/concepts/tools
Фактически сейчас “MCP” === “инструменты для LLM”. До изобретения MCP (кстати, придумал этот стандарт Anthropic) был полный зоопарк - каждый изобретал сам, как сделать, например, интеграцию LLM и инструментов типа “поискать в Google” или “сходить в Postgres и исполнить SQL запрос”.

n8n сначала сделали AI tools agent ноду, которая могла вызывать “инструменты” - под капотом там был Langchain
И только что запустили официальную интеграцию с MCP, и с одной стороны, теперь можно дергать любой сценарий n8n как MCP инструмент, из Курсора или Claude Desktop, а с другой - внутри n8n сценариев теперь использовать MCP сервера как инструменты, для их ноды AI ассистента.
Если вы не очень погружались в n8n, все это очень сложно усвоить, да. Но такова сейчас ситуация в отрасли, все меняется каждую неделю.

ActivePieces (это относительно новый игрок в лоу коде, схожий с n8n) идут дальше - они позволяют не только вызывать сценарий, а позволяют как MCP инструмент использовать вообще любую свою ноду. На скриншоте - я нажал одну кнопку и теперь, добавив один MCP сервер в Курсор - я могу работать с Google Sheets (работает хреново, API реализовано с ошибками, но это уже детали), Airtable, и еще с сотней других интеграций которые есть в ActivePieces.

Получается концепция "единого окна".
Вы спросите, зачем вообще нужен посредник в виде ActivePieces, если можно взять какой-то опенсорсную реализацию MCP сервера из npm, типа https://github.com/xing5/mcp-google-sheets - вонзить ее в Cursor, и работать?

Это хороший вопрос, и вот что я думаю: для многих крупных игроков типа Google настройка доступа к какому-то из сотен их API требует много телодвижений - зайти в Google Cloud, найти там Oauth клиента, открыть нужные API...
Это не так чтобы очень быстро и приятно делается, в эпоху, когда мы через Lovable - ВЖУХ - и создаем прототип SaaS за одну секунду - ползать по GCE и искать как на Service Account раздать прав на API Google Sheets - какое-то средневековое занятие. Средний пользователь low-code платформы, как только прочтет про три варианта получить API ключ к Гуглу ( https://github.com/xing5/mcp-google-sheets?tab=readme-ov-file#-authentication--environment-variables-detailed ) - сразу закроет эту вкладку браузера и с воем убежит.
К тому же, надо выбирать потенциально из десятка разных MCP серверов разношерстных. А не сворует ли этот левый mcp с гитхаба чего по пути? Кто смотрел в его код?

А ActivePieces, получается, сделали такого посредника, где пользователь заходит, тыкает одну кнопочку, авторизует свой Google аккаунт в браузере - и все работает. MCP Gatekeeper - новый класс инструментов, который только и занимается тем, что контролирует доступы. Интересно!

Давайте порассуждаем, что будет дальше.
Если у нас есть такой универсальный и примитивный агрегатор, который удобно позволяет работать с MCP инструментами и берет на себя только управление доступами, и есть LLM, которая не глючит и стабильно работает с этими инструментами, то нужен ли нам вообще n8n/Zapier и вся вот эта грузная логика с разбрасыванием нод на холсте, протягиванием стрелочек, и прописыванием циклов и if'ов - весь функционал, который они делали и полировали годами? Где-то нужен, безусловно, но, кажется что уже пора делать новый класс инструментов с другим интерфейсом. Эдакий n8n, built for AI era - больше похожий на Курсор, а не на n8n?

P.S. стоило мне дописать этот пост, как наткнулся на https://github.com/aipotheosis-labs/aci - прям один-в-один то, что сделал ActivePieces.

А я опять со своими low-code автоматизациями. Недавно мне скинули ссылку на интересное хром расширение - называется n8nChat.
Он добавляет чат-интерфейс прямо в страничку self-hosted n8n. Вставляете туда свой API-ключ OpenAI, пишете запрос типа “сделай мне сценарий где будет открываться вот такой сайт, … и результаты шли мне в Telegram” - и получаете рабочий сценарий автоматизации в n8n - из одного промпта (придется покликать, чтобы настройки мелкие задать и доступы выдать, конечно). Гениальный User Experience, особенно для новичков. И на простом примере - даже работает, и создает сценарии!

Декомпилировал экст, - внутри используется модель OpenAI o4-mini с длинным мастер-промптом, в котором модели предлагается использовать локальные MCP инструменты, которые прямо в браузере дёргают API самого n8n (JS функции - типа get_node_template, browse_nodes, add_workflow_nodes). Это позволяет сильно снизить количество галлюцинаций LLM модели относительно тупого подхода "а выдай-ка мне полный JSON для сценария вот такого-то" - ведь за синтаксисом конкретной ноды n8n не уследишь, он сложный и постоянно меняется.

Естественно, чуда не происходит и на мало-мальски сложных сценариях это всё равно не работает, выдает хреновые результаты. НО.

Значит ли это, что сама идея с чат интерфейсом + low code платформой - мёртвая? Нет, это просто показывает, что n8n фундаментально не готов к такой надстройке сверху. Он писался под интерфейс для существ, которые кликают мышкой. А тут нужен качественный AI (MCP?) интерфейс к самой n8n.

Уверен, прямо сейчас десятки команд активно работают над подобным продуктом, и уже скоро мы увидим реально сложные low-code сценарии, полностью собранные AI. Просто пишете один промпт, отвечаете на пару вопросов, подрубаете по oAuth свои апишки - и всё готово. Получается, ждем эдакий Lovable - но не для лендингов, а как надстройка над платформой типа n8n, Windmill или Make. LLM намного пишет лаконичные DAG сценарии и DSL, а исполняются они в контролируемой безопасной среде платформы - это вместо подхода, когда миллионы токенов сжигаются, чтобы генерировать километры html с джаваскриптом и тейлвинд классами. HTML и Javascript для новой эпохи (и новой армии вайб-кодеров) будут примерно как ассемблер 20 лет назад - сложные и низкоуровневые технологии, не очень подходящие для сверх-эффективного решения куч типовых бизнесовых задач, где надо быстро json перекидывать и формочки клепать со скоростью мысли. Естественно, огромная прослойка программистов все так же будет писать с помощью AI староверный JS и исполнять на настоящих облачных серверах, прямо как наши деды (я - точно планирую продолжать)!

Но DSL сценарий + low-code платформа дает лучшее из двух миров: тут и быстрый старт, и observability, и удобное логирование с дебагом, и наглядный интерфейс, и достаточная гибкость, и закоммитить его можно в гитхаб для контроля истории. Плюс - для большинства людей это намного безопаснее и быстрее, чем на условном Курсоре напилить Node.js скрипт и деплоить на собственные сервера или в Vercel. Не надо копаться в низкоуровневых деталях, удобнее редактировать - кликая мышкой в свежесозданных сценариях, в браузере.

У Алмаса в комментариях к его посту про правильный AI-flavored кодинг (не путать с вайб-кодингом) развязалась дискуссия по поводу подхода к работе с БД на этапе прототипирования MVP.

Традиционный подход - это система миграций, когда у нас есть кучка js/php файлов с прописанными запросами на апдейт структуры базы, обычно в некоем DSL формате - в принципе, это очень похоже работает во всех взрослых фреймворках, таких как Laravel, Django, Rails - и в knex.js тоже.

Вот в чем проблема традиционного подхода: LLM неудобно следить за эволюцией схемы БД, особенно если у вас там быстро накапливаются много миграций с ALTER запросами.

Как же дать LLM возможность всегда видеть актуальную схему БД, каждый раз когда мы пишем ему промпт на генерацию кода?

Решение №1 - регулярно делать squash миграций (когда все миграции сливаются в один дамп БД).
Решение №2 - сделать отдельный скрипт для дампа структуры БД, в файлик, и постоянно дампить - соответственно, получается структура БД в файле, который постоянно перезаписывается скриптом.
Решение №3 - генерировать типы для структур данных и надеяться, что LLM этого хватит
Решение №4 - отречься от миграций на этапе прототипирования, вообще.

Естественно, решения 1-3 самые скучные, везде используются, и не интересны никому, кто хотя бы 10 лет программировал /s.
Поэтому, переходим сразу к 4-му решению, для хардкорных минималистов и любителей сырого SQL (да, я в их числе).

создаем в проекте файл schema.sql и складываем туда структуру БД.
В .cursorrules пишем, что этот файл - source of truth для базы, и нам не нужно писать ALTER запросы, мы просто редактируем CREATE TABLE запросы.

При перезапуске аппа (в моем случае это Node.js), если env != production, мы каждый раз удаляем БД и создаем заново из schema.sql (+seed.sql если нужны стартовые данные).

Что мы получаем?
- Сырой SQL как source of truth. Никаких DSL. Великолепно.
- LLM может легко читать и ПИСАТЬ в один и тот же файл. Писать настоящий SQL под конкретную базу, а не вот это вот: https://www.prisma.io/docs/orm/prisma-migrate/getting-started
- Если происходит какая-то хрень с БД, мы это сразу обнаруживаем - на ближайшем сохранении файла и перезапуске. У нас не бывает так, что в деве все работало, а при создании базы с нуля - нет, потому что какая-то херобора и нарушение порядка ALTER-ов произошло.

Очевидно, этот подход не подойдет продукта, который развивается командой, или который уже находится в цикле развития/поддержки. А вот для скоростного AI прототипирования - прикольно получается!
Это примерно как когда из гоночной машины выдергивают все кресла, и оставляют только одно - все для снижения веса и скорости. Нам нужен готовый продукт за 24 часа, чтобы завтра он начал работать и приносить пользу/деньги - и на пути к этому все средства хороши.


Да, для прода все равно придется использовать миграции. Тут любовь к минимализму и сырому SQL пока привела меня к инструменту https://github.com/amacneil/dbmate (на замену Knex.js) - dbmate позволяет работать с любыми БД и писать все миграции в .sql файлы. Красотища!

P.S. Решение №5 (верно напомнили в комментах) - это MCP сервер для БД, чтобы Курсор сам мог ходить и смотреть схему таблиц, когда хочет. Это интересно и перспективно, но честно говоря - я пока это не использовал в реальной работе, только игрался. Мне кажется MCP сервера все-таки не такая надежная и простая технология сейчас - посмотрим, как будет развиваться!

У меня укоренился новый паттерн использования Курсора - всё больше доверяю ему самому исполнять серверные команды, анализировать показатели, делать запросы к базе (sqlite/pg), и даже создавать хосты в apache/nginx. Это похоже на MCP, но не требует никакой дополнительной обвязки, и, кажется, работает значительно быстрее и стабильнее. Пример вопроса:

analyze tcp pressure and cpu pressure and also ram and disk space - is my server OK? verify apache status as well

пример ответа:

Here is a summary of your server's health based on the checks:
1. TCP Pressure
There are a large number of established and close-wait TCP connections, especially to port 80 (HTTP).
Some connections have very high Recv-Q (receive queue) values, which can indicate the server is struggling to process incoming requests fast enough.
This could be a sign of high load, slow backend, or a DDoS/bot attack, or just very high legitimate traffic.
2. CPU Pressure
CPU usage is moderate: 19% user, 3.9% system, 76% idle.
The top process is dockerd (Docker daemon) at 50% CPU, followed by clickhouse-server and several node processes.
No evidence of CPU saturation, but some processes are using significant CPU.
…

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

Курсор в режиме agent; модель: gpt-4.1; в настройках Курсора во вкладке Features активирована галка Allow Agent to run tools without confirmation.

Для баз данных - удобно в .cursorrules прописать кратко, как до сервера достучаться и какой консольной утилитой воспользоваться.

Не рекомендую повторять под рутом на важном продакшне :)

OpenAI недавно запустил Codex - решение, которое выводит программирование на новый уровень по сравнению с Курсором или Lovable. Я не знаю, доступно ли это бесплатным пользователям, но с тарифным планом за 20 баксов (Plus) - уже доступно: https://chatgpt.com/codex

Идея такая - даем доступ до гитхаб репа, говорим что делать, процесс много раз дергает LLM модель, скачивает, изучает реп, устанавливает зависимости, умеет запускать тесты, и в конечном итоге создает полноценный Pull request в реп, с изменениями и описанием.
В принципе, концепт сам по себе не новый, я такое видел примерно год назад (правда название проекта уже забыл) но, естественно, год назад LLM модели такое совсем не тянули - слишком большой нужно контекст, и все подходы к построению агентов тоже эволюционировали сильно.
А как сейчас? Для проверки я взял репозиторий nocodb, и попросил реализовать вайтлейбл брендинг - возможность оверрайда логотипов и названия сайта (эта функциональность недоступна в community версии nocodb).

Естественно, ничем хорошим это не закончилось, пока я не прописал подробно, как лучше к этой сборке подойти. Но после того как я объяснил, что надо сделать - оно вполне неплохо сработало. Увы, запушить PR не получилось, бинарные файлы, видишь ли, нельзя (а у меня там как раз картинки). Но в остальном - выглядит код неплохо, откровенной дичи в самом коде - не заметил. Вот мой промпт который выдал адекватный результат:

Allow to customize branding and og tags like site name, title, descr - of nocodb UI.
1. create /brand-assets folder in repo root,
2. scan /packages/nc-gui package and collect a list of all important branding assets (images like logos, og image - there should be around 4 or maybe 5 files - see layout .vue files to get the list of folders with important assets - I dont want to override icons and other small UI things, just primary branding files); copy them to /assets folder without dir nesting (for easier overview and replacement by human)
3. create ./brand-assets/assets.json file with a map of all important assets with their img resolutions and proportions, and explanation of each file, and original corresponding path inside /packages/nc-gui package (maybe not .json format? what the better format so bash could easily read this file with array of files and process them on a later step, without complicated deps? )

4. modify build-local-docker-image.sh file so it copies and overwrites all files from ./brand-assets/assets.json, so e.g.
./assets/main-logo.png goes to ./packages/nc-gui/<nested-dirs>/assets/brand/logo.png - output logs for each rewrite. we need to do this before nc-gui build step.
5. create ./brand-assets/README.md

Репозиторий выкачивается и разворачивается на каждую дополнительную правку. statless это классно, но в реальной жизни работает очень медленно, по сравнению с тем же lovable/bolt. Представляете, сколько электричества и трафа сжигает OpenAI с таким подходом? Не очень похоже, что все кешируется на их стороне - но, конечно, это быстро можно докрутить.

Вот получившийся PR, кстати: https://github.com/restyler/nocodb/pull/2

Что используют AI-enhanced разработчики и фаундеры в июне 25года? Наблюдаю среди коллег активную миграцию Cursor -> Claude Code. Почему такое происходит?
На поверхности: и тут, и там одна основная модель - лучшая на рынке для кодинга (если не углубляться в нюансы и демагогию) - Claude Sonnet 4.
Курсор - это форк Visual Studio Code, а Claude Code (далее по тексту - "CC") - это терминал. Терминал, Карл! Как можно это сравнивать в реальной работе, если вы не пользовались до этого вимом десять лет, конечно? Оказывается, вполне себе получается работать в терминале, если ты только раздаешь команды.. (а вот интеграция CC в VS code: https://marketplace.visualstudio.com/items?itemName=AndrePimenta.claude-code-chat - это неофициальный экст, а еще есть и официальный)

Преимущества CC:
1. CC внедрили адекватные тарифные планы. Если раньше надо было вписывать API ключ и Sonnet 4 сжирал деньги со страшной силой, то сейчас - можно стартануть с 20 USD/mo - просто через час-полтора кодинга CC предлагает “отдохнуть” - дробит он рейт лимитирование на временные отрезки по 5 часов. Подождали до конца “окна” и продолжаем работу. Поэтому, хардкорные ребята рекомендуют тариф 200 USD/mo. Лично меня вариант с API ключом тоже не устраивал, поэтому я работал с Курсором, но теперь пользуюсь и в Курсоре, и в CC тарифами за 20 баксов (покодил в CC, если уперся в лимит - перешел в Курсор). Получается очень хороший value за 40 баксов, хотя и 200 - не великая сумма, если каждый день по 8 часов кодишь и извлекаешь пользы на тысячи долларов.

2. CC - это инструмент от поставщика LLM. В то время, как команде Курсора надо не только делать очень сложный GUI продукт, но еще и ломать голову как срезать косты на LLM, у Anthropic все очень просто - льем все в контекст и не стесняемся! Это не только дает более предсказуемый результат, но и жутко экономит силы на разработку и тестирование самого продукта.
Я хочу отметить, что Cursor + Sonnet 4 работает у меня вполне себе хорошо 80% времени - когда ситуация нормальная и пока в США не наступило утро. Просто он работает по-разному у всех, кому-то везет меньше. И самое страшное - что там у него под капотом происходит - не очень прозрачно для конечного пользователя.
В CC все счастливы примерно одинаково. В Курсор все несчастливы по-разному - у кого-то лажает UI часть, кто-то попал на проблемы с конкретной моделью LLM.
Курсор устраивает чехарду с тарифными планами и биллингом - всё по той же причине, что надо экономить деньги, но и пользователи чтобы не разбежались. Навлекает на себя гнев этих пользователей, которые привыкли к объективно халявному 20 баксовому тарифу.

3. CC - это работа с настоящим агентом, которому даешь задание и он может работать 5, 10 минут, и не зависать изредка по странным причинам (как Курсор у меня). Курсор ТОЖЕ сильно продвинулся в этом, но чертова экономия и провисоны не дают развернуться - чаще требуется человеческое вмешательство.

4. CC вводит крутой инструментарий, когда аналог .cursorules (свод правил) пишет сам CC. Гениально и просто - открыли папку с репом, сделали команду /init и короткий саммари с важными инструкциями и архитектурой проекта оказывается в одном файлике CLAUDE.md в корне репа. Этот файл легко дополняется лаконичными инструкциями (самой моделью, и нами) и мы получаем классный баланс между memory bank как черной коробочкой (где хер пойми что происходит и сохраняется) и полностью ручным режимом .cursorrules. Естественно, все это реализовывается и в Курсоре, но тут - из коробки просто и красиво.

Чего не хватает CC: удобного механизма restore - мне нравится, как в Курсоре можно быстро откатиться до предыдущего состояния, если что-то пошло не так. Так же, очень люблю удобные диффы - в терминале это не очень удобно. В CC предполагается более глубокая интеграция с Git и использование его механизмов для такого.
А вы что используете, и какие тарифы?

[на скриншоте: как узнать что проект навайбкожен? посчитай количество эмоджи в комментариях к коммитам]

Безопасное выполнение AI-сгенерированного кода в песочницах — это то, что позволяет строить крутые, коммерчески успешные AI-продукты. Под капотом любого Lovable / Bolt / 0x всегда есть песочница, в которой можно безопасно исполнить опасный чужой код, и во многом благодаря песочницам эти продукты генерируют миллионы ARR прямо сейчас. При этом технологии, которые позволяют делать изоляцию кода, находятся в тени. Пора это исправлять.

Я скомпилировал (неполный, но длинный) список технологий и инструментов AI sandoxes и выложил в открытый доступ на Github: https://github.com/restyler/awesome-sandbox - буду благодарен за любые дополнения и правки!

Под капотом

Современные песочницы используют три основных подхода к изоляции:

1. MicroVM (микровиртуальные машины) — железобетонная изоляция на уровне железа
• Каждая песочница получает свой собственный kernel, память и виртуальные устройства
• Аппаратная граница между гостевым кодом и хост-системой
• Запуск за 125-200мс благодаря Firecracker и libkrun
• Используют: e2b, microsandbox, Fly.io

2. Application Kernels (прикладные ядра) — промежуточный уровень
• Перехватывают системные вызовы в userspace
• gVisor от Google перехватывает syscalls до хост-ядра
• Не требует аппаратной виртуализации
• Используют: Google Cloud Run, App Engine

3. Language Runtimes (языковые рантаймы) — максимальная скорость
• WebAssembly с изолированной памятью и capability-based security
• V8 Isolates для JavaScript
• Запуск за миллисекунды, но ограниченная совместимость (например, v8 - это только исполнение js кода)
• Используют: Cloudflare Workers, Deno Deploy

Контейнеризация vs MicroVM

Контейнеры (в т.ч. Docker, хотя сам по себе докер довольно тяжеловесен местами):
✅ Запуск за миллисекунды
✅ Минимальные накладные расходы
✅ Зрелая экосистема
❌ Общий kernel = потенциальные уязвимости

MicroVM:
✅ Аппаратная изоляция на уровне железа
✅ Собственный kernel для каждой песочницы
✅ Неуязвимы к container escape атакам
❌ Больше накладных расходов
❌ Требует поддержки аппаратной виртуализации

Вывод: Используйте контейнеры для доверенного кода, MicroVM — для недоверенного.

🏆 Топ 3 решения для селф-хостинга песочниц

microsandbox — максимально лёгкий и быстрый
• Технология: libkrun (MicroVM)
• Лицензия: Apache-2.0
• Язык: Rust
• Запуск: <200мс
• Идеален для: железобетонной изоляции + скорость запуска песочниц сравнима с запуском контейнеров

e2b — платформа для AI-агентов
• Технология: Firecracker (MicroVM)
• Лицензия: Apache-2.0
• Язык: TypeScript/JavaScript
• Запуск: <150мс
• Идеален для: AI-агентов и долгосрочных задач

Daytona — полноценная среда разработки
• Технология: OCI/Docker контейнеры
• Лицензия: AGPL-3.0
• Язык: Go
• Запуск: <100мс
• Идеален для: долгосрочных проектов с сохранением состояния

Эти три селф-хост инструмента покрывают почти любые задачи по безопасному выполнению AI-кода. На мой взгляд, именно за ними будущее AI-инфраструктуры - особенно мне импонирует microsandbox - небольшой проект без венчурного инвестирования, при этом правильная технология под капотом, и достаточное количество звезд и коммитов на Гитхабе.


А вот SaaS в смежных областях, с закрытыми технологиями под капотом:
• WebContainers (классная вещь, используется в Bolt - nodejs исполняемый в вашем браузере!!! Wasm)
• Replit
• Cloudflare Workers (V8 Isolates)
• Fly.io (у них классный блог, рекомендую: https://fly.io/blog/)
• CodeSandbox

На десерт: пишем свой Lovable с помощью Claude Code https://youtu.be/_GMtx9EsIKU

Одна из сильных сторон Claude Code - он способен продолжать длительную работу в режиме агента, даже когда LLM модель постоянно отлетает, или интернет уходит в оффлайн. Работаю над длинным лонгридом сидя в горах на слабом интернете, и даже тут - получается что-то выжать из CC, с Курсором это получается хуже. Обратите внимание что реализован exponential backoff - каждая следующая попытка достучатьс до API - с бОльшим таймаутом. Показывает, что у команды CC было время про это подумать (в отличие от).

обновил 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, прогресс в проектах нормальный идет, только если “бью себя по рукам”, и концентрируюсь на одной очень конкретной задаче, использую минимальное количество новых технических решений, когда беру старые добрые фреймворки, которые я знаю вдоль и поперёк. Фокус решает - и тут ничего не поменялось за последние годы.