Transcription
Всем привет, кто проснулся в это утро. Вижу, что там человек 100 проснулось. Привет тем, кто в будущем будет нас смотреть в записи.
Сегодня мы поговорим про капилоты. Капилотов много разных, всяких. А, и, собственно говоря, возникает вопрос, как их различить, особенно учитывая, что есть сила маркетинга. Рассказывают, что все они замечательные, обладают одними функциями, начинают уже сравнивать по тому, сколько денег у команды, которая разрабатывает, из этого делать выводы, что круче.
Давайте пойдём с самого начала, копнём, собственно говоря, вообще, как пилоты работают под капотом, как они генерят код. Сделаем это на примере нескольких популярных. И с нами в путешествие отправятся Альберт, назовём его так, учёный. И, ну, давайте назовём его Джимми. Обезьянка Джимми. Два этих ласковых взгляда.
А я, собственно говоря, кто я такой? Я Овенир Воронов. Вот. А, собственно, с этими всеми делами я имею дело уже года три, наверное. Вот, э-э, пытаюсь продвигать и встречаю кучу скепсиса. Вот перепробовал этот вайпкодинг ещё того, как он появился. Вот, а, пережил революции, в том числе автодополнение в Jet Brands идея, когда рассказывали про то, что как это может какой-то тут инструмент за нас додумывать код. Это же невозможно, мы же программисты. Ну и так далее. Вот. Ну, если бы мне когда-нибудь во времена Квикбейсика и Паскаля рассказали про LLM, я, конечно, не спал неделю. Вот. Ну, собственно, сейчас я, а, директор по внедрению капилотов, э, в компании, которая производит, собственно говоря, капилоты. А, но я ещё не заступил полностью в должность, поэтому это не будет рекламой конкретного продукта, а это будет трезвый взгляд, вот, собственно говоря, потому что я успел нарыть за всё это время.
Давайте начнём с самого начала, собственно говоря, каким образом можно сгенерить код. И так можно пофантазировать, да? То есть, наверное, самый быстрый способ сгенерировать код - это зайти на GitHub, нажать Ctrl C, Ctrl V или Gitlon и, собственно говоря, получить код. Но это не наш способ. Нам надо всё-таки какую-то вариативность иметь, какой-то вайп-код, да.
Ну, и можем зайти с теорией бесконечных обезьян. Есть такая теория в русском фольклоре, значит, есть вариация того, что мы берём обезьяну, сажаем её за печатную машинку, даём бесконечное время. В какой-то момент она может сгенерить Льва Толстого войну и мир, ну, либо в англоязычном фольклоре Шекспира, либо взять много вот этих гипотетических обезьян. В общем, бьют по кнопкам, получают код. В принципе, это всё можно, конечно, автоматизировать, перевести в код, но, наверное, это не наш метод, и нам надо всё-таки каким-то образом сузить, а, вот эту вот генерацию. Хотя даже вот вот это вот стучание по клавишам хаотичное или там вбивание каких-то параметров непонятных и так далее, тоже имеет право на жизнь. Например, есть так называемая FUS или фаastтестирование, вот, э, которое подразумевает то, что вы, аэ, нагружаете систему случайными значениями, а, много раз и в итоге выстреливают там статистический какой-то процент ошибок, так, например, компиляторы тестируют, выявляют различные баги. Вот. Но нас интересует, э, не весь широкий спектр возможности, в том числе не работающий код, а какой-то более узкий, да, чтобы задачи всё-таки а были работающие.
И тут можно это свести, а, к тому, а что, собственно говоря, программист хочет получить и что он вбивает. И здесь возникает вопрос: а есть ли у программиста вообще свобода воли? Вот, то есть а так ли уж разнообразен ум, задачи, функции? э-э, простого инженера, да. И, э, подобный вопрос нас адресует к XIX веку. Это не просто историческая справка, это, по сути, наверное, начало нашей истории с лмами. Вот в XIX веке было много споров о свободе воли. Понятно, там произошли революции где-то с, значит, в Европе, а в Российской империи, соответственно, вопрос о том, есть ли свободная воля или нет, стоит ребром. И вышел спор двух замечательных людей, Никрасова и Маркова. Никрасов не тот, который писатель, а это, а, значит, философ, математик, который был монархистом, а он был религиозным человеком, и он хотел через математику доказать то, что, собственно говоря, мм есть у народа свобода воли. Вот. И он, значит, э обратился к закону больших чисел. Суть в следующем, что если вы, например, а бросаете монетку много раз, да, она там выпадает режка, орёл, но в конечном итоге вы, э, чем больше, значит, бросаете, в конечном итоге вы приходите к какой-то пропорции, там примерно 50 на50, вот, а с небольшим сдвигом в какую-то сторону. Она вполне ожидаемая, средняя. И в общем-то с всё время одна и та же. То же самое, если, например, вы делаете какие-то опросы, у большая ли у вас зарплата, да? Вот, э, опросили всех, приходит к какому-то значению, но есть нюанс. Ээ, если вы опрашиваете кого-то и хотите получить вот вот это вот, э, значит, средний показатель, типа там 50 на50, кто-то доволен, кто-то недоволен, куда-то там перекашивается немножко, вам надо сделать так, чтобы люди мм друг с другом не разговаривали, они не слышали ответа других, потому что если кто-то скажет, что он получает там заведомо больше, то, ну, соответственно, оставшаяся аудитория может подумать, что оно всё-таки получает мало. Вот, соответственно, должны быть независимы. Так вот, собственно говоря, этот Некрасов предположил следующее, что этот закон работает в обратную сторону. То есть если вы видите какую-то статистику, а которая повторяется из года в год, например, а количество разводов не меняется, а или, не знаю, там создание новых семей, рождение детей и так далее. Если вы видите статистику, э, что она выравнена, выровнена там в течение, допустим, 5 лет, то из этого он заключает, что, э, значит, все люди, которые участвовали в этой статистике, все семьи, которые участвовали в этой статистике, обладали свободы воли. То есть они независимо друг от друга принимали решение рожать, разводиться и тому подобное. Вот. Таким образом, это очень опасная дорожка, э, через вот эту статистику доказать, что, собственно говоря, э в государстве, ну, данном случае российском, э, у всех свобода воли, всё хорошо там, ну, и так далее. В общем, короче, много свободы и воли. Вот.
А ему оппонировал замечательный господин Марков. Причём на слайде вы видите картину Репина Евгений Анегин. Это не случайно, потому что оппонировал он через Евгения Анегина. Итак, Андрей Андреевич Марков, значит, считал, что господин Некрасов притягивает религию к математике, а на деле предсказуемые закономерности могут возникать и в системах с зависимыми событиями. А, поэтому он взял Евгения Онегина, а выкинул оттуда все пробелы. Дальше он, значит, расчертил буквы гласные, согласные, согласное, гласные, да? То есть он упростил систему, проанализировал частоту появления гласных и согласных и обнаружил, что вероятность появления следующей буквы а зависит не от всего текста, а от, э, текущей позиции. То есть текст не является случайным набором символов, а имеется структура с ограниченной памятью. А, и таким образом он дошёл до так называемой цепи Маркова. Вот. А пример её на экране, например, с известной скороговоркой ехал грека через реку. То есть вот, если посмотреть, что мы начинаем в точке ехал, доходим до грека, потом с определённой вероятностью выпадаем на через потом на реку, видит грека, соответственно, дальше мы смотрим в в реку рак, ну и так далее. В общем, сунул грека руку в реку, э, рак за руку греку ца. Так вот, собственно говоря, мы можем построить такую цепочку. Мы можем, а, рассчитать вероятности перехода а между звеньями. Вот.
И о чём это, собственно, говорит? Это говорит о том, что аэ нам достаточно взять определённое количество э каких-то используемых, мм, значений, но в нашем понимании это токены, вот, а, каких-то кусков слов. И, э, прогоняя э значит в тексты, смотря насколько часто встречаются какие-то сочетания.
Извини, пожалуйста, а можешь мьютнуть все нотификации, а то оно это реально путает, а потом ещё и на записи будет мешать.
>> У тебя, кажется, что-то
>> прошу прощения. Да, сейчас
>> это, насколько я помню, телега так любит. Вот. А, надеюсь, больше не повторится. Так.
А, в общем, суть в следующем, что, значит, мы можем взять некоторое количество кусков слов, токенов, да, а, посмотреть все варианты там текстов, кодов там и тому подобное, посмотреть, как часто они друг в друга переходят, проставить вероятности, ээ, и таким образом получить ну, по сути, карту векторов, карту мбедингов, да, вот, а, и по ней, а, понять, что должно идти за следующим токеном, за следующим словом, буквой там и так далее, в зависимости от того, какую размерность мы выбрали. Аа, значит, ну, в современных лммах, по сути, этот принцип используется на первых слоях, когда делается матрица берингов, так называемая, да, то есть когда вы задаёте какую-то фразу, а, она заходит в первый слой модели, а пытается сначала найти в таблице токенов всю эту фразу, а, значит, если она так называемый жадный механизм, да, вот если находит её, то она, соответственно, ищет, что там может быть дальше за ней, переходит на следующие слои. А если не находит, она её начинает урезать потихонечку, пока не найдёт токен, который, соответственно, в этой таблице представлен. А, и если въехал грека через реку, у вас фактически присутствует здесь двухмерная такая матрица, да, вот в которой, э, переход осуществляется, ну, условно, влево, вправо, э, то, э, например, в ламе, аэ, параметров у одного вектора 4.096. Вот, то есть 4.096 пространство, в котором, соответственно, у вас могут быть сдвиги, а как лексические одна Алексема идёт за другой, так это эмоционально различные не знаю, там оттенки, грустные, весёлые там, и так далее. То есть есть огромное количество параметров, по которым вот эти вот модели э обучаются. А дальше, соответственно, проходят по оставшимся а слоям, добавляются какие-то фильтры, механизмы внимания и тому подобное. Вот. И в итоге вы получаете, а, ответ вот, то есть это не совсем такой Т9 добавочный, а, но тем не менее, значит, это всё-таки вероятностная модель.
Определились с терминами, теперь возвращаемся, собственно говоря, с обезьянами. Итак, у нас есть замечательный механизм, который пошёл, а, значит, от Маркова, преобразовывался в течение там более полутора веков. А, и в итоге, значит, пришёл к GPT или к лоду, или там, в общем, к любой LLM, которую вы знаете. И, собственно, возникает вопрос: "Хорошо, ну тогда получается, что мы можем поставить обезьянку, а она скажет, что ей нужно, это закинется в Лулм, она, соответственно, попытается то, что значит нармотала обезьянка, разложить на составляющее, сопоставить какие-то зависимости, и мы получим.
>> Нир, давай всё-таки посмотрим, что у тебя глю это пампает. Потому что это не ушло.
>> Пампает на присоединении нового участника к зуму. А, поэтому, может быть, вообще вырубить все звуки на компьютере, и тогда оно поможет.
>> Так, хорошо. Тогда вот я вырубил все звуки на компьютере. Меня слышно? Сейчас момент, я посмотрю на Андрея. Андрей, помаши рукой, если меня слышно. Отлично. Андрей, если будут ещё какие-то проблемы, ты помаши мне рукой, потому что я вас не слышу.
Так, а отлично. Вот, значит, обезьянка LM прод. Значит, мы пришли к тому, что у нас есть модель, которая может генерить дополнять значит по зависимостям и вроде как даже укладывать код. А запускаем в прот. Что получаем? Получаем, во-первых, кривой код, во-вторых, кривой код, который не компилируется. Вот что же нам с этим делать? Наверное, нам надо пройтись по этим трём составляющим и попробовать их как-то оптимизировать. Итак, у нас рождается по сути три парадигмы. Вот аэ значит, которые э по которым мы, собственно, сейчас и пойдём, да, три точки. То есть первая точка, точнее последняя - это вот прот. А подразумевает то, что мы тюним область результата. То есть мы, например, используем какие-то шаблонные проекты или готовые модули, конструкторы сайтов RFA, не знаю, N8N, no Code, прости, господи, Low CД и тому подобное, да? То есть мы сокращаем варианты по сути на а конечной вот этой вот миле. А-а, либо а мы качаем, да, то есть обучаем её, добавляем какие-то раги, добавляем цепь рассуждений, а, ну, ещё какие-то, да, либо мы первую точку меняем, то есть мы ставим более умного инженера, учим его проумт инженерингу, добавляем всяческие рулы, workflow, а, делаем толковые ТЗ, правила исполнения, кодстайлы и прочее, да, там умные де. Вот.
Ну, давайте пойдём, собственно, с конца, с результата. Попробуем прокачать его. Работаем на стороне результата. А в данном случае, а, значит, самые, наверное, распространённые варианты, примера, а, это различные конструкторы, например, lavable. Вот мы на нём останавливаться особо не будем. Вот это инструмент, который изначально заявляет то, что вы вбиваете один промт. И фактически он вам даёт уже результат. К этим же решениям относится Bolt, Apple Pie и тому подобное. Аа причём, что любопытно, а значит, они работают достаточно хорошо, но при этом даже сами создатели этих продуктов понимают, что этого явно недостаточно. И, э, несмотря на то, что вот вайpкодиing с одного промта получаете уже готовый результат, они подчёркивают, что а данные решения также создают рабочий код, используют мультиагентов для проверки кода и генерируют, значит, архитектуру там, ну, и тому подобное, да. То есть они даже сами с, несмотря на то, что вроде как вайп-код уходит и в полное отличение от слова код, даже, наверное, это уже совсем какой-то вайпинг, вот они всё-таки им вынуждены доказывать, что это потом расширяемо и применимо в программировании. Соответственно, в какой-то момент понимаете, что недостаточно вам просто ввести промт. Вот опускаетесь ниже до классического RPA. Э, классический пример - это N8N, да, вот, в котором вы раскладываете на какие-то уже более понятные и приближенные к коду, к программированию, а, модули. Там у N8N - это не совсем уже низкий уровень, да? То есть это может быть там, не знаю, коннект в Facebook, это может быть коннект в Телегу там и тому подобное. То есть тут всё-таки а не совсем, э, какой-то низ низкий уровень. Вот. А, и они начинают добавлять себе купилоты, да? То есть они начинают себе добавлять чаты для того, чтобы генерировать, э, соответственно, их workкфлоow. Здесь, в общем, та же проблема. Это всё работает через раз. Вот. И здесь всё-таки уже недостаточно просто накидывать квадраты. Надо какую-то алгоритмизацию, по крайней мере, знать, да, вообще понятие алгоритма, наверное. Вот. А-а, ну и в итоге мы приходим к тому, что лм глупая, она генерит не то, надо всё равно дорабатывать руками там и так далее. Ну и тогда вопрос, собственно говоря, о чём мы в эту лму ходили? Аа, ну и конечная наверное стадия этого процесса - это когда вы просто-напросто описываете все варианты вообще возможные проектов, которые могут быть, да? То есть, ну, классические, не знаю, там мобильное приложения, веб-приложения, десктопное и так далее. Вы понимаете, что у них под капотом есть эээнд, там какой-то клиент, база там и тому подобное. И фактически вы заранее пишете все куски, какие только возможно, а потом LЛM, а, по запросу пользователя просто выбирает, э, какой-то уже готовый кусок и, соответственно, вы получаете работающее приложение с кодом, которое вы можете дорабатывать и тому подобное. Вот. Но, конечно, это всё от лукавого. Вот. То есть, несмотря на минимальный порог входа, на то, что у вас будет красивый дизайн, скорее всего, потому что он отработан заранее, а быстрый старт, то, что вы можете зайти в этот лаб, вбить что вам надо и вроде как получить. Вот. А потом оказывается, что есть баги, которые вам не починить. Есть проблема с безопасностью. Систему ломают, она ломается под нагрузками, когда вы начинаете выходить на большое количество пользователей, да, даже на небольшое. Вот в моей практике был пример, когда генерировали игру, а налава был, значит, для барных игр это сделали. В итоге, короче, она даже на двух игроках уже глючила и плохо себя вела. Вот. А проблема с логикой, которую вы, собственно, убедить не можете, либо вам надо, опять-таки лезть в код, э, доработать это сложно. Плюс у вас есть зависимость от вендера, который это всё дело производит. Ну, в общем, короче, минимум гибкости - это не наш подход. вообще не имеет отношения, наверное, к чистой кодогенерации, да. Вот.
А, и мы уходим на стадию LLM. Давайте качать LM. А, значит, первое, что приходится сделать, ну, вот у нас есть лэмочка, она работает как-то не так, выдаёт некопилируемый код. Что сделали? Изначально обучили лмку. Что сделали вторым шагом? Добавили размышление. Добавили размышление. А размышления оказались достаточно абстрактными, да, и стало понятно, что даже когда размышляет модель, она, например, может не попробовать скопилировать код, она может не обложить тестами, она может не описать полностью спецификации и так далее. стало понятно, что надо дробить на определённые роли, на какие-то мультимодели. Не в плане, значит, модели, которые могут себя вбирать всё, а когда вы разбиваете модели на несколько маленьких, так называемые субагенты. И когда мы говорим о о субагентах, а с первым, кто всплывает в памяти - это плоткод. Они очень гордятся своими субагентами. Они у них под капотом. Они, собственно говоря, пошли как раз по пути вот этого второго квадрата, когда ЛМ начали развивать. У них одна из одни из лучших, значит, моделей, а, значит, их несколько, да, и они их там используют в зависимости от потребности. Вот. А при этом а значит этого недостаточно. А мы сделали замечательный саморефлектирующий агент, сделали агент-оркестратор, сделали субагентов. Вот. А, но стало понятно, что задачи достаточно большие, и для того, чтобы их исполнять, нужен определённый план. Этот план был добавлен. А, соответственно, сейчас любые практически копилоты, а, умеют планировать, разбивать натаски и, соответственно, их исполнять. В случае клода исполняется, соответственно, субгентами. Вот.
Ну, и, собственно, при пример, да, то есть у колода кода, когда я сейчас подвешу этот пример немножко там дальше его разберу, но суть следующем, что мы, а, пробуем сгенерировать, а, некий тест для а спрингового сервиса. И, в принципе, клод всё разжёвывает, у него здесь есть рининг, он показывает, значит, результаты, а, и на опытный взгляд уже может, в принципе, уцепиться в то, что здесь есть явные нарушения спринга. Вот. А, но так выглядит достаточно, ну, хорошо и вроде как похоже, а, на, значит, э работающий код, хотя это не так. Вот, аа значит, что сделал плод, э, по отношению к пользователю, да? То есть ему надо было как-то общаться с пользователем. Но тут возникает вопрос: "Хорошо, если вы общаетесь с программистами, поскольку программисты всё-таки общаются с кодом, вам надо какой-нибудь, э, UI, вот, а, желательно с, значит, на стороне пользователя. А если другие вендеры пошли по пути того, что они забрали себе какой-нибудь или заранее на неё сели, значит, там к Джетбренсу прикрепились каким-то образом или ещё к кому-то, вот, то Плот пошёл по другому пути. Они заявляют о том, что мы должны изменить полностью парадигму программирования, уйти а в консоль. Вот. Причём это такое, на самом деле, заигрывание с технической с техническим менталитетом, наверное, да, потому что истинные инженеры любят консоль, а тут, в общем, предлагают, что давайте зайдём в консоль. Этот же подход использует warp-то DPC кодер там и тому подобное, да. Вот. А, но даже клодко код в како в какой-то момент не устоял и всё-таки сделал плагин для ВС-кода, поняв, что он просто теряет аудиторию.
Вот, а что под капотом, собственно говоря, у этого клода? А под капотом у него находится лидирующий агент, оркестратор, к которому прикрепляются различные тулы, но стандартные MCP тулы. Кто не знает, соответственно, что есть MCB протокол, э, такой USB для всех нейросетей, которые позволяет, соответственно, подцеплять вообще всё, что угодно, там, не знаю, там какую-то трекинговую систему с работу с диском, с памятью, с чем угодно. Вот также у клод-кода есть память, но она сделана очень интересно. Сейчас я расскажу, как вот, а-э, соответственно, есть различные тулы для поиска. Ээ, и особенность этой системы заключается в том, что она управляется вся файлами. А работает это следующим образом. То есть когда вы сидите в плоткоде там кли или через какой-нибудь значит плагин, а, и даёте команду, первое, что делает клод, он идёт смотреть, какие инструменты ему использовать, его внутреннее. Эти инструменты делятся на три типа. Это работа с кодом, то есть чтение, запись, там различные правки, мультиправки, а отдельно выделена работа с юпитеровскими ноутбуками. Вот. Либо это какая-то навигация, а, по вебу, по диску, по файлам поиск там и тому подобное. Вот. Либо там парсинг сайтов. Вот WebF - это когда переводится, собственно говоря, с какой-то сайт забирается, переводится в в marдаунтекст и, соответственно, он дальше с ним работает. И трекинг вот, ээ, статус задач, соответственно, там создаёт э дальше смотрит, чтобы они дошли до конца. А как это работает? На примере какой-нибудь транзакции? Например, вы говорите, что хочу создать текстовый файл Redmi и хочу создать какую-то программу. Да, создаётся э ассистентом план задачи. Делается это при помощи аа тула to do write tool, вот, в котором он прописывает, что создать такой файл, создать такой скрипт. Вот, подтверждает, соответственно, у ассистента а список задач. Вот. после чего переходит в прогресс, ставит, что значит первая задача пошла в прогресс, подтверждает статус, создаёт файл, вот, соответственно, записывает туда содержимое с помощью лмки. Вот. А подтверждает, что файл создан, обновляет статус задачи, переходит к следующей. Вот, создаёт, соответственно, скрипт, закидывает туда код, а завершает задачу, подтверждает, отдаёт пользователю. В этом цикле не явно не хватает, ну, с точки зрения программиста эндого количества задач. Там покрытие кода не хватае кода тестами не хватает, я не знаю, там каких-то проверок не хватает, э, э, ну, собственно, структуры проекта с понимания, какие там фреймворки там и тому подобное, да. Вот.
А на самом деле у клодкода есть, э, значит, под капотом эта информация и вопрос, как она хранится, да? То есть где, собственно говоря, память о проекте, где вообще вся его структура, где вот вот эти фреймворки, как понимать, что покрывать, ну и так далее. А, значит, э в этом моменте мы добавляем в нашу архитектуру память, да? То есть у нас есть лмка, есть оркестратор, есть субагенты, есть, соответственно, этот ризанинг, который там прокручивает вот эти вот с планами может работать, а с размышлениями. Добавляем память. Память у клода организована очень странным образом. А хотя это абсолютно укладывается, наверное, вот эту вот концепцию того, что давайте мы сделаем всё через консоль. Клод оперирует исключительно файлами. То есть, э, когда вы, э, инициируете, э-э, проект или там пытаетесь его индексировать, а он сканирует вообще все ключевые файлы, папки, а он знает, что такое ключевые, и, соответственно, если у вас что-то там совсем экзотическое, он не знает, но а для стандартных там, не знаю, React приложений ЯваA там и так далее, он понимает, какие ключевые файлы. Он их пробегает, делает по ним, по сути, сари. вот делает описание этого проекта, кладёт его аа файл и дальше он работает с ним. А он его может обновлять, он в него закидывает, в том числе а дерево файлов, которые он считает нужными. А, и после этого он отпихает свой контекст. Вот, э, собственно говоря, м, во, вот и вся индексация, да? То есть никакого рага, никакого прохода полностью по проекту с тем, чтобы вам найти какие-то куски, э, быстро, векторно уклода нет. Вот, э, он для того, чтобы вам что-то найти, сначала лезет в свою памятку, а, значит, маркдауновскую. После этого он, соответственно, использует свои тулы для того, чтобы пройтись по проекту и найти то, что ему нужно. Ну, в принципе, это достаточно быстрый подход. Вот. Но есть у него, соответственно, минусы. Вот плюсы то, что вы можете это всё файлы посмотреть. Также он использует, э, skills md, так называемые, для добавления своих тулов, в которые вы можете записать, что при определённых, э, ну, по сути, это workflow, такие с сштулы, в которые вы можете записать, что если я, допустим, запросил создать питоновский скрипт, то сделай вот вот это, вызови её такие-то тулы, вот тебе такие-то промкты и так далее. А плюс этого также подхода в том, что вы можете посмотреть эти все текстовые файлы, и они все, собственно говоря, запихиваются в контекст, который отправляется в плод. Никаких деревошей, каких-то хитрых рагов и так далее здесь нету. Вот, собственно говоря, а подход к лода.
В чём плюс этого подхода? Ну, во-первых, клод делает одни из лучших моделей для кодинга. Ещё до того, как, собственно говоря, капилоты стали появляться, но какие-то более-менее разумные, вот Клод лидировал в этом плане. Они в какой-то момент обогнали GPT с, ну, и, в общем, дальше там уже все толкались, но клод действительно хорош. У них есть, э, три модели: Sнеet, Opus, Хайку. Вот. И в самом клоде можно настроить и нужно настраивать, э, какая модель используется в каком значит момент времени. А это нужно в том числе для того, чтобы денег не потерять. Так что все модели стоят по-разному. Скорость у клода бешеная. Аа значит у него, собственно говоря, на на это упор. Всё хранится в файлах, можно просматривать. У него огромное контекстное окно, если я не ошибаюсь, 100.000 токенов у него была
Последняя, когда я смотрел. Вот. А он специализируется на LLM. Они делают свои сетки, обучают. В общем, в этом они молодцы. Вот.
А недостатки, ну, для кого-то, может, это достоинство, это то, что мы сдвигаемся в консоль, вот по полной, соответственно, теряем все наши любимые фишечки. Вот. А есть VR совершенно дичайшая система конфигов, в общем, да, файлы. Привет всем. Отсутствие, а, любого любой проверки в рантайме, датафлоу, анализы и тому подобное. Ну, плюс денежные расходы. Ну и, собственно говоря, вероятность того, что он сгенерит работающий код, на самом деле 60-70%. Вот как пример тот, который был в начале, да, когда он сгенерировал, а, соответственно, тест для спринга, а, должен быть не Mock, а MockBean. Вот есть там конфликт со SpringBootTest. Он выбрал совершенно другую аннотацию. Вот там `initest` поставил несоответствие с остальному проекту. Вот. Ну и какие-то эксепшены проигнорировал. Вот штука хорошая, быстрая, но имеет недостатки.
И казалось бы, может быть, надо сделать вообще какую-то навороченную модель, которая обучена на всём коде. Собственно говоря, GitHub Copilot, например, он пошёл по этому пути и, э, значит, на 54 млн репозиториев обучил своей модели. Вот огромное количество миллионов пользователей у неё сейчас. 92% разработчиков значит уже пробовали какие-то копайлоты. Естественно, GitHub Copilot был там одним из первых большинства. Вот. А там денег на рынке тоже там, значит, много. Но а даже GitHub Copilot он не учитывает весь проект. Хотя все заявляют, что мы работаем на больших кодовых базах и так далее, но вот вопрос, как вы с ними работаете, да? То есть если вы по ним также там пробегаетесь, чёрт знает сколько времени, то то как бы есть ускорение, но может быть есть другие способы.
А другие способы есть. Например, у Cursor есть так называемая Merkle Tree, то есть дерево кэшей. Вот они делают следующую штуку. Значит, они выносят, э, код, э, к себе в векторные базы и, собственно говоря, по ним там ориентируются. Плюс они составляют дерево проекта, по которому тоже ориентируются. Рассказывают, что значит это всё зашифровано, фунцировано, э, поэтому переживать не стоит. Но проблема есть в том, что, во-первых, они это всё хранят в облаках у себя с копом. Аа и тут, наверное, вообще стоит рассказать, а, о команде этого замечательного проекта. А значит, э люди сидят в Сан-Франциско. Вот, э, у них нет времени на разработку своей IDE. Вопрос о том, собственно говоря, что там кто лучше на рынке и так далее. Все лучшие в чём-то своём, они специализируются. Вот. Им некогда было разрабатывать свой IDE, поэтому они форкнули VS Code. Они форкнули VS Code, обнаружили, что, собственно говоря, функционала родного VS Code недостаточно, в том числе для некоторых подсветок. И они переписывали под себя популярные плагины. Вот, соответственно, закупорили какую-то сборку IDE. Также это им дало то, что они могут туда добавлять свои какие-то там вложения. Вот сейчас они там добавили агентское вложение, планы и так далее. Имети вкладки. Вот. А, то есть они могут преобразовывать интерфейс. В остаётся вопрос открытым, да, насколько хорошо, аэ, работает IDE, которую дорабатывали не те, кто специализируется на, но тем не менее она у них есть. Вот.
Аа и ещё особенность этого проекта заключается в том, что они фактически наживую, э, экспериментируются с огромным количеством пользователей. То есть у них основная база пользователей - это B2C, то есть это частный сектор, это обычные программисты. а не Enterprise, хотя у них есть Enterprise. Вот. И, э, они заменяют свои технологии по мере того, как у них система стаёт колом. Первый раз это было, когда они использовали базу Yugabyte для того, чтобы, соответственно, хранить всю информацию по проектам. Они перешли на Postgres. А неожиданно для них Postgres стал колом, потому что, э, они ожидали, по-моему, лимита на 40 ТБ, что он станет колом, а он стал уже на двадцати. Они пошли к Amazon с запросом. Они работают все на облаках. Они пошли к Amazon с запросом, собственно говоря, а а не могли бы вы решить эту проблему? Amazon развёл руками, сказал: "У вас слишком большая нестандартная нагрузка, так что решайте, ребята, сами". Вот в тот момент, когда ребята решали сами, что-то там чистили, переиндексировали и так далее, один из создателей этого проекта, он сидел, экспериментировал с TurboGraph. Это сырой стартап, но который как раз обещал такие проблемы решить. и они на него переползли раньше, чем решили, собственно говоря, проблемы Postgres. Поэтому сейчас он на TurboGraph. Это единственная причина. Вот.
А ну и, собственно говоря, у них была проблема холодного старта, когда они перезапускаются при каждом своём падении, то у них, соответственно, накидывается огромное количество пользователей, надо кого-то ограничивать и так далее. И вполне возможно, что в эту ограниченную подборку можете попасть вы. Поэтому, как бы, для домашнего решения офигенная штука, замечательная. Но а для Enterprise я бы а очень а подумал над этим. Вот, собственно, а ну, чтобы ещё раз закрепить, да? То есть это 50 инженеров, у них миллион транзакций в секунду среднея, это не пиковая. Э у них рост пользователей гигантский, то есть 100 раз за 12 месяцев. Огромное количество строк кода, а куча бабок, да, куча денег, значит, огромное количество индексов, ну, и тому подобное. Технологический стек, там TypeScript, Rust и всякая экзотика. Вот. И запускают они это всё в облаках, на них ориентируются, собственно, иначе бы они это всё не выдержали, да? То есть они на своих плечах эту всю админку просто не потянут. Релизы каждые 2-4 недели, как они называют. Но на самом деле, если вы будете пользоваться Cursor, у вас постоянно будет висеть плашка по поводу того, что он обновляется. Он обновляется несколько раз в день. Вот. А в общем, команда небольшая, объёмы огромные. Ну и, собственно, их индексация. Фиксация идёт, э, периодически, она нагружает Cursor. Вот. А с одной стороны, это хорошо, да? То есть вы получаете, а, он получает представление о проекте. Вот. А, но с другой стороны, это тоже там они периодически подвисают. То есть на самом деле, когда с мультирепозиториями работаете, то наверняка замечали это. Когда Cursor подвисает, вот он подвисает ровно из-за индексации. Вот. Он шифрует код, закидывает его на сервер свой. Соответственно, дальше, если ему надо с ним работать, он его там дошифрует, посылает обратно, ну и так далее. Вот, в общем, вся эта индексация ест времени. Вот.
А плюс у них есть разделение, значит, на пользователей обычных и на пользователей Enterprise. А, соответственно, это разные уровни сервисов облака. Вот. И, соответственно, здесь вот стоит тоже учитывать, что можно попасть в какую-то выборку, да? То есть, если вы находитесь в San Francisco, большая компания, только понятно, приоритет будет высокий. В одном случае можно попасть. Вот. А, ну, собственно говоря, это про Cursor. Достоинства Cursor'а - это то, что есть своя IDE, хоть, значит, форкнутая, а, есть своя модель. Они, значит, композитор сделали, индексируют и дерево проекта, в отличие от Copilot. Ну, он тоже вроде как индексирует, но это уже более похоже на индексацию. А, значит, используют тулы на стороне пользователей. То есть фактически вы можете попросить его развернуть вам Uber, понять, в чём ошибки, ну, в общем, всё админку сделать. А у них есть замечательные мобильные агенты, то есть вы можете прямо с мобилы запускать эти агенты, и они, соответственно, будут а там молотить в GitHub. Вы сидите с чашечкой кофе в шезлонге, можете, соответственно, что-то программировать, потом прийти, дописать это уже на ноутбуке.
Из недостатков - это гигантские затраты на индексацию в облако. А-а, стартап находится не у нас. Вот. И есть ещё один недостаток. Они исполняют него на VIP пользователя. То есть, если у вас в IDE настроено там или, не знаю, где-то в VS Code настроены значит э какие-то окружения, PATHы и тому подобное, он может там зависимости библиотеки и так далее, он мог просто просто не отловить. ВВ опять же там питоновские и так далее, он это может не отловить. Вот. Ну и он прям там весьма условный, да? То есть он прямо отрезает всё, что они делают в облаке, а это в том числе автокомплит, который работает при помощи их индексации. Вот поэтому автокомплит у Cursor локального просто работать не будет. Вот, в общем, мм замечательная штука для B2C, для прототипирования. Вот. Но не всегда не везде подходит.
Ну и последнее, собственно говоря, куда мы сдвигаемся, это когда мы попытались на проде поколдовать в сфере результата, когда мы попытались в LLM, значит, пооптимизировать. А теперь будем смотреть на стороне пользователя, собственно говоря, что можно улучшить. А, ну, во-первых, да, хотелось бы развернуть у себя. И первое, что можно сделать - это взять Cursor'ный агент C++, выкачать. У него есть плагины, у него есть тулинги, в общем, все, все 33 удовольствия, но они находятся на стороне пользователя. Вот. Аэ, значит, особенность этого инструмента, вот в чём его есть, там эксклюзивная фишка - это то, что они фанаты XML. А, то есть, если вы, например, хотите дёрнуть какой-то тул, недостаточно сказать, что тебе надо дёрнуть какой-то тул, тебе надо написать это именно в XML, иначе парсер просто это пропустит. Вот. Аа, в общем-то, а с достоинствам клиента можно отнести то, что это open source, то, что есть строго типизация, вот как раз вот это через этот XML, а он медленный и требует продвинутых, более продвинутых моделей, чем все предыдущие, потому что, собственно говоря, все предыдущие у себя забирают, начинают это обрабатывать не только силами модели, но ещё вот этими вот механизмами там оркестрации, а, субагентов, каких-то индексаций и тому подобное. Клиент это всё не делает. Он запускает агент у себя. И, собственно говоря, дальше ему нужна достаточно мощная LLM снаружи для того, чтобы, собственно, это всё обработать. То есть, ну, если это там Claude какой-нибудь, то надо взять уже помощнее какой-то подороже, а, значит, нейроночку. Вот.
Наглядный пример, как это выглядит, да? То есть, например, у нас есть исходный код какой-то вот тут callback hell, так называемый, когда а значит а когда нам надо, аэ, причесать код. Вот. И вот что делает, да? То есть он замечательно всё причесал, но обработку ошибок не добавил, да? Вот. А Cursor, например, он врубился, что надо бы сюда добавить ещё обработку ошибок. Вот время примерно сопоставимое, но результат лучше у Cursor за счёт всех его механизмов.
А, ну и, наконец, значит, э мы приходим к тому, с чего, в общем-то, начинали до искусственного интеллекта. Возникает вопрос: а зачем нам LLM на операциях, которые мы делаем постоянно, там, не знаю, покрываем тестами, аа делаем сканирование, а, на уязвимости, а, линтеры запускаем, а, ну, и тому подобное, да, то есть какие-то связи простраиваем, там, та же индексация, она вся есть в стандартных средствах разработки специализированных, да, то есть для Java это там, не знаю, IntelliJ IDEA, для Android грех не использовать Android Studio. Кто пробовал что-то использовать другое, понимает, что надо использовать Android Studio и так далее. То есть есть специализированные уже наработанные какие-то вещи, что их, собственно, не использовать. И тут мы приходим как раз вот этим формальным методом. То есть это автоматизированный функционал, значит, привычных, а, средств разработки, там линтеры, методы самоиды и тому подобное. Вот. Которые работают в разы быстрее. Вот. Аа, и, собственно говоря, их можно дополнить просто LLMкой, а, и таким образом, аэ, получить максимально быстро работающий механизм. Вот. И такой подход есть. А, то есть вот пример, да, когда мы там, например, пишем, а, тот же тест для Spring, любая IDE, ну, там в данном случае это IntelliJ IDEA, да, она понимает, что это Spring, она понимает, что надо использовать Bean, она понимает а как написаны другие, э, значит тесты, то есть она имеет доступ к индексному дереву внутреннему. А-а, и достаточно просто брать из неё информацию, запрашивать API самой IDE, как тула, передавать в LLM результаты. Таким образом вы получаете более релевантный код, который собирается, который заведомо рабочий, вот, который проверен самой системой.
Это, конечно, не является совсем уж white coding, да? То есть мы попадаем на то, что нам всё-таки надо уметь программировать. Но здесь есть приятный момент. Вот пример, собственно говоря, Explait для написания тестов, да? То есть когда он разбивает понятные этапы для, а, программистов-тестировщиков, там какой-то несколько десятков сценариев, которые происходят каждый день, он их разбивает на понятные этапы. То есть, например, для тестировщика это сначала мы, а, получаем тест-кейсы, а, выделяем те, которые нас интересуют, выбираем, какой фреймворк. Он там подставляется автоматически, если он и так понятен, куда это всё складывать. тоже это вычисляемо, э, соответственно, с какие там моки, чьи использовать и так далее. То есть вы фактически получаете уже раскладку того, что будет генерироваться заранее, и только подтверждаете это вот либо что-то отклоняете. Таким образом, вы получаете стопроцентный рабочий код, но при этом вы действительно ускоряете свою разработку. Единственным недостатком, наверное, является то, что вы должны понимать, что вы делаете. Вот. А-а, так получилось, что достоинств тут, э, у меня почему-то получилось больше, хотя недостатки тоже есть. А, значит, работает. Понятно, что эта штука на стороне пользователей, работает в разы быстрее в повседневных задачах. А-а, да. Значит, помимо чата даёт интерфейсы, которые вот я показал, да? Вот. А он прям работает замечательно. Более того, это просто плагин, а, значит, в котором вся магия происходит. LLM берётся как раз для функции там понимания языка а человеческого и перевода это в какие-то конструкции, которые, ну, там, не знаю, документацию дописать, да, вот что-то такое. А у этот же инструмент используют все SAST, DAST. Есть dataflow анализ. То есть когда вы, например, хотите отловить SQL инъекцию в работающем приложении или флейковые тесты, которые у вас мигают, то срабатывают, то не срабатывают. Соответственно, это вот возможно сделать силами. И не очень понятно, как это сделать силами LLM. Ну разве что сравнить с каким-то, что кто-то где-то когда-то написал, что вот есть такая-то ошибка в этом коде. Вот вы полностью работаете в своих env, то есть все ваши PATHы, все ваши зависимости и так далее, они наследуются от IDE, поскольку вы, соответственно, не работаете. Вот.
Ну и если конкретно говорить об Explait, а не с об аналогах, да, то, соответственно, они находятся здесь, в России. Команда с JetBrains, соответственно, для JetBrains'овских тулов и пишет. Вот. А из недостатков, ну, во-первых, нет своей добычной модели пока. Вот. И нету RAG. Вот, соответственно, с поиск происходит либо в SIM, короче говоря, по синонимичному вот этому similarity search, вот, а, либо с помощью тулов самой IDE или там WebStorm, вот, там с помощью LLM можно какие-то синонимы подобрать, но полноценного векторного поиска нет. Вот.
А, собственно говоря, выводы, да? То есть все Copilot'ы у нас разные. Вот. А если что-то можно сделать без LLM, то действительно лучше сделать без LLM. Вот. Ибо, а, значит, LLM есть галлюцинации, там есть проблемы контекста, есть проблемы верификации и тому подобное. А если есть задачи, которые делает быстрее, то есть, например, там общение с, не знаю, национальная документация, понимание какого-то текста и тому подобное, то, конечно, лучше использовать LLM. А нельзя говорить, что сейчас есть какой-то единый стандарт на то, как делают что-то Copilot'ы. Вы видели, что разные подходы, разные структуры и тому подобное. Вот. И вообще разные философии, да? То есть это ещё не устоялось и скорее всего э будут какие-то разноправленные направления, которые там интегрироваться будут и так далее. В принципе, скорее всего, а мы будем смешивать разные Copilot'ы, разные агентные системы для того, чтобы добиться, ну, какие-то гибридные системы, для того, чтобы добиться высокой производительности. Я вот там сейчас покажу табличку, как это можно смешать. В общем, даже самые крупные игроки сейчас на стадии экспериментов. Поэтому говорить о том, что у кого-то там денег больше там или ещё что-то, команда там какая-то и так далее, в принципе, сейчас вы сами можете запустить свой Copilot, не знаю, форкнуть, форкнуть VS Code, форкнуть ещё что-то и сделать в общем, войти в эту замечательную гонку. Инвесторы стоят на пороге, я вас уверяю. Вот.
Аа как же всё-таки тогда выбрать? Но если брать из этих четырёх инструментов, когда стоит брать Claude Code? Если вы поклонник консоли, однозначно Claude Code или там Warp какой-нибудь. Вот. Но у Claude просто реально мощный искусственный интеллект, они на нём специализируются, хорошие LLM делают. Вот. Э, но, значит, если вы используете IDE фанат там, не знаю, э, каких-то именно тулингов внутри IDE, то нет. И если вы не хотите зависеть от вендора, а, из Сан-Франциско, опять же, вот. Аа Cursor, соответственно, если вы вам надо сделать быстрые прототипы, если вам надо решить какие-то гибкие задачи, в том числе админские, DevOps'овские ещё какие-то, то Cursor вообще красавчик. Вот. Э, соответственно, если вы собираетесь запускать уже что-то масштабное, нагруженное решение, не стоит какой-то быстрый прототип, что-то показать, отработать бизнес теорию. Cursor, молодец. Вот. Cline, соответственно, если open source, вам надо всё open source. Cline замечательный, но тут вы сталкиваетесь с определёнными, а, ограничениями. Если вам просто нужен добавочный какой-то агент и вас это устраивает, то норм, как говорится. Ребята там бегут впереди, но будет подбирать, догонять их в какой-то момент. Вот. Но если вам нужно стабильное решение для прода, то, естественно, стоит точно не стоит брать. Это просто такая подсказка. А вот если вам нужно стабильные решения для прода именно какие-то, чтобы вам просто встроить это в SDLC именно в Enterprise на больших проектах и так далее, то есть где вам надо именно то, чтобы вы могли это автоматизировать, не знаю, там покрытие тестами, а какие-то а ну в общем, автоматизировать стандартные задачи программистов, то это Explait. Вот у них даже вынесено, собственно говоря, эти задач. Можете прямо из списка выбирать, что вам включить в эту автоматизацию. Но если вам нужен какой-то инструмент для экспериментов и white coding, он точно не подойдёт, потому что с, ну, он более специализированный, да, то есть всё-таки здесь невольная фантазия, можно на Cursor'е пофантазировать, потом в Explait'е закрепить.
А все материалы, по которым, собственно говоря, можно почитать глубже, понять, как это происходит, я приложил в презентации, да, то есть есть официальная дока, есть разбор инжиниринга. в том числе русского Claude. Аа есть описание Cursor'а под капотом, опять же там reverse engineering. Вот. Клайна вообще код доступен, можно скачать, да? У Splait'а, ну, есть документация и, собственно говоря, саппорт у вас же здесь же прямо рядышком. Вот. А если вопросы? Я сейчас включу звук. >> Приём. >> Есть, есть вопросы, Эвенир. >> А давай прямо начнём с простого. Ну вот смотри, Свереденко Алексей Explait получается больше заточен под тесты. >> Конец вопроса. >> Да. >> Вот X был заточен под тесты, но далее, соответственно, расширился до Copilot. То есть то, что было показано как UI для тестов, то же самое присутствует для разработки. Вот вообще у Explait'а, насколько я знаю, было были проведены исследования именно по российским компаниям. Ээ, значит, какие типичные задачи решают разработчики. И они все были закреплены как раз вот в эти формальные методы аа с точки зрения разработки и с точки зрения тестирования. То есть всё, что вы там делаете, условно, какие-то таски в Jira прилетают типичные, они, скорее всего, покрыты на какой-то процент большой. Вот не только тестированием. >> Но здесь вот есть. А Женя Трифонов. Почему минусом Claude Code назван вендорлок? Давай, Эвенир, сам читай, что я тебя буду это зачитывать. >> А сейчас, секундочку. Да, открою чатик. Момент. >> Там ещё, кстати, вот Глеб, спасибо большое, уже ответил на парочку, на один вопрос. Вот я вижу вот второй даже. Да, у нас тут получилось это уже горизонтальные комьюнити связи. Давай. Вот Женя Трифонов спросил. >> А так я, честно говоря, не вижу вопросов. >> Ну вот смотри. Ладно, зачитываю. Ты наговоришь, что вендорлок у Claude, потому что он хранит а он хранит всё в файликах, да? Берёшь просто эти файлики, которые у Claude, и натравливаешь на другого, на него другого агента. И вот у тебя как бы и вендорлока-то и нету уже. >> Аа, да. Значит, э натравить на свою модель можно. Вы тогда потеряете, собственно говоря, все прелести Claude Code. А, по сути, да, то есть он у себя, когда забирает, он вот эту вот всю чудесную историю проворачивает на стороне серверов. Если вы, а, отрубаете, то вы получаете урезанный функционал вплоть там до автокомплита может не срабатывать. Вот. И вендорлок здесь заключается в том, что, а, ну, во-первых, на on-prem, если вы уводите, вы теряете функционал. Во-вторых, э сам Claude, ну, собственно говоря, находится в другой юрисдикции. Вот. И в случае, если а эти случаи постоянно, вот то, что я показывал, да, там у того же Cursor'а случалось, э если вдруг какое-то падение, ещё что-то, то вы будете явно не в приоритете и поддержку не получите. Ну вот как-то так. То есть если это значимый фактор, то имейте в виду. Так, не для всех это значимый фактор. >> Ну, тут пошли это поострее вопросики. Ну, давай начнём с простого. Вот. Ээ, сложилось впечатление у Владимира Рогожина, что Explait - это больше про Java, правда или нет? >> Ага. А, да, всё, я вижу где-то вопросы. А, значит, по поводу Explait'а заточенного по Java. Он не заточен по Java, он заточен изначально был по JetBrains'овски. Ну, поскольку команда из JetBrains'ов по сути вот, э, он был заточен как раз под JetBrains'овские тулы, то есть IntelliJ IDEA и так далее. Но сегодня, если я не ошибаюсь, 2 часа будет мастер-класс как раз по Explait'у. А, и там будет как он там, Rider, да, называется этот. Я не очень уверен, насколько это родное для .NET'овцев. Вот. Но по сути, да, наверное, можно сказать, что он заточен под Java изначально, а потом он уже там расширялся. То есть он сейчас есть и VS Code и ну и в PyCharm, понятно, и с в Android Studio и кто там ещё в WebStorm. Вот. Так чтоки не догрусят. Там просто придётся на Rider переезжать или в VS Code сидеть. Так что там дальше? Мы RAG Claude'у кстати, через MCP прикручивали буквально на днях. ClaudeText называется работает хорошо. Прекрасный лайфхак. Можно использовать. Так, компания считает код своей собственностью. Вероятность утечек какая. Вот. Ну, собственно, здесь как раз к вопросу, что использовать, да? То есть, если вы, а, хотите что-то быстро сгенерировать, например, там прототипы для какого-то presale или просто показать свою идею или какую-то фишечку обкатать в проекте, а, на ограниченном вот эта территория, то, собственно, э вы можете использовать, например, тот же Cursor, который утверждает, что он фунцирует код. Насколько им верить? Ну, вопрос такой открытый. Либо вы используете российские решения с там, есть ещё там Gigacode, есть там Яндексы, соответственно, и так далее. Вот. Хотя, ну вот из них не буду рекламировать, но короче мои пристрастия, вы поняли. Вот. А, значит, э IDE в контекст, то есть запихивает это контекст ограничен. Окно может распухнуть. Да. Аа всё верно. Но у них достаточно большие контекстные окна. Вот. Но да, собственно говоря, с Claude запихивает всё в MD-хе, и он фанат файлов. А в этом есть минусы. Зато работает быстро. Так, Rider - это родное наше. Прекрасно. А, значит, вот будет как раз по нему мастер-класс. Скажите, пожалуйста, есть ли зависимость между используемым языком на проекте и выбором Copilot или Copilot'ы всё же как-то анализируют исходный код независимо от языка? А LLM в принципе по барабану, как? Ну, то есть, если она обучена на каком-то языке, она его понимает, но, э, она его понимает именно вероятностной моделью, да, то есть все особенности Spring'а, а, допустим, там для Java, да, с, ну, LLM, как я показывал, выдаст плохо. То есть, в принципе, лучше, конечно, брать проприетарные IDE. То есть, ну, там для Java IntelliJ IDEA, для React, не знаю, WebStorm, да, вот, ну, а лучше работают специализированные и то же самое с Copilot'ами. Так, стоит ли опираться на выполнение задачи с точки зрения на выполняемое с точки зрения выбора? Да, стоит опираться на с точки зрения выбора на те задачи, которые вы делаете. Безусловно, а вот, э, если что-то надо быстрое сделать, неважно где, то можно использовать любой Copilot. Если вам надо специализированно работать и включать SDLC, безусловно, вам надо подбирать тот Copilot, который на этом специализируется. Так, какие агенты порекомендовали бы Claude добавить? А, фичу видел, но как использовать сначала не придумал. А, вроде так неплохо работал, а тут, оказывается, может быть и лучше. А, слушайте, но понятно, что стандартном я добавляю технического писателя. Вот, причём я добавляю технических писателей двух видов. Один - это который пишет нормальную техническую документацию, а второй, который пишет документацию для школьников. Вот. А формирует так называемый Architecture Pods, вот для того, чтобы быстро вводить людей в проект. Вот. а также тестировщиков различного вида и с на архитектуре. Э вообще по C4 их раскидываю. Вот, э, с, соответственно, что каждый за свой слой отвечает, потому что когда делаешь такого кросс-архитектора, то а он обычно прикашивается в какую-то сторону, либо там на некоторых уровнях архитектуры квадратов мало рисует, либо там связи плохо простраивает и так далее. Поэтому лучше передаточное звено, как раз на вот этих субагентах это хорошо работает. Так, а, ну вот, собственно говоря, написали, что Code Reviewer, Test Engineer, обновление документации, да, ну, в общем, всё стандартно. А Cursor ведь тоже может использовать MD-файлы для промт, подсказок, скмd, а, архитек MD и так далее. Да, всё верно, всё строится на MD файлах. Там прямо целая религия MD-файлов. Есть ли разница в качестве результата в зависимости от языка, на котором вводится промт русский или английский? Ну хотел бы сказать, что да, вот он всё равно это потом матчит, да. И тут, кстати говоря, тоже LLM модели всё-таки есть обученные там на русском языке, есть не на русском, да, но для кода на самом деле не столь принципиально. Мы не Я не хочу ничего сказать про лексикон программистов, но, э, мы общаемся обычно не на русском языке, мы общаемся на суржике таком англо-русском, да, если вы работаете в Copilot, то, скорее всего, вы будете говорить на понятном русском для любой, которая работает с кодом. Ah.