Этот кейс важен для меня не из-за формулировки «за одну ночь». Скорость сама по себе ничего не значит, если на выходе получается одноразовый экран. Здесь было важнее другое: собрать сайт так, чтобы он жил дальше как нормальная система — с понятной архитектурой, управляемой публикацией и реальным рабочим контуром.
Речь идёт именно про этот сайт — pimenov.ai, на котором расположен сам лендинг. Я держал продуктовую рамку и решения, один агент помогал с архитектурой и ревью, второй собирал код, конфигурацию и серверную механику. В результате мы получили не временный лендинг, а быстрый сайт на Astro, где Notion работает как CMS, GitHub держит дисциплину изменений, а VPS закрывает сборку и выпуск обновлений.
Команда
Я + 2 ИИ-агента
Не абстрактный чат, а связка ролей: product owner, архитектор/reviewer и builder-агент.
Стек
Astro + Notion + VPS
Быстрый статический слой, привычная CMS и нормальная серверная среда вместо конструктора.
Результат
Рабочий контур публикации
Контент, изображения, код и выпуск обновлений собраны в одну предсказуемую систему.
Исходная задача
Мне нужен был не просто новый личный сайт, а понятный контур, где контент можно вести в привычной среде, а сама публикация не превращается в отдельную вторую работу.
Мне нужен был личный сайт про ИИ, продукты и системную сборку, но без сценария, где ради этого снова появляется мини-студия, лишние созвоны и постоянная перегрузка по вниманию.
Мне важен был не только внешний вид, но и способ жизни сайта после запуска: чтобы контентом было удобно управлять, а обновления шли по логике системы, а не через постоянную ручную возню.
Подход
Скорость пришла не из магии и не из промпта «сделай сайт». Она пришла из того, что у каждого участника была своя зона ответственности, а сама задача была сужена до реального полезного контура.
Я задавал направление, держал продуктовый замысел, принимал ключевые решения и отсеивал всё, что усложняло систему без реальной пользы.
Он помогал с рамкой, декомпозицией, порядком в архитектуре и качеством решений. Его задача была не писать код, а держать систему в собранном состоянии.
Он работал на VPS: собирал код, правил конфиги, проверял сборку, закрывал инфраструктурные детали и доводил техническую часть до рабочего результата.
Архитектура
Суть кейса не в романтике «сайт появился за ночь», а в том, что у него сразу была инженерная логика: контент, код, изображения, сервер и публикация были связаны между собой, а не жили отдельными кусками.
Для контентного сайта нам нужен был быстрый статический фреймворк без лишнего runtime. Astro здесь был точным выбором под задачу, а не декоративным решением ради модного стека.
Контент живёт там, где мне действительно удобно думать и работать. Не отдельная админка рядом с жизнью, а привычное пространство, из которого сайт собирается как часть общего процесса.
Код, правки, история изменений и сборочный контур шли через нормальный репозиторный процесс, а не через хаотичные ручные действия прямо на сервере.
Мы собирали сайт сразу в тех условиях, где он должен жить дальше. За счёт этого технические ограничения и риски проявлялись сразу, а не после формального «готово».
Изображения нельзя было оставлять временными ссылками и ручным хаосом. Поэтому мы собрали нормальный слой хранения, оптимизации и предсказуемой работы медиа по всему сайту.
Важно было не просто один раз собрать сайт, а сделать так, чтобы дальше статьи, страницы и обновления выходили по понятному процессу без ручной рассыпухи.
Процесс
Это не история про автономию ради автономии. Это управляемый процесс, где человек держит направление, а агенты закрывают архитектурную и исполнительскую глубину.
Техническая сила
Для меня важен не сам факт ночной сборки, а то, что результат не рассыпается при первом же продолжении работы. Именно это отличает рабочий продукт от красивого эксперимента.
Контент, код, медиа и публикация не были разорваны между разными логиками. За счёт этого сайт получился собранным не только визуально, но и операционно.
Мы не переносили техническую правду на потом. Всё, что могло сломаться в реальной среде, проверялось в процессе сборки, а не после показательного релиза.
Сила проекта не в конкретных названиях сервисов, а в том, что каждый слой выбрался под реальную задачу. Под другой процесс стек может быть другим, а принцип останется тем же.
После первой сборки не начинается новая ручная жизнь. Наоборот: появляется база, на которую дальше можно наслаивать контент, схемы, разделы, автоматизацию и новые сервисные контуры.
Практическая ценность
Для меня главный результат здесь в том, что стал виден более общий принцип: маленькие и средние digital-системы можно собирать не классической студией и не вокруг абстрактного ИИ-бота, а через управляемую связку человека, ролей и интеграций под конкретный процесс.
По той же логике можно собирать внутренние кабинеты, базы знаний, контентные системы, сервисные панели, маршруты обработки заявок и другие рабочие контуры, если у задачи есть ясная структура.
Один агент может держать архитектуру и ревью, второй — делать руками, а человек остаётся точкой смысла и финального решения. Это даёт ускорение без потери управляемости.
Notion, GitHub, VPS, Telegram, базы данных, CMS, CRM, внутренние панели — всё это можно собирать в один контур, если интеграции подчинены процессу, а не добавлены ради эффекта.
Да, здесь было быстро. Но по-настоящему ценно другое: после первой сборки остаётся не хрупкий результат, а система, которую можно расширять и использовать в реальной работе.
Источник
Если нужен полный рассказ про архитектурные выборы, ночные баги, сборку image pipeline, Notion как CMS и весь путь шаг за шагом, лучше открыть исходную статью, на которой основан этот кейс.
Кейсы
Кейс
Автономный контур синка транскриптов из Plaud в Notion с дедупликацией, миграцией структуры данных и рабочим UX.
Открыть →Кейс
Notion как центр управления задачами, где три ИИ-агента закрывают планирование, реализацию и проверку результата.
Открыть →Кейс
Контентный pipeline, где сырьё из Telegram, соцсетей и закладок превращается в черновики сайта через Notion-агента.
Открыть →Я не начинаю с готового рецепта и не предлагаю всем одинаковую схему. Сначала смотрю, где у вас реально живёт контекст, как движется работа, кто принимает решения и какие интеграции действительно усиливают процесс. После этого мы собираем подходящий контур: с нужными ролями, стеком, маршрутом публикации, автоматизацией и той технической глубиной, которая оправдана именно вашей задачей.