Как подготовить проект и окружение к агентной разработке Кирилл Мокевнин Hexlet

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

Хмм, вас придётся чем-то удивлять, да? А примерно 40-30%. Вот когда я на Хайлоуде задавал этот вопрос и ко мне приходили люди, там было примерно 20-25%. То есть получается, буквально за 10 дней у нас на 10% пунктов увеличилось количество людей [смех], которые не пишут код сами. А хорошо, тогда вопрос. У нас вообще сегодня будет такой немножко интерактивный доклад, э, с взаимодействием. А вы используете внутренние системы, допустим, то, что в бигтехах сейчас происходит, или вы на Клоде, кодексе и чём-то таком?

50 на 50. Или как, знаете, есть такое сейчас понятие AI shadows, что-то типа такого теневой AI, да? То есть когда вам дают, говорят: "Используйте вот нашу фигню", а вы без палева ставите туда Клод и как бы работаете на нём. Такое тоже возможно, да. Но мы никому про это не скажем. Итак, а, да, э, я достаточно давно в разработке и вообще в IT, но поскольку люди уже забывают, что было там десятки лет назад, поэтому я просто представляюсь блогер. Вот,

соответственно, с вами сегодня блогер, а я веду подкаст Организованное программирование. Надеюсь, вы его смотрите. Если нет, после сегодняшнего дня начните его смотреть. Э, и вообще, э, я занимаюсь очень долго, не только разработкой, но и обучением, с, наверное, с года с одиннадцатого. У меня достаточно большая школа. А, и, наверное, одна из вещей, которую я часто рассказываю, что я, наверное, в России больше всех выучил технических директоров. Потому что если посчитать, сколько лет мы занимаемся, то количество людей, которые достигли этой точки, их просто десятки. Даже здесь, кстати, как минимум есть один представитель. Ко мне подошёл человек из Бера, говорит, начинал свой путь с Хекслета, и сейчас он отвечает за сбор данных в Хекслете.

Ой, в Хекслете, господи, в Сбере для подготовки Ишки и обучения. Вот. Так что вот такая вот прикольная штука. Ну и Олег когда-то мне награду дал за вклад в вой IT. А у нас, значит, давайте вот с чего начнём. Это очень, может быть, неожиданно, но мы говорим вообще в целом, да, вот у вас с нуля проект, в нём ещё ничего нет. Я понимаю, что у вас у многих уже что-то есть, но мы предполагаем, что ничего нет. И возникает вопрос: а, собственно, как подходить к этому? С чего надо начинать? Самое странное, э, я хотел вас немножко удивить, поэтому начинаем с мейк-файлов.

[смех] А причём здесь мейк-файлы, да? спрашивает, кто в своих проектах использует мейк-файлы. [фыркает] Угу. О'кей. Я надеюсь, потому что вы посмотрели когда-то моё видео, которое я снял 15 лет назад на эту тему. А многие до сих пор думают, что мейк-файл — это типа вот что-то там для сишников, которые что-то компилируют. На самом деле это просто раннер, который умеет выполнять команды, да? Видите, обычные баш-команды.

И, соответственно, внутри вы можете описывать всё, что хотите, а то, что у вас происходит в проекте. В реальности это очень хорошая практика. А даже до и яишной темы была. Почему? Потому что, смотрите, часто бывает такое, что в очень много разных проектов вокруг вас, там, разные команды и так далее. И, соответственно, нужно описывать в документации, а как проект стартовать, как его собирать, как с ним работать и так далее. И я очень много лет, прямо очень много, там, буквально, я на, по-моему, с года с двенадцатого про это рассказываю, о том, что файлы — прекрасное место, в котором можно все эти команды складывать. И, например, э в моей практике я всегда делаю так. У меня есть, независимо от того, на каком языке я пишу, у меня там есть стандартный набор команд make setup, make test, make start, make def, make что-нибудь ещё. Ну, в общем, плюс ещё какой-то набор команд. И фактически одновременно доставляется как бы исполнением. Поэтому открываю любой новый проект или открываю любой проект в моей компании, а у нас там, ну, сотни репозиториев, там много разного добра, маленького и не очень, а я знаю просто, что я захожу туда и вспоминаю быстренько всё, что у нас есть. Самое прикольное, почему я про это рассказываю, вы думаете, какое отношение имеет к Ишка очень хорошо знает мейк-файлы, и она очень хорошо понимает, как это использовать и какие выводы из этого делать. И оказалось, что когда, ну, во всех наших проектах моих, на самом деле, не только, если вы посмотрите GitHub и обратите внимание на очень большое количество репозиториев, особенно во фронтенд-экосистеме, вы увидите, что они тоже этим пользуются. А оказалось, что Ишка очень хорошо их кушает и очень хорошо на основе этого разбирается, что у вас есть в проекте.

То есть даже в ag MD не всегда обязательно всё это прописывать, потому что она может сюда посмотреть и сделать все выводы. Очень простое изменение, которое готовит ваш проект к и, э, к агентной разработке и, в общем-то, помогает ишке лучше в нём ориентироваться. Ну а дальше она сама выбирает, запускать мейк-файл или запускать команды из неё. Но в любом случае практически все действия, которые у вас есть, пересетапить базу данных, запустить тесты и так далее, очень удобно засовывать сюда. Мне иногда говорят: "Кирилл, ну, это будет очень сложно". Но на самом деле, как видите, это просто набор довольно тупых команд.

Там можно и скрипты из package.json вызывать. В общем, в зависимости от того, какая у вас экосистема. На самом деле сюда поместилось 32 строчки, там их штук 100 или 150. В некоторых проектах бывает больше. Но это не история про компиляцию со сложными зависимостями. Да, кстати, и в мейке ещё классная штука, там есть зависимости. Я знаю, что иногда, когда мы с людьми это обсуждаем, они говорят: "Смотри, Кирилл, есть там альтернатива, по-моему, джаст она называется, да, или ещё что-то такое".

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

Я думаю, что вопрос, чем пользоваться, до сих пор актуально стоит, да? То есть сейчас все их пилят, а их существует очень много разных. Основные у нас кто?

Это Клод, это Кодекс, это Курсор, кто ещё чем пользуется? Пи Ага, новый пи, да. Open CD.

Ага, да, есть. Сейчас китайские китайские ребята сейчас стали все выпускать. Да. Я вам расскажу один секрет. Вот буквально сегодня здесь есть мой товарищ давний. Мы вот буквально прямо переговорили и я понял, что надо одну штуку рассказать. Короче, а вы знаете, что в большинстве случаев, когда вы используете, например, Open CD или Курсор, то доступ к моделям вы получаете по API PSGO, это называется, да? То есть вы платите фактически за каждый доступ. Вы знаете, что такая плата примерно в 10x раз больше, да? Да. То есть, ну вот, буквально сейчас мы разговаривали и, собственно, мой товарищ говорит: "Я в прошлом месяце потратил на Клод 5.000 долларов". Я говорю: "Я в прошлом месяце на Клод потратил 100 долларов". А, и в реальности оказалось то, что действительно, когда, ну, когда человек этого не знает, это легко может оказаться, то он как бы думает, что это, ну, так все платят. На самом деле Антропик, если вы помните, какое-то время назад запретил использовать свою подписку через Open CD. Там было очень большой ругань на эту тему. И фактически единственный способ экономить деньги и пользоваться подпиской, которая даёт вам, ну, хорошую, выгодную, так сказать, вариант испол

[смех] А причём здесь майк файлы, да? спрашивает, кто в своих проектах использует йкфайлы. [фыркает] Угу. О'кей. Я надеюсь, потому что вы посмотрели когда-то моё видео, которое я снял 15 лет назад на эту тему. А многие до сих пор думают, что Micфайл - это

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

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

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

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

набор команд make Situp, make test, Make Start, make def, make, что-нибудь ещё. Ну, в общем, плюс ещё какой-то набор команд. И фактически одновременно доcвляется как бы исполнением. Поэтому открываю любой новый проект или открываю любой проект в моей компании, а у нас

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

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

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

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

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

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

Там можно и скрипты из package jйon вызывать. В общем, в зависимости от того, какая у вас экосистема. На самом деле сюда поместилось 32 строчки, там их штук 100 или 150. В некоторых проектах бывает больше. Но это не история про

компиляцию со сложными зависимостями. Да, кстати, и в Мке ещё классная штука, там есть зависимости. Я знаю, что иногда, когда мы с людьми это обсуждаем, они говорят: "Смотри, Кирилл, есть там альтернатива, по-моему, джаст она называется, да, или ещё что-то такое".

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

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

Я думаю, что вопрос, чем пользоваться, до сих пор актуально стоит, да? То есть сейчас все их пилят, а их существует очень много разных. Основные у нас кто?

Это клод, это кодекс, это курсор, кто ещё чем пользуется? Пи Ага, новый пи, да. Open cд.

Ага, да, есть. Сейчас китайские китайские ребята сейчас стали все выпускать. Да. Я вам расскажу один секрет. Вот буквально сегодня здесь есть мой товарищ давний. Мы вот буквально прямо переговорили и я понял, что надо одну штуку рассказать. Короче, а вы

знаете что в большинстве случаев, когда вы используете, например, Open CД или курсор, то доступ к моделям вы получаете по IP PSGO, это называется, да? То есть вы платите фактически за каждую за каждый доступ. Вы знаете, что такоя такая плата, она примерно в 10x раз

больше больше да? Да. То есть, ну вот, буквально сейчас мы разговаривали и, собственно, мой товарищ говорит: "Я в прошлом месяце потратил на клод 5.000 долларов". Я говорю: "Я в прошлом месяце на клод потратил 100 долларов". А, и в

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

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

Поэтому получается так, что всё-таки в современном мире есть определённая привязка, несмотря на то, что OpenCд пытается там они zН свой сделали, по-моему, они го там свою штуку сделали, они пытаются рассказывать, что мы тестируем модель и всё такое. Мы это

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

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

пробовал, и всё остальное, но, честно, после опуса возвращаться куда-то ещё довольно тяжко. Не знаю, говорят GLM 52, неплохо, да. А, но в целом всё остальное сильно ниже.

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

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

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

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

редактора код в терминал? А я его никак не копировал. Мне как-то немножко стыдно было, что у меня нет такой интеграции, как у них в Джетбренсе или там в других местах, где они выделили, да, и оно сразу туда попало. А потом прошло ещё 3

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

режиме. А это там я думал, что это у меня в голове кто-то говорит. А значит, давайте сейчас пройдёмся по базе, да? Вот когда вы начинаете с нуля, а, естественно, надо начинать fic agents MD или Clot MD. Кто не знает,

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

Почему? Если вы посмотрите Isus, там стоит просто очень сильный срач. И они объясняют это, что есть некая логика, что нужны отдельные адаптеры такой Apple Style стайл с с lightйнингом, если кто знает, да, вот этот баттл. И там все

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

simли на cД и соответственно CLД MD. И у нас работает во всех системах. Это первый хак, которым я делюсь. Вот до такого дошли у нас сегодняшние конференции. [смех] Что мы про это говорим? Не, на самом деле, это довольно забавно, потому что

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

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

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

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

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

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

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

навернули, антропики им сказали: "Ребята, на самом деле это очень плохо". Почему? Потому что, а, грубо говоря, они это начинали делать, когда модели были не очень умные, ну, недостаточно умные, и они фактически пытались их как бы заставить быть более умными тем, что там

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

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

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

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

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

поменять. То есть я вам клянусь, я отправил доклад, смотрю в Твиттере всё поменялось, я снова отпра Это как помните в песне Сектора Газа, что 3 месяца назад я написал текст этой песни.

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

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

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

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

Некоторые [откашливается] люди думают, что модели по дефолту как бы сразу читают всё, что у вас есть в проект, и сразу понимают всё. А либо надо всё в Agence MD писать. Это на самом деле не совсем так. Даже если у вас лежат

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

контекстное окно, мы сможем поместить туда проект целиком, и моделька будет знать всё и будет работать максимально эффективно. Кто до сих пор так считает?

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

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

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

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

Давайте теперь быстренько вещь, которую все знают. Все уже знают MCP, все знают колайн утилиты. А есть некий минимальный набор, который надо подключать, потому что вот прямо его надо засетапить к себе. Это вот типовой набор для веб-проектов, да? То есть у вас

коллектор ошибок, у кого-то GitLab, у кого-то GitHub, а Chrome de Tool, чтобы он в браузере открыл, посмотрел. А если у вас есть доступ к базе Redonly, который можно агенту дать, это хорошо, потому что это много даёт плюсов. Есть

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

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

видите, что слева и справа, а, одна и та же штука как бы есть, как Commandline утилита и есть MCP.

А какой выбрать вариант? Левый. Левый у меня левый. Так, это вот так, наверное, да, ко, да. На самом деле изменились э уже обстоятельства. Как видите, пока мы тут разговаривали, на Хабре вышла классная статья на эту тему.

Яндекс делал исследования с современными МCпишками, которые работают через search, если кто знает, да? То есть раньше, как было, МCпишка грузилась целиком вместе со всеми описаниями.

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

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

это не очень принципиальная вещь, но есть вещи, в которых MCP вам точно будет нужен. Без вариантов. Это когда вы раскатываете на всю компанию, в том числе не на разработчиков, потому что MCP Plug Play, да, вы жмякнули. Вот, кстати, как в клоде работает? У нас

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

Теперь представьте, если бы я своему маркетологу сказал: "Ну-ка, открывай терминал и вот тебе пять коline улит надо ставить". Ну так бы не сработало.

Вот поэтому так работает. Плюс Chrome def tools или кто-то Playri себе ставит. Это штука, которая должна работать с MCP, потому что это stateful сервис, он поднимает браузер и там с команлайном не так это просто сделать.

Вам придётся в бэкграунде запускать браузеры, а они так не умеют. И поэтому тут как бы без вариантов. Поэтому кто этим не пользовался, сделайте, поставьте. У Клода, кстати, есть интеграция с Хромом. Ну ладно, это самая простая часть, тут всё понятно. Понятно,

что у вас у всех есть какая-то своя специфика. Давайте, кстати, быстро проговорим. У кого какие ещё мсипишки есть классные? Поделитесь. Фигмаг Фигма. Дизайнер.

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

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

Вот поэтому не так уж это принципиально. А что ещё? Ээ интеграция Windows MCP и он прямо в компьютер собирает, а remote control вот этот типа, чтобы он сам делал.

Нет, неремо прямо ка. Мм, по-моему, в Маках есть, говорят, сейчас популярен Apple Scriptри стал.

Не знаю, потому что есть интеграция с хромом. С кем? С хромом прямо с браузером.

Ну вот же def tools. Chrome def tools. Дада. Да. И он называется просто он так называется репозиторий, но это именно браузер. То есть он его стартует и там прямо видишь, он написано запущен в режиме а автоматизированных тулов. То

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

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

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

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

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

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

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

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

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

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

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

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

Я зашёл в один из своих проектов и спросил его: "Как ты верифицируешь а шаги свои?" Посмотрите, насколько много он всего написал.

Он говорит, что видите, он про мейки как хорошо знает, да? Говорит, он говорит: "У меня есть мейкчек. Я могу запустить тесты, я могу запустить линтеры, я могу запустить отдельные тесты, точечный прогон и так далее, и так далее".

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

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

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

обогащает и сам с собой работает. А какие-то файлики, естественно, они складываются, они становятся общими для вас всех, для вашей команды.

Давайте немножко теперь перейдём к скилам, потому что это одна из самых таких животрепещх и интересных тем и на самом деле не таких простых. А скилы в первую очередь - это то, как некий workflow процесс, да, то, что мы делаем там по

шагам. Например, у нас есть процесс, а давайте опять же поиграем немножко в игру. Какой процесс, например, мы можем сказать? А я сейчас скажу, почему это неправда.

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

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

разбили там проектирование, не знаю, API, а потом вы сделали скилл тестирование, ещё ещё какое-то, и вы в какой-то момент говорите: "Сделай такую-то фичу". Вероятность того, что он все нужные скилы в нужном порядке вызовет, не очень большая. То есть есть,

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

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

Например, у нас есть банально SEOанализ, когда мы говорим: "Проанализируй". Давайте я даже вам покажу.

Аа вот есть, например, по перфомансу, да? То есть, например, Performance FR frontend приложения, которое прямо конкретно знает про React. И вы отдельно прямо понимаете, что я сейчас не фичи пилю, не тесты не запускаю, а я конкретно хочу по посмотреть перфоманс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

начинает работать. Давайте вот поговорим про этого дяденьку, потому что, в принципе, у меня осталось буквально 5 минут, и я сейчас посвящу небольшой блог только тому, что он творит. Кто знает этого чувака?

Грилми пользуетесь, да? Супер. Ну, опять классно, что не очень много людей. Значит, мне есть что рассказывать. Буду пока полезен. Значит, этот дядька много где работал, достаточно известный. А, смотрите, у него там 6 млн скачиваний на Skills.

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

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

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

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

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

мне после каждой сессии с ним надо выйти покурить. [смех] Я понял, что это не так прозвучало.

[смех] А, ну ладно, на меня олень смотрит. А потому что он задаст какой-нибудь вопрос: "А как вот та фича будет в этой ситуации?" Я такой: "А я и не подумал".

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

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

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

конференции High с утра до ночи общался, потом был на этом лиде. Мы все та ходили там рассказывать, кто что делает. А и я понимаю одну очень важную вещь. Вот эти ребята вот у него на репозитории, по-моему, 150.000 таров. Туда комитят

просто тонны людей каждый день. А это не очень большое количество МД-файлов. Я понимаю, что объём как бы знаний и опыта как бы всего мира там сконцентрирован сумасшедший. И я понимаю, что ни одна компания крупная, самостоятельная, ни в России, ни в Америке, ни где-то ещё, не

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

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

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

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

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

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

Spec Driven Developпмента и вот всех таких вещей, потому что мы маленькая команда и нам, в общем-то, особо не надо. Но вот эти скилы заставили меня пересмотреть отношение к этому. Почему?

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

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

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

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

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

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

рассказывает о том, что это такое, какие там есть сущности и так далее. Важно понимать, что это не ag MD. Agm MD - это просто папки, команды, то есть это какая-то общая информация о том, что происходит. Это именно антология

проекта. Но если там посмотреть дальше, а, да, не в том немножко порядке, ну ладно.

Есть история grill with dogs. То есть после этого, когда вы сделали домемоделинг, в следующий раз, когда вы хотите спроектировать фичу, вместо просто создания план по такой фиче вызывается гри with docs, а не просто грилми, потому что эта штука мало того, что

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

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

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

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

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

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

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

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

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

на это посмотреть. Ну вот, собственно, смотрите, на следующем слайде я сам себе а расшифровал, но спросил в итоге у вас.

[смех] [тяжело вздыхает] Да, мне очень, кстати, понравилось. Прикольно. Я бы сам такое писать не начал, но то, что он это делает, это работает хорошо. Контекст решение, альтернативы и последствия для проекта.

Всё. Всем большое спасибо. [аплодисменты] Ну и зайдите. Как я и говорил, они сделали сейчас вот прямо пайплайн, у них там шесть, по-моему, скилов, а, и послег там to isues, он это разбивает на тикеты и после этого уже сам может делать.

Друзья, переходим к к секции вопросов и ответов. И вот прошу первый вопрос Максиму. Микрофон.

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

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

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

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

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

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

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

месте писать. Пока, честно говоря, вот такого решения, что от и до это всё выносится, нет. Там первую, знаешь, проблему какую решали? Вот мы с ребятами из Яндекса говорили, они говорят: "Ну, МCшки все писали просто, чтобы хотя бы у

тебя были ручки, чтобы данные подёргать". Вот теперь как бы история следующая пошла про контекст. А куда его вынести? А как правильно в нём искать? А как правильно получать доступы? Я, насколько понимаю, ни у кого ещё точного ответа нет, но типа мы даже на своём

уровне. Вот когда у нас это начало получаться, я такой: "О'кей, а как мы это будем выносить?" Хмм, а мы на Яндекса сидим 360 на его экосистеме. Я подумал, а у Яндекса есть Wiки. А может быть, мы как бы вот эту штуку автоматом

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

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

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

централизации всего. Я думаю, она упрётся в какой-то момент в людей и где-то там баланс возникнет. Но мы точно сейчас будем идти вот такими перекосами, типа, а централизация, ажайлile потому что когда вот это всё началось, SC Driven Develption и так далее, там в

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

тащите нас обратно, всё это кровью написано, почему мы оттуда ушли". Вот. А большинство же пришло в Agile, когда AGE - это уже была как бы система для продажи крупняку. Это это не тот жайл, который когда-то начался. Вот. Так что

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

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

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

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

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

они задали. Вот ещё ещё [смех] раз два [фыркает] вероятность, потому что хочет подарок, да?

Не, ну не за подарок. Смотри, про про клод опять же, ну, про работу с клодкодом. А значит, ну, даже опустим в сторону российскую специфику, что я так понимаю, что антропик забанят тебя через 3 минуты, да, после попытки зайти из

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

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

он терпит всё это. Очень классно, но ты сидишь всё это время. Какой какой workкфлоу тебя по опыту? Ну или вот то, что ты наблюдаешь? То есть ты всё так же как бы выверяешь все действия. Либо ты отправил его работать. Сначала много

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

понял: ага, вот в этом как бы как будто бы идея. И мы стали пытаться как бы все части в проекте вот так вот растаскивать, чтобы понять, а что вот корень, где надо смотреть начали, да? А где вот эти вот раньше раньше это

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

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

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

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

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

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

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

Слушай, классный вопрос. Значит, два ответа. Первый ответ: вот это разные модели - это от нищебродства. То есть мы это делаем только потому, что они дорогие. А я скажу, что какое-то время назад действительно у меня был сонеet основная опус я использовал, ну, как бы

понимал, куда переключаться. В какой-то момент я это пост перестал делать, потому что моей подписки стало хватать.

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

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

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

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