Как я потерял несколько лет, делая всё кроме главного — и что с этим сделал

Эта статья про две вещи. Сначала зачем: годы прокрастинации, иллюзия занятости и простая механика, которая это сломала. Потом как: 35-й вайбкодинг-проект за 10 месяцев, событийная архитектура, 39 коммитов за 3 недели, TypeScript, Playwright, LLM и деплой на двухъядерный VDS.

На Хабре вышла [статья Эдуарда Ланчева] — честная история, как один человек за 3 месяца с помощью ИИ собрал полноценный шахматный сервис. У меня похожая. Только не про шахматы, а про предпринимательство. И не 100 тысяч строк, а 9 500 — но с event store, инвариантами и Prometheus на проде.

Часть 1. Медоборудование, прокрастинация и иллюзия занятости

Потерянные годы

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

Казалось бы, что сложного.

Я не продавал.

Вместо этого: маркетинговые материалы, поиск уникального оборудования, изучение конкурентов, чтение про отрасль, прокрастинация. Классика жанра. Всё это ощущалось как работа: занят, устал, лёг спать с чувством, что что-то делал. Но денег не было, потому что без продаж денег не бывает.

Самое неприятное: не было момента осознания, не было точки, чтобы посмотреть в зеркало и сказать: «окей, ты избегаешь главного». Просто отсутствие прогресса накапливалось, доходило до критической точки — тогда начиналось шевеление, минимальный результат, и всё возвращалось на «круги своя».

Я потерял несколько лет. Единственный вывод: что-то подсознательно избегалось.

Другие проекты — та же история

Прошло время. Новые проекты, другая сфера. И всё повторилось.

Снова, что угодно, кроме того, что действительно двигало бизнес вперёд. Допиливал продукт бесконечно, перескакивал между проектами, находил причины, почему «сегодня не лучший день», и проводил его в телефоне.

Вот что интересно: на своё хобби, музыку — у меня этого паттерна нет. Никакого «не хочется», никакого «надо сначала подготовиться». Просто сажусь и делаю.

Значит, дело не в лени.

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

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

Механика, которая сработала

Родилась простая практика, сначала вручную, в ChatGPT. Три точки контакта в неделю: приоритет в начале, короткая рефлексия каждый вечер, честный срез в конце. Через месяц впервые стали видны паттерны, и появилось реальное движение. Не хождение по кругу, а результат.

Но ChatGPT не помнит предыдущих разговоров в очень длинном чате. Контекст копился, требования терялись. Так родилась идея бота, который ведёт этот процесс сам.

Появилась задача. Дальше — как она решалась и что для этого пришлось освоить.

Часть 2. С чего начинается вайбкодер

Мечта стать программистом, диплом с отличием, работа на C++ и скука

ТУСУР, диплом инженера-разработчика. Работа в Инком в Томске в 2008-м. Код правильный, архитектура нормальная, но ощущение одно: слишком долго. Чтобы сделать что-то настоящее, нужно годами работать в команде, постепенно наращивая контекст. Мне это не подходило, оказалось скучно, и профиль сменился на продажи на целых 15 лет.

Госпиталь, коляска и первый скрипт

Первый вайбкодинг случился 10 месяцев назад, в госпитале. Всё время свободное. Коляска, по 6-8 часов на улице, лето, ноутбук на коленях. Вокруг от 5 до 15 друзей в тени большой яблони на территории учреждения. Было увлекательно и весело.

Первый рабочий результат — скрипт генерации пакета документации через OpenAI API: оглавление, промпт, сборка в единый документ. Простая утилита. Но именно она показала главное: ИИ умеет делать то, что ты не умеешь, если ты знаешь, что попросить.

С тех пор пришло умение:

— формулировать архитектуру до кода;

— дебажить по логам, а не по интуиции;

— промптить точно, а не абстрактно;

— деплоить и оптимизировать на дешёвом железе.

Founder Mode — мой 35-й проект за это время.

Часть 3. Что такое Founder Mode

Founder Mode — это бот-спутник для фаундеров. Мессенджер-бот, который ведёт тот самый алгоритм из Части 1, но без потери контекста, с карточками и ритмом.

Недельный цикл

Понедельник: /declaration → Приоритет недели (фокус, почему сейчас, результат, провал)

Пн–Вс: /fixation → Фиксация дня (было движение? что продвинуло? что остановило?)

Конец недели: /report → Недельный срез (LLM обобщает неделю в честный итог)

В любой день: /change → Смена приоритета (с причиной, 1 раз за неделю)

Каждый шаг генерирует карточку — HTML-шаблон с аватаром, бейджем ритма и авто-масштабируемым текстом, который Playwright рендерит в PNG.

Неожиданный эффект: публичность

Личное убеждение: юридическое лицо не может быть не публичным. Карточки бота начали уходить в Telegram-группу и сторис VK — как публичный след основателя.

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

Три результата, которые подтвердили архитектуру

При живом использовании стало видно, ради чего вся эта инженерия:

1. Факт вместо ощущения — event store фиксирует движение или его отсутствие. Не «я работал», а конкретная запись в daily_fixations.

2. Дистанция накапливается — ритм, недельные срезы и фиксации по дням лежат в read models: можно сравнивать недели и видеть провалы без движения.

3. Синтез текста через LLM — модель по промпту сжимает уже введённые данные в связный текст — итог недели, формулировку приоритета, карточку дня — без добавления фактов, которых не было во входе. Это важно для публикации карточек в свет.

Куда это может развиваться. Поверх тех же событий и полей внимания (attention_sink, what_stopped, ветки движения) перспективны агрегаты по календарю (дни недели, сезоны), ранние сигналы при просадке ритма, группировка повторяющихся тем в «что остановило» и «куда ушло внимание», персональные подсказки после длинной истории, без выдумывания: только из накопленных фиксаций и явных правил или контролируемого LLM-слоя поверх сводок; интеграция и управление внешними «трекерами задач».

«Ритм» — формула движения

Отдельная гордость проекта. Ритм (0–100) считается по формуле с тремя компонентами и весами:

Ритм — не оценка личности. Это темп и управляемость. Если ритм падает, бот не ругает, но на карточке это видно.

Часть 4. Архитектура: от методологии к коду

Possibility-Driven Architecture

Прежде чем писать строчку кода, появилась архитектурная методология, Possibility-Driven Architecture (PDA). Документ на 484 строки, 8 шагов проектирования, от карты неопределённости до стабилизации констант.

Главная идея PDA: события фиксируют факты, домен обеспечивает инварианты, проекции оптимизируют чтение. Политики устойчивости — отдельный слой, а не размазаны по коду.

Для Founder Mode это значит:

Инварианты — физика системы

Инварианты фиксировались до разработки. Каждый имеет код и механизм обеспечения:

Стек

Схема потока

Как это устроено в коде: хэндлер после пользовательского действия вызывает доменный сервис; сервис при необходимости дергает валидаторы (domain/validators.ts), LLM и вспомогательные функции. Успешная команда → eventStore.append → проекторы обновляют read models. Затем (в том же хэндлере) рендер карточки: *-card-render.ts + card-render-shared → Playwright → PNG; при отрисовке rhythm-card читает фиксации/отчёты и делает upsert в rhythm_snapshots — эта таблица не заполняется проектором событий. Параллельно основному потоку сообщений работает scheduler/notifications (cron) и по желанию шлёт напоминания через тот же transport.

Часть 5. Цифры из Git

Вся разработка велась в одном репозитории. Вот объективные данные.

Хронология по коммитам

Дифф за историю: что переписывалось

31K добавленных строк и 16K удалённых, при финальных 9.5K чистого кода. Это значит, что код переписывался в среднем 3 раза. Рефакторинги были существенными: reflection → fixation, plan → declaration, отдельные карточки → 3 шаблона с layout presets, 7 миграций → 1 консолидированная. Это был полезный опыт.

Часть 6. Инструменты и процесс

Связка

Процесс: ставил opus 4.6, генерил план, на auto вёл разработку проекта. Потом поиск несогласованностей и рефакторинг. Когда сам пользовался продуктом — дорабатывал пайплайн и UX, искал лучшие решения.

Что появлялось «как по рельсам»

TODO → хэндлеры → миграции → тесты → онбординг → уведомления → настройки → наблюдаемость → замена flow → промпты → HTML-карточки → рендеринг → аватары → ритм по формуле → автомасштаб карточек → бейджи → вебхук.

Параллельно

Founder Mode не единственный проект. Параллельно: foodtech, встречи по гранту, автоматизация компактной домашней теплицы.

Часть 7. Где образование спасло

1. Event Store с идемпотентностью

Без понимания транзакций и advisory locks невозможно понять, зачем pg_advisory_xact_lock(42, hashtext($1)) в event-store.ts. ИИ генерировал код, но решение использовать advisory lock вместо ON CONFLICT для append-only лога было архитектурным, а не синтаксическим.

2. Проекторы (CQRS-lite)

Разделение записи (events) и чтения (проекции в 6 таблиц: пять доменных read models + users) — не то, что ИИ предложит с первого промпта. Это решение из PDA-методологии, оно требует понимания того, что проекция — это производная от факта, а не сам факт.

3. Формула ритма

Три компонента с весами, нормализация 0–1, порог stability streak — это не «попросил ИИ придумать метрику». Это инженерный расчёт: какие веса дают осмысленный диапазон, при каком streak стабильность обнуляется, почему missing день = no (а не 0).

Где образование мешало

Перфекционизм. Методология на 484 строки перед первым коммитом — это, конечно, красиво. Но полный рефакторинг reflection → fixation → declaration за 3 дня — это тоже следствие того, что «хотел сделать правильно» до того, как понял, что именно правильно.

Часть 8. Интеграция с MAX: неприятное

Сначала Founder Mode работал только в Telegram. Затем появились новости о возможном блоке Telegram в России за неисполнение законов. Пришлось добавлять транспорт на MAX (VK-мессенджер).

MAX — самое неприятное интеграционное ограничение в проекте:

— документация MAX API минимальна;

— формат апдейтов непредсказуем: user_id может быть на 4 разных уровнях вложенности объекта;

— аватары: нужно пробовать 5 разных URL-паттернов (chat members, profile, fallback), с авторизацией и без, и пока не доступны по API MAX;

— display name: кешируется в сессии, потому что callback-апдейты не всегда содержат sender;

— карточка в МАХ выглядит неполноценно в UI desktop-клиента мессенджера.

Самописный max-adapter.ts — 510 строк чистого адаптерного кода. Это больше, чем весь Telegram-транспорт. Но результат: один dispatch.ts, два транспорта, одна кодовая база хэндлеров.

Часть 9. Тесты и документация при ИИ-разработке

27 тест-файлов. Зачем?

При ИИ-разработке тесты — это единственная страховка от регрессий. Когда модель на auto генерирует рефакторинг 15 файлов за один коммит, ты физически не можешь проверить каждую строку. Тесты проверяют за тебя.

Самые ценные тесты в проекте:

— services.test.ts (480 строк) — полный цикл: declaration → fixation → report, с моком LLM, реальной PostgreSQL, проверкой инвариантов (INV-001, INV-004);

— projectors.test.ts — каждый тип события проецируется в правильную read-model таблицу;

— rhythm-score.test.ts — формула ритма выдаёт ожидаемые значения на граничных случаях.

Документация: PDA + промпты

В проекте осталось два типа документации:

1. Архитектурная — Possibility-Driven_Architecture_Methodology.md (484 строки): методология, канвасы, чек-листы, антипаттерны.

2. Промпты LLM — 4 файла в src/llm/prompts/, каждый — системный промпт для соответствующей карточки. Промпты лаконичные (25–35 строк), стиль: «конкретно, без пафоса, без эмодзи, не выдумывай факты».

Часть 10. Схема базы данных — 11 таблиц

Единая консолидированная миграция 001_init.sql (166 строк) содержит:

Часть 11. Вайбкодинг, ИИ-разработка или гибрид?

Если честно — гибрид.

Вайбкодинг — это начало: «попробуй, запусти, посмотри что получится». Так собирались первые 34 проекта. Так начинался и Founder Mode — из ручной практики в ChatGPT, которая помогла перестать терять годы на иллюзию занятости.

Но проект быстро перерос вайбкодинг, когда появились:

— инварианты, которые нельзя нарушать;

— event store с транзакционной идемпотентностью;

— два транспорта с единым dispatch;

— 27 тест-файлов;

— Prometheus + Grafana на продакшене;

— формула ритма с весами и нормализациями.

Это уже не «пробую на вайбе». Это инженерная работа, усиленная ИИ. Разница в ответственности за архитектуру: модель не знает, какие инварианты важны для твоего домена. Это знаешь ты.

За год, что я знаком с Cursor, агенты и модели сделали огромный скачок. Убеждён — дальше будет полный переворот — сложность входа в разработку станет минимальной.

Итог в цифрах

Для тех, кто хочет повторить

Одна фраза: просто пробовать делать свои идеи.

Не читать курс. Не ждать идеальную модель. Не копить деньги на команду. Взять ноутбук, открыть Cursor, описать, что хочешь — и начать. Все проекты до этого научили меня больше, чем любой учебник.

Инструменты стали достаточно хорошими, чтобы один человек мог собрать продукт. Но они всё ещё недостаточно хороши, чтобы это было без усилий. Разрыв между «попробовал» и «работает в проде» — это и есть инженерия. Просто теперь она доступна каждому, кто готов учиться на ходу.

Попробовать Founder Mode

Мой бот для тех, кто сам себе CEO и чувствует, что занят, но не двигается. Если есть руководитель с задачами и проверкой результата — внешняя структура уже есть. Если нет, её нужно создавать самому.

Бот бесплатный, занимает меньше минуты в день: [⇾ в Telegram] · [⇾ в MAX]