Transcription
Rules, Commands, MCP, Mods, hooks, Skills, Subendance. Вокруг разработки с кодовыми агентами существует огромное количество технологий, инструментов, подходов и практик. Но кажется, что это всё не должно быть таким сложным. Поэтому в сегодняшнем видео мы досконально по полочкам разложим, где и какие инструменты применять, и как сделать их использование по-настоящему эффективным. Мы рассмотрим небольшую ретроспективу о том, как развивались кодовые агенты и почему появились те или иные инструменты, какие задачи или проблемы они решали. Подробно рассмотрим каждый из инструментов, расширяющий возможности кодового агента, и в конце всё систематизируем и подведём практические итоги, как и что можно попробовать.
Начнём, конечно же, с эволюции экосистемы возможности в курсор. Когда только появились кодовые агенты, языковые модели постоянно галлюцинировали, забывали контекст, путались. Решением стало Решением стали правила. Простой плоский файл, который подкладывался в каждый диалог с агентом. Этот файл, разумеется, разрастался. Со временем его использование стало не таким эффективным. Решением этой проблемы стало появление Project Rules, которые позволили декомпозировать его на несколько отдельных. В конце года появился model contex протокол, который кодовые агенты поддержали в первую очередь. Кодовые агенты развивались и превратились из с функциями искусственного интеллекта в полноценные агентные системы. Появился запрос на автоматизацию. Ответом стали переиспользуемые промты в виде слшкоманд. Кодовые агенты эффективные, но как сделать их использование безопасным? Как сделать, чтобы не утекли твои пароли или агент случайно не удвалил базу данных или файловую систему? Ответ: технология детерминированных проверок в виде хуков. В конце двадцать пятого года появилась крайне эффективная технология skills. Курсор в начале двадцать шестого года поддержал её также как и технологию подогентов.
Кодовые агенты развивались, но одно оставалось неизменным. Это контекст, который при большом количестве инструментов, в большом количестве правил постоянно заполнялся для инструкций действительно ценных, ээ решающих задач пользователей, не оставалось места. И главное, что нужно понимать в разрезе управления контекстом, что есть э инструменты статического управления контекстом. К ним относятся в первую очередь правила и различные инструменты. Они всегда подкладываются в контекст, делают работу с агентом наиболее предсказуемой, но могут не так эффективно использовать драгоценные токены. Динамическое управление, например, Skills, это очень эффективное с точки зрения использования контекста технология, но уже зависит от возможностей той или иной модели.
И начнём с фундамента статического управления контекстом. Это правило. Правило, по сути, конституция проекта. Это инструкции, которые подкладываются в каждый диалог с агентом. В курсоре можно увидеть, какие правила подключены в виде вот такого такой плашки с иконкой линеечки, да. Это значит, что в этом диалоге по той или иной причине подключены вот эти вот правила. В курсоре существует четыре типа правил. Командные правила, они доступны для тарифных планов, э-э, больших команд и организаций. Следующее и наиболее распространённый вид правил - это проектные правила. Существуют также правила специфичные для пользователя, так скажем, личные или глобальные, а также поддержка инструкций, которые находятся в файле MD. Это открытый стандарт. Курсор его тоже поддерживает. Стоит отметить, что правила могут друг другу противоречить и при конфликте приоритет имеют более ранние. Формат описания правил - это обычный Markдаун в интерпретации курсора с небольшой вставкой метаданных вAM формате с некоторым количеством опций. Project Rules располагаются в специальной директории Cursor Rules и могут быть декомпозированы по областям, э, зонам ответственности, распределены по папкам. Все они будут использоваться. Причём в курсор поддерживается не только MDC формат, но и обычный Markу. Курсор существует четыре способа подключения правил. Первое - это правила, которые всегда присутствуют в контекстом окне. самые дорогие. А второе правило, которое агент сам решает, когда подключать, такой способ подключениние уже можно с натяжкой отнести к статическому управлению контекстом. Правила, которые агент будет подключать на основании шаблона расширений файла, правила, которые будут подключаться только, если пользователь будет в чате их упоминать явно.
Следующий тип правил - это user rules или такие глобальные правила. В таких правилах рекомендуется содержать какие-то рекомендации, не специфичные для конкретного проекта, да, а специфичные для пользователя ожидания по там стилю коммуникации, по предпочтениям, например, там способы объяснения лаконичный или наоборот подробное объяснение. -э, лично я в этих правилах также использую установку не создавать никаких дополнительных -э документаций без явного согласования с пользователем. Такое правило приходится применять при использовании модели от компании Anтропик, который на любой шаг, а, пытаются создать какую-то документацию. Agents MD - это стандарт, который поддерживает огромное количество инструментов. Курсор позволяет использовать иерархическое подключение этих файлов. То есть они могут располагаться в любом месте проекта. Если у вас, например, монорепозиторий, эээнд, фнEND или какие-то конкретные модули, то абсолютно все правила из любой поддиректории будут загружены и будут применяться. Чтобы создать правила, существует специальный раздел в настройках, в котором вы можете задать способ применения и в целом описать название, правила и рекомендации, которым агент должен следовать. В принципе, существует также быстрая команда, кнопочка создать правила с агентом, когда агент поможет создать правила автоматически. Правила постоянно будут находиться в контексте. Основная рекомендация делать их лаконичными. И эти правила должны легко читаться человеком и легко поддерживаться. Чем короче правила, тем лучше. Рекомендация, чего не стоит делать, не стоит копировать туда всю необходимую информацию, все вариации команд, которые агент и так знают, или какие-то корнеркейсы, или что-то, что вообще очень редко применяется. То есть, ээ, делайте этот документ лаконичным. И в работе с статическими правилами следует придерживаться простого принципа, что расширять их только после некоторого количества ошибок агента. Держать эти правила в системе контроля версий и при необходимости делиться с командой.
Следующая возможность называется команды или слэшкоманды. При вводе слэша появляется меню, в котором отображаются все доступные команды. Команды - это, по большому счёту, просто повторяемая инструкция, альтернатива прямо ту, которую бы вы копировали просто в диалог с новым агентом. И чаще всего это автоматизация вашей ежедневной рутины. Если вы в течение дня что-то делаете многократно, то можете это завернуть вот в такую вот инструкцию и быстрее применять в диалогах с агентом. Часто это делают какие-то задачи, связанные с системой контроляверсией, работа с гитхабом, работа с документацией или с качеством, запуск тестов, запуск линтеров и так далее. Но в целом вот такую вот повторяемую инструкцию можно настроить для любой деятельности, которая характерна для вашего собственного рабочего процесса.
Следующее расширение возможностей агента или возможностей больших языковых моделей - это model context Protocol или MCP. Это открытый стандарт, открытый протокол, который разработала компания Антропик и которая поддерживает огромное количество инструментов. И суть этого протокола или какую проблему он решает, то, что большие языковые модели, они достаточно мощные, много чего умеют делать, но совершенно оторваны от реального мира. не интегрировано с реальными системами, с которыми взаимодействуют пользователи. Да, они ничего не знают ни о гитхабе, ни о ваших базах данных, ни о каких-то там системах мониторинга и так далее. И вот этот протокол эту проблему решает, даёт возможности большой языковой модели взаимодействовать с внешним миром. в Курсор, в частности, да и в других инструментах аналогично MCP сервера, которые предоставляют доступ к тем или иным внешним сервисам, настраиваются с помощью Джейсона. В курсоре существует целая экосистема различных инструментов, которые позволяют взаимодействовать с внешними сервисами, базами данных, с браузером, возможно. И вы можете легко прямо с сайта Курсор добавить тот или иной инструмент. Также существует огромное количество каталогов, MCP инструментов, и вы можете выбрать себе подходящий или написать свой собственный и подключить его в курсор. Использование MCP-серверов. Курсор имеет ряд ограничений. И главное ограничение на самом деле связано с количеством подключаемых инструментов. Поскольку описание инструментов достаточно развесистые, и это машинночитаемый формат, то есть это JON, который описывает функции. При подключении всего лишь трёх MCP-серверов мы, а, в контексте получаем уже 93 инструмента, которые могут существенно повлиять на производительность работы с языковой моделью. И надо сказать, что, вообще говоря, использование MCP-серверов, оборотная сторона - это неэффективное использование, конечно же, контекста. И конкретно разработчики Курсора в этом направлении добились существенных улучшений, да? Да, то есть они внедрили технологию динамического подключения MCP инструментов, умудрились на там 50% практически сэкономить использование контекста.
Следующий инструмент - это режимы. Это, наверное, самый первый инструмент, который ээ вы видите, когда работаете с кодовым агентом. Всего в курсоре есть четыре режима. Ent debug и ask режимы они на самом деле определяют как бы так скажем профиль работы агента и то какими инструментами он может пользователя режим по умолчанию agent - это самая полная автономная реализация доступны все инструменты поиск по кодовой базе запись файлов выполнение команд выполнение mcp ну естественно с условием, что вы там либо разрешаете все инструменты, либо как-то настраиваете их использование. Второй режим - это режим ASК, когда агент не может ничего редактировать и создавать, он лишь отвечает на вопросы. То есть это такой как бы режим просто чата. И два режима особенно эффективных при разработке программного обеспечения. режим Plan mode и debug mode. На них сейчас остановимся подробней.
Режим планирования это режим, в котором агент не пишет код. Он исследует кодовую базу, задаёт уточняющие вопросы. Его задача- создать детальный план с архитектурой, если это необходимо, со всеми примерами кода, с какими-то соображениями, с логикой поведения. Когда он создал план, он ждёт вашего одобрения, вот или каких-то замечаний для корректировки этого плана. И конкретно случаи с планмодом это не только режим функционирования, но и ряд небольших интерфейсных удобств таких улучшений. Вот мы видим, а в диалоге с агентом результат планирования. То есть ээ агент создал план. Это визуально даже такой виджет в чате, который можно, э, открыть и посмотреть как ээ такую детальную страничку. Также есть элемент, который позволяет этот план сохранить в проект, да, и сделать этот план частью документации проекта, что, в принципе, разработчики Курсора рекомендуют делать. И мы в своей практике тоже этой рекомендации всегда следуем. Очень полезно. в дальнейшем при решении задач, при развитии проекта понимать, какие задачи были решены до этого, какие решения были приняты и почему. А также помимо описания всех шагов там детальной реализации, этот план содержит вот такой список ээ задач, по которым агент идёт, и отдельный из этих задач он на самом деле может выполнять параллельно. Как он это может делать, мы разберём ближе к концу. Цель формирования плана - это привести его в исполнение. И есть специальная кнопочка реализовать, по которой, собственно, агент начинает выполнение этого плана.
Deug mode предназначен для того, чтобы исследовать какое-то неочевидное поведение и ошибки, которые непонятно почему возникают, которые трудно исследовать. На самом деле разработчики курсор говорят, что это режим для исследования всяких заковыристых, так скажем, багов, типа утечек памяти или проблем там с производительностью, может быть. Но на моей практике даже самые простые вещи типа неправильных настроек или там неуказанного какого-нибудь ключа в конфигурации или в переменнах окружения тоже зачастую не так легко а исследовать. Вот и этот режим работает практически как действовал бы обычный разработчик. В этом режиме агент делает несколько предположений, да? То есть он исследует кодовую базу, он смотрит описание сути проблемы, предполагает, в каких местах может быть причина, да, возникновения некорректного поведения. Сделав эти два три предположения, он инструментирует всю цепочку вызовов дополнительными логами, да? То есть какие-то принты вставляет, записи в лог, в консоль браузера, возможно. А дальше инструктирует пользователя, что нужно сделать, чтобы попытаться эту ошибку воспроизвести. То есть предлагает шаги воспроизведения. Пользователь, следуя эти инструкции, всё проделывает, а агент в это время читает логи, анализирует, что происходит, делает какие-то выводы, исправляет ошибку и, соответственно, вот в таком ключе продолжает двигаться. Если ошибка исправлена, хорошо. Если не исправлена, делает новые предположения. Ну и так как бы до тех пор, пока проблема не будет решена.
Следующая возможность называется hooks. - это единственный, наверное, детерминированный инструмент, которым пользуется агент. Аа есть два типа хуков. По умолчанию используется Command based hook, то есть это конкретная программа, скрипт, который запускается на то или иное действие. Вот. И как раз-таки Command base hook - это детерминированное поведение. И есть на самом деле второй тип хуков prompt based hook. И это возможность оценить какие-то данные с помощью. Ну и это, очевидно, уже как бы поведение не такое детерминированное, да, потому что интерпретация происходит с помощью большой языковой модели. Куки в работе с кодовыми агентами, они могут применяться совершенно для разных задач. Например, а при управлении жизненным циклом. э мы начали сессию или мы вызываем инструмент какой-то или мы редактируем файл или мы закончили редактировать файл или мы запустили сабагента или, например, это команды, которые запускаются с, например, для обеспечения безопасности и контроля. Например, когда мы запускаем какие-то команды в терминале, да, или какие-то MCP инструменты, выполняем файловые операции, которые могут быть потенциально опасными. Ну и, конечно, всё, что связано там с использованием промтов, контекстом. Даже можно использовать Хук при сумморизации контекста. Пуки могут применяться не только в работе с агентом, но и отдельно на inлай автодополнение.
Чтобы понимать, что такое хук, на самом деле проще всего рассмотреть на примерах. То есть представим, что агент хочет выполнить какую-то операцию. Как гарантировать, что это не будет удаления без подтверждения вообще всех файлов в проекте, да, не дай бог, или всех файлов на сервере? Вот, пожалуйста, хук, который выполняется до вызова команды в терминале, и он запускает Python Script, который будет проверять вход этой команды. Python script мог бы выглядеть как проверка наличия всяких таких зловредных опций, да, и результатом разрешения или блокировка данной операции. Или, например, мы бы не хотели, чтобы агент передал большую языковую модель какие-то наши чувствительные данные. Пароли от базы данных или токены от Гитхаба или Телеграма, или ещё там от ээ Open AI, например. Точно также создадим э команду, которая будет выполняться перед тем, как агент будет читать файл. И если в этом файле есть какие-то чувствительные данные, мы их можем замаскировать, удалить. ну, сделать всё, что мы считаем нужным. Или, возможно, мы бы хотели, чтобы у нас автоматически выполнялись какие-то как бы задачи, связанные с принятыми на проекте соглашениями. Ну, например, там автоматическое форматирование после редактирования файла агентом. То есть это, понятно, наверное, не самый такой типовый кейс, потому что есть миллион других способов, но, в общем, как бы как пример одного из применений тоже вполне себе годится.
Следующий инструмент - это skills. В прошлом видео я проводил такую аналогию между, а-э, статическими правилами и такими динамически подключаемыми навыками, да, и статическое правило - это такая лампочка, которая горит постоянно и постоянно жжёт электричество или наши драгоценные токены. А Skills - это такой датчик движения, да, который включается только по необходимости. И Skills - это оченьочень мощная технология, да, очень хороший стандарт, который делает использование агентов крайне эффективными и с точки зрения использования контекста, и с точки зрения, на самом деле, эффективности. Ал - это такой пакет инструкций, знаний о предметной области плюс дополнительных возможностей, включая исполняемые скрипты, а какую-то дополнительную документацию, а также различные шаблоны, например, конфигураций, каких-то документов, ээ каких-то данных. скилы в своих инструкциях могут использовать другие способы автоматизации, например, э, переиспользуемые промты в виде слш-команд или, например, хуки. А вот как выглядит э навык, да, это обычный Markdown файл с небольшой шапкой из Yamel метаданных, небольшой в буквальном смысле, да? А метаданные включают название скила и очень краткое описание. Очень краткое - это буквально стандарт ограничивает размер, который вы можете использовать. И делается это не просто так. При применении ээ навыков или скилов действует, так скажем, ленивый процесс загрузки. То есть, а все доступные скилы помещаются в контекст в объёме лишь вот этой шапки с метаданными, то есть название плюс desрипtion. Аа и всё остальное тело и все необходимые дополнительные артефакты, документации или какие-то скрипты. Они все загружаются уже по мере необходимости, по мере того, как агент, например, решит, что тот или иной навык он подходит для решения задачи. В данном случае, э, ключевая роль, вообще говоря, в эффективном использовании скилов, если мы говорим об автоматическом, да, неявном использовании это, конечно же, описание. То есть описание должно максимально чётко описывать -э и инструктировать агента, в каком случае стоит использовать данный навык. И надо сказать, что это открытый стандарт, который поддерживают ээ различные кодовые агенты, включая два самых-самых популярных:Дкод, кодекс. И, например, если вы в команде используете такой разнородный инструментарий, то курсор поддерживает импорт правил из других инструментов. То есть на уровне проекта или на уровне пользователя он позволяет, например, импортировать скилы, которые предназначены для клодкода или кодекса. Начиная с версии 2.4, в которой, собственно, и появилась поддержка э-э скилов и сабагентов, появилась также команда миграции статических правил в определённом объёме в, собственно, динамически обнаруживаемые навыки. И, ну, вот есть ряд ограничений, да, что те правила, которые созданы с типом подключения автоматическим, да, когда агент сам решает, они превращаются в обычные навыки. А слш-команды - это, по сути, команды, которые вы явно используете в диалоге в чате. Они превращаются в скилы со специальной опцией, в которой ээ которая несёт тот же самый смысл, да? То есть это скилы, которые не могут быть использованы автоматически, у которых стоит опция disable model invocation true, то есть отключить автоматическое выполнение этого навыка. Это нужно для всяких вот таких вот операций чувствительных, да, взаимодействие там с файловой системой, с удалёнными серверами и так далее.
Про открытый стандарт я уже сказал, но не сказал, что очень-очень быстро в этот раз, в отличие от MCP протокола, которые там полгода или дольше раскачивались ээ все в экосистеме инструментов, да, в данном случае быстро поддержали топовые игроки, и как следствие появилось огромное количество, буквально каталоги там с сотнями тысяч навыков. Да, которые можно вдохновляться или использовать, если они вам подходят. Вот компания Антропик сделала ряд таких э пакетов по работе с офисными форматами документов. Навык, который позволяет делать не такой AI генерируемый дизайн, а какой-то более уникальный. Ну и как бы различные навыки, которые собирают лучшие практики использования той или иной технологии. фронт разработки, а-а, использования базданных и так далее. Есть куча маркетплейсов, есть удобные консольные утилиты для установки скилов к себе в проект. Но самая большая, конечно, ценность, если вы свои собственные, э, рабочие процессы будете упаковывать вот в такие наборы навыков. С учётом того, что можно использовать ээ исполняемые команды и шаблоны документов, это просто бескрайня область для автоматизации ваших процессов.
И последняя технология называется сабагенты. Сабагенты - это такие независимые, специализированные агенты. И у погентов есть ряд особенностей и или, так сказать, преимуществ. Это первое и самое главное - это собственное контекстное окно. То есть запускаемый погент, он будет иметь свой контекст, не будет расходовать токены родительского. под агента можно специальным образом инструктировать, выбрать, во-первых, с помощью какой модели он будет решать свои задачи и каким образом. И, конечно же, можно под агентов использовать параллельно, что в ряде задач э позволяет существенно ускорить ээ выполнение каких-то сложных, крупных задач, ну, и сэкономить э контекст основного агента и сделать результат более качественным. Надо сказать, что в курсоре, например, да, для работы с кодовой базой используется отдельный погент для работы с терминалом, э свой собственный и также для работы с браузером. То есть это подогенты, которые нельзя там как-то кастомизировать или явно их там использовать, но просто надо понимать, да, что они вовсю применяются, да, и делают работу с конкретным вот инструментом выполнения конкретной задачи наиболее эффективно и с точки зрения скорости, и с точки зрения качества. Субагенты, они также, как и навыки, поддерживаются не только курсором, поддерживаются другими инструментами. А курсор, в свою очередь, позволяет автоматически существующие для других инструментов субагентов импортировать и использовать.
Конфигурация такого субагента - это обычный, опять же, Markдафайл с небольшой шапкой метаданных. И в этой шапке помимо там названия описания есть возможность указать, например, специализированную модель и строить возможность использования его либо в фоне, да, а также ограничить его с точки зрения возможности редактирования, например, как какого-то такого, аэ, речера или эксперта. Вторая часть- классическая инструкция, как он должен вызываться, что он должен делать, как он должен действовать. Создать субагента самый эффективный способ, конечно же, с использованием агента курсор или там есть прямо быстрая командочка создать субагента, которая поможет создать все необходимые инструкции и ямол метаданные правильно, а потом это дело аккуратно, последовательно развивать с точки зрения вызова, да, то есть самый главный сценарий и основной - это автоматическое назначение субагента. для решения какой-то конкретной задачи. Некоторых субагентов можно, например, вызывать явно, да? Более того, можно сказать, что какое-то количество субагентов прямо в чате можем попросить, чтобы они вызывались параллельно. И дальше мы там обсудим, в каком случае вообще это удобно и эффективно. И также для задач, которые требуют какого-то длительного выполнения, да, мы можем попросить агента продолжить, э, погента продолжить выполнение задачи.
Есть там несколько условных паттернов, там первые два паттерна верификатор там или оркестратор. Суть одна, что у нас есть, допустим, этап планирования, в котором эффективне использовать какую-то умную, дорогую модель, да, чтобы всё там взвесить, правильно принять решение, да, там составить план какой-то там архитектуру нарисовать, нужные компоненты выбрать, нужные там придумать способы проверки отлад. Такая модель может быть, во-первых, дорогой какой-нибудь опус там может быть медленный, да? А вот ээ с точки зрения реализации по уже готовому плану есть супербыстрые, качественные вполне себе модельки, например, композер или какие-нибудь там кодексы, которые оченьоченьочень быстро работают. и, ээ, план сделать, э, одним агентом, а его реализацию делегировать другим агентом. А проверку, э, можно делегировать третьим. То есть и отдельная проверка отдельным э подогентом со своим там контекстным окном и инструкциями, да, оно решит проблему, э, когда, например, агент говорит: "Я всё сделал, но ничего не работает". Вот. оставляя основной контекст основного агента более чистым, без какого-то лишнего шума и делать задачу более эффективной. Или, например, третий паттерн, да, параллельное выполнение каких-то задач. Например, мы можем сказать, что мы бы хотели там, не знаю, запустить тесты или запустить какие-то линтеры или запу какие-то проверки на всём проекте. И результаты этих проверок - это, допустим, какие-то ошибки, ворнинги там и так далее, которые мы бы хотели исправить. И получается, если эти ошибки и проблемы нашлись в различных частях проекта, то их выполнение, исправление может как бы отличаться. Вот. И в целом как раз мы могли бы, например, в основном диалоге с агентом сказать там выполни там линтеры и параллельно с помощью какого-то подогента, да, который может там эффективно решать фронт-задачу, э, исправь все эти ошибки. И вот как бы такой сценарий делает кратно быстрее решение данной задачи. Или, например, часто разработчики Курсор в там Твиттере и других соцсетях рассказывают, как они используют паттерн такого типа консилиума, вот или там мультиагентного расследования. для какой-то, например, сложной задачи, да, можно попросить разных агентов с разными моделями, да, отдельно проработать задачу, а потом объединить какое-то общее решение. То есть там в курсоре, например, есть режим, когда вы можете там разными моделями а параллельно решить одну задачу, да, но это нужно для того, чтобы выбрать какое-то одно из решений. А вот если вам надо как бы синтезировать общее решение на основании мнений разных специалистов, так скажем, то вот такой вот паттерн консилиума, он здесь хорошо подойдёт. Надо сказать, да, что в курсоре, в режиме планирования мы видели как раз-таки такой список э из задач To-дуoли list. И вот когда агент при реализации этого плана проходится по этому списку, то теперь он все эти задачи а делегирует под агентом и выполняет те или иные вещи параллельно. Естественно, у использования подогентов большой потенциал, да, там в разных задачах, в разных сценариях, но есть как бы оборотная сторона, некоторый как бы оверхд такой, да, поскольку у каждого подогента свой контекст, то его там надо инициализировать это чуть-чуть дольше, да, Если мы одну задачу решаем там, да, в консилиуме каким-то количеством агентов, то это просто кратно больше тратится токенов. И надо понимать, да, что под агентов надо э-э применять аккуратно, да, для каких-то простых задач нет никакого смысла это делать, да, Есть смысл только если для какой-то конкретной задачи какой-то конкретный агент подходит больше, и он будет эффективнее, да, как вот с примере, с планированием и реализацией.
Мы рассмотрели, в принципе, все концепции, все инструменты. Дальше надо практиковать. Причём надо, наверное, мм придерживаться небольшого количества базовых принципов, да, поскольку, э, инструментов много, в сообществе ээ каких-то примеров ещё больше, да. Ээ, и это не значит, конечно, что все их надо тащить в свой проект, подробно описывать все рекомендации. Надо понимать, конечно, что агенты очень умные, да, что надо всё аккуратно и эволюционно, инкременно развивать. Одно контргантуитивное наблюдение. Агенты, они крайне эффективные. Они умеют очень много, знают множество команд, знают все паттерны. Они хорошо и эффективно ищут по вашей кодовой базе, даже самой-самой огромной, да, там они спокойно справляются там с проектами там на сотни тысяч файлов. Поэтому надо давать агенту лишней информации. Всё, что нужно в и всё, что должно быть в контексте в тот или иной момент времени, они найдут самостоятельно. Вот. И лишь в случае проблем, каких-то как бы затруднений, ошибок, агент пошёл не туда, можно уже начинать корректировать, можно применять те или иные практики.
А чтобы не только в теории познакомиться со всем многообразием инструментов, но и на практике закрепить их использование и построить ээ свой собственный эффективный рабочий процесс с кодовыми агентами, у нас есть несколько программ, на каждой из которых курсор является неотъемлемой частью. И ближайшая программа Eкодинг и агентов стартует уже в эту субботу. Это самый быстрый и эффективный способ погрузиться в разработку с кодовыми агентами. А для тех, кто хочет копнуть глубже, у нас есть две э глубоких длинных программы Driven Fullstк разработка по созданию полноценных приложений с нуля до развёртывания в облаке. А на курсед Driven разработка и агентов вы научитесь создавать полноценные агентные и раксистемы. Также напоминаю, что у нас есть Telegram-канал, в котором мы публикуем больше полезной информации. Заходите, подписывайтесь, задавайте вопросы, участвуйте в обсуждениях. Если было полезно, конечно же, ставьте лайк, подписывайтесь, чтобы не пропустить новые видео. А на этом у меня всё. Всем спасибо. Всем пока.