Claude Opus ajudou um analista de negócios a lançar dois aplicativos em duas semanas sem equipe

Эксперимент с ИИ-разработкой показал, что человек без опыта программирования уже может довести мобильный продукт до публикации. За две недели бизнес-аналитик собрал на Flutter два приложения для RuStore и потратил на это около 80 часов.

Как прошёл эксперимент

Автор подошёл к задаче как к проверке гипотезы: если бизнес-аналитик умеет декомпозировать требования, писать user story и acceptance criteria, этого может хватить для работы с ИИ-ассистентом вместо обычной команды. Для теста он выбрал два разных продукта — тайм-трекер «168 часов» и игру F1 Tycoon про управление командой Формулы-1. Стек он тоже подбирал через модель: Flutter и Dart для кроссплатформенной разработки, Supabase как бесплатный бэкенд для MVP.

График получился почти как у полноценного спринта. Первые два дня ушли на установку Flutter и Android Studio, затем началась конвейерная сборка экранов для «168 часов». Следом пришёл первый тяжёлый этап — интеграция с Supabase, где авторизация и сетевые вызовы быстро превратились в серию циклических фиксов.

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

Где ИИ ускорил работу

Лучший результат, по словам автора, дали не бесплатные инструменты, а более сильные коммерческие модели. Бесплатные варианты часто выдавали код, который не собирался, и UI в духе старых учебных проектов. GPT-5.2 оказался заметно стабильнее, но именно Claude Opus дал наиболее чистый код, современный интерфейс и лучше остальных удерживал контекст диалога. Важнее другое: навыки бизнес-аналитика неожиданно совпали с тем, что требуется для хорошего промптинга.

«ИИ — как джун-разработчик: чем точнее ТЗ, тем точнее результат.»

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

В такой схеме ИИ оказался особенно полезен в нескольких типовых задачах: генерация UI-компонентов и экранов за минуты выбор стартового стека для новичка без команды объяснение ошибок и терминов простым языком написание boilerplate-кода и базовой бизнес-логики * подготовка к публикации: подпись сборки, ключи, настройки build.gradle ## Где начались проблемы Самый болезненный участок — интеграции. Подключение Supabase выглядело на бумаге простым, но в реальности один фикс легко порождал следующий баг.

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

Когда F1 Tycoon разросся до 50+ файлов, ИИ перестал уверенно помнить ключевые классы, структуру проекта и прежние архитектурные решения. Чтобы снизить потери контекста, автор завёл отдельный «файл памяти» с описанием структуры и в начале каждой сессии снова скармливал его модели. Это помогало, но не решало вопрос полностью.

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

Что это значит

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