Нанять разработчика или создать с ИИ? Как решить

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

Что даёт каждый вариант

Мы намеренно не называем здесь ставки или зарплаты: они сильно различаются по стране, опыту и проекту, и любое отдельное число будет вводить в заблуждение. Лучше получить две-три сметы под один и тот же письменно описанный объём работ. Сколько стоит создать приложение разбирает, что определяет цену.

Когда лучше создавать с ИИ

• Вы проверяете идею. Цель — понять, нужна ли она кому-то, а не идеальный код. См. как проверить идею приложения.
• Приложение в основном CRUD. Создать, прочитать, обновить, удалить: формы, списки, записи, дашборды. ИИ-конструкторы с этим справляются хорошо.
• Вы много будете итерировать. Передумать стоит одного промпта, а не запроса на изменение.
• Это внутренний инструмент. Небольшая известная аудитория прощает шероховатости и подскажет, что не так.
• Бюджет ограничен. Вы предпочли бы потратить деньги на привлечение пользователей, а не на разработку.
• Вы хотите понимать свой продукт. Создавая его сами, вы узнаёте, где на самом деле сложность.

Что это требует от вас: чётких описаний, терпения при тестировании каждого изменения и честности, когда вы выходите за пределы своих знаний.

Когда лучше нанять разработчика

• Платежи, движение денег или финансовая отчётность сверх стандартной оплаты.
• Чувствительные данные — здоровье, данные детей, государственные идентификаторы — где ошибки несут юридические последствия.
• Сложные интеграции с устаревшими системами, нестандартными API или данные, которые должны быть идеально синхронизированы.
• Производительность и масштаб — тяжёлые функции в реальном времени, обработка больших объёмов данных, много трафика.
• Нативные мобильные приложения для App Store и Google Play, если адаптивного веб-приложения недостаточно.
• Приложение уже является вашим бизнесом. Платящие клиенты делают простой и потерю данных дорогими.
• У вас нет времени. Создание с ИИ всё равно требует часов вашего внимания; если вы не можете их уделить, заплатите тому, кто может.

Гибридный путь: сначала ИИ, потом разработчик

Это всё более распространённый и часто самый разумный путь:

1. Запишите, что вы создаёте. Короткое ТЗ делает всё дальнейшее лучше. Как написать PRD с помощью ИИ содержит шаблон.
2. Создайте первую версию с ИИ. Держите её маленькой: один поток, который доказывает идею.
3. Покажите её реальным пользователям. Узнайте, что важно, прежде чем тратить больше.
4. Экспортируйте код или подключите его к GitHub. Разработчику нужен реальный код, а не скриншоты.
5. Сначала наймите разработчика для проверки. Небольшая фиксированная задача: проверить безопасность, работу с данными и структуру, и составить список того, что он бы изменил.
6. Решите на основе его выводов. Доработать и расширить существующий код или переписать части, которые не масштабируются.

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

Если нанимаете: как сделать это хорошо

Подготовьтесь до разговора с кем-либо

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

На что смотреть

• Релевантные работы, которые можно использовать. Живые приложения, а не только скриншоты.
• Как они общаются. Задают ли они хорошие вопросы о ваших пользователях или только о технологиях?
• Письменная смета, привязанная к объёму работ, с указанием, что происходит при изменении объёма.
• Владение. В договоре должно быть указано, что код принадлежит вам, а аккаунты (хостинг, домен, база данных, платёжный провайдер) оформлены на вас.
• Передача проекта. Документация, доступ к репозиторию и понятно, как запускать приложение без них.
• После запуска. Кто исправляет ошибки, как долго и за сколько.

Начните с малого

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

Если создаёте с ИИ: как сделать это хорошо

• Описывайте продукт, а не код. Пользователи, потоки, данные, права доступа. См. как писать промпты для ИИ-конструкторов приложений.
• Одно изменение за раз, протестированное перед следующим.
• Используйте контрольные точки, чтобы откатить неудачное изменение.
• Относитесь к безопасности серьёзно: вход на каждой приватной странице, пользователи видят только свои данные, секреты вне кода.
• Оставляйте путь к выходу открытым. Выбирайте инструмент, который позволяет экспортировать код или синхронизировать его с Git-репозиторием, чтобы разработчик мог подхватить проект позже.
• Знайте свои пределы. Если вы трижды просили исправить одно и то же, а оно всё ещё не работает, возможно, пора показать код разработчику.

Тревожные признаки на любом пути

Некоторые сигналы говорят, что выбранный путь не работает.

Создание с ИИ не работает, если…

• Один и тот же баг возвращается после нескольких попыток его исправить.
• Вы не можете понять, безопасно ли это. Вы не знаете, кто видит какие данные, и не можете это проверить.
• Каждое изменение ломает что-то ещё. Приложение разрослось так, как никто не планировал.
• Вы тратите больше времени на исправления, чем на обучение на отзывах пользователей. Смысл быстрой сборки — учиться; если это перестало работать, пересмотрите подход.

Ничто из этого не означает, что нужно начинать заново. Обычно это значит, что пора показать то, что у вас есть, разработчику.

Найм не работает, если…

• Вы не видите прогресса. Нет рабочей версии, которую можно потрогать, после первого согласованного этапа.
• Сметы постоянно растут без изменения объёма работ.
• Аккаунты и код оформлены не на вас. Исправьте это немедленно, что бы ещё ни происходило.
• Вы не понимаете, за что платите, а на вопросы отвечают расплывчато.

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

Краткое руководство по выбору

Создание первой версии в Mythex

Mythex — ИИ-конструктор приложений для пути «сначала сделай сам»: вы описываете приложение, ИИ-агент пишет код и запускает его в живом превью, добавляет базу данных при необходимости и публикует по настоящей ссылке. Он создаёт веб-приложения, которые работают на телефонах, а на Pro может упаковать их как Android- и iPhone-приложения для Google Play и TestFlight. Когда вы будете готовы привлечь разработчика, на Pro можно экспортировать проект или синхронизировать его с собственным репозиторием GitHub (GitHub и экспорт), а полноценный редактор кода позволяет разработчику работать прямо в проекте. Что входит в каждый тариф, см. на странице с ценами.

Вопросы