Я — бизнес-аналитик, без изначальных навыков в программировании, дизайне или архитектуре. Пишу мобильные приложения с помощью чата с ИИ (Claude) и Android Studio. Это — промежуточный отчёт после публикации двух приложений в RuStore.

Суть эксперимента

Цель — не заменить разработчика, а проверить, насколько далеко можно уйти, если человек без технического бэкграунда использует ИИ как основного исполнителя. Я беру на себя роль постановщика задач, тестировщика и интегратора.

Результат — не демо или прототип, а реальные приложения, которые устанавливают, используют, оставляют отзывы и сообщают о багах.

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

• Claude — генерирует код, объясняет ошибки, предлагает решения, помогает с архитектурой.
• Android Studio — сборка, запуск, отладка, внесение изменений (в основном через копипаст).
• RuStore — публикация, обновления, сбор обратной связи.

Роли:

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

Как я ставлю задачи ИИ

Качество результата зависит не от ИИ, а от точности описания контекста. Сейчас использую чёткий формат:

1. Что сломано / что нужно получить (наблюдаемое поведение).
2. Шаги для воспроизведения.
3. Версия приложения или экрана (если важно).
4. Ограничения: «без переписывания всего», «сохранить UI», «не терять данные» и т.п.
5. Что уже пробовал: ошибки, логи, предполагаемые места кода.

Для багов прошу не просто «починить», а:

• назвать вероятную причину,
• указать, где искать (файлы, слои),
• предложить 2–3 решения с рисками,
• и только потом — конкретные правки.

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

Раньше делал крупные фичи с нуля. Сейчас работаю иначе:

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

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

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

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

В RuStore доступны:

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

Оба можно скачать и протестировать. Эксперимент остаётся публичным — иначе выводы не имеют веса.

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

• «168 Часов»: с 1 до 71 скачивания.
• «F1 Tycoon»: с 13 до 45 скачиваний.

Это не вирусный успех, но уже не ноль. Появились реальные пользователи, которые используют приложения не так, как я ожидал.

3) Пришли реальные баги

Как только приложение вышло за пределы моего телефона, начались типичные проблемы:

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

Это переход от теории к реальности.

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

Симптом: таймер в «168 Часов» обнулялся при возврате в приложение.

Как описал ИИ:

• сценарий (старт → выйти → зайти),
• ожидаемое поведение (восстановление),
• текущее (сброс),
• предположение: проблема в сохранении состояния.

Что предложил ИИ:

• проверить, где хранится «истина» времени — в UI, памяти или на диске,
• предложить хранить timestamp старта и пересчитывать при восстановлении,
• указать типовые точки сбоя: жизненный цикл активити, persistent storage.

Время на исправление: около 2 часов — от воспроизведения до публикации обновления.

Вывод: баг не сложный, но реальный. Он был закрыт в реальном цикле релиза.

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

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

ИИ помог:

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

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

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

Появилась «карта местности»:

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

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

Честный разбор: где границы

1) ИИ не отвечает за целостность проекта

Он может предложить изменения, но:

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

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

2) Дебаг по описанию работает не всегда

Если проблема воспроизводима и локализуема — ИИ помогает быстро.

Но если она:

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

— начинаются итерации «попробуй это/попробуй то». ИИ ускоряет расследование, но не заменяет его.

3) UI/UX — слабое место

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

• не чувствует контекст пользователя,
• не видит метрики поведения,
• не несёт ответственность за когнитивную нагрузку.

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

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

Залить в стор — не значит «готово». Нужно:

• регулярно выпускать обновления,
• думать про обратную совместимость,
• обрабатывать отзывы как требования.

ИИ — помощник, но не процесс.

5) Граница «без знаний» существует, но не там, где думают

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

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

Выводы

1. Продуктовая реальность наступает быстро — уже при десятке пользователей. Баги и запросы приходят сами.
2. ИИ позволяет не-разработчику доводить задачи до релиза, но только если человек — системный интегратор: формулирует, проверяет, воспроизводит, выкатывает.
3. Скачивания маленькие (71 и 45), но достаточные: появились внешние баг-репорты, и можно перестать полагаться на «у меня работает».
4. Эксперимент продолжается. Приложения живы, обновляются, получают пользователей. Судить нужно по траектории, а не по старту.

Что дальше

1. Стабильность «168 Часов»: закрывать баги по отзывам, привести поведение таймеров к предсказуемому, добавить ручные тест-кейсы.
2. Маленькие итерации: добавлять фичи только в рамках текущей структуры, не раздувать «на будущее» без подтверждения от пользователей.
3. Подтянуть инженерную грамотность: не «выучить всё», а закрыть ключевые пробелы — жизненный цикл, хранение состояния, структура, диагностика.
4. Следующий отчёт: будет, когда появятся измеримые данные — обновления, баги, решения, динамика. Сроков не обещаю.

Если хотите проверить — приложения в RuStore: «168 Часов» и «F1 Tycoon». Нашли баг? Вы не хейтер — вы тестировщик в бою. Это самый полезный фидбэк для эксперимента.

Вступление

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

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

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

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

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

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

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

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

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

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

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

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

1. Что сломано / что нужно получить(наблюдаемое поведение).
2. Как воспроизвести(шаги).
3. Какая версия приложения/экрана(если важно).
4. Ограничения: «без переписывания всего», «без новых библиотек», «сохранить текущий UI», «данные не потерять».
5. Что я уже пробовал и что увидел: сообщения ошибок, логи, где примерно находится код.

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

• назвать вероятную причину,
• указать, в каких файлах это обычно живёт,
• предложить 2–3 решения с рисками,
• и только потом — конкретные правки.

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

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

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

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

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

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

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

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

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

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

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

• «168 Часов»: с1до71скачивания
• «F1 Tycoon»: с13до45скачиваний

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

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

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

• пользователь нажал не в том порядке;
• пользователь перезапустил приложение «не вовремя»;
• пользователь ожидает сохранения состояния там, где я про это не думал;
• пользователь хочет фичу, которую я не планировал, но которая логична.

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

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

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

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

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

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

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

• предложил проверить, где хранится «истина» времени: в UI‑состоянии, в памяти, в базе/на диске;
• предложил стратегию: хранить не «сколько секунд прошло», аtimestamp стартаи при восстановлении пересчитывать;
• указал типовые места, где всё ломается при перезаходе: жизненный цикл экрана/активити, сохранение в persistent storage, восстановление при старте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• он не чувствует контекст пользователя,
• не видит метрики поведения,
• не несёт ответственность за когнитивную нагрузку.

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

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

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

• обновления требуют дисциплины,
• нужно думать про обратную совместимость,
• нужно обрабатывать отзывы как входящие требования.

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

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

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

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

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

1. Продуктовая реальность наступает быстро, как только у вас появляется больше десятка пользователей. Баги и запросы приходят без приглашения.
2. ИИ действительно позволяет не‑разработчику доводить задачи до релиза, но при условии, что человек выполняет роль системного интегратора: формулирует, проверяет, воспроизводит, выкатывает.
3. Скачивания небольшие, но достаточные для проверки гипотезы.71 установка — это не коммерческий результат, но этого достаточно, чтобы получить внешние баг‑репорты и перестать полагаться на «у меня работает».
4. Эксперимент не закончился.На текущей точке видно траекторию: приложения живы, обновляются, получают пользователей, чинятся. Судить можно по этой линии, а не по стартовому рывку.

Что дальше

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

1. Стабильность “168 Часов”продолжить закрывать баги по отзывам;привести сценарии с таймерами/состоянием к предсказуемому поведению;добавить минимальные тестовые сценарии (пусть даже вручную по чек‑листу), чтобы не ломать исправленное.
2. Развитие функционала через маленькие итерациидобавлять фичи только если они укладываются в текущую структуру;не раздувать приложение «на будущее», пока не понятно, что реально нужно пользователям.
3. Подтянуть базовую инженерную грамотностьНе «выучить всё», а закрыть самые практичные пробелы: жизненный цикл, хранение состояния, структура проекта, диагностика.
4. Дальше — ещё один отчёт, когда появится следующий измеримый срезНе обещаю сроков. Публиковать буду, когда будет что фиксировать цифрами: обновления, баги, решения, динамика.

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