Когда чата уже мало: помощник внутри проекта

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

Первый шаг: установи агента и поговори с ним

Можно начать с Codex, Claude Code, Kimi Code, Cursor, Copilot или другого доступного тебе помощника. На старте не так важно угадать «самый лучший». Гораздо важнее открыть настоящий проект и выяснить, что выбранный агент умеет именно в твоём окружении.

Установи приложение по инструкции на его официальном сайте, войди в аккаунт и выбери папку для работы. Название кнопки зависит от программы: ищи действие вроде «Открыть папку» или «Добавить проект». Для Unreal Engine нужна папка с файлом .uproject, для сайта — папка с исходниками. Можно взять и наш about-me с одним HTML-файлом.

В ответах могут встретиться несколько сокращений. IDE — редактор кода вместе с инструментами проекта, CLI — управление программой командами через терминал, а MCP — протокол подключения внешних инструментов и данных к агенту. Если термин непонятен, попроси объяснить его на примере твоего проекта. А для начала отправь такой запрос:

Я открыл тебе папку проекта. Пока ничего не меняй. Изучи структуру и расскажи: в какой папке ты запущен, какие файлы видишь, можешь ли редактировать их и запускать команды. Есть ли у тебя способ собрать проект, открыть Unreal Editor или управлять им? Если прямого доступа нет, какие варианты подключения подойдут: CLI, MCP, плагин, расширение или отдельный скрипт? Не угадывай — отдели то, что уже доступно, от того, что ещё нужно настроить.

Ответ даст первое представление о возможностях помощника. Теперь попроси подтвердить их простым действием: прочитать README, найти .uproject или перечислить файлы в about-me. Так ты увидишь, что агент действительно работает с нужной папкой.

Когда стало понятно, что агент видит, можно дать первую настоящую задачу:

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

Не бойся прямо спрашивать агента: «Как мне дать тебе доступ к Unreal?», «Можешь ли ты обработать это видео?», «Какой плагин нам понадобится?» или «Можешь написать такое расширение сам?». Хороший агент не обязан уже уметь всё, но он может исследовать задачу, найти подходящий способ подключения и помочь его настроить.

Что такое harness

Ты устанавливаешь не просто языковую модель с полем ввода. В агентском приложении вокруг модели работает harness — обвязка, которая даёт ей контекст, доступные инструменты, работу с файлами, запуск команд, систему разрешений и цикл из нескольких действий. Codex, Claude Code и Kimi Code — готовые агентские продукты со своим harness. В разговоре harness нередко называют и всю такую программу целиком. Для первого знакомства этой разницы достаточно.

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

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

Какой инструмент выбрать

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

У Kimi есть и приложение для компьютера: режим Kimi Work позволяет работать с файлами в выбранной папке. А Kimi Code предназначен для терминала и поддерживаемых редакторов кода.

Для разработки мне также рекомендовали Google Antigravity. Сам я его пока не использовал. Это среда для работы с проектами, файлами, терминалом и браузером. На 9 сентября 2026 года у неё был бесплатный план с недельными лимитами; доступ зависит от страны и аккаунта. Перед установкой проверь текущие условия в FAQ.

Научи агента работать по-твоему

Допустим, агент уже сделал что-то полезное. В следующем чате хочется продолжить с этого места, а не заново объяснять весь проект. Для этого сохраним правила, удачные приёмы и короткую запись о том, на чём остановились.

В Unreal мы используем Coding Standard. Похожим образом можно сформулировать правила для помощника и сохранить их прямо в проекте.

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

AGENTS.md и CLAUDE.md: постоянная памятка для агента

У таких правил есть вполне конкретные имена. Codex читает файл `AGENTS.md`, а Claude Code — `CLAUDE.md`. Обрати внимание: AGENTS.md пишется во множественном числе, с буквой S. Это обычные Markdown-файлы. Чаще всего их кладут в корень проекта и сохраняют вместе с кодом, чтобы инструкции работали и у тебя, и у других участников команды.

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

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

Например, небольшой AGENTS.md может выглядеть так:

# Правила проекта

- Это проект на Unreal Engine 5 и C++.
- Для коллекций используй TArray, TMap и другие контейнеры Unreal.
- Перед созданием нового класса найди похожую реализацию в проекте.
- После изменения собери проект и сообщи, что удалось проверить.
- Не меняй плагины и настройки проекта без необходимости.

В большом проекте можно положить дополнительные файлы правил ближе к отдельным папкам. Например, общие требования оставить в корне, а особенности плагина описать внутри каталога плагина. Механика загрузки отличается: Codex при старте собирает AGENTS.md по пути от корня проекта до текущей рабочей папки, а Claude Code может подключить вложенный CLAUDE.md, когда начинает читать файлы в его каталоге. Если правила будто не работают, спроси агента, какие инструкции он загрузил.

Названия не взаимозаменяемы. Claude Code сам по себе читает CLAUDE.md, а не AGENTS.md. Если хочешь работать с Codex и Claude Code в одном проекте, не обязательно копировать правила дважды. Оставь общие инструкции в AGENTS.md, а рядом создай короткий CLAUDE.md:

@AGENTS.md

## Только для Claude Code

- Перед большой правкой сначала покажи план.

Строка @AGENTS.md подключит общие инструкции в Claude Code, а ниже можно оставить правила только для него. Сам файл правил тоже полезно попросить нейронку подготовить: «Изучи проект и предложи короткий AGENTS.md с командами запуска, проверками и принятыми соглашениями». Но перед сохранением обязательно прочитай результат. Агент может неверно понять структуру проекта или записать случайное решение как вечное правило.

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

Скилл: сохрани удачный процесс

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

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

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

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

Документация: память самого проекта

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

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

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

Полезно добавить это требование и в AGENTS.md или CLAUDE.md. Тогда новый чат сразу поймёт, где искать накопленные знания и когда их обновлять.

STATE.md: короткая передача работы следующему чату

Для текущего состояния удобно держать отдельный STATE.md в корне проекта. Это не обязательный стандарт Codex или Claude Code, а наша простая договорённость. В моём проекте MALENASTROM такой файл содержит четыре раздела: активная работа, следующий шаг, блокеры и последняя проверка незавершённых изменений.

docs отвечает на вопрос «как устроен проект и почему», а STATE.md — «на чём мы остановились прямо сейчас». Поэтому STATE.md не должен превращаться в многомесячный дневник. Завершённое переносим в документацию или историю изменений, устаревшее удаляем, а наверху оставляем только актуальный статус.

# Проект — оперативный статус

Обновлено: [дата]

## Активная работа
- Что сейчас меняется и в каком состоянии.

## Следующий шаг
1. Самое ближайшее проверяемое действие.

## Блокеры
- Что мешает продолжить или требует решения человека.

## Последняя проверка незавершённых изменений
- Что запускали, что прошло и что ещё не проверено.

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

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

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

Попробуй на своём проекте

Для первой пробы достаточно папки about-me из прошлого урока. Попроси агента прочитать страницу, внести одну небольшую правку и показать, что изменилось. Открой страницу сам, затем попроси записать способ запуска в документацию, а текущий результат и следующий шаг — в STATE.md.

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

Автоматизация, API и свой агент

Когда локальных инструментов становится мало, их можно соединять. Например, собрать цепочку в n8n: форма → обработка заметки моделью → проверка полей → таблица. Если ты знаком с Blueprint, соединение узлов будет выглядеть привычно.

Через API твоя программа сама обращается к модели. Так Telegram-бот получает сообщение, отправляет запрос и возвращает ответ пользователю. Здесь уже нужно учитывать стоимость запросов, ошибки соединения, безопасность данных и разделение пользователей.

Свой агент появляется, когда модель получает несколько инструментов и сама выбирает следующий шаг. Например, решает, какие заметки прочитать, когда вызвать поиск и когда остановиться. Собрать его можно в коде, визуальном конструкторе или поверх готового harness. SaaS — лишь способ отдать такую программу пользователям как онлайн-сервис; само слово ничего не говорит о сложности ИИ внутри.

Для обработки одного видео не обязательно сначала писать свой API-клиент. Начни с готового агента, спроси, какой инструмент ему нужен, подключи его и проверь результат. Если задача повторяется — оформи процесс в скилл. Если проект растёт — веди docs и STATE.md.

От первого запроса к вайбкодингу

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

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

1. Чат: «Подскажи, как это сделать»

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

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

2. Помощник в редакторе: «Давай напишем это вместе»

ИИ предлагает продолжение кода, объясняет выделенный участок и помогает с правками прямо в рабочей среде. Меньше копирования между окнами — проще оставаться в задаче. Такой подход есть, например, у GitHub Copilot.

Ты читаешь предложения и решаешь, что принять. Само нажатие Tab ничего не говорит о качестве кода, а объём доступного помощнику контекста зависит от конкретного инструмента и его настроек.

3. Агент: «Вот задача, доведи до рабочей версии»

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

Твоя работа — объяснить цель, обозначить границы и принять результат. «Готово» в чате ещё нужно подтвердить: открыть страницу, отправить сообщение боту или запустить игру. Иногда агент застревает, и тогда вместе разбираете причину.

4. Вайбкодинг: «Хочу, чтобы это ощущалось вот так»

Когда агент берёт на себя написание кода, появляется место для быстрых проб. Можно описывать поведение, показывать референсы и наговаривать правки:

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

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

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

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

Что будем вайбкодить дальше

У тебя уже есть основа: объяснить задачу → получить первую версию → проверить → попросить конкретную правку. Теперь этот же процесс можно применить к чему-нибудь своему.

В следующих бесплатных материалах Академии разберём отдельные задачи:

• Сайт-портфолио. Доведём страницу до сайта с проектами и опубликуем на GitHub Pages, чтобы можно было отправить ссылку.
• Telegram-бот с нейросетью. Пройдём путь от первого сообщения до ответа модели и разберём, что делать, если запрос не удался.
• Бот для Twitch. Подключим помощника к чату и продумаем, когда ему отвечать, чтобы он помогал, а не мешал стриму.
• Unreal Engine и свой плагин. Возьмём конкретную задачу в редакторе, дадим агенту нужные инструменты и проверим результат в движке.

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

Я буду показывать задачи, которые решаю сам: что получилось, где пришлось переделывать и какие нюансы стоит учесть. Это самостоятельные материалы — выбирай интересный тебе пример, проходить всё подряд необязательно. Раздел пополняется, так что заходи почаще =)

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