Это третья часть серии. В первой я разбирал механику прокрастинации умных людей — с исследованиями, формулами, мета-анализами. Вторая была личной историей про интроверта-продавца, у которого в собственном бизнесе отказала вся внешняя конструкция, и про практику ежевечерней фиксации, которая эту конструкцию начала собирать изнутри.
Эта — про деньги. Про то, сколько мне стоило не понимать, что у меня за паттерн. И про то, что я сделал, когда наконец понял.
Сумма
Полтора миллиона рублей.
Это то, сколько я потратил на команду из пяти человек за несколько месяцев, пока пытался сделать два продукта, не умея управлять разработкой. Три разработчика, дизайнер, CGI-художник. На выходе — ноль релизов.
Это последний сюжет в длинной цепочке попыток вырваться из найма, каждая из которых заканчивалась одинаково: я обнаруживал себя через полгода с пустыми руками и не понимал, куда ушло время.
Почему команда не спасает нетехнического фаундера
Логика, по которой я нанимал команду, была простая и, как мне тогда казалось, разумная. Я не программист в активном смысле: диплом C++ двадцатилетней давности, пятнадцать лет b2b-продаж, код видел последний раз в университете. Значит, нужны люди, которые умеют. Я соберу команду, поставлю задачу, они сделают.
Собрал с запасом — чтобы всё быстро. Когда стало понятно, что быстро не получается, начал увольнять. Сначала дизайнера. Потом одного разработчика. Потом ещё. Потом ещё. Не было ни одной драмы, ни одного конфликта — просто постепенное осознание, что деньги уходят, а продукта нет.
Причина была не в людях. Люди были нормальные. Причина была во мне.
Я не умел управлять разработкой. Не понимал, что именно просить. Не мог оценить качество того, что получалось. Не мог вовремя остановить процесс, который шёл не туда, потому что не видел, что он идёт не туда. Нетехнический фаундер платит за то, чего не может проверить, — и в моём случае эта ставка оказалась равна всем полутора миллионам, потому что продукта в итоге не было.
Но честно — это не только «не умел управлять». Команда для меня была той же внешней конструкцией, которую я всю жизнь искал. Не производственный инструмент — попытка купить среду, в которой я снова буду работать под давлением: руководители, планы, клиенты, которые ждут. Только в этот раз я за неё платил сам, а она ничего от меня не требовала. Всё, что осталось, — пять зарплат в месяц и задача, которую я по-прежнему не умел описать. Я не изменил конструкцию — я пересобрал её в более дорогую версию.
Когда пришлось делать самому
После того, как разогнал команду, у меня не осталось выбора. Второго полутора миллиона у меня не было. Либо я учусь делать сам, либо закрываю всё и возвращаюсь в найм — туда, где конструкция снова будет бесплатной, но и потолок снова будет чужим.
Я выбрал первое, и выбрал не из героизма. Просто второй вариант был страшнее.
Cursor я начал плотно использовать летом 2025-го, сразу после релиза версии 1.0. Моя модель работы была примитивная: промпт, код, смотрю, что получилось, если не работает — копирую лог ошибки обратно в чат. В код я не лез из ощущения «я не буду тратить год, чтобы разбираться в каждой строке». Смотрел на имена функций, на то, как они друг друга вызывают, какие файлы создаются. Этого хватало, чтобы держать в голове структуру и замечать, когда агент собирает что-то подозрительное.
За десять месяцев я потратил на подписки и платные модели около 1500 долларов. Это звучит много, пока не поделишь полтора миллиона на эту сумму — получается коэффициент 50. За ту же сумму, которую одна зарплата одного разработчика съедала за месяц, я получил десять месяцев работы с топовыми моделями.
И было ощущение суперсилы. Промпт — код — работает. Ещё промпт — ещё код. Быстро, весело, почти без боли.
Потом проекты начали разваливаться под собственным весом.
Где вайбкодинг ломается
На старте у меня не было структуры, в которую класть то, что генерируется. Каждая новая сессия начиналась заново. Контекст терялся. Решения противоречили друг другу. Агент пишет код, я смотрю — работает. Через неделю я возвращаюсь к тому же месту, прошу доработать, и агент делает это на новых предположениях, которые не совпадают со старыми. На выходе — кодовая база, которая держится на честном слове и на том, что я пока помню, что где лежит.
Я генерировал, генерировал, генерировал — и топтался на месте.
Это был тот же паттерн иллюзии занятости, только в новой форме. Раньше я «работал над проектом» — читал рынок, оформлял презентации, не звоня клиентам. Теперь я «писал код» — запускал промпт за промптом, получая десятки файлов, ни один из которых не собирался в рабочий продукт.
Со временем я углубился в понимание архитектуры и доменной модели, производство backend. Стало понятнее, как строится стабильный софт. Появился первый деплой, попытки в маркетинг.
И вот тут произошло главное.
Spec-driven разработка и честная работа с собственным вектором — это один и тот же цикл. Сначала формулировка. Потом движение. Потом сверка. Разница только в объекте: в одном случае — код, в другом — твоя жизнь. Человек без спецификации на собственную жизнь — тот же агент без ТЗ: генерирует активность, пока задачи не начнут противоречить друг другу, ресурс не кончится, а продукта всё ещё не будет.
Founder Mode: 39 коммитов за три недели
Когда я это понял, сел писать то, что потом стало называться Founder Mode. Впервые — по-инженерному: сначала спецификация на 484 строки, потом инварианты, потом архитектурные решения, и только потом код. Я пришёл к этому сам — методом проб, через поломанные проекты. Несколько дней назад узнал, что у этого подхода уже есть название — vibepp, и есть комьюнити. Я не знал, что это «правильный» способ. Просто другие перестали работать.
За три недели — 39 коммитов, 16 активных дней из 21. 9 546 строк, 27 файлов тестов, event store с идемпотентностью, два транспорта (Telegram и MAX), Prometheus-метрики в проде. Это продукт, который год назад я бы нанимал команду из трёх человек собирать. Сегодня — один человек с ноутбуком на Selectel за копейки.
Этот продукт работает в проде. Я пользуюсь им каждый день.
Почему маркетинг не шёл
Я собрал Founder Mode для себя, потому что мне это было нужно. Но я сделал его ещё и для других — для фаундеров-одиночек с той же проблемой. Начал рассказывать, показывать, предлагать попробовать.
Люди заходили. Ставили приоритет. И на этом всё заканчивалось.
Не «мало лайков». Не «не поняли механику». Люди ставили какой-то приоритет — и не возвращались. Фиксация не шла. Я не понимал, в чём дело.
Потом я присмотрелся к тому, что они писали в поле «приоритет недели». И увидел: это были не приоритеты. Это были задачи, ответы на чужие ожидания, пункты из чужих планов. Что угодно, только не то, что на самом деле важно человеку прямо сейчас. Founder Mode подразумевает, что ты это знаешь. Но большинство людей — не знают. И инструмент сверки без настоящего приоритета — это пустой бланк.
Вот тогда и родился ÆON Map System. Не как красивая идея, а как ответ на конкретную поломку: человек не может пользоваться Founder Mode, если не знает своего настоящего приоритета. Значит, нужен первый этап — до всего остального.
ÆON Map System
ÆON Map System — психоэмоциональный опросник по семи слоям с ИИ в роли собеседника. Первый слой — поведение, что ты делаешь прямо сейчас. Последний — экзистенциальный, откуда вообще твои паттерны. Между ними ещё пять. Каждый следующий ставится на предыдущий, не заменяет его.
На выходе человек получает три вещи: свою сильную сторону в чёткой формулировке, свою слабую — увиденную не как недостаток, а как защитный механизм, и вектор — одно направление на ближайшие месяцы.
Его функция — сделать видимой конструкцию, с которой дальше работает инструмент ежевечерней сверки.
Я сам пришёл к этому разбору не по книгам — через несколько лет бизнеса, где «работал по десять часов в день» значило «двигался по кругу». Пока не разложил собственную конструкцию на части и не увидел, где застреваю. После этого инструменты — Founder Mode, spec-driven, что угодно — встали на свои места. До этого — нет.
Я хочу сделать этот разбор доступным не через многомесячный коучинг, а через разговор с ИИ, который ведёт по слоям и не уходит в поверхностное.
ÆON Map System сейчас в публичном репозитории. Там спецификация, сетап, по которому я работаю, и описание формата. На днях начинаю разработку.
Почему в публичном
Я мог бы закрыть ÆON — это продукт, и на нём можно зарабатывать. Но я выкладываю его открыто.
Последние месяцы я внимательно читаю Хабр в разделах про вайбкодинг, агентов, Cursor, Claude Code. Там сейчас кипит жизнь: десятки постов в неделю, люди рассказывают свои сетапы, сравнивают модели, делятся промптами. Это отличная волна, и я сам многое из неё взял.
Но я заметил одну вещь. Все эти посты — в одиночку.
Каждый сидит в своём углу со своим Cursor, своими подписками, своим продуктом, который он сам собирает по вечерам. Люди делятся опытом — но не работают вместе. Коллабораций нет. Общих сборок инструментов нет. Нет формата «двое вайбкодеров рядом друг с другом» — только «я один, я выдал пост, я жду комментов».
И я узнаю в этом свою собственную ловушку. Один человек с одним продуктом — это уязвимая конструкция. Не потому что технически не справляешься. А потому что одиночество в проекте — это отдельная проблема, которую дисциплина не решает. Её решает второй человек рядом, который идёт по той же логике, смотрит на твою работу и позволяет смотреть на свою.
Это же классика. Парное программирование, код-ревью, стендапы — всё это существует в нормальных командах не потому, что разработчики не умеют работать одни. А потому что одиночество — это налог на результат, который никто не хочет платить, когда есть выбор. У вайбкодеров-одиночек выбора пока нет, потому что формат не устоялся. Но его можно собрать.
Я публикую этот пост как первое публичное приглашение — не видел, чтобы кто-то в русскоязычном вайбкодинг-сообществе это делал до меня.
Я ищу людей, которые вайбкодят что-то своё и чувствуют ту же усталость от одиночки. Не найм. Не зарплата. Свой проект, общий ритм, общая сборка инструментов, общее поле для сверки. Один раз в день — честная сверка по тому, что важно. Один раз в неделю — срез. Всё.
Если ты читаешь это и в тебе что-то отозвалось — репозиторий в профиле. Если пошёл смотреть — это уже ответ.
Что я понял за эти десять месяцев
Две вещи.
Первое. Нетехнический фаундер с современным агентом делает работу, за которую год назад платили команде из трёх человек. Не идеально. Не без дыр в архитектуре. Но на уровне MVP — делает. И если у тебя есть соблазн потратить полтора миллиона на команду под прототип, которого пока нет, — не трать. Потрать эти деньги на год подписки и полгода времени на изучение. В худшем случае поймёшь, что не твоё. В лучшем — выйдешь с продуктом в проде и пониманием, кого именно нанимать следующим.
Второе. Любой инструмент производительности бесполезен, если ты не разобрал, с чем работаешь. Founder Mode без ÆON — пустой дневник. Spec-driven без честной формулировки приоритета — дисциплинированное топтание на месте. Команда без понимания того, что ты у неё просишь, — полтора миллиона за ноль.
Порядок важен. Сначала разбор конструкции, которая перед тобой, — свой собственный разбор, без поспешности, со всей нелёгкостью. Потом инструменты. Потом агенты. Потом скорость.
Если перепрыгнуть первый шаг — всё остальное превратится в более дорогую и более быструю версию того же круга, по которому я ходил несколько лет.
Я прыгнул. Я заплатил. Я собрал инструмент, который поможет кому-то не ошибиться дорого.
Отвечаю раз в день — потому что так устроена моя практика. Один раз в день честная сверка с тем, что важно. Этот пост тоже её часть.
Это третья часть серии. Первая — про механику прокрастинации умных людей. Вторая — личная история: мне всю жизнь говорили, что я умный, а потом я в 34 попробовал своё дело.
ссылка на оригинал статьи https://habr.com/ru/articles/1026782/