Transcription
[музыка]
Всем привет, кто смотрит сейчас или в записи. Меня зовут Артём, и я тимлит продукта Докой в компании Coden Side. Я занимаюсь разработкой разных решений для бизнеса, в основе которых лежит искусственный интеллект. Преимущественно область моих моей деятельности связана с работой, с закрытым контуром и с рагами, с их разными реализациями, локальными моделями и всей этой интересной темой.
И как раз подобная работа, достаточно близкая с искусственным интеллектом, и дала мне ряд полезных знаний, навыков и понимания о том, как его можно использовать в том числе лучше и в разработке, в ап-кодинге. Как раз сегодня я и хотел бы поговорить про сильные и слабые стороны языковых моделей в разработке и агентов, с чем мы сталкиваемся, работая с такими инструментами. И самое главное, что мы можем сделать с теми слабостями, что есть сейчас у ИИ. Ну и думаю, будут ещё ощутимое время, как мы можем создать для него комфортную среду, даже, наверное, где-то прогнуться, чтобы ИИ мог работать на нас гораздо лучше.
И начать я как раз хотел бы с сильных сторон. Собственно, почему вот вайпкодинг вот так популярен, так выстрелил? Ведь если так посмотреть, это действительно выглядит как настоящее чудо, которое нельзя было представить ещё буквально, не знаю, лет пять назад. То есть это казалось чем-то на грани фантастики. Сейчас же вот даже вот по предыдущим докладам видно, как люди, скажем так, незнакомые до этого практически с разработкой, уже занимаются созданием полноценных там приложений, которые, в том числе работают в проде. Это действительно инструмент, который нам позволяет быстро проверять какие-то гипотезы, собирать какие-то прототипы, что действительно позволяет нам значительно ускорить какие-то исследовательские задачи.
С помощью ИИ мы можем очень быстро учиться, то есть познавать, как, скажем, айтишники или люди, которые хотят начать программировать какие-то новые библиотеки, языки программирования. То есть не просто так Stack Overflow из года в год после выхода ChatGPT теряет популярности. Ведь чаще всего общаться с ИИ, который тебе доходчиво объяснит, сколько потребуется, как потребуется, проведёт любые аналогии, зная твой бэкграунд. Это, ну, гораздо приятнее чаще всего, чем, скажем, общаться с незнакомцами в интернете на тему возникающих эти вопросов.
И также ИИ нам очень здорово помогает автоматизировать какую-то рутину. То есть он бодро пишет документацию, пишет логирование, генерирует синтетические данные, тесты. Всё это, конечно, может потребовать определённые настройки наших ИИ-агентов, но всё равно при правильном подходе это даёт достаточно приятный результат. И всё выше описанное действительно кажется даже сейчас настоящим чудом. Прямо ещё недавно невероятным.
Но думаю, как многие знают, что, ну, в конце концов, чаще всего ИИ-разработка, кодинг упирается в ряд проблем. Наверное, самая основная из них сводится к тому у людей при работе с инструментами, что либо их ИИ-проект, который они разрабатывают с нуля, становится слишком сложным, либо та кодовая база, в которую они хотят применять ИИ-агенты, она изначально слишком комплексная и агент банально, ну, не может полноценно справиться со своими задачами без каких-то настроек и подготовок проекту. То есть, проводя аналогию с, скажем, чем, ну, чем я занимаюсь, как разработкой ИИ-систем, что, скажем, в RAG ты не можешь просто взять и загрузить какие-то там данные из конфи в векторную базу. Данные должны там пройти целый пайплайн по преобразованию формата, по составлению какой-то метадаты, а, по какой-то там, не знаю, XML-разметке для LLM и прочих других вещей, которые там позволит уже нашему RAG уже хоть как-то прилично функционировать.
И то же самое у нас происходит с нашими проектами, что когда наш проект, ну, по сути, является не особо подготовленным для ИИ-инструментов, то мы достаточно сильно ограничены в том, что мы можем использовать. То есть это уже не, скажем, полноценные таски по внедрению какого-то функционала ИИ-агентам, а максимум объяснения какого-то кода, рефакторинг, что, конечно, тоже очень здорово, но тоже далеко не всегда идеально и, ну, тоже, ну, не полный, ну, потенциал реализуем того, что у нас есть. И также люди, часто работая, как многие знают с ИИ-инструментами, они не очень любят проверять код, который получается на выходе. И как раз всё это и приводит к тому, что, ну, в большинстве случаев, в большинстве подходов ИИ-разработка как раз и ограничивается чем-то на уровне создания каких-то прототипов. Потому что чем ближе мы пытаемся что-то из этого полноценное сделать, тем больше вещей у нас разваливается. То есть любая попытка добавить какой-то новый функционал в разросшемся проекте приводит к тому, что у нас сломается уже какой-то существующий функционал. Всё это переезжает в бесконечную сессию дебаггинга с ИИ-агентом и, ну, чаще всего ничем хорошим не заканчивается.
И как раз, что мне кажется важным, что люди часто ищут проблему не совсем там, где она находится. То есть часто люди думают, что, скажем, проблема в инструменте, что я там перееду из Cursor в Code Interpreter, подключу какой-нибудь LangChain или ещё другой набор LLM-серверов, а, ну, и оно как-то заработает. То есть появится какой-то чудо-инструмент, появится чудо-языковая модель, которая решит э-э все мои проблемы, которая разберётся в моём недокументированном коде, который разберётся в этой сложносвязанной архитектуре, и произойдёт чудо. Ну, спойлер, чудо не произойдёт. То есть чудо инструментов не существует, и в ближайшее время они навряд ли появятся.
-э Когда по сути, если копнуть глубже, то, ну, все современные агенты для разработки, будь то там Kill Code, Cloud Code и так далее, по сути, это, ну, очень схожие системы. У них есть какие-то отличия, как там, особенно у Cloud Code, но по сути, э-э со всеми ними можно выстроить достаточно хороший пайплайн, и все их инструменты там по оркестрации, по дебаггингу, по написанию документации, они в целом у всех достаточно общие и близкие. И всё это сводится к тому, что, ну, всё же причина кроется не в ИИ-инструментах, так как всё же это достаточно похожие вещи, если копнуть глубже.
И тут мы как раз переходим к тому этапу, что же мы сами, как разработчики можем сделать для ИИшки, для нашего ИИ-агента, для языковой модельки, чтобы создать для неё те условия, в которые ей будет прямо гораздо комфортнее, где ей будет проще ориентироваться, где она будет лучше понимать наш код и что мы сделаем, чтобы она лучше понимала наш код.
И первое, что мы можем сделать, если у нас опять же имеется такая возможность, потому что я понимаю, что у кого-то, скажем, рабочие проекты не подразумевают там свободу выбора языка, но если мы можем выбрать какой-то язык популярный, на котором ИИ обучено хорошо, какой-нибудь Python, JS, ну, Java, допустим, то это даст нам первый буст, который мы можем получить. То есть, если взять тот же Python, Python, по сути, я бы назвал его самым родным языком, ну, после английского для всех языковых моделей. Э-э, то есть он обожает на нём писать какие-то скрипты. Даже помню, когда тестировал в Cursor GPT-4, когда он вышел, там были с ним какие-то странные приколы, что, ну, вместо того, чтобы там использовать какие-то внутренние инструменты Cursor-овские там по листингу директории и прочего, он зачем-то начинал генерировать как раз Python-скрипты, делающие то же самое. То есть по Python языковые модели обучены, допустим, гораздо лучше, гораздо лучше понимают его. И, ну, опять же, если у нас есть такая возможность, если мы как-то знакомы с такими языками, а то, ну, было бы здорово, если бы мы сделали выбор в их пользу, потому что чем популярнее язык и чем лучше ИИшка на них обучена, тем лучше код у нас будет получаться на выходе.
А следующий как раз пункт, что мы можем сделать - это подумать над макроархитектурой. То есть, если мы говорим о каком-то, ну, среднем, большом приложении, то есть по ряду причин, почему, скажем, ну, для какого-то монолитной архитектура, для средних приложений больше, особенно если у нас работает несколько человек в команде, она будет не самой удачной. Ну, первое самое банальное, понятно, что работа с ИИ-агентом в рамках монолита несколькими людьми - это, конечно, будет потом от конфликтов в Git. То есть это, ну, не совсем то, с чем захочется жить. Но с другой стороны, если у нас есть возможность выбрать архитектуру, как, допустим, микросервисную, если мы говорим про бэкенд, где у нас чётко система развивается на такие компоненты, э-э с чётко определённой задачей, а, с не такой здоровой кодовой базой, то ИИ гораздо проще будет в этом всём деле работать, когда, скажем, он, ну, понимает за счёт нас, что вот есть вот этот микросервис, у него есть определённая задача и есть определённое разделение внутри него, а, и определённая кодовая база, которая не слишком здоровая. В такой архитектуре нашему ИИ будет гораздо проще ориентироваться. И самое главное, если у нас команда состоит не из одного человека, то мы можем, по сути, заниматься параллельно разработкой таких ну микросервисов. То есть и как раз за счёт того, что ИИ хорошо всё документирует, можно как раз и на лету подготавливать документации для интеграции этих самых микросервисов.
Если же рассмотреть, скажем, как реализуются сами микросервисы или небольшие программы, то тут тоже стоит посмотреть на ту архитектуру, где будет обеспечиваться ну не такая тесная связь компонентов, как, скажем, в гексагональной архитектуре, а когда у нас существует чёткое, э-э разделение между компонентами программы, то есть есть порты, есть адаптеры, есть ядро приложения. И когда нам, скажем, потребуется реализовать, допустим, другую реализацию подключения к базе данных или там другой интерфейс взаимодействия с программой, то подобная архитектура, где нам просто нужно уже реализовать, ну, какой-то отдельный адаптер для ИИ будет гораздо проще. потому что он будет понимать, что есть такое-то разделение, что мне нужно работать вот конкретно, скажем, в области адаптеров там или сервисов или моделей, и что если мне нужно внести какой-то функционал новый, то, ну, функционал новый, я тоже, ну, не поломаю чего-то. И по сути уже на текущем этапе мы уже можем построить такое приложение для нашего, ну, для нашей разработки, в котором языковая модель будет гораздо проще ориентироваться. Опять же, всё это потребует определённой настройки правил пайплайна, о чём мы поговорим подробнее в конце. Но вот такое чёткое разделение на относительно небольшие кодовые базы, на чёткое разделение структуры нашего проекта значительно упростит для ИИ задачу по внесению изменений.
А следующее такое немножко экзотическое, что мы можем сделать, а это сделать определённую разметку кода. То есть для чего это нужно? Во-первых, если мы говорим, скажем, про разметку самого кода, то тут это нужно, во-первых, для понимания, а, ИИ-сковой моделью контекста того, с чем она работает. То есть, что это за метод, а что он возвращает, что он делает, какие этапы происходят в процессе его работы. А это упрощает понимание и также помогает ИИ находить требуемый код. То есть ИИ часто пользуются, ну, ИИ-агенты пользуются векторным поиском, полнотекстовым поиском. И такая вот документация позволяет намного проще находить, скажем, требуемые методы.
И второе тоже, а что может быть полезно - это описание, а структуры проекта. То есть, скажем, на уровне аа всего проекта, на уровне модулей, так вот на втором скриншоте, что мы, а, описываем, что находится в проекте, то есть чтобы ИИ могла понять, что у нас есть в нашей кодовой базе, а не загружая её целиком в свой контекст. То есть контекст у ИИшек, конечно, сейчас подрос, но, во-первых, его всё ещё не хватает. А самое главное, что по разным тестам, что чем больше контекст у ИИ, тем меньше процента успешно завершённых задач. Чем больше контекста, тем больше она начинает путаться. а, имея такой, скажем, файлик в своём контексте и уже конкретный код, в котором она должна работать, из какой модели, и агенту гораздо проще понять, с чем она сейчас работает и что вообще в целом имеется в проекте. А, и если появятся какие-то новые вводные, она легко сможет сориентироваться, куда ей сходить, где что находится, где что поправить. Это опять же требует, конечно, настройки определённых правил агента, чтобы поддерживать подобную чёткую структуру. Но как раз это во многом и решает проблему контекста для ИИ-агентов, что мы можем не обязательно загружать весь наш код, особенно если он большой, в контекст LLM-ки, а мы можем просто вот поддерживать такой файл с описанием, а за счёт которого она будет лучше понимать, что у нас происходит.
А, и как раз ещё, что мы можем сделать для, скажем, нашей отладки и в целом поддержания процессов, это позаботиться о логировании и тестах. То есть, если мы вернёмся на скриншот назад, как раз, как я люблю делать, и посмотрим на левый скриншот с э с кодом, то там видно, что я обычно стараюсь, ну, писать обёртки для Python по логированию, чтобы логировать, ну, можно сказать, абсолютно всё, что происходит. То есть какие функции мы заходим, из каких функций мы выходим, какая у нас бизнес-логика вызывается, какая переменная меняется и так далее. То есть это как раз нужно для того, что если всё-таки у нас происходит какая-то проблема и требуется отладка в окошке ИИ-агента, чтобы мы могли передать ей весь контекст, чтобы она увидела полностью всё то, что происходит в программе, а все те нюансы, которые происходят, и за счёт этого гораздо быстрее решить проблему, потому что чаще всего какие-то какие-то ошибки, ну, могут дать неполную информацию, то есть просто какой-то трейсбэк ошибки не даст полную информацию агенту о том, что на самом деле произошло. И также это может помочь ИИ-агенту увидеть какие-то неточности, когда, скажем, у нас, а, программа вроде и работает, но какие-то, скажем, нюансы всё-таки возникают.
И также можно позаботиться, а, даже, наверное, нужно позаботиться о тестах, то есть как раз выстроить такой пайплайн, о чём, наверное, сейчас поговорим. А когда мы занимаемся разработкой задачи, ну, думаю, уже агенты многие это сами инкапсулировали, как многие видели, что часто, когда мы ставим какую-то задачу, у нас агент в первую очередь её планирует и уже далее поэтапно приступает к этапу реализации. То есть я помню, раньше ещё на заре Cursor-а приходилось самостоятельно просить его сгенерить какой-нибудь Markdown с планом реализации и уже поэтапно следовать ему. Сейчас это агенты уже в себя собрали. А, и как раз, как один из этапов внедрения, реализации задачи можно подключить тесты, что мы реализуем с помощью агента какой-то функционал. И после какого-то, а, весомого этапа реализации задачи мы прогоняем тесты, реализуемые для нашего приложения, и проверяем, что у нас ничего не сломалось. Опять же, конечно, с тестами тоже надо дополнительно поработать, потому что бывают там кейсы, когда, скажем, вот было где-то видел у кого-то вот пытался кто-то с Claude решить какую-то задачу, связанную с ИИ-разработкой. У Claude не получалось, потому что тесты не проходили. И Claude вот полез править имеющиеся юнит-тесты, чтобы вот сказать, что вот задача выполнена. То есть как раз реализовать какие-нибудь Cursor Rules или другие правила в зависимости от вашего агента потребуется, чтобы, собственно, ваши тесты получались достаточно качественными.
И как раз, резюмируя эти этапы, хотелось бы ещё раз проговорить про все вот эти особенности, что надо понимать, что языковые модели, они действительно, ну, всё больше умеют творить чудеса. То есть они, скажем, умеют писать с ходу небольшие программы, то есть, не знаю, от змеек там до каких-то там базовых э-э сервисов бэкендских, прямо простых, допустим. Но часто вся эта магия как раз начинается рушиться из-за того, что наш проект, наша кодовая база получается достаточно комплексной, достаточно тесно связанной, что ИИ не может держать весь контекст. Ему сложно понять какую-то специфику, и как раз в наших силах позаботиться о том, чтобы у языковой модели как раз были все условия для своей комфортной работы. И это как раз и поможет нам самим лучше выстроить работу, опыт с нашими агентами. То есть со временем, скажем, почему я решил также копнуть в эту сторону и так вот провокационно назвать свой доклад, что я думаю со временем, а всё же э-э во многом, мне кажется, разработка, по крайней мере, а каких-то не слишком серьёзных решений, понятно, не банковских, но, скажем, для какого-то малого, среднего бизнеса, она как раз за счёт того, чтобы сделать разработку доступной, они будут приходить к подобным подходам, когда у нас будут выстраиваться уже какие-то определённые пайплайны, уже будут готовые правила по разработке подобных э-э микросервисов, какие технологии использовать, э-э, э-э как всё это реализовывать и что в целом ну постепенно с наработкой практик, опять же, с улучшением моделей, инструментов, а, думаю, приведёт нас в какую-то точку, в какую-то, э-э нишу, где, скажем, подобные архитектуры, а, построенные в первую очередь под ИИ будут ну, достаточно хорошо котироваться, потому что с ними действительно можно достаточно быстро, а, и опять же, имея за рулём опыт разработчиков подготовить достаточно хорошее, эффективное и самое главное, э-э рабочее приложение. Опять же, это не говорит о том, что у нас пропадут разработчики. И опять же, что ИИ-разработка, она прямо во все сферы не скоро вольётся, но в тех сферах, где нам, где, скажем, типичная разработка кажется дорогой, подобные решения кажутся как раз э-э достаточно эффективным решением. И, думаю, со временем мы как раз и будем постепенно к чему-то подобному приходить. Подумайте не только о том, что ИИ может сделать для вас. Подумайте о том, что вы можете сделать для ИИ, как вы можете позаботиться о нём, с чем вы можете поступиться ради него, если есть такая возможность, и он обязательно отплатит вам эффективным результатам со временем и с наработкой каких-то практик.
Вот, наверное, у меня всё. Если кому-то будет интересно пообщаться, подискутировать, есть интересные мысли, пишите, буду рад пообщаться. Андрей, а так я справился.
>> Это здорово.
>> Да, [смех] да, спасибо. Мм, э-э такой достаточно это, ну, не скажу, что прямо философское, но как раз обобщающее получилось завершение того всего того, о чём мы сегодня говорили. Вот. Стабильно, точнее стандартно, если есть вопросы, можно поднять ручку и пообщаться голосом. У нас достаточно много времени. Вот. Либо написать текстом. Вот. Соответственно, тут вот появился мм речь про аннотации кода. Интересно, как реализуете, отдельными ли правилами, либо промптом.
>> Так, ну да, всё это потребовало, чтобы всё это поддерживать, конечно, потребовало, ну, прямо несколько дней посидеть только над правилами. То есть, чтобы всё это отладить, это, конечно, очень серьёзная работа над правилами, чтобы он всё это поддерживал, чтобы он этому следовал, чтобы он ориентировался в этих э-э разметках. Это, конечно, определённая работа, но она того стоит, потому что действительно это то, что помогает. Но надо просто понимать, что правило - это уже прямо такой эталон. То есть и программировать с ИИ без правил в двадцать пятом году уже нельзя. То есть это то, в чём надо разбираться, что надо понимать и с чем надо работать. Я, кстати, на протяжении вообще докладов думал о том, что мы, по сути, в некотором смысле сейчас с LLM-ками, с ИИшками проходим весь тот путь, который до этого проходили, в принципе, да, в разработке. То есть всевозможные вещи, архитектурные принципы, которыми когда-то и для людей про это создавались, там тестирование сегодня много говорили и прочее. По сути, мы типа это учимся делать теперь всё то же самое, только с ИИшечкой.
А так вот ещё доклад появился. Мм, а как будто в каждой каждый раз в каждой презентации рассказывают примерно одни вещи. разбивайте большие задачи на мелкие, подобно прописываете код, строите правильную архитектуру и так далее. А как ты считаешь, почему это ещё не стало стандартом и вообще об этом говорят?
М, ну я думаю, тут ещё сильная роль в том, что, как сказать, у нас ещё не перешёл не произошёл переломный момент, который потребует, мне кажется, не один год далеко. заключающийся в том, что всё-таки большинство проектов, ну, большинство людей работают либо на Legacy проектах, либо на, ну, так сказать, разрабатывая даже с нуля, ещё так достаточно слабо адаптируя ИИ. То есть в целом каких-то прямо чётких правил, прямо истин не появилось. То есть новая банда четырёх ещё не показала себя. И, наверное, от этого пока что всё это как во многом на уровне теории реализуется. То есть кто-то делает разметку одним способом, кто-то другим. И я думаю, постепенно всё это придёт пока что просто из-за того, что это действительно, ну, сложная тема. То есть сложно где-то понять и сложно понять, где он работает, где-то надо набить шишки, внедрить это тем более в большие проекты. Это сложный этап. И, наверное, ответ на вопрос просто в том, что, ну, пока что, ну, большинство людей проектов пока ещё к этому не готовы. То есть это путь, который как раз лежит перед нами следующие несколько лет.
Кстати, тоже интересно, мм, есть инструменты, которые появляются, да, и развиваются. А насколько там те какие-то, да, правила, принципы, которые мы сейчас вырабатываем, да, находим, насколько они будут, грубо говоря, обрастать новыми или, может, какой-то момент радикально изменится тоже.
Ну вот у меня есть мысль, что как раз, допустим, та же тема с разметкой, которую я показывал, она в своё, ну, тоже, думаю, своевременно, ну, в своё время, точнее, уйдёт под капоты и агентов. То есть, как ушло планирование, как вот я приводил пример под капот, что раньше мы генерировали Markdown с планом и просили ИИ ему следовать там в году двадцать четвёртом. Сейчас мы вот делаем такую разметку, а потом просто ИИ-агенты заберут у себя под капот, то есть будут всё это описывать, будут делать такое такое вот семантическое описание. И как раз постепенно будет как раз упрощаться такие подходы, но опять же где-то ещё требуется прямо сильное понимание архитектуры и других программистских вещей.
>> Угу. Так, тут ещё был вопрос, если я не ошибаюсь, про то, как вы собираете RAG. Не очень понял, к какому моменту это привязано.
>> Ну, наверное, речь про то, что как раз продукт, где я являюсь тимлидом, это, ну, такой ИИ-ассистент корпоративный для, в основе которого лежит такой комплексный агентик RAG. Ну что я могу сказать? Наверное, это всё же тема отдельного доклада, но если проводить параллели с нашим докладом, как раз много схожего, что для RAG надо также готовить контекст, преобразовывать данные, форматировать при передаче, форматировать этот самый контекст при передаче в ИИ и следовать многим другим практикам. Но всё же, наверное, это немножко не по теме моего доклада.
Так, ещё вопросы есть ли? Закидывайте. Я, кстати, на эту тему могу многое понабрасывать. А просто у нас закрытие через полчаса, мне нужно как-то время тянуть.
>> Нет, [смех]
>> вот на самом деле вот говорили сегодня там все действительно плюс-минус говорят, какие там вырабатывайте какие-то, да, там архитектурные принципы, там дробите задачи, продумывайте про архитектуру и прочее. Ну, то есть вот набор каких-то, да, общих, я не знаю, принципов, подходов, кажется, сложился, которыми стремятся следовать. Вот эти шаги по сути-то тоже выполняем в моделях. А вот, э-э, такой такой вот сейчас наивно пофантазировать хочу. А почему мы не можем до сих пор сделать условно какого-нибудь универсального агента, который там, не знаю, формулирует, уточняет описание задач, потом сам с другими агентами проектирует архитектуру, нарезает, валидирует, тестирует и вообще всё делает сам.
Ну, по сути, по-моему, попытки таких агентов создать есть. Я помню в своё время на этой теме ещё где-то полгода, год назад был Devin, который как раз обещал как раз такое решение или потом его open source реализация Open Hands, как раз, когда у нас полная итерация, что в бесконечном цикле, ну, и ставится задача, и пытается её реализовать. Он далее там какой-то агент DevOps всё это разворачивает, всё это пытается протестироваться. Если возникают ошибки, всё начинается заново. То есть происходит такая вот машина спагетти кода. М. Но я думаю, что пока что всё это не появилось, потому что, а, у ИИ своего рода, как мне кажется, нет такого понятия, как, не знаю, ну, проблемы не с памятью, а вот с таким более крупным пониманием задачи. То есть, чтобы осознать всё, что требуется, потому что всё-таки, ну, любая разработка, она имеет много своих особенностей и что, по сути, ну, в наших реалиях умещается пока что только в человеческом мозгу, и то не всегда целиком. И в текущих реалиях все вот эти сложности, наверное, э-э, ну, можем только мы, как условные операторы такого ИИ-агента транслировать ему. То есть и у нас очень силён как такой разработчик небольших программ, то есть что мы там можем прямо с ходу что-то сгенерировать, а, но всё-таки в каких-то сложностях ещё, по крайней мере, очень долго будет завязан человек.
А я вот на эту тему, когда думал, у меня как раз пришла аналогия, ну, если с сравнивать промышленностью, что условно, как мы, допустим, э-э пришли от э-э там, не знаю, первых конвейеров и паровых двигателей там к вот нашим, не знаю, чипам, на которых там современные видеокарты производятся и так далее, что вот условно вот так долго такой путь проходит, что вот до ракетостроения и так далее. в целом, как технологии всё больше погружаются, ну, в нашу жизнь. И тут как раз пришла аналогия. Это тоже, как кажется, естественный путь разработки и разработки, что вот по сути технологии, IT-технологии, они, ну, всё больше погружаются в нашу жизнь, что вот раньше у нас это, э-э, была стезя там учёных, потом гиков и всё больше это становится какой-то базой. И я думаю, как раз вполне возможно, что и разработка, ну, в каких-то там относительно ближайших или далёких реалиях станет как раз тем, что поможет нам как раз, э-э ещё больше проводить какую-то цифровизацию, то есть ещё больше приближать нас к какому-то киберпанку и чему-то подобному, когда у нас повсеместно внедряются технологии, потому что мы сможем создавать какие-то легковесные ну, легковесные в плане лёгкости разработки решения для чего угодно и тем самым, скажем, создать новый уровень абстракции, как ты сказал, Андрей, чтобы мы могли создавать, скажем, ещё более сложные системы, как вот, скажем, какие-нибудь вот Госуслуги там лет, не знаю, 15 назад казались чем-то невозможным, а вот тут у нас появится какой-то ещё более глобальный сервис, который как раз, возможно, и будет работать за счёт того, что там мы можем написать какие-то какие-то низкоуровневые простые модули, такие вот микросервисы с помощью ИИ. То есть тут, на самом деле, много чего интересного может из этого вырасти, но непонятно не завтра, но потенциал у этого есть достаточно большой.
Угу. Спасибо. А ещё вопросик прилетел. Ты не упоминал про Spec based, то он же Spec Driven Development. Используете, не используете. Почему?
>> Ну, я бы, наверное, копнул немножко в соседнюю область, а, наверное, такую более техническую. Что, ну, чаще всего, наверное, какое-то кастомное решение у нас прижилось. как раз, э-э, не совсем Spec Driven, но, мм, да, как раз с помощью агентов мы, ну, можем, по сути как раз э-э планировать, создавать э-э какие-то решения, реализовывать задачи. Мм, но, наверное, с ходу не смогу описать, что именно мы используем, но, наверное, что-то, э-э близкое. И как раз, я думаю, это тоже одна из тех вещей, которая каким-то образом, э-э, а, своевременно эгенты, ну, как-то начнут тоже упрощать нам жизнь с подобным планированием. Мм, тут ещё есть нет вопросов как, а, или есть?
>> Да, тут, кстати, ещё вопрос на вопрос можно вкинуть. А вот Алекс, не знаю, как именно. Алексей Александр, аа речь-то вообще про SDD как подход или имеется в виду конкретно там Kirc Kit и именно ИИ короче вы про подход или про инструменты тоже я бы уточнил.
>> я больше про подход, потому что как я и ну сказал ранее, что по сути ну все современные агенты для разработки, они-то в целом-то достаточно похожие. То есть, что у нас там есть? У нас есть тулы по применению дифов, есть тулы по поиску в интернете, по там запуску команд в командной строке и вот, ну, всё прочее очень похожее. То есть в целом-то инструмент - это, ну, если мы говорим про основные, самые популярные инструменты, самые такие передовые, как Cursor, Code, Cloud Code, то там в целом со всеми ними можно выстроить очень такие удачные рабочие пайплайны. Как раз то, про что я больше хочу донести - это именно подходы с точки зрения, ну, подхода к архитектуре и к написанию кода, что мы можем сделать. То есть как раз позаботиться самое главное, о самой, наверное, главной проблеме ИИ - понимании контекста программного обеспечения, то есть нашей программы, нашей системы, и о, собственно, ну, разбиении на компоненты и, э-э реализации задач, ну, в целом каких-то поэтапных шагов пайплайна по тестированию, отладке, что как раз в целом и может делать достаточно хорошо. Но ему надо как-то с этим помогать пока что.
Ещё вопрос. Так, ты, возможно, видел, э-э, какие у тебя топ best practice для среды разработки с ИИшечкой?
>> Мм, best practice в плане настройки или в каком плане best practice? Что-то не совсем понял вопрос.
>> Хороший вопрос, Михаил.
>> Да,
>> можете прокомментировать. Да, в плане правил настройки.
>> Ну, в плане правила, а, именно настройки планов. Ну, тут у нас уже даже речь не просто про планы, а как у нас появилось в том же Cursor, э-э, в Kill Code у нас помимо правил ещё появились так называемые команды. То есть, условно, я обычно стараюсь строить разработку следующим образом, что, э-э, правило у нас для, мм, такого самого общего, то есть как раз по технологиям, по проекту, по, скажем, правилам разметки и, ну, прочим таким общим вещам, и команды как раз для конкретных операций, что вот, допустим, э-э есть команда, то есть там как в Cursor, допустим, добавляешь команду, ставишь слэш, и у тебя выводится твоя кастомная команда. И как раз в промте этой кастомной команды описываешь, а, скажем, вот эта команда там для генерации кода, что ты там, когда генерируешь код, ты там сначала вот этот вот каркас, э-э, э-э обновляешь, в котором у тебя описана структура кода, а далее уже там реализуешь код или там сначала ты там генерируешь каркас, предлагаешь мне план, я вот его согласую, ты генерируешь код. И так для разных операций, то есть для операции добавления кода, для операции его обновления и подобного. То есть такие вот два кита. Одни у нас описывают общие подходы, а другие нам позволяют более точечно их применять для конкретных задач. А в целом э-э какие-то вещи пока что прямо не выработались, стандарты. С этим, конечно, приходится экспериментировать, тратить на это много времени. искать какие-то подходы, но, наверное, такой best way to go - это описывать общие правила как раз в правилах, а для конкретных задач, скажем, реализации тестов, писание обычного кода, отладки кода, обновления кода, использовать уже кастомные команды со своими промтами, чтобы ИИшка не путалась, то есть, чтобы не сваливать всё это в правила, чтобы ИИшка не начинала путаться сильно.
Артём, спасибо огромное. Такая хорошая как бы общая финалочка о смысле получилась у нас.