Первый проект с ИИ: как дойти от идеи до рабочей версии

Проект, который пришлось начать заново

Я хотел сделать ИИ-сервис для владельцев животных. Рассказал агенту идею, он принялся писать приложение. Описание получилось расплывчатым, поэтому в основу, особенно в базу данных, попало много лишнего. Часть возможностей осталась заготовками, другие я пытался доделывать. Несколько дней переделок спустя проект стало проще начать заново, чем понять, что в нём уже работает.

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

Сначала опишите путь пользователя

Представим учебный дневник ухода за собакой. Хочу записывать покупку корма и визит к грумеру, видеть историю и исправлять ошибку. Фраза «сделай сервис для питомцев» не сообщает, нужен ли семейный доступ, несколько животных, напоминания и подписка. Агент вполне может добавить всё это сам — формально идея позволяет. Только пользоваться первой версией мне нужно совсем иначе.

Мне проще наговорить задачу обычным языком: «Пока пользуюсь один и только на компьютере. Открываю карточку питомца, добавляю запись с датой, позже могу её исправить. Закрыл программу, открыл снова — запись на месте. Напоминания и другие пользователи пока не нужны». Здесь есть действия и проверяемый результат. Не требуется заранее знать, какие файлы и таблицы создавать.

Прежде чем агент начнёт писать код, я прошу коротко пересказать, что он понял, и назвать недостающие решения. В рекомендациях OpenAI для Codex тоже есть совет дать агенту расспросить вас о сырой идее. В нашем примере одно уточнение сразу меняет объём: записи должны открываться только на компьютере или ещё с телефона? Для пользователя это «ещё один экран», для приложения — новая задача. После разговора полезно сохранить договорённость рядом с проектом, а будущие идеи — отдельно.

Маленькая версия должна работать по-настоящему

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

Для макета заглушка допустима, если о ней сказали заранее. Для рабочего дневника мой критерий другой: карточка создаётся, запись сохраняется, исправляется и остаётся после повторного запуска. Этого мало по числу возможностей, зато весь путь завершён. Если агент предлагает временную имитацию, я прошу показать её место и объяснить, зачем она нужна.

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

Как объяснить дизайн, когда «красиво» не помогает

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

Макет почти всегда показывает идеальные данные: короткое имя, три аккуратные записи и ни одной ошибки. Реальная программа начинается с пустого экрана. Потом в неё вводят длинный текст, открывают на узком телефоне или получают сбой. Поэтому я отдельно прошу продумать пустое состояние, ошибки и размеры экранов, а после реализации смотрю на результат сам. Замечание «заголовок вылезает за карточку» куда полезнее, чем «сделай симпатичнее». И нарисованный шрифт ещё не означает, что такой шрифт существует в готовом файле.

Три вещи, которые стоит освоить сразу

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

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

Третье — данные. Git хранит файлы проекта, но не воскресит удалённые записи из базы. Если агент предлагает Docker, я прошу объяснить, где будут лежать данные после пересоздания контейнера. Постоянное хранилище и резервная копия — отдельные решения. Проверять их стоит до того, как дневник наполнится важными записями.

Проверяйте как пользователь, а не только как заказчик кода

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

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

Я читаю сообщения агента по ходу работы. Однажды он ушёл слишком глубоко в исследование, хотя для решения уже хватало сведений. Полезный вопрос в такой момент: что конкретно мешает продолжить и как это относится к текущей задаче? Для большого изменения сначала обсуждаю короткий план и вычёркиваю лишнее. Для замены одной надписи большого совещания не требуется.

Когда сломалось и когда пора открыть новый чат

Если запись исчезает после обновления страницы, фраза «всё сломалось» почти не помогает. Лучше написать: «Добавляю запись, нажимаю сохранить — она видна. Обновляю страницу — записи нет. Повторил дважды. Вот сообщение в консоли». После исправления повторяю именно эти шаги. Скриншоты полезны, если на них нет паролей, ключей и чужих данных.

Со временем чат обрастает попытками и вариантами, которые уже не нужны. Я сохраняю постоянную документацию: что делает проект, как его запускать, где правила и данные. Отдельно пишу короткую передачу состояния: что сделано, что проверено, что осталось. Например: «Записи сохраняются после перезапуска; поиск добавлен, но пустой запрос ещё не проверен». В новом чате агент сначала сверяет заметку с реальными файлами. Так легче продолжать без нового старта с нуля.

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