Production начинается там, где заканчивается вайбкодинг

В 2013 году мне казалось, что я отлично зарабатываю.

Я уже около года фрилансил и получал что‑то порядка 100–120 тысяч рублей в месяц. Для того времени — очень неплохо.

В голове математика ^[1] была простая: аренда квартиры — около 25к, еда — около 15к.

Значит, живу примерно на 40–50к, а всё остальное — свободные деньги.

Поэтому покупка машины в кредит казалась нормальной идеей.

Проблема была только в том, что я считал очень оптимистично.

Я не учёл платную заочку. Не учёл лечение зубов, на которое как раз попал. И, конечно, не учёл, что машина — это не только ежемесячный платёж.

Это ещё ОСАГО, ТО, постановка на учёт, бензин, резина и десятки мелких расходов, которые почему‑то не спрашивают, есть ли они в твоей финансовой модели.

А кредит под ~30% годовых довольно быстро превращает:

«машину за 530 тысяч»

в

«миллион, который ты будешь выплачивать сильно дольше, чем планировал».

Тогда я впервые понял, что:

«много зарабатывать» и «понимать свои деньги» — вообще не одно и то же.

---

Как Google Sheets превратилась в систему принятия решений

Сначала это была обычная Google‑таблица.

Потом в ней появился план/факт, прогноз по месяцам, обязательные траты, сценарии крупных покупок и понимание кассовых разрывов.

И вот тут внезапно выяснилось, что самые неприятные расходы — не ежедневные.

А те, про которые все забывают ^[2]: налог на авто, отпуск, годовые подписки, обслуживание и любые платежи формата «раз в год, но зато больно».

Один такой месяц мог спокойно развалить весь баланс, если заранее его не учитывать.

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

Но в какой‑то момент меня начала раздражать сама таблица.

Любая новая категория — это правка формул. Любая реорганизация — риск случайно сломать суммаризацию.

А ошибку ^[3] можно заметить сильно позже, когда в прогнозе внезапно появляется кассовый разрыв, которого «не должно было быть».

И вот тут я решил:

«Ладно. Сейчас AI всё быстро накодит».

---

И самое неприятное — интернет не врал

На тот момент я использовал Codex 5.2, GPT и spec‑kit.

И первая версия действительно собралась за пару вечеров.

Она повторяла логику ^[4] таблицы, убирала боль ^[5] с формулами, выглядела как настоящее приложение и действительно работала.

Правда, всё это работало только локально, на одном устройстве и с хранением данных прямо в браузере.

Но после Google Sheets это всё равно ощущалось как магия.

Я тогда реально стал тем человеком из AI‑постов:

«LLM меняют разработку».

Потому что на этапе демки — они действительно её меняют.

И вот это, как мне кажется, главный источник сегодняшнего AI‑вайбкодинга.

Проблема в том, что между:

«смотрите, оно работает»

и

«этим можно нормально пользоваться каждый день»

находится огромная инженерная пропасть.

---

Local‑first оказался не фичей, а архитектурной проблемой

Изначально всё было просто: данные лежат локально в IndexedDB.

Когда появился backend, самый очевидный путь был — переписать всё на server‑first.

Но UX сразу становился хуже.

Финансовое приложение должно позволять быстро записать расход даже когда сеть плохая или backend лежит.

Поэтому local‑first слой пришлось оставить.

В итоге получился гибрид: UI работает из IndexedDB, изменения складываются в outbox, sync worker отправляет typed mutations на backend, а backend валидирует изменения и возвращает server version.

И вот тут начинаются вещи, которых не видно в демке: конфликты изменений, версии сущностей, курсоры синхронизации, идемпотентность запросов, shared‑доступ к бюджетам и постоянная борьба с рассинхронизацией кэша.

---

В какой‑то момент внезапно появляются законы

И это был момент, когда пет-проект внезапно начал превращаться в настоящий продукт.

Потому что выяснилось, что я храню уже не просто «какие‑то JSON’ы».

У меня появился логин через Yandex ID, пользовательские профили, история операций, категории, бюджеты и данные, которые вполне можно связать с конкретным человеком.

И вот тут внезапно приходит неприятное осознание:

«кажется, это уже персональные данные».

Я изначально вообще не воспринимал приложение как что‑то, попадающее в эту область.

Казалось:

«ну это же не банк и не госуслуги».

Но по факту даже связка логина через Yandex ID, пользовательского профиля, истории действий, cookie, session‑данных и auth‑токенов уже начинает попадать в область вполне реальных требований законодательства.

И это очень меняет мышление ^[6].

Потому что дальше ты начинаешь думать уже не только про фичи.

А про удаление аккаунта, отзыв сессий, хранение токенов, права доступа, последствия утечки и восстановление доступа.

И это уже совсем другой тип задач.

Потому что демка — это:

«смотрите, приложение работает».

Production — это:

«что будет, если что‑то пойдёт не так?»

---

Самое опасное в LLM — они очень убедительно генерируют техдолг

Одна из первых вещей, которую я понял:

LLM отлично оптимизируют ближайший успешный шаг.

И очень плохо чувствуют момент, когда архитектура уже начинает разваливаться.

Самый показательный пример был с мобильной версией.

В какой‑то момент AI начал решать все задачи одинаково:

«дописать ещё немного в тот же компонент».

Так один из mobile screen‑контейнеров вырос до 10 537 строк.

Внутри одновременно жили страницы, формы, фильтры, авторизация, синхронизация, финансовые расчёты и AI‑заглушки.

UI при этом продолжал выглядеть нормально.

Цена обнаружилась позже.

Любой визуальный фикс внезапно рисковал задеть бизнес‑логику, расчёты, синхронизацию или состояние экрана.

В итоге пришлось выносить мобильные компоненты, разделять view‑model, отделять UI от расчётов и добавлять golden tests.

И это был очень показательный момент.

Потому что интерфейс ещё выглядел «нормально».

А архитектура уже несколько тысяч строк как перестала быть поддерживаемой.

---

Production‑боль часто вообще не в коде

Часть проблем внезапно оказалась вообще не в приложении.

Например — Docker images.

CI при каждом merge в main собирал и пушил API, migrations, frontend, backup job и backup‑check job.

Сначала migration image был собран максимально «удобным способом» — вместе с Go toolchain.

Он работал.

Но потом оказалось, что:

• registry начинает быстро расти;

• vulnerability scanning становится дорогим;

• VM забивается Docker cache;

• deploy начинает тормозить.

В итоге migration image пришлось отдельно ужимать: только runtime, только migration binary, только SQL и ничего лишнего.

И это очень хорошо описывает разницу между:

«LLM помогла собрать»

и

«production теперь нужно эксплуатировать годами».

---

Самая большая ошибка — начать полностью доверять модели

Первые успешные результаты очень быстро создают иллюзию контроля.

Кажется:

«ну всё, теперь AI реально пишет почти production‑ready код».

А потом модель начинает уверенно утаскивать архитектуру в сторону.

Самая неприятная часть:

чтобы получить хороший технический результат, недостаточно просто написать:

«сделай красиво».

Нужно самому понимать архитектурные ограничения, компромиссы, потенциальные узкие места и то, где система может стать хрупкой.

Иначе модель начинает очень уверенно предлагать решения, которые выглядят правдоподобно, но разваливаются на реальных сценариях.

В какой‑то момент работа с LLM начала ощущаться не как:

«AI пишет проект за меня».

Скорее как управление очень быстрым разработчиком, которому постоянно нужен review.

---

AI внутри AI‑продукта оказался отдельной инженерной задачей

Самое ироничное: добавить AI в приложение оказалось неожиданно сложно.

Я думал:

«Сейчас скормлю модели финансовые данные — и она начнёт давать полезные советы».

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

«Постарайтесь меньше тратить».

В какой‑то момент стало понятно, что AI‑слой — это вообще не:

«отправим текст в модель».

Сначала backend должен посчитать агрегаты, собрать предсказуемый контекст, определить кассовые разрывы, отделить обязательные траты от разовых, ограничить горизонт прогноза, убрать слабые сигналы и только потом отдавать что‑то модели.

Потому что «умный AI-ассистент» без надёжного и проверенного источника данных очень быстро превращается в генератор уверенной финансовой ерунды.

---

AI меняет не только скорость. Он меняет ритм разработки

Самое забавное — проект не разрабатывался «полгода каждый день».

Если посмотреть на график коммитов, видно скорее серию коротких интенсивных спринтов с большими паузами между ними.

LLM действительно радикально ускоряют фазу реализации.

Если у тебя есть инженерный опыт ^[7], понятное видение продукта и понимание, куда вообще движется система,

то за неделю сейчас реально собрать MVP, на который раньше ушли бы месяцы.

Но дальше начинается совсем другая история.

Production — это уже:

• ограничения;

• инварианты;

• поддерживаемость;

• UX;

• sync;

• rollback;

• эксплуатация;

• последствия архитектурных решений.

И именно здесь исчезает магия:

«сделал SaaS за вечер».

---

И, кажется, AI делает разницу между инженерами только заметнее

Наверное, самое интересное изменение я начал замечать даже не в коде, а в людях.

Я работаю техруком, и последнее время всё чаще думаю:

«а как вообще теперь калибровать инженеров в эпоху LLM?»

Потому что объём выдачи действительно вырос.

То, что раньше делалось неделю, сейчас местами собирается за день.

Но парадокс ^[8] в том, что критерии сильного инженера почти не изменились.

LLM очень хорошо ускоряют реализацию.

Но они почти не помогают с инженерными компромиссами, эксплуатацией, отладкой и пониманием последствий архитектурных решений.

И, кажется, именно поэтому AI пока не «обнуляет» опыт и экспертизу.

Скорее наоборот — делает разницу между уровнями заметнее.

---

Что я в итоге понял

Сейчас мне даже немного смешно, насколько похожими оказались финансы и AI‑разработка.

В обоих случаях главные проблемы начинаются сильно позже первого успешного результата.

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

С AI примерно то же самое.

Демка собирается быстро.

Настоящая стоимость появляется позже: sync, rollback, техдолг, поддержка, production, последствия быстрых решений.

AI действительно радикально ускоряет старт разработки.

Но демо и production — это всё ещё две разные вселенные.

Хайповые истории не совсем врут.

Сделать SaaS за вечер — реально.

Просто между:

«смотрите, оно работает»

и

«этим можно пользоваться каждый день»

обычно находится ещё несколько месяцев инженерной работы.

И это именно та часть разработки, которую AI пока не отменил.

Собственно, результат этого эксперимента можно посмотреть здесь: financehelperai.ru ^[9]

Будет интересно почитать в комментариях, где у вас лично заканчивался «вайбкодинг» и начинался настоящий production.