Как я создала Flutter-приложение с ИИ: где он сэкономил до 70% времени, а где уверенно ошибался

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

Я прошла гораздо более длинный путь: от идеи до работающего Flutter-приложения и публикации в App Store. И могу сказать честно: ИИ действительно способен очень сильно ускорить разработку. Но только в том случае, если человек не передаёт ему право принимать окончательные решения.

На отдельных рутинных задачах экономия времени у меня доходила примерно до 70%. Одновременно именно из-за уверенных ответов ИИ мне приходилось долго перепроверять код, архитектурные решения, слова, значения и контексты.

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

Расскажу, как это работает на примере мобильного приложения «Смысл слова и контекста».

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

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

Для разработки я выбрала Flutter. ИИ-инструменты использовала на разных этапах: при обсуждении продукта, работе с кодом, поиске ошибок, подготовке данных и проверке отдельных решений.

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

Во Flutter много повторяющейся работы: Row, Column, Container, отступы, выравнивание, состояния кнопок, карточки и списки.

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

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

Когда в проекте много структурированных данных, приходится создавать Dart-модели, поля, конструкторы, а также методы fromJson и toJson.

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

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

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

Но перевод интерфейса и работа со смыслом слова — разные задачи. Формально правильная строка ещё не означает правильную формулировку. Все пользовательские тексты всё равно требуют отдельной редакторской проверки.

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

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

Самая опасная особенность ИИ не в том, что он ошибается. Ошибаются все. Проблема в том, что он часто ошибается очень убедительно.

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

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

Поэтому работа с контентом оказалась не «попросить нейросеть составить базу», а выстроить отдельный процесс проверки:

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

ИИ легко решает локальную задачу и гораздо хуже удерживает архитектуру всего приложения.

Например, в одном месте он мог предложить быстрое обновление через setState, в другом — логику на Provider, а затем добавить фрагмент, построенный по принципам BLoC. Каждый кусок по отдельности мог выглядеть рабочим, но вместе они создавали несколько источников состояния и усложняли поддержку.

Проблема не в конкретном инструменте: и setState, и Provider, и BLoC имеют свои области применения. Проблема — в их бессистемном смешении без заранее определённых границ.

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

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

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

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

«Пусть приложение работает офлайн» звучит как одно требование. На деле за ним стоит целая система решений:

ИИ склонен предлагать самое короткое решение для текущего фрагмента кода. Оно может пройти один демонстрационный сценарий, но не выдержать обновления, большого объёма данных или аварийного завершения приложения.

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

Я намеренно не называю здесь несуществующий «единственный правильный» пакет. Выбор локального хранилища зависит от структуры данных, объёма, поиска, миграций и требований конкретного приложения. Назвать одну библиотеку и написать «после этого всё полетело» было бы эффектно, но неправдиво.

В начале хотелось формулировать задачу и сразу получать решение. Со временем процесс стал гораздо строже.

Теперь я разделяю работу так:

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

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

Но ИИ не несёт ответственности за целостность продукта. Он не чувствует цену потерянных данных, неверного значения слова, сломанного пользовательского сценария или ошибки перед публикацией. Эту ответственность всё равно несёт человек.

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

ИИ может быстро принести кирпичи. Но проект здания, контроль материалов и приёмка остаются за человеком.

Если вам интересна разработка без иллюзий — от идеи и требований до архитектуры, тестирования и релиза, — я рассказываю об этом в Telegram-канале «От смысла к продукту ИИ | Марина».

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

А как вы используете ИИ в работе: как генератор готовых ответов или как помощника, результат которого обязательно нужно проверять?