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

Когда пора уходить с 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 агента будет по собственному желанию замерять на _достаточном_ объеме тестов, это же такой геморрой? Так что - рекомендую поучаствовать. Это, на всякий случай, не реклама, а рекомендация от души.