Роадмап по Агентской разработке в эпоху AI

У большинства из нас сейчас день начинается одинаково. С утра включаешь компьютер, открываешь Кодекс или Cloudкод, и он помогает тебе разрабатывать софт или писать код. И кажется, что ты овладел ИИ-шкой, овладел агентами, понимаешь, как это всё работает, и спокойно можешь двигаться дальше по карьере. Но на самом деле есть довольно много подводных камней, граблей, на которые можно наступить при использовании агентов и ЛМ. И в том числе, если ты хочешь быть прямо максимально компетентным в вопросах использования, стоит точно глубже разобраться, как его можно использовать. И сегодня я проведу тебя по роудмапу шаг за шагом, что нужно внедрить в свою разработку, в свой проект, чтобы, во-первых, это было быстрее, во-вторых, дешевле, у тебя оставалось много токенов, и ты мог решать просто больше задач, то есть максимально оптимизировать свою работу. Меня зовут Артём. Я сеньор энд-разработчик. Ныне также занимаюсь разработкой с использованием агентов. Поэтому, если тебе нравится подобная тема, обязательно поддержи видео лайком и подпиской на канал. А мы начинаем. Итак, давайте начнём с самой базы и потихоньку дойдём до самых неочевидных и продвинутых опций использования агентов. Итак, первый шаг нашего роудмапа, который большинство, скорее всего, уже сделали — это переход от LLM к агентской разработке. То есть у вас стоит на компьютере какая-то софтина, это какое-то приложение, например, Кодекс, или вы в терминале работаете с Cloudкодом, и у него есть доступ к вашему компьютеру, к тому, чтобы выполнять какие-то команды, открывать файлы, изменять гит-репозиторий, то есть, чтобы он был максимально близок к вашему коду. Вам не приходилось ручками копипастить что-то из браузера и вставлять в свой код. А шаг довольно простой, понятный. Я бы пропустил его довольно быстро, если бы не одно, но, и оно касается по большей степени ChatGPT. Если мы говорим про Cloud, это к нему не относится. А вот к ChatGPT относится. Если у вас есть довольно большие объёмные задачи, например, связанные с research, с планированием, которые немножко абстрагированы от кода или можно легко дать частичку контекста в браузерную версию, то вполне можно тратить токены в браузерной версии на тяжёлый research, исследование best practice, планирование какой-то сложной задачи или её декомпозиции, а затем переносить в агента. Почему так происходит? Просто потому, что у нас есть как бы два набора токенов. Один для браузерной версии, для ChatGPT, один для агента, для Кодекса, например. В Cloudкоде так не работает — у вас и в браузере, и на компьютере будут одни и те же токены тратиться, но в части нейросетей, в том числе в ChatGPT, очень удобно. Можно делегировать такие задачки на подумать в браузерную версию. Окей. Тем не менее, конечно, процентов 90 мы проводим в агентах, и нужно понимать, как с ними ведётся работа. Итак, перед тем, как переходить к агентским файлам, инструкциям, конфигам, скилам, хукам, давайте просто поговорим. А вот агент, чем он отличается от ЛМки, потому что многие даже, может, не понимают. И суть в том, что просто мы по-прежнему общаемся с ЛМкой, она по-прежнему принимает какие-то решения, но исполнитель часто — это наш компьютер. Например, ЛМка понимает: "Ага, мне нужно вот прочитать вот эти файлы", отдаёт команду агенту, и наш компьютер знает, что можно там вызвать команду ls и посмотреть, какие файлы есть, например, в репозитории в текущей папке, или прочитать или поискать через grep, например, на Линуксе или на Маке, просто через команду поискать вхождение какого-то слова во все файлы. То есть этим не ЛМка занимается, она лишь получает данные от агента, то, что он нашёл в нашем компьютере, и даёт ему какие-то команды на изменения. Ну, помимо этого, конечно, наш агент может работать с внешними МСПишками, с внешними инструментами, ходить в базу данных и многое-многое другое. И помимо того, что у агента есть довольно большая свобода действий, важно помнить, что нужно всегда давать ему ограничения. Мы посмотрим чуть позже, в каком формате это можно делать, но важно его ограничивать, указывать, какая у вас архитектура проекта, какой стек вы используете или за какие рамки нельзя выходить, что не нужно делать. Это очень важно. То есть не только просить его обозначать какую-то цель, да, definition of done, что должно быть сделано, как понять, что задача выполнена, но и запрещать ему некоторые вещи. И в том числе важно помнить, что агенты очень сильно любят жрать контекст, особенно если он, например, запускает, вот вы разрабатываете какой-то продукт, и там есть 100 тестов. Если ваш агент запускает каждый раз после каждой задачи тесты, тесты генерируют, например, 10 000 строк логов, ну просто что тесты успешно прошли, то ЛМка всё равно подгружает эти 10 000 строк кода. Там огромное количество токенов, там условно 300 000 токенов. И затем они у вас в контексте живут и просто его перенасыщают. У вас тратится больше токенов, ну или больше денег, вы менее эффективно работаете. ЛМка просто сжирает ненужные ей данные, анализирует зачем-то, понимает, что там всё хорошо. Хотя можно было бы, конечно, от этого, например, избавиться. Об этом тоже чуть позже поговорим. Окей, давайте переходить уже к настройке агента, потому что это то, что обязательно должно быть в вашем проекте. Причём, в чём специфика вот таких файлов agents.md или clod.mk. Markdown, что они не универсальны в зависимости от проекта, который вы делаете: сайт, Telegram-бот, какой-то frontend, у вас будет разный файлик agents.md. Вам нужны разные какие-то правила, важные разные настройки, разные способы запуска. То есть в этом markdown-файлике, ну, по сути, просто текстовый файлик, вы можете описать, а самое главное, довольно лаконично, например, не больше там 100-200 строк. Не нужно туда записывать, запихивать всю архитектуру проекта, как всё работает, всё взаимосвязано, какие-то схемы и картинки. Нет. В этом файлике обычно хранится основная информация, что это за проект. Например, если это энд, что у него за архитектура и стек используется, какие команды можно использовать. Например, для запуска вот эта команда, для запуска тестов эта команда, для запуска линтера вот эта команда, для прогона миграции вот эта команда, чтобы он точно использовал их и не придумывал, не изобретал велосипед каждый раз. Дальше обязательно указывайте запреты, что нельзя делать этому агенту в этом проекте. Например, ему нельзя ходить в продовую базу данных или ему нельзя ходить и изменять данные или пытаться изменять данные. Понятное дело, что эти запреты не гарантируют, что агент не сходит и не удалит вашу продовую базу. Конечно, здесь важно, ну, как бы иметь голову на плечах и не давать ему логин и пароль до пользователя к продовой базе или только донли пользователя давать, чтобы он мог только читать данные, даже если он попробует их изменить и нарушит инструкции, чтобы он, ну, просто ему отказала база данных. То есть мы полагаемся на этот файлик, но мы никогда не доверяем агенту. Мы не уверены, что он будет всегда это использовать. Мы должны предохраняться в данном случае, ну и аккуратно взвешивать риски. Также, что очень важно и многие забывают или не знают, это вложенные файлики agents.md или там gemini.md для Gemini или clod.md. Они всех называют, собственно, по-своему. В чём смысл? Для каждой директории. Например, вот у меня есть в проекте директория, связанная с тестами. У меня для тестов может быть какой-то свой набор правил, как они пишутся, в каких директориях они создаются, что конкретно мы тестируем, насколько там какой процент покрытия тестами должен быть, насколько мы упарываемся в тестирование каждого там атрибута, ключа, значения и так далее. А это прописывается уже в каждой папке отдельно. То есть, если код, который пишет агент, или фича, которая разрабатывает агент, предполагает тестирование, когда он дойдёт до папки с тестами, он увидит там файлик agents.md, поймёт: "Ага, мне нужно вот это, это, это сделать". Или если он зайдёт, например, в папку для работы с платежами и нужно будет что-то поменять по платежам, по платёжной системе.

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

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

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

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

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

вставлять в свой код. А шаг довольно простой, понятный. Я бы пропустил его довольно быстро, если бы не одно, но, и оно касается по большей степени чат GPT.

Если мы говорим про клод, это к нему не относится. А вот кчат GPT относится.

Если у вас есть довольно большие объёмные задачи, например, связанные с речем, с планированием, которые немножко абстрагированы от кода или можно легко дать частичку контекста в браузерную версию, то вполне можно тратить токены в браузерной версии на тяжёлый resarch, исследование best practice, планирование

какой-то сложной задачи или её декомпозиции, а затем переносить в агента. Почему так происходит? Просто потому, что у нас есть как бы два набора токенов. Один для браузерной версии, для chт GPT, один для агента, для кодекса, например. ВCLД кодка так не работает у

вас и в браузере, и на компьютере будут одни и те же токены тратиться, но в части нейросетей, в том числе в chatт GPT, очень удобно. Можно делегировать такие задачки на подумать в браузерную версию. О'кей. Тем не менее, конечно,

процентов 90 мы проводим в агентах, и нужно понимать, как с ними ведётся работа. Итак, перед тем, как переходить к агентским файлам, инструкциям, конфигам, скилам, хукам, давайте просто поговорим. А вот агент, чем он отличается от лэмки, потому что многие

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

наш компьютер знает, что можно там вызвать команду ls и посмотреть, какие файлы есть, например, в репозитории в текущей папке или прочитать или поискать через ГРП, например, на Линксе или на Маке, просто через команду поискать вхождение какого-то слова во все файлы.

То есть этим не Лэмка занимается, она лишь получает данные от агента, то, что он нашёл в нашем компьютере, и даёт ему какие-то команды на изменения.

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

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

обозначать какую-то цель, да, definition of done, что должно быть сделано, как понять, что задача выполнена, но и запрещать ему некоторые вещи. И в том числе важно помнить, что агенты очень сильно любят жрать контекст, особенно если он, например, запускает, вот вы

разрабатываете какой-то продукт, и там есть 100 тестов. Если ваш агент запускает каждый раз после каждой задачи тесты, тесты генерируют, например, 10.000 строк логов, ну просто что тесты успешно прошли, то Лэмка всё равно подгружает эти 10.000 строк кода. Там

огромное количество токенов, там условно 300.000 токенов. И затем они у вас в контексте живут и просто его перенасыщают. У вас тратится больше токенов, ну или больше денег, вы менее эффективно работаете. ЛМКА просто сжирает ненужные ей данные, анализирует зачем-то, понимает, что там всё хорошо.

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

agents.mdown или clod.mk. Markdown, что они не универсальны в зависимости от проекта, который вы делаете сайт Telegramбот какой-то frontend, у вас будет разный файлик agents.m. Вам нужны разные какие-то правила, важные разные настройки, разные способы запуска. То есть в этом marкdдау

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

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

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

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

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

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

ну и аккуратно взвешивать риски. Также, что очень важно и многие забывают или не знают, это вложенные файлики agents.m или там gemini.md для Gemini или clot.mD. Они всех называют, собственно, по-своему. В чём смысл?

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

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

тестами, он увидит там файлик agents. Markdown, поймёт: "Ага, мне нужно вот это, это, это сделать". Или если он зайдёт, например, в папку для работы с платежами и нужно будет что-то поменять по платежам, по платёжной системе, подключению, там, кака, cloud payments,

stripe, неважно, у него будет набор инструкций, что можно делать, что нельзя делать, как, где что расположить, чтобы ничего не сломалось, да? Вот это, наверное, самое важное. И вот эти все инструкции такие мм локальные, относящиеся к платежам, там, к

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

Разбивайте их на маленькие подфайлики вложенные. Они могут быть не только вложенные с а одним уровнем, они могут быть вложены в там под папку, под папку, под папку. И для неё есть свой файлик agents.

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

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

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

А давайте сразу проясню, чем отличается вот файлик agents. Markdown от скилов. Agents - это, наверное, описание просто вашего проекта, как мы с ним ведём работу, как мы с ним не ведём работу. То есть очень верхнеуровнево.

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

типом добавляется в таблицу. И может быть правила, как добавляется эта миграция, что нужно ещё сделать.

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

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

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

И если задача частая, она рутинная, в ней что-то всегда повторяется, какие-то кусочки кода, имеет смысл обернуть это в скил, чтобы всегда, например, если нужно проверять, что это администратор или модератор или обычный пользователь. Второе- не забывать подтягивать ID пользователя. Третье,

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

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

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

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

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

планирование, второй - реализацию, третий независимо критикует всё, что произошло, типа реvьет код, и четвёртый delivрит, там, пушит в репозитории в гиIT. Всё вроде хорошо. Но потом оказалось, что так как я этот скилл постепенно там днём за днём добавлял,

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

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

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

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

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

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

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

продакшене? Вы задаёте вопросы, получаете все ответы на свои вопросы, закрываете фундамент разработки через агентов. То есть неважно, чем вы пользуетесь, кодекс, ClкоД, OpenCД или другие харнесы. Вы понимаете, как это устроено фундаментально, и затем можете использовать абсолютно любой харнес.

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

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

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

Многие слышали про MCP, но почему-то забывают их внедрить или не знают, что у системы, которую вы используете, есть MCP. Представь себе рабочую задачу. У вас в в корпоративной системе есть GРА для тасктрекинга или Асана, а Confluence для документации и там лежат какие-то

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

документацию, из гитлаба, там, не знаю, последние эмры или последние комиты, в общем, какую-то информацию из репозитория условно, [фыркает] и даёте ссылку или там опять же копируете всю ошибку бага из centry или glгличп.

Это очень просто тупая работа. Она тупая, потому что её можно оптимизировать. То есть раньше все так и делали. Как бы это было нормально. Ты копируешь такой, ищешь в Гугле, на Steck Overflow, на Хабре, сталкивался ли кто-то с этой проблемой. Сейчас это

просто неэффективно. Ты просто тратишь лишнее время. Гораздо удобнее подключить MCP всех этих инструментов. Подключить [фыркает] MCP конфлюенса, чтобы агент всегда знал, что, а, у меня есть конфлюнс. И лэмка, когда будет размышлять над задачей, скажет: "Ага, да, о'кей, давай сходим сначала в жиру,

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

с вашим кодом и поймёт: "Ага, вот здесь была ошибка, давай поправим её так, так, так тактак".

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

Вот вы используете там Postg SQL или Mongo DB или Click House. У вас, скорее всего, локально на компьютере, ну, если вы разработчик смотрите это видео, а у вас есть консольный клиент, например, PSQL для Postgress, и он спокойно может

делать запросы в вашу базу данных. Вам не нужно, ну, как бы это tools, да, это тулза, это просто а консоль инструмент.

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

запросов и тестирования. А не всегда нужно подключать MCP, потому что это как-то классно и круто. Если у вас на компьютере уже есть Толза, пожалуйста, используйте её. Следующее.

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

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

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

выдать какой-то план решения этой задачи, а лучше использовать последнюю модель, самую продвинутую, в том числе самую дорогую. И у неё довольно хороший, высокий уровень размышлений, да, reasoning, reasoning high или extra high, если у вас доступен или вам не

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

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

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

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

уровень размышлений с high до medмедиум или low или вообще там опять же в семейство GPT поменять с GPT 56. 5.6 на Terra или Lлу. То есть взять ещё какие-то более слабенькие модели и у них ещё более слабенький уровень

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

это использую, как там у меня друзья синьоры используют. И токены очень быстро сжигаются, поэтому эта фича вполне может помочь вам на регулярной основе тратить меньше на 10, 15-20% токенов. Дальше. Субагенты для независимых задач. Вот только-только ты разобрался, что такое агенты, как

появилась какая-то неведомая фигня, типа субагенты. На самом деле это не очень сложно для понимания. А сразу вот если взять пример, ты открыл два чата параллельно и там дал свои промпты и работают агенты. Это два независимых агента. Это не субагенты. Субагенты -

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

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

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

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

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

Проверь, всё ли хорошо, нет ли никаких проблем, всё ли по стандартам, по нашим по там файлику agents.

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

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

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

просто менеджер, который сидит, сложа руки, и такой: "Ты вот это делай, ты вот это делай". Он тоже может работать.

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

Следующий этап - это параллельная работа через Git Work 3. Это относится, конечно, больше к разработчикам, особенно когда у вас в работе много задач, несколько новых багов появилось, несколько фич вы разрабатываете. И если раньше никто не пользовался Git 3, ну

просто потому что зачем мы обычно использовали Git Stash, то сейчас это очень классная фича. А что, что это значит? Git for 3. А ты на одном компьютере, на своём можешь один и тот же репозиторий одновременно редактировать из разных веток. То есть,

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

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

Если у вас много фичей, много дедлайнов и в стартапе, то обязательно говорят, что рекомендую использовать Gitwork 3.

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

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

сломалось, потом в другом поменял, в этом сломалось. И агент может не находить зависимость, что нужно там в обоих местах что-то сразу поменять или удалить одно из этих мест. Он может не понимать зависимость, как какие-то элементы зависят друг от друга, потому

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

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

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

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

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

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

хуки, чтобы без нашего вмешательства или с минимальным нашим вмешательством наша система могла автоматически улучшаться.

И опять же поясню, для каждого проекта как бы свой набор тулзов, MCP, хуков, фидбек лупа актуален.

Тяжело просто взять, скопировать с другого проекта какой-то весь набор и всё, у вас всё будет работать, всё будет летать. Скорее всего, нужно под себя настраивать, тюнить хотя бы какие-то вещи. И довольно популярная вещь Spec Driven Development, которая используется

в bigтех компаниях, во многих командах, я слышал, в том числе я использовал. Очень классная методология.

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

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

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

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

демонстрации, как это происходит с самим агентом, как реализуются эти скилы, как реализуется это verification loop, подключаются эти тулзы, настраивается MCP, как всё это происходит на реальном проекте.

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

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

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

прокачивайтесь. Если вам понравилось видео, поддержите его лайком, комментарием, подпиской. Вот на этом канале ещё не было видео про Ии. Тем не менее, мне есть много чем поделиться.

Поэтому, если вам интересно, отпишите в комментариях. И всего доброго. Пока.