Transcription
Всем привет. И сегодня мы долка на тему месяц разработки Сquдкод Мак. Опыт лучшей практики AI Driven 2 на Питоне.
Меня зовут Эфектистов Станислав. Я являюсь м инженером команды R&D, где мы занимаемся разработкой решения на базе искусственного интеллекта. В свободное время я участвую, побеждаю в фокатонах по искусственному интеллекту и являюсь спикером канала Клуб разработчиков Санкт-Петербурга. Ну и также с недавнего времени я Open source contributтор.
Краткий дмап сегодняшнего доклада. А поговорим о моём бэкграунде разработчика и проекте, на котором я отрабатывал свой подход AI Dream Development. Будет крабки, причина, по которой я перешёл с курсора на кодкод, мой вариант парадигмы AI Driven Development, главные инсайты и ошибки, которые я хотел бы до вас донести и какие итоги у такого подхода.
Зачем этот доклад? Все уже, наверное, слышали термин не только coding, но и Dreven Development. И он, безусловно, сейчас на слуху, многие даже его пробовали, но тем не менее качественных ресурсов пока не так много. Никто не освещает проблем, которые возникают при масштабировании проектов. А я поделюсь своим личным опытом, своими наработками, которые мне помогли, а, справиться с этими проблемами.
А, да, чтобы понять отравную точку, с которой я начал, давайте поговорим о моё о моём бэкграунде как разработчик. Ещё 6-8 месяцев назад я не вылазил в тетрадки, экспериментировал с м там. И если нужно было уже обернуть моё решение в какой-то сервис, этим занимался какой-то другой разработчик. А я к этому руку не прикладывал. Потом возникнула ситуация, когда переносить мой код было некому, а этим начал заниматься я. И, разумеется, начал я никак не с грамотного AI Driven Development, а, разумеется, начал с веб-кодинга. А поначалу, конечно, прикольно, но через время понял, что на этом всё не заканчивается и далеко так не уйдёшь.
Сейчас я уже очень надёжно, осознанно и грамотно разрабатываю в стиле ID. За месяц разработаю Python проект на 20.000 строк кода при учёте, что я не являюсь каким-то опытным-инженером. Я в первую очередь, да, тамщик, LM, NLP и так далее.
А что за проект, который я разработал? А в двух словах это система на базе LM для создания персонализированного учебного материала называется Learn for AI4 бата и веб-сервис можете перейти QR-код по ссылке а GitHC а архитектуры стек проект то есть у нас есть несколько сервисов это морепозиторий FastP iogram и пог Ну в общем весь стандартный стек питон разработки а агентов.
Давайте в этом докладе я не буду очень фундаментально останавливать на что такое ADAM Development. Для этого у нас есть канал A Dialog и курс VMST, где мы подробно разбираем весь фундамент. А здесь я хочу заостриться на более конкретных моментах, более глубоких практиках. Но тем не менее, давайте краткий рекап сделаем, да.
Моё определение AI Dream Development - это парадигма разработки использования искусственного интеллекта, где человек выступает в роль технического директора или архитектора, а написании кода делегирует агенту. И вот такая цитата: человек строит системы, машина пишет код.
И а чем же отличается от Arievelopment? Я бы сказал так, что Dream Development - это, скажем так, некоторое развитие вапкодинга. И, наверное, будет не ложе сказать, чтодинг - это плохой AI Driven Development, а AI Driven Development - это грамотный кодинг.
Да, я сказал, что, э, в IDD человек выступает в роли архитектора, но здесь бы хотел провести некоторую аналогию, что архитектор в классической разработке, наверное, проектирует архитектуру, процессы, но сам не пишет, неет код. Ну, по крайней мере, наверное, архитектор в классическом понимании, если там не стартап, где у нас архитектор из-за разработчика, там из-за инженера выступает. А в A Dream Development архитектор однозначно ревьют и иногда даже пишет код сгенерированный LВ, потому что на данном этапе развития больших языковых моделей мы не можем на полную автономность отдать написание кода большой языковой модели. То есть она ещё там далека от идеала. Некоторые моменты ей пока не под силу, но кто знает, что будет через некоторое время.
Суть AI Driven Development достигается через тщательное планирование и ведение проектной документации. В целом нет какого-то чёткого подхода документов, они у многих пересекаются, но тем не менее это всё зависит от проекта, от человека. Вот в моём случае это состоит из глобального видения проекта, бизнес-модели, дорожные карты, бэклоп с задачами и там какие-то Адер для архитектурных решений. Ну и соглашение по разработке, хотя ими я активно не пользуюсь. А как я их соблюдаю, расскажу чуть позже.
И в какой-то момент а я разрабатывал рабочие задачи использование курсор. Через время я всё-таки перешёл на кд-код по определённым причинам. Почему же я перешёл? Основная причина это, конечно же, деньги. То есть на моей практике курсоры стоят очень дорого. То есть, да, там, безусловно, есть подписка с 20 долларов, но кончается, по мое по моему опыту, он, ну, дня за три очень активной разработки, например, fullтайм, а после этого уже подключается оплата за фактическое использование. То есть по IP апи платишь за токены, и там один вызов модели может стоить несколько долларов. Я в целом никогда в нашей команде не платил за это. То есть, э, платилось бюджета нашей команды. Но тем не менее, а, мне попалась крупная задача. Через там неделю я увидел в курсоре вот такой счёт. И если бы я довёл эту задачу до конца на курсоре, в конце месяца я бы выкатил нашей команде счёт на 1.000 долларов. И немножко я потеснялся это делать, поэтому начал искать альтернативы. Пробовал кодекса топй, но пришёл всё-таки кд-код. Там есть подписка за 100 долларов код код маx. И помимо базовой двадцатидолларовой подписки нам. И как вы видите за месяц, ну, чуть больше, я потратил на токены, точнее потратил бы на токены 1.300 долларов, но фактически потратил 100, потому что всё включено в подписку. А, то есть эта подписка покрывает всё. Но даже здесь оговорка, эти 100 долларов я не платил. Их любезно согласился оплатить Бектемиров Сергей, за что ему большое спасибо. Он, по сути, является спонсором сегодняшнего доклада. Он активный участник нашего закрытого Gйк клуба. Поэтому, если есть желание, присоединяйтесь к нам.
А, да, давайте пройдёмся кратко по ценным отличиям, затем каждый из них разберём поподробнее. Отличие курсора от код-кода. То есть первый, конечно же, тип курсора - это классическое DE, там какой-то форк VS-кода, но, разумеется, со встроенным агентом. ДТ-код - это же классический терминальный инструмент. А по лимитам, как я уже сказал, да, в курсоре есть месячные лимиты, которые входят в подписку, а затем так называемый usage based, то есть основаны на фактическом использовании. В кодкоде это пятичасовые лимиты с некоторой оговоркой, потому что нашлись некоторые обузеры, которые шарили учётку на несколько участников, и в итоге эти пятичасовые лимиты использовали все сутки. В результате там за двадцатидолларовую подписку можно было, а, потратить 5.000 долларов токенов. И, разумеется, это всё как бы ложится на бюджет антропик. Я бы отметил, что парадигма у колодко кода отличается. Она не просто агентная, она мультиагентная. А потому что там у нас основной агент может вызывать какого-то сабагента, ну, то есть выступать в роли некотоготора. А в курсоре, безусловно, есть бэкграугенты, которые добавились вслед за кодексом, но тем не менее интуитивно выработалось понимание, что кд-код он более мультиагентный.
Чекпоинты в курсоре есть. То есть вы можете отправить агента с реализацией, а затем нажать, чтобы не было необходимости делать подтверждения. И после этого, если вам что-то не понравилось в реализации, агент реализовал полную фигню, вы можете просто вернуться на прошлый чекпоинт, и все изменения откатятся. А вклад-код такого нет. И работа с кодовой базой, как круто отметил, а в курсоре это семантический поиск. То есть модель может задать прямой вопрос на естественном языке, как бы внутрь нашей кодовой базы. Ей вернётся там релевантный чанк, релевантный документ. Ну, по сути, классический рак. А в код-коде- это классические инструменты консольные GREP и find.
Да. Вот вы видите курсор. Ну, Вадим, собственно, показывал, но я тем не менее вставил скриншот. Классическое DE, но с окном для АД-код - это, в первую очередь, терминальный инструмент. Вот так он изначально выглядит. Но очень хорошо сделали интеграцию курсора с кд-кодом. То есть, как вы видите, я нахожусь как бы в де, в удобной де со всеми её преимуществами, со всеми её фичами. Тем не менее, у меня открыт в этой ED терминал. И самое главное, я вижу изменения очень удобно, а то, какие изменения делает мой агент, запущенные вдкод. И после этого уже кд-код не воспринимается как сырой терминальный инструмент. И у меня там особо а интуитивных отличий не выработалось. То есть как будто бы я разрабатываю в той же, ну там, с небольшими какими-то нюансами и мелочами, да.
Лимиты код код макс. Насколько же хватает этих лимитов? То есть они сбрасываются каждые 5 часов. Разумеется, мы за эти 5 часов их можем потратить. По моему опыту, если использовать самую крупную модель Clot OP 4.1, то непрерывной разработке хватает на 2 часа. Но здесь хочу отметить, что непрированная разработка - это когда мы вообще не думаем. Даже, наверное, это когда мы уже не ревюем код, что я считаю неправильным при разработке в AI Driven Development. Если уже идти более правильным путём, и мы делаем сначала планирование, разработка и всё это вместе, то исключительно на самой большой модели Clot OPUS, а, в принципе, разработки хватает на 3-4 часа. А если комбинировать Clot Oppus и Cod Sanet, CL Sonet - это более маленькая модель, например, не все задачи требуют действительно большой модели. очень многие задачи можно делегировать там маленькой модели и не тратить лишние токен, то вот такого подхода хватает на все 5 часов. То есть можно разрабатывать без остановки.
Есть также такая удобная утилита кд-монитор, потому что изначально клод-код не показывает, сколько токенов потрачено, сколько осталось лимитов. Они там вывешивают предупреждающую надпись о том, что скоро лимиты закончатся, и при этом вывешивают они её после полчаса использования, даже когда осталось 90% токенов. Здесь у нас а более понятная схема. А здесь не стопроцентная точность, но тем не менее можно использовать как очень хороший ориентир. Тут он даже показывается, когда токены исякнут при текущем использовании.
Да. И как я уже говорил, сабагенты код открываются по такой команде. Можно создать нового агента. Есть агенты пользовательские, то есть которые принадлежат тем проектам, но не какому-то конкретному. Есть также проектные агенты. А, например, я у себя в проекте такое запушил, и в результате любой желающий может их посмотреть и использовать также, если у него тоже кд-код есть. Здесь можно создать нового агента. И, как уже обсуждалось, какой у нас был вопрос в предыдущем докладе, то, что можно создать не обязательно дать ему полный системный промт, а естественным языком описать задачу. И опять же модель напишет промт. Здесь всё как бы удобно и полноценно. И вот как выглядит документ с агентом, то есть название, описание, когда главный агенткод, который у нас по умолчанию в переписке, может вызвать этого агента. И ниже вы видите уже системный промт начинается. Для многих он может показаться интересным, но об этом попозже. И вот примерно как выглядит. То есть мы просто в нашем чате я пишу: "Напиши implementation план, план реализации для добавления". Я не пишу, что нужно вызвать агента, и она, то есть наш главный агент, он понимает, что нужно вызвать агента и так и делает. Вот у нас всё красиво отображает.
Чекпоинтинг, да, как я уже говорил, в курсоре мы можем нажать вот такую кнопочку restore checkpoint и всё откатить. В clд-код такого нет, поэтому возвращается, да, наш, а, старый добрый гит, система контроля версии. То есть я слышал про какое-то расширение в код-код для того, чтобы поддерживать этот функционал чекпоитинга, но тем не менее я всё-таки придерживаюсь просто чистой истории разработки. Пушу комичу, одна фича, там один комит, а и тем самым-код буквально вынуждает нас придерживаться чистых практик разработки.
Работа с кодовой базой. Курсоре - это классический рак, то есть у нас строится индекс по нашей кодовой базе, а вдкоде- это вот в виде подобной команды. И здесь я хочу донести очень важный момент, что на практике я бы сказал, что вот эти классические команды, то есть поиск там по по совпадениям слов, он работает как минимум не хуже, а во многом даже и лучше, потому что наверное здесь проблема урага - это классическая проблема эмбедингов. То есть не всегда получается построить действительно показательный мбединг, репрезентативный, который отражает смысл чанка. То есть я считаю, что если мы в качестве чанка там делаем делаем чанка бединг по куску документа, по куску кода, где у нас особо не отражена бизнес-логика, то есть у нас там нет названий перебных специфических, то этот код он как бы безликий, и поэтому бидинг по нему строится соответствующий, например, а и он не показательный. Ну, а в клоде как-то, ну, на практике действительно работает лучше с тем, чтобы вручную направлять агентов какой документ, я в кдкоде становился меньшее число раз, чем когда использовал курсор.
Здесь хотел бы отметить такой важный момент про хаотичность модели quadcд. Наверное, многие, кто использовали эти модели, они это замечали, что действительно там, если сравнивать сейчас GPT с Gini те же самыми, а то CLД они очень могут, скажем так, галлюцинировать. Они могут сделать то, чего не просил или не сделать то, чего просил. И это на самом деле не случайность. Это действительно так и есть. То есть у них очень высокая инициативность. А, но я здесь бы хотел отметить, что их инициативность - это их даропроклятие, потому что их инициативность позволяет им делать успехи в агентстном программировании. То есть, что нам нужно для IIP, когда они сами могут ориентироваться по кодовой базе, вызывать инструменты и так далее. Но эта же инициативность является источнком галлюцинации, когда им приходится много предпринимать, и в итоге так получается, что они это предпринимают не тогда, когда нужно. В простых сценариях эта их отечность, конечно, контролируется промтами. Ну, например, общение в диалоге. Я вот у меня вот очень частый сценарий, когда я, а, диктовываю голосом какие-то мысли по, например, архитектуре или ещё чему-то, потом транскрибирую и затем закидываю это текстом в чат. И когда у меня была подписка ClД Max, я начал, конечно же, это закидывать, в том числе и в большую модель Clopus 4.1, ну, ради интереса. И очень часто она начинала что-то реализовывать, писать код или что-то такое. Хотя в моих словах этого не было. Я просто там накидываю свои мысли, а-а, всякое такое. И, конечно же, в простых сценариях это можно исправить тем, что мы просто явно её указываем. Чего делать не нужно, там не надо ничего реализовывать, не надо внести изменения, давай просто проработаем. Вот так я и пишу. Но, конечно же, когда мы говорим о подходе A development, когда мы хотим отправить нашего агента реализовывать автономную задачу, в идеале даже мы не хотим смотреть за его кодом, то есть мы хотим не хотим ревю каждую его изменения. Мы хотим в конце увидеть сделанную задачу. И, конечно же, вот этого промта не хватает. Если мы даже его где-то дадим, то через 50 вызовов инструментов его уже, конечно, модель будет не помнить. И в таком случае моим, да, там, а, моим инструментом стал качественный план реализации, следуя которому уже агент реализует соответствующий функционал. То есть он, конечно, тоже не отработан во всех случаях, но это мой основной инструмент. И ещё добавилось потом с ростом проекта некоторые техники промтов, а про которые я тоже расскажу. И в совокупности это работает ещё дольше.
Также с подпиской к Мак за 100 долларов, в отличие от обычной подписки на кд за 20, открывается доступ к модели OPUS, которая сейчас, наверное, лучшая в агентном программировании. Многие там мечтают её попробовать, как и я, до того, как Сергей оплатил мне подписку. И такой вопрос: а есть ли разница? Моё мнение, что принципиально разницы нет. Обе модели одинаково хаотичны, на мой взгляд. То есть, безусловно, опус модель получше, следовательно, лучше понимает запросы, усваивает больше контекст и в итоге лучше реализует задачи. В итоге на практике задачи, которые опусу можно дать с верхним уровнем описание. То есть, например, без реализации кода санету мне приходится писать код и только после этого отправлять на реализацию, на действительно автономную реализацию. То есть без того, что я за ним смотрю каждый строчку кода.
Теперь давайте перейдём к моему подходу, к моему варианту AI Driven Del.
Планирование задач. У нас есть, конечно же, документация в проекте, в частности дорожная карта, где мы кратко оказываем все глобальные этапы развития проекта. А примеры такого этапа вы видите справа. А верхнеуровневый этап веха, он делится на некоторые крупные задачи, инициативы. А каждая инициатива делится на конкретные планы реализации. и один план реализации, одна задача - это одна итерация разработки агента. Всё это, да, примера вы видите опять же справа.
Вот как выглядит дорожная карта. То есть слева мы видим, у нас очень крупно расписаны наши этапы развития проекта. Open source relase, да, там prodдаction платформа и там продвинутые возможности. То есть их там будет не так много. И уже в каждой вот этой вехе мы расписываем эти крупные задачи. То есть они тут, ну, расписаны так довольно буквально тезисно, но в целом я здесь не вижу ничего страшного. То есть главное зафиксировать и не потерять потом эту идею. Конечно же, если у вас возникают какие-то мысли, вы хотите их сразу сюда задокументировать, это вполне уместно. Вы сами можете там под себя адаптировать. Но я вот пришёл к тому, что когда возникает какая-то идея, я лучше её просто вот так тезисно зафиксирую, потому что я, если я хочу её зафиксировать более подробно, у меня, как правило, изначально идей не так много, и модели накидывают эти иде эти идеи от себя, что я считаю неправильным. То есть вот здесь основной, а, ну, в принципе, как и в остальном подходе, здесь основное основная доля работы должна быть выполнена вами. Агент, безусловно, напишет этот документ, но здесь ваше понимание должно быть полным. То есть вы должны видеть проект свысока, максимально чётко и подробно.
Далее среднеуровневое. А мы вот на основе вот этих инициатив хотим зафиксировать крупную задачу. А, но иногда вот на основе этого тезиса не всегда получается чётко понять, что нам нужно. Иногда нужно сделать некоторые исследования, разобраться в деталях. Exploration. И это тоже документируется и фиксируется в Directory Explorations. То есть, ну, например, там мне нужно реализовать сервис, но я не знаю, как он должен работать, а какие есть нюансы и так далее. Следовательно, мне нужно сначала это проработать, и это тоже не должно оставаться лишь в чате с агентом. Это лучше зафиксировать и задокументировать. Я это фиксирую в отдельную дикторию Explorations. Там можно наносить кучу правок, итераций и так далее. Если принимается какое-то важное решение, можно внести в ADR, то есть это Architekor Decision Record, если какие-то важные решения принимается. Но, конечно же, можно исследовать не всегда. Можно планировать сразу, если у вас есть кристальное понимание, что вы хотите от той большой задачи, которую вы планируете.
А описание крупной задачи у нас соответствующей директорию кладётся и там такой общий Redmi для этой задачи. И в этом Redmi мы описываем эту задачу более общее, более высокоуровнево. И в этом же документе мы можем поделить её на отдельные этапы. Ну так, буквально слегка отдельный планы реализации для одной итерации мы будем реализовывать дальше.
Да, вот как выглядит бэклог задач. Для такой истории я имею папку архив и тягущие задачи. А здесь у нас, видите, одна задача есть в обеих директориях. И у нас здесь после реализации вместо плана реализации кладётся так называемый post implementation summary, потому что в рамках реализации у нас могут возникать некоторые отклонения, и мы здесь именно их фиксируем. А а сам исходный план реализации, ну, для такого версионирования, он кладётся, в общем, в архив. И вот мы также индексируем эту всю историю изменений в специальный файл. index.md. И вот так он примерно выглядит. То есть у нас есть вся история изменений, красивая, лаконичная. Я считаю, такое вести очень важно. Ну, по крайней мере, мне очень важно вот такое иметь в своём проекте.
А что важно в плане реализации? Что должно там быть? Я здесь неспроста соблюдаю такую иерархию, такую структуру. То есть здесь я отсортировал, а, по убыванию, то есть сверху самое важное. То есть в целом, а сначала я прошу модель отразить смысл и цель реализуемой задачи. То есть не просто что нужно реализовать, а зачем и почему. Далее текущее состояние проектное. Я указываю, нужна ли обратная совместимость и теста, потому что без этого клод наш инициативный очень любит добавить какой-нибудь ненужный backквод комбиility для проекта, у которого ни одного пользователя и всякие тесты, которых у нас в проекте отроду не было. Далее, из чего должен состоять план реализации? Всего тут два поинта, но я просто кратко пробегаюсь. Далее мы подробно посмотрим. Это полный фол работа нового функционал, то есть, а, полная последовательность действий. И это нужно не агенту, это нужно нам для того, чтобы мы качественно про проревьюили. И, разумеется, граничные случаи, которые могут возникнуть. Конечно, всех их мы учесть не сможем, это попросту невозможно, но тем не менее очень неплохо бы понимать, с какими проблемами мы можем столкнуться.
Далее требования. Я вот такое требование указываю, что не нужно писать код, а в плане реализации, ну, условно, там только контракты, то есть аргументы, типы и так далее. Но, честно говоря, с ростом проекта я прихожу к тому, что, наверное, всё-таки их писать надо, потому что без этого иногда ходит плохо даже на большой модели, особенно если логика сложная, проект большой, контекста много нужно держать и так далее. Здесь же я считаю, что при написании плана реализации, самое важное, при написании плада плана нужно соблюдать вотти принципы ягня кис, то есть там не реализовывать функционал, который нам сейчас не требуется, а и придерживаться до простых решений. И также есть требование, что нужно сделать перед составлением плана агенту, это изучить реализованный функционал, изучить стек проект.
Да, давайте разберём про деталях, посмотрим на него. На самом деле, то есть, да, здесь, надеюсь, довольно крупно. Давайте даже вот так. То есть это пром для агента, которого я вызываю для того, чтобы он мне написал план реализации. Как вы видите, здесь м промт написан не в формате Markда, как обычно все пишут, он написан в таком интересном формате XML. Ну, сам по себе формат, конечно, неинтересный. Многие с ним сталкивались и работают. Но именно для написания промтов он только сейчас набирает популярность. И в чём его суть? А ключевое отличие от маркдауна то, что он двухсторонний. То есть в маркдауне у нас в списке они там у них а не отражается конец, у них не отмечается он отдельно. А в маркдауне у нас есть закрывающий тег, который позволяет чётко отделить. Собственно, за счёт этих названий тегов, за счёт того, в какой вложности они расположены, мы можем задать максимальный смысл проекта, точнее максимальный смысл промта. Мы можем донести максимально а смысл задачи до агента. То есть без этого у нас требовалось бы очень много слов расписывать на естественном языке. Но такой формат эмпирически, да, там доказано, что модели воспринимать легче. Но двухсторонний это нужно для подкапотных технологий у большой языковой модели, да, там self attention и так далее. И как я уже сказал, да, вот эти названия тегов, они отражают а вот это требование, например, да, давайте теперь по самому промту.
У нас есть контекст проекта. Здесь я указываю обязательно, что у нас находится на стадии МВП. А то, что у нас вот есть минимальное а требование к сложности. То есть нам не нужно сложность ничего не нужно ничего усложнять. Пишем просто. А также есть вот требования, что на текущей стадии тесты не требуются. Далее у нас а критическое ограничение. Ну, как я говорил, что я указал, что код писать не нужно, если не указано явно. Но в последнее время я всё чаще и чаще прошу модель написать код, особенно если перед этим его проработал где-то сам. Поэтому, возможно, это требование скоро переработаю. А, ну здесь, в принципе, стандартно, да, мы уже это обсуждали. А принцип ягни, далее адаптировать, а, существующие компоненты. Никакой обратной совместимости, потому что, ну, до текущего момента мой проект там даже не реализируется в open source. И, ну, какая обратная зависимость, то есть непонятно для чего. Ну, здесь, в принципе, соглашение по тому, как нужно сохранять эту задачу. Ну, здесь каждый для каждого проекта сдаётся самостоятельно, да. И тут структура плана, смысл и цель задачи, архитектура, полный фол работы, интерфейсы, ну, и так далее. Здесь ничего принципиально нового нет. Ну, здесь считаю самое важное - это, конечно же, наверное, смысл и цель задачи. Наверное, не у всех можно встретить такое. Обычно в сухом формальном документе такое не принято писать.
Далее, после того, как наш агент написал
У нас план реализации, мы доводим этот план до идеального состояния, потому что изначально он, конечно, далёк от идеала. И что значит идеальный план? Он нам кристально ясильно понятен. То есть не должно быть каких-то деталей, каких-то моментов, технологий, которые нам непонятны в проекте, и мы видим там просто как слово, не понимаем смысла. Такого быть не должно, потому что если у нас нет понимания, то от агента что уж можно ожидать.
А далее у нас не должно быть противоречий в плане, потому что бывает, особенно там после проработки, после улучшения плана реализации у нас остаются какие-то противоречия. Например, там в основной части указано использование там определённого класса, а там в конце мы забыли там исправить, у нас поминается уже другой класс, который был изначально. А, разумеется, такого быть не должно, потому что даже там краткое упоминание, а краткое упоминание может очень сильно повлиять на разработку, и агент там с упоминанием одного класса может его полностью реализовать. И без оставшихся артефактов от предыдущего рефакторинга, то есть от первоначального плана, который мы редактировали.
Вот после этого мы отправляем агент реализовывать. То есть, как я уже говорил, я не слежу над агентом, как он каждую строчку пишет. А я отправляю, я даю ему план реализации и нажимаю Shift T, чтобы он, а, сам принимал свои изменения. То есть я там над ним каждую строчку не смотрю.
А после реализации, да, здесь я расскажу про практики, которых не было у меня до того, как проект преодолел, э, цифру в 15.000 строк. Но со временем пришлось их добавить, потому что после этой цифры даже самая лучшая модель OPUS 4.1 очень часто стала галюционировать, то есть отклоняться от плана реализации. Не сильно, но тем не менее с течением роста проекта, я думаю, это неизбежно. То есть раньше, когда агент заканчивал реализацию, я приступал к ревью кода. И теперь вместо того, чтобы сразу ревьюить, я сначала прошу агента сделать так называемые self-ревью. То есть пробегись по плану реализации, распиши, что ты не реализовал из плана реализации, что ты реализовал с отклонениями и что ты реализовал сверхплан.
А далее парец доработок. То есть агент пишет какие отклонения, а то есть мы ему пишем там принимаем какие-то минимальные решения, нужно то или иное дорабатывать, потому что наш план реализации тоже может учесть не всё. Некоторыми моментами может агент столкнуться, которые не описаны в плане. И это на самом деле нормальная практика. Идеальный план, как бы, никогда нельзя сделать. В итоге с таким подходом стало работать гораздо надёжнее и проще. Галлюцинации их источник не сейчас, но мы с ними как-то совладали. То есть у меня теперь нет какого-то в голове опасения, что вот мой агент начнёт много эволюционировать с учётом роста проекта и так далее.
И после того, как мы закончили с реализацией, для тщательного ведения проектной документации, я пишу вот такой промт. То есть после того, как мы закончили с реализацией согласно плану, актуализируй всю соответствующую документацию и сам по анализу архивируй, проиндексируй, да, там в историю в index.md, а вместо него оставь post implementation summary. А где очень важно именно расписать не только, что реализовал, а также какие были отклонения от плана реализации. Всё это агент выполняет. Здесь очень важный момент. Этот post implementation summary очень важен при планировании следующей задачи в рамках одной крупной задачи. А поэтому я пишу всё это одним за одним. То есть я не пишу по большой крупной задаче сразу пять планов реализации. Я сначала пишу один план, реализую один, потому что, да, там какие-то моменты могут возникать в разработке. И тем самым, когда мы пишем задачу два на основе post implementation summary, задача один, мы делаем это планирование более тщательным и более, наверное, правильным. То есть мы составляем не на основе того, что должны реализовать, а на основе того, что реализовали по факту, да?
И какие главные инсайты по AI Dream Development я бы хотел до вас донести сейчас? А очень много, на первый взгляд, можно делегировать агенту. Можно, например, вообще не читать код, не читать документацию, не иметь видения проекта. Агент всё равно что-то напишет, но очень важно держать на самом главном фокусе. То есть первое - это понимание проекта. Оно должно быть в первую очередь не у агента, а у вас, его видение, планы и текущее состояние. Потому что если у вас нет понимания, как вы собираетесь руководить агентом, а по сути, когда вы разрабатываете в парадигме AI Dream Development, вы по сути являетесь, а, да, там автором проекта, руководителем его там, продукт-менеджером, разработчиком, архитектором и аналитиком.
А далее очень важно соблюдать лучшие практики разработки, потому что очень важно для агента, например, уметь запустить удобно проект, сервис, чтобы его отводить, логи, а потому что без этого очень сложно. То есть это для человека сложно, для агента ещё сложнее. И там, а, управление зависимостями - это всё сюда же.
Далее такой важный аспект, как single source of truth, то есть единый источник правды, потому что сейчас, да, когда нам агент может за 2 секунды нагенерить новый документ, а главное держать все документы синхронизированно и организационно, не было, чтобы не было такого же, что у нас там два документа диктуют там разную правду. То есть мой кейс такой был, что я я расписывал задачу крупную, а, и там лежал какой-то документ, который я вообще не читал. Он был сгенерирован языковой моделью просто по этой же задаче очень давно, когда я её только планировал в дорожной карте, там были написаны совсем другие вещи. И после этого мой агент подхватил этот нерелевантный план реализации, а на основе его синтезировал какой-то средний, и там получилась полная чушь. И в результате этой концепции как никогда важно придерживаться.
Ну и очень такой важный совет, я бы советовал всем учиться Computer Science. То есть на первый взгляд там кричат: "Вот искусственный интеллект сейчас заменит всех программистов". Но я считаю это не так. Он, может быть, заменит каких-то кодеров, которые исключительно пишут код и ничего не понимают выше. Но хороший разработчик - это всё-таки человек, который там понимает, как это должно работать. Может быть, где-то залезет даже на архитектуру, не только архитектор. И сейчас вот даже я, как я говорил, не очень опытный backend инженер, но тем не менее начал там учить, какую-то архитектуру, какие-то, а, паттерны проектирования, разработки и так далее. И это, я прямо чувствую, это очень важно, это очень помогает в AI Dream Development. То есть я считаю сильному разработчику, а, например, Вадиму с его глобальным опытом, будет довольно просто стать, а, вот прямо крутым специалистом по AI Dream Development, даже если он сейчас не имеет большой опыт разработки backend, потому что он очень опытный разработчик, которым, ну, кем я не являюсь, но планирую, конечно же, стать.
Да, насколько эффективна такая разработка? Я за 120 часов единый человек разработал 20.000 строк рабочего кода. При этом занимался всем: архитектурой, кодом, дизайном, документацией, даже видеологотип сам записывал. И вот QR-код на проект, где вы можете убедиться, что это всё работает, запускается. Это как раз-таки Learnflow AI система, про которую я говорил. А если вам понравится, то поставьте звёздочку, мне будет очень приятно. Спасибо, что смотрели доклад. А буду рад вопросам и обратной связи.
Да, спасибо за доклад. А сейчас вопросы? Вопросы. Ну, у нас такие, у нас Николай больше делится своим опытом. Я думаю, можно просто прокомментировать, там, согласиться. Он говорит, что он делает. Ты видишь, да, вопрос? Да, делаю так. Одна задача, один чат. А, всё правильно. Я тоже перед тем, как написал план реализации, точнее, после того, как написал план реализации и начинаю реализацию, я создаю новый чат, чтобы у агента был как бы чистый контекст, где будет только вот план реализации и дальнейшие шаги. Всё правильно, да? Согласен максимально.
Так, следующее - это вот про подписки Claude. Есть более крутая подписка. Не знаю, пробовал ты. Ну да, как раз-таки я про вот эту про 100 долларов. Я у меня вот она была этот месяц. А, ну, изначально я там 20 долларов пользовался подпиской. Ну, конечно же, просто на 20 долларов подписки там, конечно же, лимиты сильно меньше. И самое главное, там нет вот этой мощной модели. Но, конечно же, у кого-то лишних 100 долларов нет. Ну, на 20 долларов тоже можно, в принципе, сделать неплохо разрабатывать. Но, конечно же, если купить подписку за 100 долларов, иметь вот эти лимиты по токенам и уметь грамотно разрабатывать, это, я думаю, окупится в десятки раз, если всё уметь. Угу.
[музыка]
Так, следующий про XML схемы. Когда увидели XML? Ну, вообще я читаю Telegram-канал, скажем так, специалиста по промтингу Владимир Иванов. Ты, наверное, его знаешь, Александр, и он там очень так сильно и углублённо разбирает, почему XML промт лучше. Но есть ли какие-то рекомендации от Anthropic, а так не скажу, но сейчас я точно знаю, чат GPT в их руководстве появилось примеры XML промтов как замена Markdown, потому что, ну, вот как раз-таки двухсторонность в основном их, а, привлекает то, что в Markdown не могут у агента секции смешаться. То есть он может там, условно в Markdown секции отличаются там переносом строки, и агент, ну, может, скажем так, не обратить своё внимание на этот перенос. А когда там действительно стоит токен, то есть, да, в XML эти же слова потом конвертируются в токены, и токены уже несут в себе какой-то смысл, какую-то какой-то там вектор. А, соответственно, в основном, наверное, вот эта двухсторонность, возможность разграничить всякие секции. Ну, и, как я говорил, вот эта семантика, вот этот смысл, который ты доносишь в названиях и вложенностях вот этих секций, тегов и так далее. Если попросить модель, она напишет такой промт. Если просто просить, типа, напиши мне промт в формате XML, а там, по-моему, выйдет что-то невнятное. Но в целом а я сейчас, да, работаю над разработкой промта, а там вот даю вот эти инструкции как раз-таки, как вот правильно писать промт в формате XML. Поэтому, если вставить модели системный промт, где ты распишешь, как нужно писать промт, а для XML, то, да, я думаю, очень даже спокойно напишет. И это точный вариант. Я, в принципе, сам, ну, прямо вручную не пишу, но очень тщательно, как бы, валидирую то, что он пишет. Как-то так. Спасибо за вопрос. Угу.
Я бы ещё, наверное, дополнил, наверное, минус XML в том, что он многословен, да? У него надо открывающий тег, закрывающий тег. И вот с модельками и вот этим контекстом и потреблением токенов не очень. Но в XML есть крутая фича, которая нет там в JSON, в YAML - это, возможно, атрибуты, да? То есть мы можем в каждый элемент добавить какой-то ещё атрибут, то есть метаинформацию. Ну, наверное, это пока ещё, скажем так, сама реальность рождается прямо у нас на глазах. И вот все пробуют что-то новое, ну или там что-то переизобрести и так далее.
Так, следующий вопрос. Сейчас, можно я твоё дополнение прокомментирую? Тоже, да, прикольный поинт про вот эту метаинформацию, атрибуты. Честно, не пробовал, но вот что-то появилась идея прямо попробовать. А поводу многословности я немного не согласен, потому что, ну, в Markdown тебе нужно много всяких предлогов, артиклей писать, а в XML, наверное, всё-таки, да, то есть ты два раза пишешь одни и те же слова в начале и в конце, но тем не менее ты можешь многие, наверное, предлоги опустить. То есть, например, вот здесь в XML промте я, например, просто написал одно слово между двумя тегами. А так, если бы я в Markdown писал, а я бы это было типа я бы писал project, а я бы писал project. Я, наверное, больше к тому, что в итоге должны прийти к какому-нибудь YAML, потому что в YAML ты просто пишешь stage двоеточие MVP, и у тебя вот сколько там символов сэкономлено. Ну, YAML, да, но вот опять же то, что нет двухсторонности, ограничения, вот, наверное, вот это минус. Это очень, ну, важно как бы для вот этого трансформера. Ну, технология, да, это тип нести. Ну да, и конец искать строки сложно. Угу. Да, да, да.
Так, давай следующий вопрос. Про облачные функции. А интеграцию CLS GitHub. Мм, наверное, раз я не могу ответить, наверное, я ничего не применяю, а там в плане функции по типу там Claude может залезть в мой репозиторий, что-то по нему ответить и так далее. А просто так не совсем понимаю, какие там инструменты. Там можно подключить GitHub репозиторий, чтобы код по нему искал, что такое, если не ошибаюсь. Да, но так, наверное, нет. Хотя фича очень прикольная, интересная. Ну, там нар Александр сейчас дополнится вопрос. Да, если дополнит, ответим будет.
Так, дальше тоже Николай своим мнением. Visual Studio. Visual Studio. Ну, я сам Visual Studio не особо пользуюсь, поэтому там, наверное, интеграция она, наверное, через плагин и там зависит от разработчиков плагина, наверное. Ну да.
Так, следующее. И не может удерживать контекст. Он человека не сменит никогда. Ну, никогда. Но это мы посмотрим, конечно. Я сам надеюсь, что меня не заменит большая языковая модель. А в целом поинт хороший про контекст. Я с ним сильно согласен. То есть действительно, наверное, одно из фундаментальных ограничений, по которому там многих из нас пока не заменил искусственный интеллект, это контекст. Действительно, Николай очень прав. Да и, ну, учитывая скорость, которой они развиваются, я думаю, никогда, ну, тоже там имеет какой-то срок давности.
Александр дополнил вопрос про облачные функции. Это по сути, э, всякие ревью, не знаю, там issues создавать, то есть не около старые тулы по типу там возможность создать, да, какая-то функция даётся агенту и он может вызвать её в GitHub. Угу. Issue я понял примерно. В общем, нет, не использовал, но получается issue - это когда какой-то сторонний разработчик может к моему проекту там какой-то какой-то вот issue открыть, да, там, потому что там баг или там подработки, правильно помню? Ну, допустим, ты создал там, да, да, по сути задача, да, там баг или фича. По сути, ты создал pull request, добавил новую фичу, и у тебя функция может быть либо ревьюить, либо создать там, не знаю, а ты решил блок в ту-ду внести и создать, попросить агента, чтобы он создал тебе задачу на будущее. Ну, типа там, не знаю, улучшить качество или что-нибудь такое. Вот. Ну, пока нет, не пользовался, но, возможно, буду пользоваться. Но опять же здесь фундаментальный момент, что прям тоже на полную автономность без моего ревью не хочу пока ничего отпускать нигде. Даже там на обзор не, ну о'кей. На реализацию точно не хочу, на внесение там документации тоже не хочу, поэтому всё равно мой контроль нужен. И здесь, наверное, ну с этим с с учётом этого не так сильно это всё будет бустить, наверное, поэтому не знаю. Ну да, на самом деле технология сырая, она как будто только вот где-то весной начала набирать популярность, когда там всяких агентам давать доступы, чтобы они тебе прямо в коде ходили, делали. Тоже чат GPT запустил codex.
Так, следующий вопрос. Про ускорение, профессиональный рост. Я считаю, что я никогда так много, никогда так мощно, никогда так сложно не программировал, как вот начал с подходом AI Dream Development. То есть именно не то, что я, понятно, что я не пишу код в основном, но именно всю соль разработки, я считаю, я именно начал познавать с парадигмой. Вот я ивент делал, где мне нужно погружаться во все сервисы, протоколы и так далее и тому подобное. То есть опять же, да, как я говорил, я не не веб-кодингом занимаюсь и как я дал совет, что нужно учить Computer Science. Наверное, в первую очередь я дал его на себя, а для себя. Поэтому как сколько быстрее стал изучать новые технологии по сравнению с классическим подходом? А, сложно сказать, но понятно, что это какие-то разы, но я думаю раза в четыре, может быть. Ну вот так.
Какие-то рекомендации всем, кто начинает. А всем, ну, условно там, начинающим разработчикам, кто вот может разрабатывать в парадигме AI Dream Development и там быстро расти, а какие рекомендации? Ну, наверное, не бояться и делать всё осознанно, то есть не бояться. То есть я обычно думаю вот сейчас типа, ну, например, хочу применить какой-то паттерн, и я думаю: "Ну, сейчас мне нужно с ним пару часов разобраться теории и т.д". А так, конечно, теория нужна, но отрабатывать лучше на практике. И я тут посоветовал бы не бояться, но при этом делать всё осознанно с пониманием, потому что без понимания вот агент там закончит реализовывать и а всё забудется. Когда ты делаешь всё осознанно с пониманием, оно у тебя откладывается, и в будущем ты можешь принимать очень классные решения по архитектуре, по разработке. Ну, наверное, пока такие рекомендации, но может быть что-то упустил, может быть, что-то не добавил ещё. Угу.
На самом деле это такая подводка к моему докладу в скором будущем. Я вот тоже занимаюсь там, ну, отражу про рост, про как там учиться и всё это прочее. У меня будет именно вот на этот доклад нацелен.
Так, следующий вопрос. Это, наверное, про опыт с codex. А, честно говоря, нет. Я кроме cursor и codex я ни на что не пока не разрабатывал. Я видел вот на канале AI Dialog как раз-таки есть видос про codex. Я так посмотрел, интерес, конечно, есть поработать, но вот в последние 2 недели был очень сильно занят своим pet-проектом и ничего, ну, не было времени пробовать. Ну, конечно же, а планирую попробовать. Ну, а так ничего пока поэтому не думаю, не пробовал. Угу. Ну вот там Александр скинул ссылку на видео, он там делал обзор и, наверное, а ну это создаёт какую-то конкуренцию. Я думаю, это всем пойдёт на пользу.
Так, следующий вопрос про опять про XML. Угу. А, да, всё правильно. Прямо вот, ну, вот это вот начало системного промта. То есть прямо в таком формате они отправляются в LLM. Всё правильно. То есть это там ни во что не конвертируется, но понятно, что под капотом это там, а, переходит в токены. Тут, наверное, будет токен такой такой такой, но они будут разделены вот этими всеми. И да, то есть так они прямо и отправляются. Угу.
Так, следующий вопрос. Видимо, про большой контекст. Так. Milvus MCP context. А я, честно говоря, не знаю, что такое контекст. Я знаю, что это векторная база для RAG, если, конечно же, под этой аббревиатурой не значится что-то ещё. MCP модуль контекст протокол. Ну, не слишком понимаю, что могу предположить, что Claude, видимо, у себя будет хранить контекст, наверное, не каждый раз его гонять, но это надо, а, ну, типа индексировать в базу, в случае чего к нему обращаться и так далее. Но вообще эта идея интересная, то есть по сути подключение, ну, RAG, который есть в cursor, но в Claude, в codex. Ну, конечно же, да, когда большие проекты нужны, что-то такое придумывать, наверное, это один из возможных вариантов, там вопрос вопрос в подходах в качественных и в конкретных там э методах. Возможно, вот у меня возникли такие идеи, что, ну, я говорил, да, там про момент с некачественным построением билдинга по какому-то участку безликого кода. Ну, мне кажется, возможно, если как-то размечать комментариями какими-то, чтобы строились embeddings, а-а, чтобы строились embeddings, можно вот комментарии давать и чтобы по ним строились embeddings. Мм, у нас действительно смысл отражался. И тогда, я вижу, можно что-то очень крутое разработать с таким подходом, но это отдельный отдельный момент, отдельно прорабатывать надо. Угу. Да.
Вот там Сергей пишет, что, ну, по сути, типа аля RAG, да, с индексацией кодовой базы, чтобы она лучше по коду ориентировалась.
Так, следующий вопрос у нас про Так, ещё раз про XML уточнение. А для XML случаем схемы нету с описанием всех полей. А мы можем же поля любые сдавать. Или про какие поля тут имеется название тегов? Ну, наверное, вот ты по сути вот эту схему придумал сам, да? Да, она вообще абстрактна. Можно лю Да, она любые любые слова может принимать. То есть это мы сами придумываем. Это не какой-то там шаблон. Мы можем сюда любые слова написать, даже там с ошибками. Я не знаю. Это не то, что там, помнишь, была тема structured output, да, когда мы даём схему, она её заполняет на выходе. Здесь да, это это не то, да, это просто это просто вход, это просто, ну, обычный текст, но да, он как бы в формате XML. А просто, ну, так вот. Угу. Ну, просто в, скажем так, в понятном формате для машины, да, для модели. Угу. Угу.
Так, есть ли у нас ещё вопросы? Пока вопросов нет. И у нас, на самом деле, был вопрос к предыдущему докладу. А я постараюсь ответить. Мобильное приложение можно подобным образом создать с запуском на эмуляторе. А это вот к докладу Вадима, да, где он там разрабатывал ботов. Мне кажется, с мобильной разработкой, наверное, низкий спрос, либо скептические разработчики мобильных приложений к этому на это смотрят, да, и как бы не пытаются там какие-то практики делать. И и я вот к чему, что мне кажется, если самому попробовать разработать мобильное приложение с там, не знаю, с агентом, то это потянет на какую-то статью, доклад или какое-то видео. Ну, потому что на самом деле прямо здесь сейчас опыт этот нарабатывается. И я думаю, там может быть проблема вот как раз-таки с этой интеграции дать агенту какую-то информацию из эмулятора, потому что там на этих эмуляторах есть какие-то вот топовые IDE типа там Android Studio ещё какая-то, ну или там есть iOS у Xcode. Вот. И там даже другие IDE не получается переплюнуть их. Вот. То есть там такая, скажем так, есть свои топовые IDE и и они как бы никто с ним не хочет конкурировать. Я думаю, вот вот в этом нюанс, что либо нужно какой-то там, ну, не знаю, MCP или что-то подобное, чтобы у тебя с эмулятора отдавалась информация агенту. Ну, вернее, он запрашивал и получал её, типа, там криво всё нарисовано или нет, как это, допустим, агенты из HTML просто делают. Вот так.
Вопросов новых. Ага. А так, ну, тут призывают статью сделать, да, идея есть в целом на Хабре, конечно. Ну, нужно время просто. Ну, да, планы есть, конечно.
Так, ну, да, то есть чёткая разметка промта XML. Ну да, то есть в ёмком в ёмком формате скажем, да. Его далее Сергей говорит с возможностью ссылаться на определённые теги. Это правда. То есть если, ну, например, я могу вот так сослаться там в какой-то другой в каком-то в конце промта, я типа могу написать типа смотри на секцию. А вот так могу сослаться. И это очень хорошо работает. То есть, потому что здесь, ну, название совпадает, токены одинаковые получатся. Это, ну, внимание, механизм внимания сильно заставит работать модели. По сути, типа для использования переменных. Угу. Ну да, кстати, да, тут, кстати, коллеги в чате про SOAP вспомнили с XML. Вот сейчас может неровно про него рассказать, что это такое и зачем это надо было.
Так, у нас А по вопросам, кажется, всё. Стасу большое спасибо за доклад. Спасибо за вопросы.