Transcription
Всем привет. Вы находитесь на канале Я и Дакс. И пока все спорят, что лучше курсор или Clotкод или Gemini CLI, Alibab пользованием искусственного интеллекта под названием Coder.
Эта платформа сейчас находится в публичном превью, доступна бесплатно. И она особенно интересна тем, что у команды разработчиков очень здравый взгляд на то, что такое разработка программного обеспечения и какой она должна быть с использованием больших языковых моделей. И они подошли к этому вопросу системно. И сегодня мы разберёмся, что же у них получилось. Мы посмотрим на их философию. Они её раскрывают в своём блоге. пробежимся по функциям и обязательно, конечно, посмотрим особенно интересные реализации в действии и на практике.
Начнём с официального сайта coder.com. Э, бесплатный доступ на период публичного превью. И они сразу же в заголовке подсвечивают, что их платформа агентного программирования, она предназначена для реальной промышленной разработки. М, конечно же, кодер построен на базе ВС-кода. В основе лежат языковые модели, поддерживают, очевидно, все базовые функции разработки в таком режиме диалога. но обладают несколькими уникальными возможностями, уникальными режимами и технологиями, которые лежат в их основе. И самая киллер фича, которую мы обязательно разберём по кусочкам, она называется Quest Mod. И она заключается в философском взгляде на решение проблем или вообще решение задач разработки программного обеспечения через делегирование автономным агентам. И понятно, что у них, конечно же, есть ээ все базовые функции. Они умеют, естественно, хорошо работать с козовой с кодовой базой. разбираются в ваших репозиториях, умеют управлять памятью, и этому мы уделим особое внимание. Конечно же, используют инструменты, включая использование MCP протокола и так далее.
Что из интересного, и это как бы их тоже в некотором роде философия, они прямо на главной странице заявляют, и в интерфейсе вы нигде не увидите, а какая же модель используется для решения той или иной задачи. Они говорят, что они всегда выберут оптимальную модель, и они эти модели используют самые-самые расподние и объяснят потом, почему. Они, конечно, умеют делать умное автодополнение. Это очевидно. Было бы странно, если бы такой инструмент не обладал такой функцией. Мм, отдельно отмечают, ээ, что они достаточно хорошо умеют управляться с контекстом. Уникальная особенность. то, что они делают вики для вашего репозитория, умеют использовать память, правила inline, chatчат, MCP протокол уже сказал. И в основе их инструмента лежат три главных концепции. Это улучшенное управление контекстом, э умное управление контекстом, комбинирует понимание кодовой базы и использование памяти. прозрачность через формирование проектной документации, которая является по сути таким связующим звеном, артефактом между разработчиком или тем, кто управляет агентом и непосредственно агентом. И Spec Driven Development - это уже не новая не новый термин. В принципе, Amazon своей IDE Kira уже использовали его, и это становится таким в какой-то степени стандартом разработки таких инструментов. И что стоит отметить, мм, какие языки программирования, да, все, в общем-то, популярны, какие знают современные модели. Какая модель используется? Мы используем самые лучшие. Вот выберем сами под вашу задачу. И сколько это стоит. Пока что есть некоторый, э-э, на этапе превью предоставляемый лимит. И в общем, этого хватит, чтобы мм попользоваться и понять, что это такое.
И давайте разберём подробней все составляющие этого инструмента перед тем, как приступить к непосредственно тестированию. Они достаточно системно подошли, э-э, написали заметку в своём блоге про то, что лежит в основе. Они обозрили, в общем-то, тренды, э, последнего времени, э, в AI-кодинге, и они такие, что первая фаза - это такое как бы умное автодополнение, то, что, в общем-то, делали и качественно, и без языковых моделей. Дальше инструменты, которые они охарактеризовали как такой диалоговый рефакторинг или там какое-то взаимодействие с кодовой базой, изменение её через чат. Это вот все инструменты, которыми мы на текущий момент так или иначе пользуемся, всякие курсоры, винсёрфы и так далее. И, э-э, автономные агенты. Мм, сюда они относят, в общем-то, и свой инструмент. Это полное делегирование задач к автономному выполнению через агенты. И сюда же, наверное, можно как бы отнести некоторые инструменты вроде клод-кода, которые похожие возможности предоставляют. И вот они на таком достаточно понятном графике м объясняют эволюцию [музыка] разработки от, собственно, диалогового режима там или автодополнения к решению задач и обеспечению полного жизненного цикла разработки.
Мм, они отсылают тезисы реальной разработки программного обеспечения к книге, которая была написана аж 50 лет назад. Фредерик Брукс, мифический человек и месяц, который выделяет на самом деле четыре ключевых проблемы, которые не только не решаются с использованием искусственного интеллекта, но и некоторые усугубляются. И четыре этих проблемы - это сложность программного обеспечения, это необходимость в соответствии каким-то стандартам внешним, не всегда как бы обоснованным, объективным. Изменчивость и невидимость архитектуры в данном случае, да, то, что даже если мы там архитектуру задокументировали, то она очень быстро с ростом и изменением системы устаревает. И, собственно, от этих сложностей они оттолкнулись и будут предлагать какие-то решения как бы каждой из них. Они подсвечивают, что как бы большинство проблем сохраняется, какие-то задачи искусственный интеллект может взять на себя, но при этом э взаимодействие с там языковыми моделями, с исхвременных, оно часто сводится к такому ээ синхронному взаимодействию в диалоговом режиме через чат, что не является эффективным. И следствием такого взаимодействия является, в принципе, не самый качественный код, когда там разработчику приходится каждый шаг контролировать, исправлять мелкие ошибки, и они на эту, э, задачу смотрят совсем по-другому. Их подход строится на, э, максимизации потенциала, который есть у искусственного интеллекта и у современных автономных агентов. И для того, чтобы использовать всю мощь, да, необходимо обеспечить или решить проблемы, которые обозначил ещё Фредерик Брук в своей книге. И, э, прозрачность м они обеспечивают через м управление знаниями. И как бы заявляя, что наша цель сделать невидимое видимым. Вот. И мы потом посмотрим, как они это делают. Но, в принципе, как бы преимущество видимости знаний, там, устройство проекта, понимание всяких разных связей, оно, конечно же, не только снижает там порог входа, время погружения, но и качество решений, которые будут на основании этого знания сгенерированы. прозрачность выполнения, расширенное управление или улучшенное управление контекстом. И оно строится, на самом деле, на двух таких э-э базовых вещах, включает очень хорошее понимание кодовой базы всех взаимосвязей, структуры, проектов, модулей, э функций, даже, э, архитектуры на разных уровнях и, э, знания истории взаимодействия с этой кодовой базой, как лично конкретного разработчика, так и, э, историю взаимодействия в целом, истории изменений, э, на протяжении там длительного времени.
Ключевая особенность - это SP Driven, подход разработки и делегирование полноценных задач. То есть в эру агентов, они говорят, что задача чека или разработчика, она смещается из области исполнения в область как бы постановщика задачи. И они прямо разделяют ээ взаимодействие с пользованием чата. Это вот как бы предыдущая стадия развития -э на вариант делегирования автономному агенту. И даже они там -э где-то, наверное, мы это посмотрим, описывают видение своего светлого будущего, как разработчик будет взаимодействовать с такой системой. И, э, ну вот они говорят, что там взаимодействие через чат - это какие-то там быстрые задачки, обязательно управление, а они называют свой подход кмод. Разработка через написание спецификаций - это такая долгоиграющая задача, хорошо объяснённая, где тебе надо только проконтролировать финальный результат. И в целом вот в рамках этого подхода э квест Driv, а вы пишете спецификацию, эт автономно её там планирует, выполняет, и вы только проверяете результат.
Очень важный аспект всего этого решения - это, собственно, прозрачность знания. И в основе лежит управление памятью. Они тут достаточно подробно описывают свою м философию и как бы сложности, которые есть с управлением памяти. В принципе, они всем знакомы, да, большинство систем, они как бы плохо плохо запоминают контекст. Надо с ним очень аккуратно обращаться, направлять, повторяющиеся какие-то как бы ошибки исправлять. И вот они говорят, что вводят там несколько уровней, да, персональная история. Это как бы какая-то история - взаимодействия и хорошее понимание кодовой базы. Это основа такой долговременной памяти. Причём, эта память и эта система, которая лежит в основе, она такая как бы самооптимизирующая, то есть решает, что нужно и когда забыть, что включить, обновить. Память эволюционирует. Но память - это лишь основа, и её эффективное использование, конечно же, невозможно без хорошей системы поиска. И они, конечно, рассказывают, какую они э реализовали гибридный подход для вот самого высокого качества. строится на комбинации векторного поиска и графовой структуры всех связей. Кому интересно, может тут подробно ознакомиться со всеми аспектами.
И что самое классное, всё это работает в главной, э, киллер функции, квест моде. Это такое делегирование задач агенту. И оно строится м ну они тут объясняют, что в принципе языковую модель, начиная там с клод 4, они достаточно хорошо уже умеют делать сложные ээ задачи, которые могут выполняться длительное время. Они эти возможности, естественно, используют и считают, что задача разработчика грамотно, качественно описать требования, потратить на это время и делегировать исполнение полностью автономному агенту. Эта фаза называется спекф, когда вы как бы вместе с такой моделью вот подробно подробно пишете требования, но они говорят, что это самая-самая важная особенность и, в общем-то, плохо написаны требования, что на входе, то и на выходе. То есть плохо напишите м результат и плохой получите. И по большому счёту это вот главная проблема всех современных кодовых агентов. И, значит, написали мы спецификацию. Дальше фаза, когда мы делегируем исполнение агенту. И тут они говорят, что важный аспект в этом делегировании, да, кажется, что если мы передали управление агенту, то мы сами его потеряли. То есть может разработчик почувствовать некоторую потерю контроля, э, и они бы хотели этого избежать. И, более того, ставят свои задачу, что нужно сделать такой инструмент, чтобы разработчик мог понять там как бы в пределах 10 секунд, то есть что происходит, как бы какой план, где мы находимся, что выполнено, что не выполнено, и мы посмотрим, как это реализовано. И финально, когда агент свою задачу завершил, э пишется обязательно отчёт, который, собственно, разработчик должен проверить и принять. Если не принял, то, соответственно, что-то там исправить.
Лучше один раз увидеть, чем 100 раз услышать. Перед вами мм открыт уже проект. Э, в этом инструменте в основе его лежит V-cд, и он как бы ничем практически не отличается от любого инструмента, начиная от самого Искода и заканчивая всеми инструментами, которые сейчас существуют, которыми все пользуются. курсор, Wiнсрf, и куча всяких других форков, мм, которые выглядят абсолютно одинаково сле слева дерево проектов и различных функций. Вот здесь есть уникальные особенности. А справа панелька для ведения диалога. Собственно, диалог классический, тут нечего сильно рассказывать. История взаимодействия, управление контекстом. В контексте можно использовать файлы, папки, ссылаться на как бы изображения, использовать историю изменений. Есть правила, опять же, и два режима привычных уже режим вопроса, когда м не будет производиться никаких действий и режим агента, который уже может ээ писать файлы, выполнять команды и полноценно решать задачи. Этим никого не удивишь. Такой диалог есть в любой ээ IDE.
Что здесь как бы особенного? Да, мы не видим, в принципе, инструмента для того, чтобы выбрать ту илиную модель. Почему? Потому что разработчики считают, что выбор моделей - это не задача конечного пользователя, да, разработчика. Выбирать, какая модель подходит лучше. В принципе, почему бы и нет? кажется это вполне себе неплохим таким постулатом, но у него, конечно же, есть оборотная сторона, да? То есть, в принципе, может качество модели или сама модель, которая выбрана автоматически или по какому-то принципу может не понравиться. Так что тут решение как бы спорное, но какое есть есть история. можно создавать новые чаты и всё, в общем-то, привычно.
Давайте, мм, посмотрим, что интересного. Первое, э, это основа на, по мнению разработчиков, эффективной работы с проектом - это хорошая база знаний. И здесь это специальная вкладочка, которая называется Репаки. А, которая формируется автоматически. У неё сейчас есть там определённые ограничение, что м вот этот вот вики каталог, он может быть построен только как бы в рамках репозитория. То есть ээ какая-то папка с вашим проектом, который не является гитрепозиторием, он строить ничего не будет. Плюс сама эта документация, э, не хранится в GTпозитории, но разработчики все вот эти вот пожелания э пользователей слышат, они с ними работают и как бы стараются максимально быстро там всё это исправить. Всё, что на поверхности лежит, очевидное, да, они это, ну, 100% улучшат. То есть этому инструменту неделя. Поэтому я думаю, что не надо тут строго судить.
что из себя представляет вот этот каталог. Они также отмечают, что, в принципе, вот формирование вот этой вики страницы, это важная составляющая и а оно может занимать длительное время. Вот у меня тут проект небольшой. Это такой диалоговый ассистент в виде Telegram-бота под капотом, как бы М, который вызывается у облачного провайдера. То есть, ну, никаких сильно функций нет. И, наверное, там, ну, может быть, несколько десятков файлов. И вот у меня вот эта Виiки, мм, генерировалась, ну, наверное, там несколько десятков минут, может быть, 15-20 минут. Они говорят в себя, что репозитории объёмом там до 4.000 файлов может индексироваться там порядка 2 часов. Но это, в данном случае, такая основа коммуникации в рамках любых агентских взаимодействий и как бы не агентских тоже. То есть, что из себя представляет это Вики? [музыка] Это м на разном уровне сформированное описание проекта на основе очень глубокого анализа всей кодовой базы, анализа исходных кодов, документации, всех связей, всех процессов. И это как бы текстовое в описание, Markdownфайл, обильно использующий Mirm JS разметку для диаграмм. Опять же, как бы недостаток этим процессом формирования, да, генерации. Нет возможности сейчас как-то управлять, например, сделать его на русском языке, да, и надо сказать, что, ну, достаточно хорошо тут всё детально описано. Структура файлов, вот разные диаграммы, flow диаграммы и компоненты, и sequнсдиаграммы, и даже майнмапы, диаграммы для писания моделей. То есть все, которые, в принципе, так или иначе в большинстве своём используются для описания архитектуры, э, программного обеспечения, здесь применяются. Вот здесь там технологический стек, как бы как всё работает. Опять же, небольшой недостаток, да, что эту документацию нельзя подправить, да, она как бы не видна здесь в IDE, и её нельзя открыть в виде файла, поэтому вот им приходится придумывать всякие такие как бы навигацию, да. э управления там, точнее, навигации по разделам, потому что они не могут использовать дефолтную навигацию, которая есть вот здесь вот, которая называется outline. То есть, если мы откроем любой Markда файл, то вот та же самая структура, которая здесь есть, э, будет здесь отображаться. Но это всё как бы мелкие придирки, в принципе, ерунда. Хорошая, подробная дока формируется долго, упорно, является основой следующей функции.
Этомод. Он живёт на отдельной вкладке. Qu mod - это фактически задачи, которые мы ставим. И я тут одну задачку уже выполнил. Мы посмотрим. Одну запрувить. И давайте посмотрим, что она из себя представляет. То есть у нас был простой ассистент, у него даже был какой-то там базовый системный промт, типа ты ассистент, ничего сложнее. И первую задачу я попросил его сделать управление, точнее даже не управление, а фактически промт, который там задаст некую роль, которая будет определять функцию. И сформулировал эту задачу в этапе или там, не знаю, в фазе, которая здесь называется дизайн. То есть это этап формирования функциональной такой спецификации. И я задал, естественно, ну, это всё делается в режиме диалога. А я задал м чуть-чуть контекста, да, вот в файликах intro и IDD описывается как бы базовые функции и попросил его, в общем, что-то сделать, сформулировать дополнительно. И результатом этого стала вот такая спецификация, которую можно, э, посмотреть в режиме preview. Она хранится в уже в проекте, что плюс. Но редактировать её по-прежнему нельзя, к сожалению, кроме никак, кроме как из диалога. И эта документация - это такой дизайн-документ, который отражает главные функции, как бы описывает там структуру, изменения там в компонентах и даже на более низком уровне конкретные какие-то как бы пожелания к реализации, да, там как должен выглядеть промпт, как должен выглядеть какой-то класс, как должна быть реализована какая-то функция. И это такая подробная подробная спецификация, примеры, значит, параметров. Ээ, это не только лишь получается описание такое функциональное. Это глубокий на всех уровнях полноценный такой документ для разработки. Когда мы этот документ написали, он сначала у меня там получился на английском языке, я его попросил написать на русском языке. И, в общем, ну, какие-то уточнения в режиме диалога мы вносили. И после того, как он, э, согласован разработчиком, наступает фаза выполнения.
Фаза выполнения. Для неё предусмотрено отдельное здесь место в интерфейсе. И, э, в рамках фазы выполнения агент сначала подробно планирует, да, и этот план можно посмотреть прямо в интерфейсе. Это как раз то, что разработчики ставят своей целью, да, обеспечить быстрое понимание, где мы сейчас находимся, когда агент работает, особенно если он может работать долго. И вот здесь ээ соответственно агентство Styleп, первая фаза, там а какая-то базовая реализация, потом улучшение, потом тестирование и проверка. Когда он это всё сделал, значит, написал отчёт и, э, просит меня согласовать. Пишет, что он сделал. У меня есть возможность посмотреть историю, э, всех файлов, которые были задействованы, да, что добавилось, что изменилось, и принять либо отклонить, собственно, это решение. После выполнения этой задачи она остаётся в вкладке квест в истории. Вот она здесь хранится, всегда можно к ней вернуться. Поскольку главный атрибут вообще вот этого делегирования и повышения эффективности разработчика, это асинхронность, да, то здесь можно создать сколько угодно много а задач, которые будут параллельно в фоне выполняться. И только тогда, когда требуется реакция разработчика, да, какое-то подтверждение, согласование, уточнение, то здесь появляется в статус баре призыв. Ээ, да, вот такая-то задачка. Это вторая задача, которая заключалась в том, чтобы добавить мультимодальные возможности к нашему к нашему ассистенту Telegramботу, да, чтобы он мог принимать изображения. И вот эта задача выполнена. Весь план здесь он не такой развесистый, да, и более простой, э, нейрархически пройден, выполнен и написан отчёт, который надо согласовать. Соответственно, мы там его согласуем. Всё, мы совсем согласны. Код посмотрели, всё хорошо.
И давайте с вами вместе прямо попробуем какую-нибудь новую задачку быстренько сделать, посмотреть, как это вживую работает. Мм, когда мы нажимаем кнопочку New Task, у нас появляется фактически диалоговый режим, но в таком особом формате quest mode. И, э, мы можем сказать, что либо делая сразу же реализацию, что противоречит этой концепции, либо можем наполнить контекст какой-то информации и попросить что-то сделать. Ну, например, мы можем добавить с точки зрения мультимодальности там новую возможность. И можем ещё в контекст добавить, например, соглашение, которое у нас есть по проекту. Главное из соглашения - это использование принципа простотыs. Чтобы не сильно выдумывал агент. Я хочу реализовать возможность обработки аудио с использованием облачного Open AI э модели для транскрибации. Следуя всем принципам из соглашений. Это базовый промпт для того, чтобы агент написал для начала полноценную спецификацию. Я, конечно, забыл сказать ему, что надо всё это делать на русском языке. Ну, всё, что ему нужно, там прочитает, проверят и так далее. Кстати, в рамках выполнения он, естественно, как и любой агент, он там делает какие-то тесты, запускает, э, выполняет проверки того, чего он сделал. То есть как бы в соответствии со своим планом, да, это тоже можно потом ознакомиться, посмотреть. Надо сказать, что как бы с точки зрения скорости кажется, что она медленнее, чем в привычных инструментах, в каком-нибудь курсоре с клодом или в клодкоде, да. Но в общем, надо понимать, что а этот инструмент совсем-совсем свежий и интерес к нему огромный. Они сказали, что за первые там, по-моему, 5 дней, 21 августа, они открыли. Вот на текущий момент за неделю у них уже набралось там порядка 100.000 активных разработчиков, которые используют их инструмент.
Ну, как я уже сказал, вот он реализовал на английском, соответственно, нарисовал тут все схемки, требования написал и, ну, вот как бы, если нам что-то не нравится, можем его просить дорабатывать. Ээ, перепиши, пожалуйста, на русском языке и проверь, чтобы использовался принцип KISS: никакого овенжиниринга.
Что касается формирования проектной Вики, то она строится и перестраивается автоматически. Э разработчики там в документации говорят, что это происходит при а фиксации изменений в виде комитов. или там по какому-то расписанию, вот, или при получении изменений из удалённого репозитория. И таким образом они вот эту проектную догу делают актуальной автоматически. Например, в том же самом инструменте Кира от Амазона, там для похожей задачи используется технология или механизм хуков, да, которые настраиваются на какие-то действия и могут м триггерить выполнение вот такого рода там на обновления документации. Кстати, можно, наверное, уже этот файлик посмотреть, да, на русский он пока не не густо переписывает, но, в общем, надо сказать, что вот эти вот дизайн-документы, они достаточно-таки скрупулёзные и высокого качества. То есть, конечно же, в какой-то степени этим страдает, что они могут раздуть э любую документацию, да, но вот как будто бы, если функция не очень там какая-то огромная, если правильно декомпозировать, обобщить, то здесь вот как бы полный набор полезной документации он присутствует, полезный с точки зрения реализации, в том числе агентам, да. Вот. О'кей, я там всё убрал, переписал на русском, как бы простота, все дела. И что теперь? А теперь, пожалуйста, можно выполнять. Вот он приступает в фазу Action Flow, э, изучает документацию, планирует, декомпозирует и как бы реализует в конце, как бы пишет отчёт и просит согласовать. И надо сказать, кстати, что у конкретно этого инструмента, поскольку его разработчик - это компания баabба, то у них есть, в принципе, конкурентное преимущество в том, что у них огромное количество очень хороших э разных моделей и для программирования, и мультимодальные. Это вот все модели семейство, и визуальные, и для математики. Э все какие угодно. В целом, это кажется хорошее преимущество, если ты делаешь вот такой вот инструмент для разработки. Не зависит только от какого-то там э провайдера. И при планировании, естественно, это многие инструменты сейчас делают. Вот самое главное, как бы такой способ декомпозиции и последовательного правильного выполнения - это использование тудушек, да, то есть просто список задач, по которому агент проходит реализуя то, что запланировано.
Наверное, всё самое интересное я постарался, обозрил. На мой взгляд, те функции, которые мы посмотрели, очень интересные и перспективные. Мне лично они нравятся, и они коррелируют с теми подходами, которые мы называем AI Driven подход, да, который можно построить, в принципе, с использованием любого инструмента, но в его основе лежит ровно те же самые, э, концепции и принципы, да, что нужно хорошо продумать решение, хорошо его задокументировать, а потом декомпозировать на итерации для последовательного. такого аккуратного выполнения, а всё взаимодействие с искусственным интеллектом, с моделями вести через фазу план, согласования, реализация, валидация, да, когда мы просим сначала сказать решение и потом только как бы делать. И это, в принципе, эти подходы они перекликаются просто с лучшими практиками, которые вот мы обозревали в недавном видео от команды клодкода.
И что хочется сказать в качестве заключения, что мы видим, какие последние шаги происходят в рамках индустрии. это те инструменты, которые появляются или новые функции у существующих инструментов уклодкода, они идут в сторону э вот такой систематизации, да, и применения принципов инновационных в какой-то степени, да, и которые часто противопоставляются такому вайб-кодингу, когда типа вау, проект с одного промта получили. И это, конечно, больше маркетинг, да, и такие подходы, они не работают с настоящими сложными проектами, в которых там задействовано много людей, много команд, которые развиваются, сопровождаются, эволюционируют, которые не надо каждый раз писать с нуля. Вот и они ложатся в основу инструментов, да, являются, по сути такой конвой процесса взаимодействия. И конкретно в этом инструменте новая такая мысль, наверное, про то, что агенты, если им хорошо объяснить, вот, если они хорошо будут понимать, ээ, вашу кодовую базу, ваши все задумки, возможно, которые вы там формализуете в документацию, то они смогут как бы практически автономно выполнять задачи. И вот я так не показал, но просто я перескажу, что светлое будущее, которое видит команда - это когда ты утром приходишь, с этим инструментом, описываешь до обеда там подробно спецификацию. Э-э потом, значит, агент планирует и ты там к концу дня валидируешь этот план, запускаешь, а утром приходишь и проверяешь результат. То есть, в принципе, у тебя главная задача как бы качественно сделать постановку. Мне лично все эти движения нравятся.
А если вам понравилось это видео, было полезным, ставьте, конечно, лайки, подписывайтесь, э задавайте вопросы в комментариях, обязательно пробуйте новые инструменты. И я напомню, что у нас есть Telegram-канал AI Dialogs, в котором больше материалов, и мы обсуждаем какие-то инструменты новой модели или технологии. И всех, конечно, приглашаю на ближайший поток нашего интенсива, на котором мы научим вот своему подходу, который мы называем AI Driven разработка. И в рамках этого интенсива мы даём фундамент в виде подхода, который работает с любым инструментом. И, конечно же, закрепляем все полученные знания и навыки через реализацию реальных проектов, от там простых ассистентов, которые мы сейчас смотрели, до уже таких автономных агентов, похожих на те, которые выполняют ваши задачи. На этом всё. Всем спасибо. Всем пока.