Transcription
Приветствую вас на канале FWS. Меня зовут Вячеслав Колдовский. Я работаю компетенс-менеджером в Софтсервис. Также я руководитель центра генеративного искусственного интеллекта в IT-степ-университете. И я специализируюсь на внедрении искусственного интеллекта без DLC. Работаю с реальными проектами, имею реальные челенджи, а также делюсь своим опытом на воркшопах, курсах, в том числе с FWS Academy. И сегодня мы поговорим об Agentic Engineering, современном в 2026 году, как он выглядит, >> что такое agentic engineering, чем отличается от vibe coding? Если вы только начинаете использовать искусственный интеллект для того, чтобы делать какие-то приложения, то вы видите, как очень много всего, в том числе с терминологией. На самом деле все очень быстро, э меняется, бурлит. Это очень, очень интересно. И буквально еще год назад э термин кодг только появился, то есть его придумали буквально в феврале 2025 года. И этот термин стал словом года 2025, но на самом деле уже сейчас он приобрел определенный негативный подтекст, потому что вебкодинг - это когда, э, собственно инженерии как таковой нет. Это когда мы берем просто из своих мыслей говорим искусственному интеллекту, что надо сделать, и какой-нибудь инструмент, clдкод, курсор, там их сейчас очень много разных, он просто, э, превращает наши мысли в решение. Но на самом деле, э, это не так просто. Это работает для достаточно простых, примитивных проектов. Но когда мы начинаем делать что-то сложнее, работать с каким-то большим кодом, legacy кодом, проектом, который имеет много функциональности, требований, то такой подход, он не очень работает. И здесь, собственно, надо говорить о том, что есть другая сторона э вебкодинга. Это, собственно, agentic engering, то, что сейчас, собственно, так называется. Есть э к этому термину двигались мы очень разными способами. Так и был AI assisted development, AI augmented development, сейчас именно говорят agentic engineering. То ключевое отличие в том, что мы делаем инженерию, то есть мы применяем инженерные знания, best practices к тому, чтобы сделать проект, который касается всего и архитектуры, и производительности, и безопасности, и используем AI инструменты, чтобы ускорить и получить результат. То в этом, собственно, отличие. >> Как меняется софтвер-инженеринг и в чем сложности? >> Итак, вы, возможно, слышали из новостей, что многие компании переходят на то, что практически вручную не пишут код, то есть код от является полностью автогенерированным. На самом деле это далеко не всегда пока возможно, но действительно движение идет именно в таком направлении. И это такие навыки, которые ты не получишь достаточно быстро без предыдущего опыта, потому что в отличие от код, о котором мы говорили в начале, agentic engering все-таки требует достаточного большого объема пониманий, знаний, навыков, где надо знать об инструментах, их ограничениях, моделях, знать, что такое контекстное окно, знать о MC CP, знать о правилах, знать техники промпт-инжиниринга, знать agent skills. И на самом деле много-много много всего. И получается, что если раньше разработчик, он в значительной степени был ограничен своей собственной производительностью и он не мог выдать результат достаточно быстро, э, каким бы классным он ни был, он был ограничен, то сейчас происходит очень интересная ситуация, которой, в принципе, в отрасли никогда не было раньше. Это когда человек с помощью искусственного интеллекта можно, э, можно сказать, он масштабируется. Да, то есть, если ты хороший профессионал, то используя знания навыки agentic engering, ты можешь себя усилить и условно там 10х инженер умножить на 10х э э AI навыков и там получаем условно 100х инженер. Да, но если наоборот ты не профессиональный, не хороший специалист с точки зрения инженерии, плюс возможно ты не получил эти навыки agentic engженірингу, то соответственно и что-то там умноженное на ноль будет ноль. Да. Поэтому происходит на самом деле очень много изменений в отрасли относительно того, что одни навыки становятся, возможно, не такими критическими, как раньше, например. Навык, собственно, написания кода, он, вероятно, становится уже сейчас не таким важным, как раньше. А более важным становится навык понимания, ревью кода и так далее. Его надо по-другому развивать. Также изменения происходят в командах разработчиков, потому что мы начинаем сталкиваться с челенджами, которые вообще раньше не были присущи, когда нам надо, например, сделать ревью огромного объема кода. И и это еще не все понимают, как это делать правильно. То есть даже те команды, которые активно используют искусственный интеллект, конечно, они применяют модели и инструменты, которые делают кодрев'ew, но эта задача пока до конца не решена, как работать с большим объемом кода, который генерируют модели. Хотя есть определенные подходы, которые позволяют это решать и, в принципе, можно пробовать их применять. Что с безопасностью? >> На самом деле очень часто задают вопрос: "Что делать, если искусственный интеллект украдет мой код?" Да [смех] и на самом деле часто очень приходится с этим сталкиваться, э кому-то объяснять, убеждать. То действительно вопрос не выдуманный, это это правда, но здесь надо понимать много нюансов. Ну, во-первых, я ни в коем случае не говорю, что вопрос безопасности преувеличен. Он никогда не не может быть преувеличен, но это риск и надо уметь с рисками работать. Здесь, кстати, я сразу скажу, что практически все компании сейчас используют инструменты контроля версий, хранят свой код в облаке, натхабе, gitлабе, в ажure devops. И уже мы с этим риском на самом деле живем. То что код работает в облаке. Мало того, запускаются процессы CCD, код куда-то переносится. Это это уже это уже стало реальностью. И у нас просто добавляется дополнительный дополнительный периметр. Можем сказать так, что используем есть инструменты. И часто есть предубеждение, что вот, например, там мы начали использовать там курсор с проектом, ну и курсор соответственно получил доступ ко всему нашему коду и и весь его может украсть. Здесь я просто хотел бы некоторые развеять мифы относительно этого. Ну, во-первых, у курсора есть режим privacy. И, в принципе, во всех инструментах есть режим, в котором вы сознательно запрещаете использовать ваш код для тренировки моделей. Это первое. Второе, когда мы используем AI инструмент с кодом, то на самом деле такого не происходит, что вот он сразу весь куда-то передается. Даже если мы используем курсор, у него есть индексация кода, то есть он его индексирует. Но он в облаке хранит только векторные вложения, вектор Bings, и не делает собственно копию нашего кода в в облаке. То есть код у нас остается, как как он был в нашей системе. И лишь какие-то фрагменты кода передаются на серверы курсора и он уже передает провайдерам моделей. И эти провайдеры там дописывают части кода. Мы мы сделали какой-то там запрос, какой-то ко контекст передался, то есть ни в коем случае сразу весь проект туда туда не идет. Ну и кроме того, если мы используем режим privacy, то мы запрещаем тренироваться моделям с с нашего кода. Плюс также есть такая вещь, как там курсорnor, можно добавлять файлы в в Gitignore. Они должны игнорироваться при сохранении и при обработке AI моделями. Поэтому есть механизмы, которые нам позволяют управлять этим риском. И здесь вопрос, почему мы доверяем? То кто-то начнет говорить, что на самом деле, ну, может быть, нас обманут, то но на самом деле мы, когда загрузим код системы контроля версии, то мы тоже тоже доверяем. Вопрос доверия. Но, конечно, что есть провайдеры сомнительные. Сейчас на самом деле много появилось китайских моделей, китайских про провайдеров. И здесь уже вам надо быть осторожными, уже взвешивать риски. Доверяете ли вы, например, обещаниям провайдера, который говорит, что он не тренируется. Да, возможно, надо просто искать провайдера, которому вы больше доверяете. Или есть еще вариант строить свою infence инфраструктуру, то которая будет запускать м модели. И здесь, даже если вы там запускаете модели какие-то э-э китайские, в том числе, я думаю, вопрос безопасности уже не будет таким критическим. Хотя есть риски, что, например, модель может что-то сделать с вашим кодом, и это надо просто его проверять. То есть вы должны иметь механизм, который проверит выдачу кода. И уже сейчас очень много историй, когда какой-то я инструмент, что-то не то написал, оно пошло в продакш, что-то упало. Это уже вопрос даже не к инструменту, а к процессам в вашей компании, как вы делаете ревью кода. Это то, что я уже говорил на предыдущем вопросе. >> Слишком много инструментов. В чем отличие между ними? На самом деле сейчас инструментов с искусственным интеллектом, которые доступны разработчикам, стало очень много. Я бы сказал даже слишком много, но это такие реалии конкуренции. Некоторые инструменты, они достаточно давно существуют на рынке и активно развиваются. Ну, возьмем курсор и GitHubilot, например. Некоторые они стали новые, модные. Клодкод сейчас очень популярен, а некоторые появляются, исчезают, о них уже успевают все все забыть. Э, в чем собственно между ними отличие? Здесь я бы хотел сказать, что есть инструменты такие более универсальные. Это собственно там IDE, куда я отнес бы и курсор, и Copilot, и CL COD, и Vin Surf, и Anti Gravity, и еще можно много назвать других. А есть более специализированные под разные конкретные задачи, например, там для работы с фронтендом Verсеel Vzer или ФГМА сделала Фигма Makeй, ну и и тому подобное. И в принципе разработчик в своем арсенале, я считаю, должен иметь несколько инструментов. Он должен также сравнивать их, не на чем-то одном не не останавливаться, потому что - это штука очень опасная. И часто, когда ты с чем-то одним работаешь, то ты просто упускаешь, возможно, возможности и других инструментов. Та здесь я бы отдельно отметил, что часто люди на инфраструктуре, в экосистеме Майкрософта часто используют лишь GitHubilot, но, ну, у него есть свои нюансы. Я бы не хотел говорить, что инструмент, у него есть свои свои нюансы. И несмотря на то, что Microsoft его активно развивает, все-таки мир шире и возможно с другими бу вас лучшая производительность. И здесь, кстати, интересный вопрос, что у инструментов могут быть одни и те же AI модели и и казалось бы, что и там есть ко клод и и в другие инструменты. Там опус может быть и и в курсоре, и в копайлоте, и в том жедко, но на самом деле отличие не только в моделях. Здесь надо понять, что когда A инструменты в разработке применялись поэтапно, то сначала мы использовали там самый примитивный э промптинг. Мы, э, писали промт ЛМ выдавала код, мы его запускали, проверяли, но потом инструменты начали обрастать функциональностью, и сейчас они намного сложнее, чем просто запуск модели. Фактически можно сказать, что инструменты, они занимаются контекст-инжинирингом. То есть вы, когда открываете с вашим проектом, э, тот же курсор, например, то он его индексирует. Далее вы делаете запрос. Он кроме индексов также пробует детальнее исследовать код. Э, далее он необходимую информацию передает в контекст к к запросу. Причем каждый инструмент свой формирует контекст. Также он может использовать tools те, которые встроены в него, а может использовать те tools, которые вы дадите. Например, это могут быть MCP. Вы можете добавить какие-то распространенные MCP, можете свой сделать MCP. Про MCP мы еще отдельно поговорим. А также можно задать, э, какие-то правила rules. Также можно использовать команды. И сейчас очень модная, популярная техника - это использование agent skills. И это все вместе работает в контексте какого-то инструмента. От того, как инструмент построен, результат может быть очень разный, э, даже с одной и той же моделью. То есть тот промт, который вы написали в копайте, в курсоре и в выбрали ту же модель, вы можете получить совершенно другой результат. Именно потому, что все стало намного больше, чем просто модель. И это надо изучать, сравнивать, исследовать. Я советую пользоваться разными инструментами. У меня у самого очень много подписано. [смех] Я даже я я даже страшно посчитать, сколько это все стоит. А а ну для для моего опыта, я считаю, оно себя окупает. >> Чем отличаются модели? >> Итак, следующий вопрос - это собственно AI модели. Чем отличаются? Иногда люди находятся в поиске лучшей модели. И это важно и их сравнивать, подбирать, но часто лидеры меняются и для разных задач может разные модели по работать по-разному. Поэтому когда какие-то там HL Wars начинается за модели, то это на самом деле ну не не совсем правильно, потому что для одной кодовой базы одна модель может работать лучше, для другой и другая лучше. И здесь на самом деле надо принимать во внимание много показателей, по которым их стоит сравнивать. Я рекомендую смотреть рейтинги, потому что они могут быть такой отправной точкой для того, чтобы вы понимали хотя бы на что ориентироваться. И, например, есть такой очень популярный рейтинг LM Arena. Они сейчас вообще переименовались Arena. Заходите, там есть рейтинги, смотрите, сравнивайте. Оно дает понимание хотя бы примерно, какая модель лучше, какая какая модель хуже, но на практике надо еще принимать во внимание очень много нюансов. Э, первое, это, вероятно, стоит понимать, что есть модели, которые имеют sнрежим, так называемые думающие модели. Есть модели, которые сразу дают ответ. Конечно, что модели пока не думают как человек. Они имитируют процесс процесс мышления, но именно за счет этого SK mod они могут выдавать лучший результат. Однако медленнее. Да и это может быть дороже, потому что эти модели, они когда выполняются, они сжигают больше токенов, цена идет оплата за за токены. И это на самом деле может быть дороже, медленнее. Не для каждой для каждой задачи оправдано. Хотя, например, в моем флоу работе я вижу, что если сделать хороший план с хорошей моделью в режиме, то потом уже по этому плану можно запустить модель проще, быстрее и она его сделает до достаточно хорошо. И главное до до достаточно быстро, потому что если, например, запустить модель Sнing, как и для плана, так и потом для его имплементации, то мы можем получить практически тот же самый результат, но это будет и медленнее, и дороже. Далее надо понимать, что есть вопрос контекстного окна и есть разный объем, который контекста поддерживают модели. Но я бы не гнался за, ну, исключительно огромным контекстным окном. Вы, кстати, если откроете инструменты и посмотрите вот их их контекстное окно, которое по дефолту используется, то вы увидите, что часто меньше, чем допускает модель. Например, вот в копайте сейчас там большинство моделей, они там, кажется, 128 000 токенов. Это это очень быстро может все меняться, но просто для сравнения. У курсора там 200 пс. И для того, чтобы, например, использовать миллион токенов, то надо в курсоре там активировать отдельный режим. У CLC код надо переключаться между между моделями явно и выбирать миллион токенов. Но на самом деле нам далеко не всегда нужен максимальный контекст. Дело в том, что обработка большого объема - это и долго, и дорого. И кроме того, не все знают, но модели еще по-разному работают с разным контекстом по объему с точки зрения качества. Есть такой, можете поискать тест там про иголку в стоге сена и про проверку качества контекстного окна. И получается, что чем больше мы передаем контекста, тем хуже модели с ним справляются. И поэтому правильный подход при работе - это, собственно, задавать именно тот необходимый объем, который нужен для решения задачи. Не больше, ни меньше. В этом, собственно, и вся мастерство, э, современной разработки с инструментами и заключается. Э, далее я бы отдельно отметил вопрос стоимости, потому что на самом деле модели очень могут отличаться по по цене. И если делать agentic работу в режиме нон-стоп, то это будет еще на самом деле и недешево. Да и я видел такой шутку. Я я не знаю, шутка ли это, или это э реальность. может быть одно другое, где разработчик написал там в Штатах, что я получил зарплату 20 000 $, так из них там потратил там столько с тысяч там на жилье, на еду и так далее, но 12 000 больше половины пошло на на клодко и осталось 250. И ну и я считаю, что это абсолютно реально, потому что надо управлять также и расходами. И это вопрос очень нетривиальный, потому что если нон-стоп запустить работать модели, а еще можно запустить параллельно много агентов, это может быть не просто недешево, это может быть очень дорого и значительно больше, чем зарплата разработчика. То есть в такой реальности мы находимся. Поэтому поэтому вопрос не простой. С точки зрения подбора моделей провайдеров. Этим надо заняться достаточно серьезно, взвешивать каждый выбор, который вы делаете. >> Проблема ограниченного контекстного окна. >> Мы на самом деле уже говорили о контекстном окне, когда говорили о выборе модели, но я здесь остановлюсь подробнее. Это фактически одно из самых больших э ограничений и проблем в современной разработке. Собственно, мы не можем обычно, особенно когда речь идет о больших проектах, то просто взять и скормить одним промтом весь большой проект. На самом деле для малых проектов такая возможность есть. И есть такой очень хороший tool, называется Repomix. Вы можете просто его установить э-э в систему или использовать команду NPX Repomix и она упакует ваш весь репозиторий с кодом в один файл, который посчитает количество токенов. И для относительно небольших проектов это на самом деле вполне э-э doable. И можно и целый проектик закинуть в какую-то модель, которая поддерживает большой контекст, там Google Gemini, например, Gemini Pro и попросить какие-то вопросы задать. Это это doable, но как только мы переходим к достаточно большим проектам, то это это уже не возможно и и часто оно не не очень правильно. Я об этом говорил, что это может быть вам недешево. Надо просто научиться с этим с этим жить. Интересно, что современные инструменты уже научились, например, э упаковывать контекст. Это довольно интересная, э, вещь, когда вы, например, работаете в одном чатике в курсоре и в какой-то момент вы видите, что у вас есть показатель контекста, он там заполняется и достигает максимума. И курсор делает у summari, то есть он он упаковывает информацию. На самом деле он не сжимает как архиватор, он просто делает самери из той работы, которая была проведена. И и иногда это искажает результат. То есть иногда тогда ответ начинает плохо выдаваться. Да, вам нужно будет это все корректировать, но иногда он он продолжит работать нормально. То собственно мы должны заниматься вопросом контекст-инжиниринга. Мы должны, например, э сами вот применять свои инженерные знания для того, чтобы понять, что нужно модели для решения этой задачи. Можем явно подставлять файлы, которые для нее нужны. Э, можем прописывать спецификации какие-то, чтобы мы не нуждались в доступе вообще ко всему коду документацию делать. То есть это нормально, когда модель не будет весь код использовать, а просто какие-то спецификации, документы для того, чтобы сгенерировать ответы. Собственно, мы с этим ограничением должны научиться работать. Если к нему подойти правильно, то я бы не сказал, что это уже такая проблема, какой была она раньше, потому что несколько лет назад, да, это была одна из самых серьезных проблем, что контекстное окно довольно ограничено и как только модель начала выдавать хороший результат, здесь перестала помещаться в контекст. Я, кстати, буквально э-э когда кодинг только появился, видел такое сообщение, что кто-то написал, не помню, какой именно инструмент, но он написал, кажется, это был клодк колод как инструмент. Он написал, что в какой-то момент э перестал он мне помогать. Или или курсор, это это не так важно, но в какой-то момент мне инструмент перестал помогать, потому что весь мой код не вмещается в контекстное окно. И до этого все было хорошо, проект проект работал нормально, а теперь я ничего с этим не могу сделать. То сейчас на самом деле с этим все значительно лучше, но вы, как инженеры должны уметь и понимать, как с ним работать, >> в чем сложность больших проектов и как AI с ними могут справиться. Многие из вас на самом деле работают с серьезными большими проектами, часто с Legacy кодом, с огромной кодовой базой, которая состоит там из разных уровней архитектуры. И архитектуры тоже иногда бывают э не очень красивые и правильные, как описывают в учебниках. И вот когда вы начинаете использовать я инструмент с такими проектами, то очень часто сталкиваетесь с тем, что они просто не выдают то то, что нужно. То есть ты даешь задание, а то, что оно делает, либо несовместимо с другими функциями, либо пишет код не не так, как нужно, либо, например, пытается добавить лишние зависимости, а вы не можете просто так добавлять лишние за лишние зависимости. либо, например, пытается ходить по проекту и каких-то там рандомных местах вносить правки. Ну, это это на самом деле часто приводит к тому, что есть ощущение, что вроде инструменты не могут справиться с такими проектами. То то на самом деле, э, с моего опыта и с теми командами, с которыми мы работаем, на самом деле мы пытаемся эти проблемы решать. Я могу сказать, что уже есть определенные паттерны, как это делать более корректно. Я смогу назвать довольно так ориентировочно сейчас, что что работает, но, конечно, в это все надо погружаться значительно глубже. Итак, на на самом деле э работает документация, которая лежит рядом рядом с кодом. То потому что часто в больших проектах документация она находится где-то на конфлюенсе, шерпоинте, какими-то отдельными документами. часто устаревшими и ро разработчик там открывает документацию в одном окне, открывает ID в другом окне и начинает работать. AI модель э с этим не не очень ей удобно так работать. Мы можем дать документацию через MCP, но на практике это не не очень удобно. Лучше документацию держать максимально близко к коду и в идеале та ее составлять в репозиторий. возможно делать автогенерированную документацию, чтобы она была достаточно быстрой. То есть мы даже не столько для людей делаем для A-агентов. И мы ее держим э в самом коде по по факту в самом коде. Следующее. Документацию стоит разделить. То есть есть документация, которая собственно техническая про сам проект, его там архитектуру, его технический стек, какие-то там практики кода. Я что мы пишем, что мы не пишем. э, зависимости. Это все, это все детально перечислить, чтобы было понятно. А другой вопрос - это функциональность. Это какие-то спецификации, которые описывают, что у нас собственно в этом проекте происходит, какие-то API, которые мы имеем, как как мы к ним до до доступаемся и детальная документация, которая описывает части проекта, их функциональность для того, чтобы я инструмент понимал. И собственно, если мы сделаем достаточно качественную документацию, то мы существенно улучшим э работу инструмента с нашей кодовой базой. Также важно прописать правила. Есть даже такое понятие steering rules. Мне очень нравится. Steing - это как руление. Да, то есть правила они управляют работой агента. И вообще в софtін engженеринге есть очень большое разнообразие, я как писать код. То есть можно там писать процедурно, функционально, объектно, еще как-то, то то на самом деле прописав агенту про правила, мы можем ожидать от него, что он будет именно так делать задачи, как я, как мы хотим. Следующий вопрос - это такой подход, о котором мы еще отдельно поговорим. Spec Driven Development. Вот он тоже очень хорошо работает по отношению к большим проектам, потому что мы в этом подходе мы фактически еще до того, как начать писать код, мы формализуем наше решение с учетом ограничений. И если мы необходимую подготовительную работу сделали качественно, то уже кодогенерация - это уже вещь, ну, по сути, второстепенная. То есть она уже э не не настолько э-э критична, как ро работа с на предыдущих этапах. Э на следующее - это разные интеграции. То есть у нас есть возможность сделать интеграции, э, в том числе с использованием MCP, Model Context Protocol. И мы можем настроить MCP сервера, которые нам будут помогать в работе над проектом. Например, можно сделать MCP-сервер, который будет обращаться к определенному контре конкретному контексту, например, возможно там доставать какие-то какую-то информацию из базы данных для того, чтобы мы ее понимали или какая-то специфическая документация. То есть он будет делать поиск, по возвращать результат и правильно настроенная экосистема, она будет давать вам э результат другого качества. Ну и, конечно, то, что сейчас очень активно развивается, это Agent Skills. Мне очень нравится сам по себе подход стандарт. И я даже считаю, что мы сейчас на пороге до вообще новой парадигмы в программировании, которую бы я назвал как-то skills development parad, да? То есть, где мы фокусируемся на формализации agent skills. И в формализованные agent skills, например, там может быть такая более общая, там front-end developer, где мы описали, что делает frontend developпер, а можно сделать скил э очень с специализированный для конкретной задачи. Ну, там условно генерация файлов определенного формата. И просто создавая подобные skills, мы можем делать одновременно и и промпт, и и правила, и даже интеграцию с с какими-то э инструментами, аналогично тому, как делает MCP. И наполнив скилами, необходимыми для проекта, мы можем получать очень, очень хорошие результаты. Поэтому обратите внимание на это. >> Что такое SPC Driven Development? Я уже говорил о том, что Spec Driven Development - это один из очень интересных подходов, которых который на самом деле сейчас в тренде. Интересно, что развиваться эта эта тема начала буквально осенью прошлого года, то есть буквально осенью KРО от Amazon, потом Спект от Gitхаub, потом еще начало появляться очень много других инструментов. Мне, например, лично очень по нравится подход OpenS, но есть и другие, например, BMAD. Это это вообще очень интересный подход. Э, он предполагает фактически моделирование команды разработчиков, тестировщиков, аналитики. Вы просто как дирижер этой команды, фактически, как пм этой команды, э на своем собственном компьютере, э, находитесь. Собственно, и я считаю, что это общий тренд к тому, как постепенно софтвеенни трансформируется. Мы просто находимся в такой точке, где мы начинаем переходить к следующему уровню абстракции. Здесь стоит сказать, что языки программирования, с которыми мы работаем сейчас, на самом деле это языки программирования высокого уровня, которые принципиально не отличаются от языков, которые первые возникли конец 1950-х, начало 60-х годов. То есть там Фортран, Лиcп, Кобол, это это те языки, которые положили начало языку программирования высокого уровня. И и это довольно странно, но там Python, который возник в начале 90-х, JavaScript в 95-м, C#AR там конец 90-х, начало 2000-х, Java - это тоже, это тоже тоже 90-е, они считаются относительно современными новыми языками относительно. А, но на самом деле идеи они все пришли еще с с начала 60-х годов. принципиально нового в языках программирования высокого уровня, которыми мы пользуемся сейчас, на самом деле особенно и нет. И именно сейчас я считаю, что мы в том же, можно сказать, историческом этапе, когда появлялись языки программирования высокого уровня, мы начинаем переходить от того, чтобы двигать значения там в переменных, в массивах, писать цикла циклы к формализации на наших мыслей и преобразования их в работающее решение. И в этом случае, да, Spec Driven Development, который на самом деле эта терминология была придумана еще где-то в 2004 году. То есть это на самом деле 20 п лет как идея возникла, но только сейчас она получила свое реальное внедрение. И она предполагает, что мы имеем спецификацию как документ, который является достаточно четким для того, чтобы по нему был сгенерирован код. И именно Spec Driven Development открывает нам очень интересные возможности. Мы, например, можем переключаться между стеками, фреймками, просто перегенерировав их в разных фреймках, возможно даже между языками программирования. Но с точки зрения Spec Driven Development есть тоже много нюансов и надо получить определенного опыта для того, чтобы научиться его делать правильно. Обычно это проходит определенные этапы. Я говорил, что, например, мне нравится, как Open Spec работает. Там буквально там три этапа сформировали спецификацию, сделали apply и заархивировали ее. А, но на разных этапах нам возможно нужна коррекция с точки зрения разработчика. И это довольно интересный подход, если вы еще не пробовали, я рекомендую. То есть Spec Dreven Development - это то, что я рекомендую. Это то, что реально работает. Он не всем нравится, он требует определенной п подготовительной работы, работы со спецификациями. И для некоторых задач, я на самом деле считаю, что это не обязательно все задачи делать именно так. Но если вы хотите получить результат, особенно в больших крупных проектах, то то это тот подход, который работает. Рекомендую. Что такое [музыка] MCP? Что такое agent Skills? >> Я дам ответ на вопрос вместе. Дело в том, что я бы сказал, что это довольно близкие вещи. И MCP, как стандарт, он существует год плюс. Agent Skills. Я точно помню, насколько э стандарт э новый, но Agent Skills именно сейчас буквально несколько последних месяцев начали активно развиваться. Собственно, если вы уже пользовались или знаете, что такое MCP, это на самом деле очень мощный инструмент. Фактически мы нашим агентам даем руки. мы даем, э, такие tools инструменты, которые, фактически, это как функции в коде. Они имеют параметры, имеют документацию и они загружаются в контекст модели. И модель сама принимает решение, какой из э этих tools вызвать. Мы можем использовать MCP, какие-то уже разработанные для нас доступные. Context 7, например, мне особо особенно нравится. есть очень много там для доступа к базе данных и тому подобное. А также MCP можно создавать под свои конкретные задачи. Вот вы решаете, что вам нужно дать какой-то инструмент и пожалуйста, можно его сгенерировать. Это не обязательно писать вручную и вы имеете инструмент, интеграцию с чем-то. Это на самом деле очень классно, но у MCP есть определенные недостатки. Например, много MCP инструментов, они фактически переполняют контекстное окно. Очень хорошо у клодко есть визуализация. Вы можете посмотреть визуализацию контекстного окна. Если вы запускаете, добавляете много MCP, вы можете увидеть, как много они потребляют контекстного окна. Также много MCP, э, они, а-а, запутывают модель. То есть, если у вас до довольно много этих MCP Tools, то иногда модель может не вызвать нужный инструмент, может вызвать не не очень корректный инструмент. И, ну, они еще часто бывают относительно медленные. Также есть там вопросы ри рисков по безопасности, особенно если используете сторонние и так далее, и так далее. Поэтому этот инструмент мощный, но у него есть определенные ограничения и им надо уметь пользоваться, чтобы получить результат. И Agent Skills - это фактически э-э, я бы сказал, моя любимая инновация сейчас среди я инструментов. То потому что Agent Skills к к этому подошли несколько иначе. Skill он описывается, то есть есть стандарт agent skills. IO, вы можете его почитать. Skill он описывается в MCDown файле. В нем есть такое понятие frontm. В front пишется название skill и также пишется description, который показывает, зачем этот скил нужен. И когда модель выполняется, у нас есть доступность skills, то загрузится только frontмер. И из-за этого мы можем подгрузить довольно много skills. И потом инструмент решает, что какой нужный скил активировать. Потом начинается фаза его активации. Он читает весь скілd файлик. В нем есть набор инструкций. И также мы к скилу можем иметь дополнительно ресурсы разные assets, скрипты, файлики и так далее. И каждый скил, он на самом деле может быть достаточно объемным. Достаточно объемным. Итак, по моему убеждению, инвестиции времени в создание и разработку Agent Skills - это сейчас то, чем, собственно, стоит заняться и оно себя должно окупить при правильном подходе. Итак, спасибо за то, что дослушали до этого момента. И для тех, кто действительно дослушал, есть промокод на мой креш-курс, который я провожу с FWS Academy по использованию искусственного интеллекта именно для больших Legacy проектов Brownfield Development, именно там, где это бывает сложно. Поэтому приходите, будет полезно, интересно. Промокод на экране. До встречи. И, конечно же, подписка на канал, лайк. Все. захочется