Я хотел понять, в какой момент позову разработчиков. Так и не позвал

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

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

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

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

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

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

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

Гипотеза была такая: до какого этапа дойду без команды и в какой момент слезно напишу корешкам разработчикам с просьбой помочь. Спойлер: не написал. Начал в декабре 2025, в июле приложение вышло в App Store.

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

Мобильная разработка. Закрылась полностью. 7 месяцев, ни одной строки руками. Тут я ждал провала, но его не получил.

Бэкенд. Закрылся. Синхронизация, метрики, админка. Вырос больше, чем я планировал, и об этом ниже.

DevOps. Закрылся неожиданно спокойно. Сервер, контейнеры, развертывание, домены, сертификаты, миграции базы. То, на что я точно нанимал бы человека.

Тестировщик. Закрылся частично, и это самый интересный случай в списке.

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

Но роль не закрывается целиком. Финальную проверку сборки все равно делает человек, и до сих пор это всегда был только я. Без живого прохода выгружать сборку нельзя. Агент проверяет, что код делает то, что написано в задаче. А проверить надо, что продукт делает то, что нужно живому человеку. Это разные вещи.

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

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

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

Итого 4 роли закрылись целиком, одна частично, одна не закрылась. Для человека без технического бэкграунда это, по-моему, чудненько)

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

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

А вот сколько то же самое стоило бы командой, я посчитал отдельно: по типам компаний, от AI-first команды из 10 человек до бигтеха с пятью тысячами айтишников, с множителями на легаси, бюрократию и интеграцию в существующий ландшафт. Разброс вышел неприличный. И там же вылез вопрос, который мне самому не нравится: сколько телодвижений нужно в большой компании, чтобы просто получить такую оценку, и решится ли вообще кто-нибудь идти с ней на согласование запуска. Про это напишу отдельно, в ближайшие или не очень, дни.

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

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

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

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

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

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

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

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

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

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

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

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

Он случился до релиза, и он не технический.

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

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

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

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

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

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

Приложение называется Кубыш, оно (пока) бесплатное, для iPhone: https://apps.apple.com/app/id6778792103

Про то, как оно развивается дальше, вещаем в телеграме @kubyshka_user, 3-4 раза в неделю и без спама.

Процессную часть этой же истории разобрал на Хабре: как устроен файл правил для агента, зачем нужен порог уверенности, почему на каждый экран лежит свой документ и как выстроена приемка. https://habr.com/ru/articles/1067120/

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