К началу июля я выгорел. Первую версию я дебажил несколько недель и в какой‑то момент понял, что в 47 раз запускать симулятор я не готов. Наклепал скриншотов, сложил в папочку, показал Клоду и сказал: «Шурши и не булькай», а сам отправился собирать вайбовую дачную лампу из того что нашел в гараже.

Вернулся через 2 часа. В браузере полностью заполненная форма App Store Connect и синенькая кнопка «Отправить на проверку». Нажал. Все сработало — первая версия приложения ушла на проверку в эпл.

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

Через неделю я загружал следующую версию и решил сравнить, сколько времени на это уходит у меня самого. Не вышло вообще. Apple сыпала ошибками и душила всем чем могла: скриншоты определенного размера и формата, какие‑то подпункты, поля, про которые я не знал. Я считаю, что терпение это моя сильная сторона и его хватило на +‑ на 24 минуты. Потом я позвал Клода, у него весь процесс занял 10 минут.

Вот после этого мне и захотелось рассказать историю целиком.

---

Что я проверял

Я Product Lead. 7 лет строю цифровые продукты, последние годы в корпоративной среде: крупные сервисы, путь от идеи до промышленной эксплуатации и метрик. Кода я не пишу, мобильной разработкой не занимался никогда.

Гипотеза была простая. До какого этапа я дойду без команды и в какой момент слезно напишу корешкам разработчикам с просьбой помочь.

Интерес был не абстрактный. На прошлой работе я подвыгорел, в основном из‑за оценок: команды дают огромные сроки и даже в них не укладываются. Мне хотелось в этих спорах чувствовать себя еще увереннее, а для этого понимать своими руками, сколько на самом деле стоит сделать продукт — не только код, а в целом. Плюс была бытовая задача, которую я много лет не мог решить: у меня набор целей, которые плохо укладываются в голове одновременно, например дача, где каждый чихпук от 100 тысяч рублей. По отдельности цель каждая понятна (Ремонт дачи, отпуска, машина, инвестиции), но вместе они превращаются в фоновую тревогу и в вопрос, на который я не умел отвечать — сколько я могу потратить сегодня, чтобы не сломать все остальное?

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

В декабре 2025 я начал.

Объем работы

Чтобы дальше было понятно, о каком масштабе речь. В проекте оказалось приложение под iOS, математическая модель распределения дохода и рассчета сроков+сумм, локальное распознавание списка операций со скриншотов банков, агент внутри приложения с доступом к функциям продукта, бэкенд с синхронизацией и метриками, инфраструктура с сервером, доменами и сертификатами.

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

Ограничением оказался не код

Вот главное, что я вынес, и мне интересно, совпадет ли это с чужим опытом.

Я был уверен, что упрусь в незнание кода. Не уперся ни разу за 7 месяцев. Уперся в другое: насколько хорошо я умею ставить задачу и принимать результат. А это ровно то, чем я занимался предыдущие 7 лет.

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

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

Когда я отдавал задачу человеку, половина требований рождалась в разговоре. Он дочитывал постановку, приходил и спрашивал: а если у пользователя 2 цели с одинаковой датой? А если он удалил трату, из которой сложился план? Я никогда не считал это своей работой, это был нормальный рабочий шум.

Модель не приходит с вопросами. Она принимает решение молча и идет дальше. Каждая неоднозначность в постановке превращается не в вопрос, а в реализованное поведение, о котором узнаешь через 2 недели, причем случайно.

Из этого выросло почти все, что я потом построил вокруг процесса.

Что пришлось выстроить

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

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

Один файл с правилами, который агент читает перед каждой задачей. У меня получилось 243 строки: суть продукта, целевая аудитория с поведенческими особенностями, метрики, принципы работы с кодовой базой, обязательный рабочий цикл, инварианты, формат ответа, шаблон постановки. Это не документация проекта, скорее должностная инструкция для исполнителя, который не помнит прошлый разговор.

Про этот файл у меня есть история, за которую немного стыдно. Файлов было 2, под разные инструменты. В конце июля я обнаружил, что они разошлись: в каждом были уникальные разделы, которых не было во втором. Причина оказалась глупейшая. Второй лежал в списке игнорируемых системой контроля версий, то есть был локальным, существовал только у меня на ноутбуке и до других агентов физически не доезжал. Месяцами я был уверен, что работа идет по правилам, половину которых исполнители в принципе не видели.

Порог уверенности. Дыру с непереспрашиванием я закрыл 2 строками в правилах: если уверенность в понимании задачи ниже 99%, задавай вопросы до начала работы, если выше, действуй сразу и без лишних вопросов. Порог намеренно абсурдный, и это осознанно. С формулировкой «уверен на 80%, тогда спрашивай» не работает ничего, модель почти всегда чувствует себя уверенной. А 99 честно не берет почти ничего, кроме механических правок.

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

Фильтр по метрикам. Здесь я наткнулся на проблему, о которой мало пишут. Когда стоимость разработки падает почти до нуля, выясняется, что делать можно все, и поэтому начинает делаться что попало. За неделю можно выпустить 5 функций. Через месяц у тебя продукт из 30 функций, в котором не работает главное. Я на это попался.

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

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

Скилл на каждый экран. Модель не помнит прошлую задачу, и это создает проблему, которую я сначала не оценил. Экран, над которым ты работал 3 месяца, содержит десятки решений, у каждого была причина, и ни одна причина в коде не написана. Почему здесь 2 шага, а не один. Почему эта кнопка проходит без заполнения поля. Новый исполнитель видит странность и добросовестно ее исправляет.

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

Критерий, по которому я решаю, что пора завести новый, вышел такой — если я второй раз объясняю в постановке одно и то же правило, правило переезжает в файл. Второе объяснение это не совпадение, а сигнал, что узким местом стал я.

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

Я попробовал закрыть это так: перед нетривиальным решением прогонять его через профили известных основателей. Каждый профиль это набор вопросов, которые задал бы конкретный человек. Маск: подвергни сомнению, удали, упрости, и только потом автоматизируй. Безос: работай от результата назад, отличай обратимые решения от необратимых. Джобс: фокус это умение сказать нет. Талеб: а что мы теряем, если ошиблись.

Работает лучше, чем я ожидал, и кажется по понятной причине. У модели нет своего мнения о моем продукте, но она хорошо воспроизводит рамку рассуждения. Это ровно те вопросы, которые в одиночку не задаешь, потому что уже влюблен в свое решение. Правило пришлось добавить такое: прогонять 2–3 релевантные линзы, нерелевантные честно пропускать и говорить об этом. Иначе получаешь 7 абзацев ритуального текста на каждую задачу, и это не читает никто, включая меня.

Приемка, где я проверяю только результат. Здесь я просто перенес то, что умел раньше. Агент готовит план тестирования на конкретную сборку: экран, что нажать, что проверяем, ожидаемый результат, без воды. Я прохожу и отмечаю прямо в том же файле: работает, баг, или что увидел вместо ожидаемого. Агент разбирает, ищет корень, формирует список правок, обновляет статусы. Я перепроверяю только затронутое. К публикации таких планов было около 20, почти по одному на сборку.

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

Что оказалось тяжело

Математическая модель. Мучился с ней очень долго. Приоритеты целей, желаемые даты, точные прогнозные даты, все это упорно не хотело жить вместе. Думал, что наконец закончил. А потом вспомнил, что у меня есть еще и премия, и она тоже должна участвовать в расчетах. Вот это было отдельное геморройное удовольствие.

Аналитика. Задача элементарная, посчитать пользователей по событию, и именно здесь я потерял больше всего. Причина, кажется, вот в чем. У аналитики нет проверяемого ответа. В математике я беру доход, 3 цели и считаю на бумаге, расхождение видно сразу. А 34 активных пользователя или 4 я на бумаге не проверю никак, любое число выглядит правдоподобно. Остается верить.

Пример, чтобы было понятно, как это выглядит вживую. Активация нового пользователя считалась у меня по двум способам внесения траты. Логично же. Только основной способ в приложении третий, импорт из скриншота, и на него приходится почти 9 трат из 10. Его в расчете не было. Отдельно смешное: в том же файле, 20 строками ниже, другая метрика этот же способ учитывала. 2 метрики в одном месте считали одно событие по‑разному, и обе были написаны очень уверенно.

Код при этом работал. Тесты проходили. Все читалось правильно.

Мне кажется, это главное отличие новой эпохи, и его стоит запомнить. Ошибки, которые делает модель не падают. Раньше плохая работа проявляла себя: вылет, красный тест, заметная поломка. Теперь код компилируется, проходит проверки и тихо считает не то. ИИ был абсолютно уверен в своем решении. Жаль только, что оно считало неправильно.

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

Что удивило приятно

Тесты. В проектах с командой они первыми идут под нож, когда жмут сроки. Я это видел много раз и, честно говоря, сам в этом участвовал. А тут писать их дешево, поэтому они просто есть. Дисциплина, которую я годами выбивал уговорами, получилась сама собой, и для меня это оказалось важнее скорости написания функций.

Инфраструктура. Сервер, контейнеры, развертывание, миграции базы. То, на что я точно нанимал бы человека. Прошло на удивление спокойно.

Документация. Впервые в моей практике она соответствует продукту. И не потому, что я вдруг стал дисциплинированным, а потому, что от нее зависит качество следующей задачи. У документации появился потребитель, который наказывает за вранье.

К апрелю узким местом стал я

Довольно неожиданный поворот. Я уперся не в возможности модели, а в свои.

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

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

Название меняли 3 раза

Рабочее было «Финик». На покупке домена для бэкенда выяснилось, что нейминг уже занят. Пришлось резко придумывать новое, придумали супер оригинальное «Кубышка» и с ним вышли в стор. Спойлер: потом оказалось, что такое название уже занял другой сервис, и в версии 1.4 приложение стало «Кубыш»

Самое неприятное случилось до релиза

Получив доступ к App Store Connect, я собрал версию в TestFlight и дал потестить друзьям. Установок было 15–20.

Реально воспользоваться приложением не захотел никто.

Тут я расстроился и запереживал. Технически все работало, я 7 месяцев вел проект и ни на чем серьезно не сломался. А продукт при этом был никому не нужен, и выяснилось это еще до выхода в стор.

Чем закончилось

4 июля я отправил версию на проверку. Около 9 июля приложение появилось в App Store.

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

Вторая половина не проверена никак, и она важнее. Нужен ли этот продукт кому‑то, кроме меня. TestFlight с друзьями довольно прозрачно намекал, что нет.

И вот что я понял, стоя в этой точке. Худший исход эксперимента — это вовсе не технический провал. Технически все получилось. Худший исход — это аккуратно сделанный, работающий, никому не нужный продукт. А до реальных пользователей отличить одно от другого нельзя.

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

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