Неразработчик + чат с ИИ + Android Studio: промежуточные результаты после публикации двух приложений

Вступление

Я бизнес‑аналитик. Пишу мобильные приложения с нуля — без исходных знаний кода, архитектуры, дизайна и маркетинга. Инструменты те же: Claude в чате и копипаст в Android Studio.

Это вторая статья. Первая была про старт эксперимента и публикацию первых версий. Реакция ^[1] была предсказуемая: часть читателей сочла это «неподдерживаемым способом разработки», часть — «игрой в прототипы», часть — «без навыков всё развалится». Я не собираюсь спорить на уровне тезисов. Поэтому вместо дискуссии — отчёт по фактам.

Ссылка на первую статью ^[2]. Здесь не будет пересказа. Это именно промежуточный срез: что произошло после публикации, когда пришли реальные пользователи и реальные проблемы.

Гипотеза

Неразработчик может создать и развивать реальный продукт с реальными пользователями, используя только ИИ как основного “исполнителя”, если он берёт на себя роль постановщика задач, тестировщика и интегратора.
Не демо, не прототип «для друзей», а продукт, который живёт: у него есть установка, баг‑репорты, фиксы, обновления.

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

Метод

Инструменты и схема работы

• Claude в чате — генерирует код, объясняет ошибки ^[3] сборки, предлагает варианты исправлений, помогает думать по структуре.

• Android Studio — собираю проект, запускаю на эмуляторе/устройстве, вижу ошибки, вношу правки (обычно копипастом).

• RuStore — публикация, обновления, сбор обратной связи через отзывы/сообщения.

Роли распределены так:

• Я: формулирую требования, проверяю поведение ^[4] приложения, воспроизвожу баги, принимаю решения «что именно должно быть», интегрирую изменения в проект, прогоняю сборку, выкатываю обновление.

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

Как формулирую задачи для ИИ

За это время стало понятно: качество результата почти всегда упирается не в «умность модели», а в то, насколько точно вы описали контекст.

Сейчас я задаю задачи в формате:

1. Что сломано / что нужно получить (наблюдаемое поведение ^[5]).

2. Как воспроизвести (шаги).

3. Какая версия приложения/экрана (если важно).

4. Ограничения: «без переписывания всего», «без новых библиотек», «сохранить текущий UI», «данные не потерять».

5. Что я уже пробовал и что увидел: сообщения ошибок, логи, где примерно находится код.

Если баг — я прошу не «пофиксить», а:

• назвать вероятную причину,

• указать, в каких файлах это обычно живёт,

• предложить 2–3 решения с рисками,

• и только потом — конкретные правки.

Что изменилось по сравнению с первой итерацией

Если в начале я работал как «пишем фичу целиком с нуля по описанию», то сейчас чаще работаю как:

• маленькие изменения вместо больших переделок;

• фиксы через минимальный дифф: исправить ровно то, что ломает сценарий;

• контроль состояния и данных: где хранится, когда сбрасывается, что переживает перезапуск;

• понимание структуры проекта: не «какой-то набор файлов», а отдельные сущности: экраны, модели данных, хранилище состояния, логика ^[6] таймеров и т. п.

Это не делает меня разработчиком. Но снижает вероятность, что я случайно «починю одно — сломаю три».

Промежуточные результаты (сухие факты)

1) Два приложения опубликованы и доступны

В RuStore лежат два приложения:

• «168 Часов» — планировщик времени (идея: 168 часов в неделе как бюджет).

• «F1 Tycoon» — простая игра.

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

2) Рост скачиваний после первой статьи

После публикации первой статьи и последующей активности:

• «168 Часов»: с 1 до 71 скачивания

• «F1 Tycoon»: с 13 до 45 скачиваний

Это не «успех» и не «продукт взлетел». Это просто 71 и 45 установок. Но ключевое: это уже не ноль. Появляются люди, которые используют приложение не так, как я ожидал.

3) Пришли реальные пользователи → появились реальные баги

Как только приложение перестаёт быть «моим проектом в студии», начинается нормальная жизнь со стандартным набором:

• пользователь нажал не в том порядке;

• пользователь перезапустил приложение «не вовремя»;

• пользователь ожидает сохранения состояния там, где я про это не думал;

• пользователь хочет фичу, которую я не планировал, но которая логична.

И это, пожалуй, самый важный переход: эксперимент перестал быть теоретическим.

4) Кейс: баг с таймером, который сбрасывался при перезаходе

Симптом: таймер в «168 Часов» сбрасывался при перезаходе в приложение. То есть пользователь стартует активность/таймер, выходит, возвращается — и видит не продолжение, а обнуление/несогласованное состояние.

Как баг обнаружен: пользовательское использование + воспроизведение мной по шагам на устройстве.

Как я описал проблему ИИ:

• сценарий воспроизведения (старт → выйти → зайти),

• ожидаемое поведение (таймер продолжает отсчёт или хотя бы корректно восстанавливается),

• текущее поведение (сброс),

• предположение, что проблема в сохранении состояния между сессиями.

Что сделал ИИ по сути (без кода):

• предложил проверить, где хранится «истина» времени: в UI‑состоянии, в памяти ^[7], в базе/на диске;

• предложил стратегию: хранить не «сколько секунд прошло», а timestamp старта и при восстановлении пересчитывать;

• указал типовые места, где всё ломается при перезаходе: жизненный цикл экрана/активити, сохранение в persistent storage, восстановление при старте.

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

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

5) Добавлена новая фича: ручное создание активностей

Параллельно добавил фичу: ручное создание активностей (то есть не только предзаданный список/шаблоны, но возможность пользователю самому завести сущность).

Здесь ИИ помог в двух местах:

• предложил, как протянуть новую сущность через структуру приложения (экран → модель → сохранение);

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

Фича тоже ушла в обновлении.

6) Что я начал понимать в разработке (не «выучил программирование», а ориентируюсь)

За время после первой статьи у меня появилось не знание синтаксиса, а практическая «карта местности»:

• что такое классы в проекте и почему их много;

• что такое модели данных и почему «поменять поле» — это редко одно место;

• где обычно живёт логика экрана, а где — хранение данных;

• почему ошибки часто возникают не «в строке, которую подсветило», а в нарушении контракта между частями системы;

• что такое «состояние приложения» как причина половины пользовательских багов.

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

Честный разбор: что НЕ получается и где границы

Ниже — не жалобы, а ограничения метода в текущей конфигурации «чат + копипаст».

1) ИИ легко генерирует код, но плохо отвечает за целостность проекта

Если просить «сделай фичу», он может предложить изменения в нескольких файлах, но:

• забыть обновить связанное место,

• предложить несовместимые элементы,

• или «починить» так, что сломается другой сценарий.

То есть архитектурная ответственность остаётся на человеке, даже если он не разработчик. Иначе проект превращается в набор заплаток.

2) Дебаг “по описанию” работает до определённой сложности

Пока проблема воспроизводима и локализуема (таймер/сохранение состояния) — чат помогает быстро.

Когда проблема:

• плавающая,

• зависит от устройства,

• связана с конкурентностью/потоками,

• или упирается в нюансы платформы,

без нормальной инженерной дисциплины (логи, диагностика, понимание жизненного цикла) начинаются итерации «попробуй это/попробуй то».

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

3) UI/UX и дизайн — слабое место

Можно сделать «работает», но сделать «удобно» — это другая профессия. ИИ может накидать идеи, но:

• он не чувствует контекст пользователя,

• не видит метрики поведения,

• не несёт ответственность за когнитивную нагрузку.

В итоге у меня приложения функциональные, но по UX они не эталон. Это честная цена нулевого бюджета и отсутствия профильных навыков.

4) Публикация и поддержка — это отдельная работа

Сам факт «залить в стор» не означает, что дальше будет легко:

• обновления требуют дисциплины,

• нужно думать про обратную совместимость,

• нужно обрабатывать отзывы как входящие требования.

ИИ здесь помощник, но не процесс.

5) Граница “без знаний” существует, просто она не там, где её обычно рисуют

Нельзя всерьёз рассчитывать «не понимать вообще ничего» и при этом стабильно развивать продукт.
Но и тезис «без разработчика ничего нельзя выпустить» в практическом смысле оказался слишком жёстким.

Реальность посредине: можно выпустить и чинить, но вы платите временем и вниманием ^[8]. И постепенно всё равно наращиваете понимание — иначе не выдержите темп.

Выводы на текущем этапе

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

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

3. Скачивания небольшие, но достаточные для проверки гипотезы. 71 установка — это не коммерческий результат, но этого достаточно, чтобы получить внешние баг‑репорты и перестать полагаться на «у меня работает».

4. Эксперимент не закончился. На текущей точке видно траекторию: приложения живы, обновляются, получают пользователей, чинятся. Судить можно по этой линии, а не по стартовому рывку.

Что дальше

Планы прикладные, без «в следующей версии сделаю всё идеально»:

1. Стабильность “168 Часов”

   • продолжить закрывать баги по отзывам;

   • привести сценарии с таймерами/состоянием к предсказуемому поведению;

   • добавить минимальные тестовые сценарии (пусть даже вручную по чек‑листу), чтобы не ломать исправленное.

2. Развитие функционала через маленькие итерации

   • добавлять фичи только если они укладываются в текущую структуру;

   • не раздувать приложение «на будущее», пока не понятно, что реально нужно пользователям.

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

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

---

Если вам нужно проверить эксперимент руками — приложения в RuStore: «168 Часов» и «F1 Tycoon». Если найдёте баги — вы не “хейтер”, вы тестировщик в бою. В этом эксперименте это самый полезный тип обратной связи.