В 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.
