Вайбкодинг с нуля: как сделать свой проект с ИИ и не потерять контроль

Что такое вайбкодинг и чем работать

Первый проект начинается с понятной задачи

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

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

Поэтому полезно с самого начала договориться о результате, который можно проверить. Не «сделай красивое приложение», а «после добавления и перезагрузки запись остаётся; экспорт содержит именно мои записи; неверная ссылка не превращается в кнопку запуска кода».

Документация инструментов проверена 26 октября 2026 года. Ниже — самостоятельный учебный маршрут Neurosaver, а не пересказ чужого личного опыта. Поводом стал материал Павла Молянова на vc.ru. Названия меню, доступность функций и условия подписок меняются; устойчивые приёмы отделены от особенностей отдельных продуктов. Инфографики объясняют процесс, а не показывают реальные интерфейсы.

Оглавление

• Что называют вайбкодингом
• Как выбрать среду и не перепутать её с моделью
• Сколько это стоит и что оплачивается отдельно
• Как выбрать первый проект
• Что подготовить перед началом
• Первый запрос и короткое техническое задание
• Сквозной пример: каталог референсов
• Как работать небольшими этапами
• Как проверять приложение
• Как исправлять ошибки и давать правки по дизайну
• Как сохранять код, данные и настройки
• Что нельзя доверять браузеру
• Как дать агенту безопасный доступ
• Память проекта, навыки и параллельная работа
• Публикация и последующая поддержка
• Когда нужен разработчик
• Частые вопросы и источники

Что называют вайбкодингом — и где кончается эксперимент

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

Различие существенное. Для одноразовой анимации без чужих данных можно позволить себе больше экспериментов. Для сервиса с оплатой и личными кабинетами визуальной проверки недостаточно. Чем выше цена ошибки, тем меньше решений стоит принимать по принципу «вроде работает».

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

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

Как выбрать среду и не перепутать её с моделью

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

Способ работы	С чего удобно начать	Что выяснить заранее
Обычный чат	Обсудить идею, разобрать ошибку, получить небольшую заготовку	Может ли он работать с файлами и проверять результат, а не только присылать код
Агент в приложении или редакторе	Развивать проект в своей папке, запускать тесты, исправлять несколько связанных файлов	Какие команды и сетевые действия ему разрешены; где выполняется код
Браузерный конструктор	Быстро собрать интерфейс и получить предварительный адрес	Можно ли забрать код и данные, где сервер, как устроены публикация и расходы
Агент в облачном репозитории	Передать ограниченную задачу и получить изменения для проверки	Доступны ли зависимости и тестовые данные; кто проверяет и принимает изменения

В Codex можно работать с выбранной папкой проекта; отдельные варианты предусмотрены для терминала, редактора и облачной среды. Начальный путь лучше сверять с официальной инструкцией, а не искать кнопку по старому скриншоту.

Claude Code подходит для работы с существующим кодом и последовательных изменений. Anthropic рекомендует сначала разобраться в задаче, затем составить план, выполнить изменение и проверить его. Для мелкой понятной правки подробный план избыточен. Практики Claude Code.

Cursor объединяет редактор и агента. Это полезно, если вы хотите видеть рядом файлы, изменения и диалог. Его правила проекта помогают передавать повторяющиеся ограничения без длинного вступления в каждом запросе.

Lovable — пример конструктора, где нужно отдельно проверить переносимость результата. У него есть синхронизация с GitHub, но копия кода сама по себе не переносит рабочую базу, ключи и подключённые сервисы. Наличие кнопки экспорта не отменяет пробного восстановления.

GitHub Copilot cloud agent работает с задачей в репозитории и возвращает изменения для проверки. GitHub отдельно рекомендует ограничивать объём задачи и описывать критерии приёмки. Это полезный путь для проекта, у которого уже есть репозиторий и понятные проверки. Рекомендации GitHub.

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

Сколько это стоит и что оплачивается отдельно

У проекта обычно несколько разных расходов. Подписка на помощника оплачивает работу в определённой среде. Хостинг — доступность вашего сайта или бота. Запросы из готового приложения к внешней нейросети могут оплачиваться по отдельному API. Ещё могут понадобиться домен, хранилище файлов, отправка писем и резервные копии.

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

Перед подключением сервиса полезен такой запрос:

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

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

Подготовка проекта и первый запрос

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

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

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

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

Фраза «пока без» помогает закончить работу. Это не отказ от развития. Просто каждый новый внешний сервис добавляет настройки, права, расходы и ещё один способ потерять данные.

Что подготовить перед первым запросом

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

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

Попросите агента объяснить, что установлено и чего не хватает. Не обязательно заранее выбирать язык и набор библиотек. Но у выбора должно быть простое основание. Для нескольких полей ввода и локального хранения может хватить HTML, CSS и JavaScript. Если агент предлагает сервер, очередь задач и несколько баз, стоит спросить, какая конкретно функция требует каждого компонента.

Первый запрос: описание задачи вместо роли «сеньор с двадцатилетним опытом»

Роль в запросе не заменяет сведения о пользователе, данных и результате. Агенту нужно знать, какую работу вы хотите изменить и по каким признакам примете решение.

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

Хочу небольшой каталог референсов для себя.
Я добавляю название, ссылку и одну метку; потом ищу запись по названию.
Нужны удаление записи и экспорт всех записей в JSON.
Данные пока хранятся только в этом браузере. Регистрации и сервера нет.
Нужна работа с клавиатуры и аккуратный вид на телефоне.

До написания кода:
1. Перескажи задачу и задай вопросы, от которых зависит реализация.
2. Предложи минимальный состав файлов и объясни выбор.
3. Запиши проверяемые критерии готовности.
4. Отдельно перечисли то, чего в первой версии не будет.

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

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

На этом же этапе полезно решить судьбу ошибок. Пустое название не должно добавлять пустую карточку. Недопустимый адрес должен дать понятное сообщение. Если браузер не разрешает сохранить данные, приложение не должно уверенно писать «сохранено».

Сквозной пример: каталог референсов

У нашего учебного каталога есть три слоя. HTML описывает поля и кнопки. CSS задаёт оформление. JavaScript проверяет ввод, хранит записи и обновляет список. Это достаточно маленький пример, чтобы не потерять связь между запросом и результатом.

Данные сохраняются в localStorage — хранилище браузера для определённого источника страницы. Они переживают обычную перезагрузку, но это не облачная база и не резервная копия. В другом браузере коллекции не будет, а очистка данных сайта может её удалить. Поведение для страниц, открытых прямо как file:, не стоит считать надёжной основой; пример запускается через локальный HTTP-сервер. Документация MDN.

Что входит в первую версию

Название ограничено разумной длиной, адрес принимает только http и https, метка остаётся обычным текстом. При показе записи текст не вставляется как HTML. Поэтому строка с угловыми скобками остаётся строкой, а не новым элементом страницы. Это полезно проверить даже в игрушечном каталоге: безобидный пример быстро превращается в основу следующего приложения.

Для поиска мы сравниваем название и метку без учёта регистра. Кириллица работает так же, как латиница. Записи с одинаковыми названиями допустимы; каждая имеет свой идентификатор, поэтому удаление одной не должно задевать остальные.

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

Как попросить первую сборку

Можно скачать исходники учебного каталога: в архиве HTML, JavaScript, тесты и инструкция, без ключей и внешних зависимостей приложения. Это стартовая версия для изучения, не многопользовательский сервис.

В распакованной папке, если установлен Python, локальный запуск выглядит так:

python -m http.server 8091 --bind 127.0.0.1

Откройте http://127.0.0.1:8091/. Чтобы остановить сервер, нажмите Ctrl+C в его окне. При установленном Node.js команда node --test model.test.mjs запускает проверки логики. Мы также проверили добавление, поиск, сохранение после перезагрузки, повторный импорт без дублей, отмену удаления и обработку отказа хранилища в браузере. Это проверка данного примера, не гарантия безопасности будущих доработок.

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

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

Разработка, проверка и исправления

Как работать небольшими этапами

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

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

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

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

Как проверять приложение, если вы не умеете читать весь код

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

Проверка каталога	Что должно произойти
Добавить название на русском и ссылку HTTPS	Появляется одна новая запись
Попробовать добавить пустое название	Записи нет, причина объяснена рядом с формой
Ввести javascript:alert(1) вместо адреса	Адрес отвергнут, исполняемая ссылка не создаётся
Написать HTML-тег в названии	Тег показывается как текст, не исполняется
Найти запись другой раскладкой регистра	Находится ожидаемая запись
Перезагрузить страницу	Состав коллекции сохраняется
Отменить удаление	Запись остаётся
Экспортировать и импортировать коллекцию	Данные восстановлены без самопроизвольных дублей
Импортировать повреждённый файл	Прежняя коллекция остаётся целой
Запретить запись в хранилище	Приложение сообщает об ошибке и не обещает сохранение

Автоматические тесты помогают повторять эти действия после изменений. Проверка отдельной функции отвечает, правильно ли разбирается адрес. Браузерный тест отвечает, может ли человек заполнить форму и увидеть запись. Это разные уровни, и один не заменяет другой. В Playwright тест выполняет действия в браузере и сравнивает получившееся состояние с ожиданием.

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

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

Как сообщать об ошибках и исправлять дизайн

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

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

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

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

Данные, доступы и память проекта

Как сохранять код, данные и настройки

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

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

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

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

Перед большой правкой попросите назвать точные объекты восстановления. Каким коммитом восстановится код? Какой файл вернёт записи? Какие секреты потребуются после переноса? Затем выполните пробное восстановление в отдельной тестовой папке или среде. Не стоит впервые узнавать ответ во время аварии.

Что нельзя доверять браузеру

Браузер пользователя — не место для секретного API-ключа. Файл .env помогает передать настройки приложению, но не является сейфом. Если сборщик включил значение в JavaScript, посетитель сможет его получить. Ключ, дающий платный или административный доступ, должен оставаться на серверной стороне с ограниченными правами. Разделение клиентской и серверной логики в Lovable.

То же касается доступа к данным. Скрытая кнопка «Администратор» не запрещает отправить запрос напрямую. Сервер должен проверить, кто делает запрос и имеет ли право на эту запись. Для некоторых баз это дополняется правилами доступа к отдельным строкам — например, Row Level Security в Supabase. Само наличие RLS ещё не доказывает, что правила написаны правильно: полезен тест с двумя разными пользователями.

Если секрет уже попал в публичный репозиторий, удалить его из последнего файла недостаточно. Он мог сохраниться в истории и копиях. Пострадавший ключ нужно отозвать и заменить, затем выяснить последствия. GitHub отдельно описывает поиск секретов и действия при утечке.

Как дать агенту доступ и не превратить проект в полигон

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

Разделяйте разрешение читать код, изменять учебные файлы, устанавливать зависимости, обращаться к внешним сервисам и публиковать результат. Это разные уровни риска. В Codex для этого предусмотрены ограничения среды и согласование действий; в Cursor также описаны защитные механизмы и их ограничения. Не стоит отключать их просто потому, что запросов стало много.

Подключение MCP не делает инструмент автоматически безопасным. Проверьте, какие действия он предоставляет: посмотреть таймлайн, открыть документ, выгрузить файл или удалить запись. Агенту, который только анализирует проект, не нужен инструмент массового удаления.

Содержимое сторонних страниц и файлов не должно менять вашу задачу. Если инструкция из README требует передать ключ автору репозитория, это не штатный этап установки. Незнакомую зависимость и её установочные скрипты стоит проверить до запуска. OWASP Top 10 полезен как карта типичных рисков, но не заменяет аудит конкретного приложения.

Память проекта: что оставить следующей сессии

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

Для небольшого каталога достаточно такой структуры:

reference-catalog/
  README.md          как запустить и проверить
  AGENTS.md          обязательные правила для агента
  docs/
    product.md       что делает первая версия и чего не делает
    decisions.md     существенные решения и их причины
    checks.md        сценарии проверки
  src/               код
  tests/             проверки

Это предложение для учебного проекта, не обязательный формат всех инструментов. Codex читает AGENTS.md; у Claude Code есть свои правила загрузки инструкций и памяти; у Cursor — правила проекта. Не нужно заводить несколько независимых противоречащих инструкций только ради поддержки разных приложений. Лучше один набор решений и короткие входы к нему.

В память стоит записывать то, что изменит следующую работу: данные локальные, ссылки только HTTP/HTTPS, публикация требует согласования, импорт заменяет коллекцию после подтверждения. Полный журнал каждого исправления не должен загружаться перед сменой цвета кнопки. OpenAI также рассматривает файлы этапов и контекст проекта как полезные соглашения, а не обязательные имена для всех репозиториев.

Когда пригодятся навыки и несколько агентов

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

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

Публикация и границы самостоятельной работы

Как опубликовать проект и не перепутать это с сохранением

Локальное приложение доступно у вас. Репозиторий хранит исходники. Хостинг запускает или раздаёт приложение посетителям. Это три разных состояния. Иногда отправка кода запускает автоматическую публикацию, иногда нет — выясните связь до первой отправки.

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

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

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

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

Когда нужен разработчик — даже если прототип уже красивый

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

Признаки, что проект перерос спокойный эксперимент: вы не можете объяснить, где настоящая база; не знаете, как восстановить записи; агент предлагает заменить всю систему ради одной ошибки; проверка проходит только после отключения защиты. Ещё один сигнал — код без объяснения перестал обновляться из-за несовместимых зависимостей.

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

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

Следующий шаг после небольшого приложения — монтаж и моушн-графика с ИИ-агентом: там тот же цикл задания и проверки применяется к кадрам, движению и экспортированному видео.

Вопросы, выводы и источники

Частые вопросы

Нужно ли писать запросы по-английски?

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

Можно ли всё сделать бесплатно?

Небольшой локальный пример может не требовать платных внешних сервисов. Доступ к агенту, ограничения выбранной среды, сервер и API рассматриваются отдельно. Бесплатность первой попытки не гарантирует бесплатную работу опубликованного сервиса.

Если тесты зелёные, можно публиковать?

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

Можно ли перенести проект к другому агенту?

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

Что стоит унести в свой первый проект

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

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

Источники и границы проверки

Проверено по официальным материалам на 26 октября 2026 года:

• Codex: начало работы, согласование действий и безопасность, AGENTS.md.
• Claude Code: практики работы, память, границы контрольных точек.
• Cursor: безопасность и правила.
• Lovable: безопасность и GitHub.
• GitHub: ограниченные задачи для агента, поиск утёкших секретов.
• Git: фиксация изменений, Playwright: браузерные проверки, MDN: localStorage, Supabase: доступ к строкам, OWASP Top 10.

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