Как сделать мобильную аппку с ИИ. Апдейт прошлогоднего поста. За полгода в разработке изменилось многое. Модели и среды разработки стали сильнее, но и порог входа стал парадоксально выше. Мы составили список из 10 пунктов чтобы не отставать от обновлений. Наш основной источник заработка - это наши же аппки. Поэтому подходим к делу серьёзно и вот какой алгоритм вывели за последнее время: 1. Сначала делаем план разработки. Идём в claude sonnet\opus или другую мощную модель. Пишем свою идею подробно и как оно должно сработать. Думаем над бизнес планом, аудиторией и на основе этого уже думаем как это закодить в продукт. Просим модельку собрать это в виде ТЗ с подробным описанием всего. 2. Берём ТЗ и относим в Antigravity. Можно со старта продумывать план там же. Важно чтобы это превратилось в файл, который моделька сможет читать и ориентироваться на него во время разработки. Так модель не уйдёт случайно во время разработки делать что-то совершенно другое и ненужное. 3. По ходу разработки стоит завести Devlog файл. Просить модельку записывать туда все изменения, чтобы моделька сама могла видеть что уже сделано. Каждый новый диалог оставляет модель без памяти, поэтому важно ссылаться не только на общий документ с целью, но и док с прогрессом. Автоматически программы так умеют уже создавать файлы. Но мы сами попадали и другие пользователи жалуются - автоматические файлы от ИИ легко теряются навсегда. Локальный файл надежнее. 4. В новостях постоянно рассказывают как ИИ строит компиляторы и игры за один промпт "просто купи подписку и так же сможешь". Но в реальности нет. Придется избавляться от багов. Часами, неделями. И чтобы баги не повторялись - надо завести ещё один файл, где будут указаны особенности проекта, известные баги и способы их обхода. 5. В итоге так выглядит промпт для нового диалога (или промпта проекта): Изучи структуру и файлы проекта. Прочитай readme, devlog, bugs файлы. Там ведётся этот проект и обьяснены особенности. Внеси изменения туда, после новых изменений, подтвержденных по качеству пользователем. — а дальше пишем саму задачу на новую фичу. Иначе модель начнёт пилить код неглядя, поверх существующего. Двойной-тройной интерфейс? пожалуйста. 6. Бекапы. Руками берём рабочую папку и кладём в архив после каждых значимых апдейтов. Ну или используем Гит, если умеем. 7. Один проект - одна модель. Надо определиться, что если используем Claude - используем только их ряд моделей. Если гугл - только их. У них разный подход к написанию кода. Если мешать между собой - работать будет плохо. Например, модели по-разному пишут названия переменных. Клод напишет "Apple_fruit_item", гугл напишет "item_apple". Если ехать на одной модели - это будет совместимо. На двух - нет. Это разные датасеты и развесовка моделей. Но допустимо набросать в первых итерациях код на Opus, а потом перейти на gemini pro. 8. Нерешаемые баги можно пробовать закидывать в другие модели. Но главное в багфиксе - дать контекст модельке что делали раньше и какая логика. Меняли тут 1-2-3, может что-то старое осталось и мешает, проверь. 9. ИИ делает ошибки, это нормально. Частая ситуация: попросили ии сделать фичу, а фича не работает. Можно просто откатить изменения и прогнать агента пару раз по задаче, пока не получится сделать с первого раза. Это лучше, чем править баги потом у полу-работающего решения. Если не получается сделать фичу с нуля при 4х попытках - проблема в другом. 10. Не стоит переусложнять инструкции для агентов. Для того чтобы курсор\антигравити хорошо работали - в компаниях работают целые отделы. И старый промпт, скопированный из интернета в духе "думай как инженер, не пиши код без подтверждения и тд" - может вмешаться в современные инструкции моделей. А внимание модели уделяют очень много таким инструкциям. В итоге можно сделать хуже. Что выбрать? - На начало 2026 по цена\качество выигрывает antigravity. Купил на месяц - месяц можешь кодить. Курсор стоит раз в 5 больше. - Opus - планирование, нерешаемые задачи