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

В голове математика была простая: аренда квартиры — около 25к, еда — около 15к. Значит, живу примерно на 40–50к, а всё остальное — свободные деньги. Поэтому покупка машины в кредит казалась нормальной идеей. Проблема была только в том, что я считал очень оптимистично.

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

А кредит под ~30% годовых довольно быстро превращает: «машину за 530 тысяч» в «миллион, который ты будешь выплачивать сильно дольше, чем планировал».

Тогда я впервые понял, что: «много зарабатывать» и «понимать свои деньги» — вообще не одно и то же.

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

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

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

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

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

А ошибку можно заметить сильно позже, когда в прогнозе внезапно появляется кассовый разрыв, которого «не должно было быть». И вот тут я решил: «Ладно. Сейчас AI всё быстро накодит».

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

На тот момент я использовал Codex 5.2, GPT и spec‑kit. И первая версия действительно собралась за пару вечеров.

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

Правда, всё это работало только локально, на одном устройстве и с хранением данных прямо в браузере. Но после 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‑токенов уже начинает попадать в область вполне реальных требований законодательства.

И это очень меняет мышление. Потому что дальше ты начинаешь думать уже не только про фичи. А про удаление аккаунта, отзыв сессий, хранение токенов, права доступа, последствия утечки и восстановление доступа.

И это уже совсем другой тип задач. Потому что демка — это: «смотрите, приложение работает». 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 действительно радикально ускоряют фазу реализации. Если у тебя есть инженерный опыт, понятное видение продукта и понимание, куда вообще движется система, то за неделю сейчас реально собрать MVP, на который раньше ушли бы месяцы. Но дальше начинается совсем другая история.

Production — это уже:

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

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

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

• UX;

• sync;

• rollback;

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

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

И именно здесь исчезает магия: «сделал SaaS за вечер».

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

Наверное, самое интересное изменение я начал замечать даже не в коде, а в людях. Я работаю техруком, и последнее время всё чаще думаю: «а как вообще теперь калибровать инженеров в эпоху LLM?»

Потому что объём выдачи действительно вырос. То, что раньше делалось неделю, сейчас местами собирается за день. Но парадокс в том, что критерии сильного инженера почти не изменились.

LLM очень хорошо ускоряют реализацию. Но они почти не помогают с инженерными компромиссами, эксплуатацией, отладкой и пониманием последствий архитектурных решений. И, кажется, именно поэтому AI пока не «обнуляет» опыт и экспертизу. Скорее наоборот — делает разницу между уровнями заметнее.

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

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

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

AI действительно радикально ускоряет старт разработки. Но демо и production — это всё ещё две разные вселенные. Хайповые истории не совсем врут. Сделать SaaS за вечер — реально. Просто между: «смотрите, оно работает» и «этим можно пользоваться каждый день» обычно находится ещё несколько месяцев инженерной работы.

И это именно та часть разработки, которую AI пока не отменил. Собственно, результат этого эксперимента можно посмотреть здесь: financehelperai.ru

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