Инженерный блог

Как платформа устроена на самом деле.

Глубоко технические разборы для инженеров — байты в проводе, LSN и функции, которые делают всю работу. Без маркетинговой воды.

Start here

Most AI app builders stop at the preview. What production actually demands — and the architecture that answers it.

Part 1ArchitectureAI-agentsKubernetes

Анатомия платформы для AI-приложений, которая доходит до продакшена

Превратить промпт в работающий продукт — это задача не про модель, а про систему. Перед вами карта всей машины: как сообщение в чате становится изолированной нагрузкой в Kubernetes с собственной веткой Postgres, масштабируемой до нуля; почему работу агента оценивают компиляторы и живые пробы, а не его собственное мнение; и как релиз превращается в продвижение ветки базы данных с якорем для отката. Каждый другой пост в этом блоге разбирает один из блоков этой схемы крупным планом.

14 июня 2026 г. 7 min read

Part 2ProductArchitectureAI-agents

Превью — это ещё не продукт

Любой ИИ-конструктор приложений покажет вам работающее превью через считанные минуты после промпта — генерация стала простой частью. Продукт — это всё то, что должно выдержать нагрузку после того, как в приложение зайдёт незнакомый человек: деплои, которые не трогают его данные, откат, который что-то значит, секреты, которые никто не вставлял руками, нулевая стоимость простоя и история восстановления для каждого способа, которым может умереть сборка. Это обзор той самой пропасти и проектной позиции, которая её закрывает: агент имеет право ошибаться; платформа — нет.

14 июня 2026 г. 4 min read

Part 3ProductAI-agentsArchitecture

Жизнь приложения, написанного за выходные

Один вечер пятницы, один небрежный абзац про таблицу с расходами на горнолыжную поездку — и платформа, которая делает всё то, что демо никогда не показывает. Это правдивая история одного приложения: реальные промпты, реальные временные метки, реальные деньги — от первого сообщения до проверенного, замороженного, ничего не стоящего приложения. Каждая остановка на таймлайне — это дверь в механику, благодаря которой всё прошло буднично и без сюрпризов.

14 июня 2026 г. 7 min read

Part 4ProductArchitectureDeployment

Adorable против Lovable, v0, Bolt и Replit: где на самом деле работает ваш бэкенд

Любой AI-конструктор приложений сегодня умеет сгенерировать рабочее full-stack-приложение. Категория сошлась на лёгких 80%. Что по-прежнему различает эти инструменты — три вопроса, которых нет ни на одном лендинге: где физически выполняется код вашего бэкенда, что деплой делает с вашими данными и сколько движущихся частей — сервисов и приложений — может уместить один проект. Если мерить по этим осям Lovable, v0, Bolt, Replit и нас, поле раскалывается так, как таблицы фич это скрывают.

15 июня 2026 г. 9 min read

The database

Copy-on-write Postgres branches, scale-to-zero compute, deploys as branch promotions, and time-travel for the data an agent can break.

Part 1ArchitecturePostgresNeon

Почему Postgres с разделёнными storage и compute — правильная база данных для AI-агентов

Базы данных больше создаёт не человек, заполняющий форму на провижининг, — это делает агент, поднимающий сотни короткоживущих и почти всё время простаивающих баз. Такая нагрузка ломает предпосылки, на которых строится традиционный подход «один Postgres на приложение». Вот почему разделение storage и compute с branching по принципу копирования при записи и масштабированием до нуля — это архитектура, которая действительно подходит, разобранная примитив за примитивом в проекции на то, что делают агенты.

14 июня 2026 г. 8 min read

Part 2ArchitecturePostgresRust

Postgres с масштабированием до нуля: Rust-прокси, который будит базу прямо посреди подключения

Каждое приложение на платформе получает собственный Postgres, который ничего не стоит, пока простаивает — compute масштабируется до нуля. Весь фокус в том, чтобы прозрачно разбудить его на следующем подключении: Rust-прокси говорит на wire-протоколе Postgres, паркует клиента, масштабирует K8s Deployment 0→1 и пробрасывает запрос, как только база поднялась. Разберём парсинг wire-протокола, single-flight-пробуждение и дисциплину регистрации на tokio Notify, которая держит пробуждение корректным при конкурентном доступе.

14 июня 2026 г. 8 min read

Part 3ArchitecturePostgresNeon

Путешествие во времени для кода И данных: как откатить ошибки ИИ-агента в базе данных

ИИ-агент уверенно выполнит миграцию, которая удалит не ту колонку. Git даёт undo для кода — а для данных не даёт ничто. Вот как устроено путешествие во времени для кода и данных поверх Postgres-таймлайнов с копированием при записи: чекпойнт по LSN, восстановление через copy-on-write и согласованность кеша, благодаря которой repoint compute остаётся корректным.

14 июня 2026 г. 7 min read

Part 4ProductPostgresNeon

Даём агенту кнопку «отменить» для ваших данных

AI-агент, который собирает ваше приложение, заодно прогоняет миграции, массовые правки и сидинг — деструктивные операции, которые git отменить не может, потому что git версионирует только код. Поэтому мы дали агенту отмену данных, которой он управляет сам: он делает снимок перед рискованной операцией и откатывается, если операция ломает данные. Разбираем, как это работает на Postgres с копированием при записи, почему восстановление сохраняет ту же строку подключения и почему целый флот таких приложений ничего не стоит, пока простаивает.

14 июня 2026 г. 5 min read

Part 5ArchitecturePostgresNeon

Деплой — это перевод ветки в продакшн, а не миграция

Выкатка в продакшн обычно означает перенос данных: снять дамп с dev, восстановить его в отдельной прод-базе, прогнать миграции и надеяться, что окружения не разошлись. На таймлайнах Postgres с копированием при записи всё устроено иначе — продакшн это ветка, а выход в продакшн это перевод ветки в продакшн. Байты не перемещаются: продакшн форкается от head ветки dev, повторные деплои продвигают продакшн и применяют только ожидающие миграции, откат — это ветка на момент времени, и каждое окружение масштабируется до нуля независимо. Вот модель и её механика.

14 июня 2026 г. 6 min read

Part 6ArchitectureGitKubernetes

Что откату позволено удалять

Откат через путешествие во времени должен привести проект в согласованное состояние сразу в трёх очень разных хранилищах: git-исходниках, живом рантайме Kubernetes и общей ветке Postgres. Интересен не вопрос «как восстановить», а вопрос «что именно нам позволено физически удалить и как при этом остаться обратимыми?» Ответ — единственный инвариант: удаляем только то, что либо восстановимо из истории git, либо регенерируется из спеки, а единственный реляционный якорь, который их связывает, мягко архивируем.

14 июня 2026 г. 8 min read

The model

Which LLM drives the agent, how it's routed per task, and why a real bug is a truer benchmark than a leaderboard.

Part 1AI-agentsBenchmarkingModel-routing

Реальный баг — более честный бенчмарк, чем любая таблица лидеров

Каждая модель выходит с цифрами из таблиц лидеров. Они измеряют дедуктивные головоломки, решаемые с одного захода, — и почти ничего не говорят о том, как модель ведёт себя, когда застряла на настоящей проблеме внутри живой системы. Нам выпал незапланированный поединок один на один: один и тот же промпт, один и тот же сломанный файл, одно и то же работающее приложение, две модели. Одна сожгла весь свой бюджет за 51 шаг, заново выводя векторные произведения вручную, и так и не починила баг; другая починила его за 19. Разрыв был не в чистом интеллекте. Он был в *стратегии поведения в тупике*, — а баг по случайности оказался сконструирован так, чтобы измерить ровно это.

12 июня 2026 г. 14 min read

The runtime

A Kubernetes namespace per app: isolation, lifecycle, secrets, custom domains — the day-2 operations nobody demos.

Part 1ArchitectureMulti-appKubernetes

Гравитация основного приложения

Проект на этой платформе — это не одно приложение и один стек, а N изолированных приложений и M сервисов, делящих один namespace в Kubernetes, и всё это разворачивается из сообщения в чате. Стоит это допустить — и почти каждый баг начинает рифмоваться: «новое соседнее приложение» молча схлопывается обратно в основное. Это рассказ о том, почему так происходит снова и снова, о единственном принципе, который чинит весь класс этих багов — сходиться к объявленному состоянию в одной контрольной точке и падать с отказом вместо отката к основному приложению, — и о том, как тот же принцип, прокрученный в обратную сторону, позволяет нам путешествовать во времени со всем стеком сразу (код в git, данные в общей ветке Neon и живая инфраструктура K8s) обратно в один согласованный момент.

14 июня 2026 г. 13 min read

Part 2ArchitectureKubernetesLinux

Как усыпить тысячу простаивающих приложений: KEDA, CRIU и freezer cgroup v2

Каждое приложение на платформе должно стоить ноль, пока на него никто не смотрит, — и мгновенно оживать, когда кто-то заходит. Мы выбрали контейнеры вместо микро-VM, а затем перепробовали три способа сделать простой бесплатным: масштабирование до нуля через KEDA, checkpoint/restore через CRIU и, наконец, freezer cgroup v2 с вытеснением в swap. Первые два очень по-разному показали нам, в чём на самом деле было ограничение. Это хроника экспериментов, режимов отказа, на которые мы наткнулись, и той архитектуры, что в итоге выжила.

14 июня 2026 г. 13 min read