Transcription
Сегодня первый вебинар из серии о том, как и инструменты меняют подходы к разработке и созданию продуктов. И сегодняшний доклад будет о моём личном пути к такой роли, которую назвал Full Cycle и я инженер.
И сегодня хотелось бы поговорить не о каких-то там конкретных инструментах или там моделях, о том, как фундаментально вообще меняется индустрия, принципы создания продуктов, роли, бизнес. Э не на каких там абстрактных примерах, тезисах, а через личный путь и личную трансформацию.
Инструменты и модели, которые сейчас появились, они фундаментально меняют, в принципе, то, как э можно теперь создавать продукты, валидировать гипотезы, э, делать автоматизацию и многие другие вещи.
То есть, как было раньше. Если у тебя есть идея или тебе надо создать какой-то продукт, тебе нужно сначала собрать команду. Причём эта команда ээ достаточно внушительное количество ролей включает, да, начиная от, а, там, какого-нибудь системного аналитика или продукт-менеджера, конечно, разработчиков, тестировщиков. Аэ, в зависимости от сложности инфраструктуры, возможно, потребуются там devops, специалисты, а, и как бы в зависимости от масштабов проекта, там, э, руководители проектов. И дальше начинается долгий цикл, в принципе, от постановки через разработку, тестирование и выпуск. И в целом это достаточно длинная цепочка, даже если хорошо выстроены, в принципе, инженерные процессы, внедрены такие практики, какие-нибудь agile и devops подходы.
И мм с появлением, э качественных достаточно мощных языковых моделей и кодовых агентов вот этот подход к созданию продуктов, он фундаментально поменялся. То есть написание кода и разработка, они вообще перестали быть узким местом и позволили огромному количеству разных специалистов приобщиться к созданию продуктов и запуску своих идей э в как бы в разработку и использование.
И чтобы чуть лучше, наверное, понимать, расскажу немного о том, какой у меня прошлый опыт. Сергей уже сказал, что мы, в принципе, закончили вместе ИТМО и получили инженерное образование. И с тех пор, в принципе, э занимались так или иначе в разных ролях ээ разработкой. И я лично начинал как разработчик. ээ какое-то количество времени в самых разных ролях был там и системным аналитиком, и таким фулстек разработчиком, но с как бы профессиональным ростом. И там как бы последние, наверное, лет восемь в создании там продуктов и сложных информационных систем я выполнял роль по сути руководителя руководителя там небольшой группы или команды или даже нескольких команд. И по сути вот эти там последние лет восемь до примерно там 20004 года, э, там конца, я вообще не занимался написанием кода и даже перестал в какой-то момент его там читать и ревьюить, но при этом а с появлением чата GPT и я стал активно его использовать для решения своих как бы управленческих задач разнородных и в принципе также при участии в хокатонах. Вот о чём дальше, в принципе, подробнее расскажу.
А, и первый первый шаг или первый пример, а, про который хочется рассказать, это пример из 2023 года. По сути, э, тогда уже чат GPT появился. Э, не было, наверное, ещё такого понятия, как кодовый агент или даже агент. И в этот период наша команда, она достаточно, мм, активно, э-э, стала участвовать в различных хокатонах ээ по искусственному интеллекту. И как бы основная основная моя роль она была на работе фактически в роли руководителя, да, организатора процессов, в лучшем случае какого-то там как бы высокоуровнего архитектора. И получается, что хакатон - это процесс такой компактный, несколько дней от идеи до хорошей реализации. И на всех этих катонах я, как правило, э как бы выполнял роль такого, э, как это сказать, разнорабочего или ещё в IT там называют никейщик. То есть я человек, который руками ничего не писал, но имеет достаточно широкий кругозор и опыт, да, инженерный. И в целом как бы мой мой прошлый опыт позволял помогать команде там организационными задачами, а, возможно, какими-то там проверками гипотез, в лучшем случае анализа данных, например, которые нужно было.
И вот в момент, когда появился чат GPT, и в одном из хакатонов я как вдохновился очень сильно. И вот тут вот пример, в целом, решая задачи, то есть мы в хокатоне участвовали с небольшой заготовочкой, нужно было создать, э, чатбота, который бы помогал сотрудникам МФЦ решать свои задачи, помогать посетителям, отвечать на их вопросы, помогал бы оформлять э какие-то там документы. И там в середине хакатона так получилось, что результаты, которые наше заготовленное решение выдавало, они как бы нас не удовлетворяли, были не очень качественными. И э в то время GPT по сути не так давно появился и он достаточно хорошо и так инициативно помогал тем, кто им пользовался. И вот я пошёл в GPT сначала, э, отдал туда наш датасет, попросил его там проанализировать и для этого датасета сделать систему э выступить в роли этой системы. Вот. И по сути чат GPT это всё проделал, написал какой-то код и стал этот код выполнять, отвечая на мои вопросы на основании датасета, который я ему в виде файлика отправил. И по сути вот это буквально цитата из нашего командного чата, да, когда я получил в результате вот таких нехитрых как бы действий без особого погружения, да, по большому счёту передав данные и запрос на реализацию, получил результат, который превосходил на самом деле по качеству то решение, которое мы подготовили, которое подготовила команда, которая занималась похожей в принципе областью, да, созданием ассистентов.
И, в общем-то, а вот этот вот как это это, в общем, стал пример переломным моментом, когда появилось глубокое убеждение, уверенность, что вот такие инструменты, как чат GPT, в основе котох лежат большие языковые модели, они могут, а, совершенно давать феноменальные результаты. Вот. И как бы это был первый, наверное, пример, где мой вклад в там общее общий результат, он нёс не только какой-то вот организационный характер, но и инженерный. То есть, в принципе, я вот тут вот почувствовал немножко вкус из прошлой жизни, когда я там был разработчиком. И надо сказать, что как бы то решение, которое сделал чат GPT, оно легло в основу нашего решения, которое как бы выиграло, да, мы в этом хакатоне победили и не без заслуги, естественно, вот этого участника. Вот. То есть в целом вот этот эпизод, он такой переломный, воодушевил очень сильно. И, конечно же, как бы, наверное, в том числе благодаря вот этому случаю GPT стал с тех пор таким как бы основным рабочим инструментом.
Но как бы повторюсь, да, у меня роль основная - это руководитель. И в общем GPT на тот момент я использовал, естественно, для аэ как бы повышения эффективности и там как бы где-то качества в тех процессах, в которых я там непосредственно участвовал. Это большое количество всяких задач, связанных с наймом сотрудников, да? Это формирование там вакансий, подготовка тестовых заданий, оценка результатов тестовых заданий. То есть, в принципе, в особенности в тех сферах, в которых у меня не было каких-то глубоких профессиональных компетенций, да, то есть смежных с разработкой. Там не знаю, например, там инфраструктурные, там devs инженеры. Э, очень сильно мне GPT помогал. Ну и понятное дело, всё, что связано с коммуникациями, с текстами, там структурированием мыслей, как бы существенно снижается когнитивная нагрузка. И, в общем, GPT на тот момент стал таким как бы мощным, мощным рабочим инструментом, который позволил как бы гораздо эффективнее все свои задачи решать.
Но как бы надо понимать, да, что классный инструмент, ээ, мощный, может давать вот такие фантастические результаты. Но в том виде, в котором он, в принципе, на тот момент присутствовал, он как бы не способен претендовать на мм такой как бы название инструмента рабочего, да, какого-то. Встроенного в во все рабочие процессы, потому что получается, что любую задачу, которую ты решаешь, она изолировано на самом деле от твоего рабочего окружения, от не знаю конфилюнс системы, от тикетсистемы, от почты и всего прочего. То есть любая задача, она дополняется вот этой вот рутинной необходимостью как бы передать контекст, да, загрузить туда в веб-версию, там эчата GPT какие-то данные, ээ, получить оттуда какие-то результаты и загрузить обратно в те системы, в которых эта информация нужна и полезна. Ну и, конечно, вот это дополнительное копирование, переносы, они как это ослабляли как бы веру в то, что вот этот инструмент может претендовать на такую роль основную в рабочих процессах.
Но, в общем, так или иначе, достаточно активно я в то время его использовал, а, и верил, конечно же, да, что должен появиться какой-то инструмент, э, который позволит мне заниматься вот этим бездумным копированием. И на самом деле такой инструмент появился. Вот. И он до сих пор есть и развивается. И этот инструмент называется курсор. Вот. То есть он появился, наверное, а, я так думаю, в конце двадцать третьего года. И там первые какие-то упоминания, по крайней мере, мне встречались, но, ээ, не доходило всё никак, не доходили руки до того, чтобы его как-то использовать и ощутить его мощь. Вот. Но такой момент настал, и это, по сути, м первый коммерческий проект, который, ээ, в котором я участвовал с применением этого инструмента. И этот проект - это м такая система интеллектуальная для помощи редакторам э онлайн новостного издания. Главная суть и главная задача нужно было ээ редактору предоставить инструмент, который позволил бы собирать ээ как бы информацию вокруг какого-то инфоповода. Э её агрегировать, там, систематизировать и делать заготовку для написания статьи вокруг этого инфоповода. То есть и дополнительно этот инструмент должен ээ был генерировать ээ какую-то обложку, да, иллюстрацию для визуализации сути этого и привлечения внимания к этой статье новостной. Вот, то есть основа этого проекта получается, э, там несколько генеративных моделей и обвязка для того, чтобы этим было м удобно пользоваться.
И ээ это как бы основа, но в этом проекте заказчик попросил дополнительно, поскольку система э редакции была написана на языке ПХП, то для того, чтобы можно было вот этот инструмент, который немного в стороне находится, легко интегрировать, то заказчик попросил э сделать интеграцию э на языке phхп э-э и плюс сделать визуализацию и какие-то формы, которые можно было бы использовать для тестирования и отладки. То есть, в принципе, планировалось впоследствии полноценно интегрировать вот это в виде сервиса в систему редакторскую, но на этапе опытной эксплуатации нужно было предоставить какой-то макет, прототип, э, чтобы это всё дело хорошенько протестировать и отладить. Ну и, конечно, любой проект коммерческий, он включает в себя часть, связанную с какой-то там упаковкой. Здесь надо было всё запаковать в докер, ээ, и поставлять в контейнерином виде, снабдить API, э, все документации, э, снабдить весь проект вообще инструкциями по структуре, по, не знаю, запуску локальному, по развёртыванию. Там, соответственно, шёл большой комплект документации. Вот.
И, э-э, для решения задачи вот центральной части сервиса у нас был эксперт, специалист, который это всё прекрасно сделал и, по сути, сделал API, эээ, который нужно было обернуть во всё, что я только что перечислил. То есть большой набор всяких вот таких вспомогательных задач от ПХП до формы и докера, который шёл таким бонусом к этой корчасти. И, конечно, там нашей небольшой команде никаких экспертов там по ПХП не было. Вот документацию писать тоже выделенного специалиста не было. Мы работали маленькой командой. И по сути я в этом проекте выполнял роль в такую мм как бы руководящую, да, или координационную, вот взаимодействовал с заказчиком и формулировал, возможно, какие-то там э небольшие задачи на реализацию. И вот большой спектр вот этих вот задач он, э, было непонятно, кому делать. И м я решил, в общем, э-э, воспользоваться как это поводом и проверить курсор на практике в бою, на реальной рабочей задаче. Напомню, это был эчало двадцать четвёртого года, то есть первый квартал, я думаю. То есть, в принципе, это ещё задолго до вот такого как бы зрелости этого инструмента.
И что у меня было на входе? То есть опыт какого-то вот такого системного использования таких инструментов на тот момент не было. Я открыл курсор, у меня было на входе, на самом деле, готовый сервис на Питоне, который был реализован, и фактически были требования, которые, э, определяли вот полный спектр работ. И я не нашёл ничего лучше, чем буквально сказать в чате в курсоре, что вот смотри, значит, у нас есть вот такое м такой договор, в нём перечень требований, что надо сделать. Вот это требование, фактически корчасть, оно реализовано, а всё остальное, включая ПХП, вебформы, докеры, документации, вот всё, всё остальное, всё, что было, э, оно как бы не реализовано. И реализуй это, пожалуйста. Вот я не помню, честно говоря, в тот момент какая была актуальная модель э-э по умолчанию в курсоре, но вот мой запрос был буквально вот такой прямолинейный. Вот тебе список задач, пойди, пожалуйста, и сделай. И значит, курсор пошёл делать спустя, ну там надо было, конечно, ему сказать, дать разрешение, там самостоятельно выполнять все задачи. И спустя какое-то непродолжительное время, там, не знаю, полчаса или там 40 минут, он, соответственно, сказал, что всё готово, пожалуйста, можно проверять. Значит, докер запустить вот так. Форму сделал, ПХП сделал, всё задокументировал. Смотри.
И как бы я пошёл смотреть и действительно, то есть всё работало, как бы API был интегрирован, сама форма единого требования, на самом деле, не предъявил, не просил её делать какой-то там как бы удобной, не выбирал стек. То есть фактически для этой формы был только API, да, который корчасть умела делать. И на выходе, ну, меня, конечно, просто потряс результат, потому что, во-первых, сама форма, она была как бы достаточно удобная. Он там предусмотрел для тестирования какие-то варианты параметров, о которых я даже не успел подумать, честно говоря. Вот. И эта форма была удобной, она работала, она позволяла всё это проверить. И как бы весь стек, эээ, он запускался в доке, и вся документация была написана. Она была исчерпывающей, подробной, э, и в ней там всё, что необходимо было для того, чтобы отчитываться. И фактически вот этот результат, полученный за полчаса, он как бы произвёл, ну, вообще вау-эффект, потому что, ну, естественно, там никакого ПХП ээ я там на тот момент не помнил. Я на нём примерно лет 20 назад начинал программировать ещё, когда учился в институте. Вот. И с тех пор вообще даже в глаза не видел, как как выглядит стек с ПХП под капотом. Вот. А ну что такое докер, я, конечно, понимал. Вот. И документации писал достаточно, да. Но, в общем, всё остальное было, включая формы и бутсрап, который он выбрал, да, это было для меня, по сути не в зоне моих компетенций. И этот же результат я как бы дальше представил заказчику и получил как бы положительные очень отзывы. Что, ну, буквально то же самое, что я сам ощущал, что классно всё выглядит, хорошо работает, но, естественно, не обошлось без каких-то пожеланий. Вот там не предусмотрели что-то, что удобно там редактору, например, или удобно для процесса там тестирования. И как бы заказчик сказал: "А вот можно, пожалуйста, вот здесь, здесь там что-то поменять, улучшить. Вот. И как бы будем тогда дальше двигаться по этому проекту.
И что вы думаете дальше произошло? То есть, как бы, ну, естественно, ээ, делая оценку для вот этой задачи, где мне надо было так много всего сделать, я там заложился с учётом новых стеков, э и всего прочего возможных проблем и рисков и как бы представлял, что даже, наверное, с такими инструментами, как курсор или в худшем случае, если там не пойдёт с каким-нибудь GPT, за там 2 недели я, наверное, смогу вот это всё собрать, написать эту документацию и всё такое. Вот. Но, конечно, получил результат гораздо быстрее. Ээ, и после фактически, ээ, первой демонстрации заказчику я пошёл, э, эти пожелания превращать в жизнь. И вот здесь вот у меня реально открылись как бы глаза и пришло понимание, что вот такие подходы, как я использовал, да, как бы бездумные, возможно, и с очень большим объёмом работы, который я там делегировал агенту, они не очень хорошо работают, несмотря на то, что я получил вау, эффект, результат, э дальнейшие какие-то изменения небольшие. Они на самом деле абсолютно всё ломали. То есть заказчик попросил поправить форму. Я передаю эту просьбу, казалось бы, микроскопическую агенту. На выходе получаю полностью переделанную форму, ещё и с ошибками, которых до этого не было. И в общем, как бы следующие итерации всё по примерно такой же логике. Э, соответственно, на тот момент, э, у меня там не существовало какой-то практики, понимания, как действовать в таких ситуациях, как правильно вообще, э, выстраивать эту работу с такими инструментами. И, в общем, следующие 2 недели примерно я потратил на то, чтобы вот как бы результат, который получил за полчаса, довести до результата, который устроит полностью, да, на 100% заказчик. То есть вот эти там, не знаю, э, микроскопические 3 или 5%, да, каких-то косметических правок, они у меня превратились реально в такую, э, со слезами борьбу с курсором, с агентом, с вечными ошибками и падениями. Ну и, в общем, это был первый, по сути, мой, э, как это, опыт, вывод, э, как бы, который я получил, вот, и который, естественно, я в следующих проектах, э, постарался учитывать, но, э, это и это и была большая ценность, на самом деле, потому что, конечно, несмотря на вот эту боль и там проблемы Общий фон от этого проекта, он был положительный, вдохновляющий. То есть, по сути, я там как бы открыл новый стек, в него там спокойно погрузился, решил задачу в конечном счёте качественно, так как это устроило заказчика. И в общем это вдохновляло, да, ещё больше двигаться дальше, этот инструмент осваивать, развиваться.
И, э, следующий проект - это проект по, э, созданию лендинга нашего м lm. И это тоже очень очень интересный опыт. То есть на момент когда мы приняли решение, что надо этот лендинг создавать, мы там активно применяли э уже курсор и делали какие-то проекты, связанные с продуктами, в основе которых лежат там большие языковые модели, ассистенты. Какие-то, да, там рак системы и так далее. И, в принципе, даже участвовали в хакатонах, которые подразумевает использование вот таких вот и я инструментов, но, э, конкретно применительно к созданию каких-то фронт приложений. Как бы лендинг - это частный случай и звучит, возможно, не так масштабно, но мой прошлый опыт, э он достаточно м такой как бы внушительный и сформировал определённую такую ээ какое-то мнение вокруг вообще всей этой области. То есть я помню и фронт приложения, и лендинги - это не исключение. И когда нам, например, в компании, в нашей в нашем департаменте пришла мысль создать там страничку или лендинг нашей команды, то мы для этого собирали настоящую проектную команду, которая включала, в принципе, все роли. Там был дизайнер, там был системный аналитик или там аналитик, да, который ээ с дизайнером там плотно взаимодействовал. Там был разработчик, там был фронт-разработчик выделенный, да, который как бы эксперт вообще по вот этой сфере достаточно узкой в последние там годы моей работы. И там был даже специалист, который помогал это всё разворачивать. И длилось это, в принципе, на самом деле, несколько месяцев, потому что, э, дизайнеру, чтобы какой-то макет сделать, надо собрать требования, чтобы аналитик собрал, всё передал. Э, когда готов дизайн, разработчик его берёт в работу. Ээ и дальше как бы по цепочке классической там с начального слайда.
И у меня, конечно, в голове сформировалось такое устойчивое мнение насчёт этой области, что это сфера очень бурно развивается, появились какие-то сверзко специализированные роли и даже которые мы вынуждены были добавлять в проектные команды. То есть фронтенд разработчик, React какой-нибудь фронтенд разработчик. И это, э, там вся эта экосистема, да, вокруг там джаваскрипта или тайпскрипта с кучей каких-то фреймворков, которые каждый день меняются, каждый день новые систем сборок. В общем, страшное страшное дело. То есть кажется, что вот самостоятельно подступиться к созданию чего-то такого - это просто неподъёмная задача, в принципе, да, и если даже не говорить про часть, которая связана, ну, во-первых, с дизайном, да, с визуальной составляющей, и второе вообще со всей этой экосистемой. Вот.
Но, ээ, потребность есть, как бы команда по-прежнему небольшая, фактически. Э, вот и задача важная, как бы обсудили, договорились и я пошёл за эту задачу браться вот с определённым опытом уже пост первого проекта, про который я только что рассказал. И в этом проекте уже, э, конечно, выстраивал какую-то, как это, зачатки системной работы, да, с какими-то требованиями, с какими-то соглашениями, вот с постановками для, э, кодового агента. И, ээ, надо сказать, что здесь тоже был буквально шок, потому что я, ну, естественно, не обладаю всеми знаниями, да, вот всей экосистемы терминологии каких-то связанных со стилями, э, какими-то знаниями, которые как бы необходимы, допустим, дизайнеру, там композиция, цвета и всё. всё прочее. Но в целом я, конечно же, как и любой человек, способен объяснить, что мне нравится, что мне не нравится. Вот я, естественно, видел много разных дизайнов, которые могу привести в качестве примера, например. Вот. И в принципе в таком мм подходе я подошёл книл ээ как бы примеры э внешние э сайтов, которые мне нравятся, нравятся, не знаю, по цветовому оформлению, по шрифтовому, по каким-то элементам. Э как бы определился, что там мне условно нравится там как бы тёмный тёмная тема. Э-э, и дальше итерационно, э-э, выбрал стек с быстрым разбирательством вообще, какие бывают, что что лучше, что хуже подходит, и в целом погрузился ещё в одну сферу, которая как бы, ну, кажется скрыта, когда мы говорим слово лендинг, но это большая область, которая связана с написанием текстов и представлением последовательности информации для того, чтобы её было там, не знаю, удобно воспринимать тем, кто будет на этот лендинг приходить. То есть там какие-то механики нужно использовать из маркетинга или там UIUX подачи и так далее.
И в целом, м, вот вооружившись, в принципе, вот такой подачей простой, да, я хочу сделать лендинг. У меня вот такие примерчики. Мне нравится [смех] цели у этого лендинга вот такие. Я ничего не знаю про маркетинг и так далее. Мне тут нужна помощь. и в таком формате выстроил как бы некую систему, в которой там разобравшись зафиксировал там принципы вот все, которые важны для создания лендинга. И после того, как это зафиксировал, фактически, чтобы создать вот от цели, да, и от идеи до работающего прототипа и который ещё и благодаря начики облачных провайдеров, таких как там Railway или Versell, например, да, которые позволяют там в один клик буквально из репозитория развернуть без какого-либо кода, да, работающий проект проект и ещё и подключить к нему бесплатно домен. У меня заняла первая версия реально 4 часа. И это был фактически второй пример - ещё более вау эффекта, потому что результат лично меня крайне ээ удовлетворил, вдохновил, да, и как бы самое главное помимо вот такого эстетического ощущения, да, у меня, конечно же, произвела скорость, ээ скорость от там идеи до реализации, до момента, когда я смог поделиться там с Сергеем первой ссылкой и сказать, что вот, пожалуйста, типа опять же там не за неделю, не за две, а за полдня удалось собрать вполне себе вменяемый, ну и даже вменяемый, мягко сказано, лендинг - вот который, в принципе, вы до сих пор можете видеть. То есть фактически то, что вот тогда таким способом было сделано, оно продолжает развиваться, обрастая уже, конечно, как бы там системностью, исходя из нашего опыта, вот, которая появилась.
И, э, вывод как бы из этого проекта - это, конечно, фантастическая скорость, с которой можно получать результат. Фактически это как бы полноценный продукт, да, можно его там назвать, и который очень-очень быстро я получил без вообще говоря копейки компетенций каких-то во всех этих инструментах, да, и даже на самом деле обладая багажом такого типа страхов. Вот. Потому что вот у меня там опыт как бы плачевный. Ну, условно плачевный, да. Там как бы если в прошлом это занимало там несколько месяцев у команды, да, то что будет сейчас со мной? Вот. Но, в общем, так, шаг за шагом постепенно выстраивалась система, да, работы всё более и более эффективной и с таким разблокированием новых областей, да, в данном случае это фронт-разработка. И логичным выходом и следующим шагом или следующим проектом это были задачи и решения инфраструктурные. Вот. То есть я там упоминал, что на протяжении всего этого времени мы занимались созданием, э, систем, там, ассистентов, да, раксистем, вопросно-ответных, вот, которые на которые у нас была экспертиза, да, но любая такая система, она, конечно же, при передаче в какую-то опытную эксплуатацию или промышленную, она подразумевает большой спектр работ, связанный с инфраструктурой, с развёртыванием. Вообще говоря, сам процесс подразумевает работу, связанную там с со сборкой и доставкой этих приложений и интеграцией их куда-то в системы заказчика. Вот. И это была такая цепочка, ряд проектов, в которых эти задачи ээ по остаточному принципу ээ выпало выполнять мне. И они в себя включали по сути несколько вещей, да. Э там у нас есть контур разработки, какой-то сервер, э, у заказчика где-то есть какой-то сервер в там своём ЦОДЕ.
или какой-то свой сервер, или в облаке. Вот. И его надо настроить, да, установить туда все необходимые утилиты. И туда нужно как бы развернуть разово или организовать доставку на регулярной основе э всех изменений, которые мы делаем в тех или иных приложениях. И как бы вот эти все задачи, они относятся к такой сфере тамвопс или инфраструктура. И они достаточно сильно похожи, да, там на серверах используется операционная система Linux, да, там мы уже много лет там -э как бы понятно, существует контейнеризация и принято уже доставлять все приложения в контейнеризированном виде. А перед этим их надо там собрать и, возможно, настроить какие-то как бы CCD процессы. И это всё плюс-минус, на самом деле, во всех проектах одинаково с, ну, с небольшими, возможно, э там как бы адаптациями, да, там перечня приложений, э куда там они могут быть интегрированы, да, куда им могут быть предоставлены доступы, но, в общем, очень сильно похожи.
И, соответственно, здесь уже было понимание, да, что как бы не должно быть такого, что ты фактически каждый новый проект с чистого листа начинаешь. То есть уже существовало как бы чёткое понимание, что вот такие инструменты, как курсор, да, КДВН, они очень хорошо умеют работать. То есть понятно, что они всё это знают, да, но если ты там два раза попросишь решить одну и ту же задачу, они её могут решить как бы совершенно по-разному. Вот. И, ну, в нашем случае, конечно, э это нам не подходило, хотелось иметь какой-то повторяемый результат. И основа этой повторяемости помимо как бы системы - это наборы каких-то шаблонов, примеров, соглашений там или принципов, которые лежат в основе и которыми агент будет руководствоваться при решении задачи. И вот в этих проектах, по сути, для их реализации сначала мы подготовили там некий шаблон структуру, да, м, в которой были все основные решены задачи. И дальше каждый новый проект с точки зрения, да, всех этих развёртываний и сборок решали, э, путём адаптации этого шаблона для конкретной задачи. Ээ, то есть вот вот у меня шаблон там инфраструктурный, в нём вот эти вот эти вещи там решены с определённым набором технологий. Причём они могли включать там настройка сервера - это достаточно простая вещь. Вот. Но они могли включать также и автоматическое развёртывание, например, облачных серверов ээ с использованием, например, тираформа, да.
И как бы понятное дело, что в этой сфере она divвопс вообще это область и этот, не знаю, подход, методология, философия, может быть, она суперактивно развивалась там последние там лет 10. И в этой области появилось там огромное количество э- технологий, инструментов, каких-то там языков разметки. Вот просто это целый целый зоопарк для решения вот этого спектра задач. И особенность всей этой сферы э инженерной, да, что они крайне все эти инструменты, технологии, они крайне недружелюбны к конечному пользователю, да, это всегда какой-то очень сложный там синтаксис, jсоны, ямлы, какие-то конфигурации, которые ну вообще невозможно в принципе выучить, да, да, что говорить, даже настройка сервера и там как был скрипты баш, который лично я там с институтской скамьи ещё применяю. Вот я я там за 20 лет как бы не выучил, не могу вот так вот сесть и с нуля без подсказок, без копирования написать какой-то как бы среднестатистический скриптик. Вот. А, и вот это всё, это такие отягощающие обстоятельства, да, но современные языковые модели, они как бы со всеми этими историями суперлегко справляются, да, и используя вот такие как бы шаблоны, рекомендации, удаётся вот эти задачи, большой спектр инфраструктурных задач решать э очень как это надёжно. прогнозируемо, повторяемо, то есть от проекта к проекту.
И надо сказать, что -э вот вот эти задачи они как бы такие скажем, мм, оффлайн или асинхронные. То есть ты пошёл, сел, разобрался, там написал какой-то с агентом код, развернул, проверил на сервере и как бы ты никого не там тревожишь. нету реальных пользователей в этот момент, которые там, да, на которых это может повлиять, но в этот же, как это, пакет, не знаю, набор ээ задач, которые в этой области находятся, э мне приходилось и решать задачи, связанные с сопровождением, э, инфраструктуры для участников наших программ. То есть, в принципе, ээ аналогичная программа, о той, о которой сегодня в конце там расскажу, э, это вот такой для IT-компании ф к обучения, да, в котором большая часть финальная, да, инфраструктурная. И, конечно, слушателям, там, студентам курса нужно было предоставить там всю необходимую инфраструктуру, когда они на ней будут работать. То есть это там, не знаю, 20 или там 30 серверов, да, как-то преднастроенных. И в процессе, когда они будут все эти 30 человек, значит, одновременно заходить, э, неправильно вводить пароли, блокироваться и у них не будет работать SS или докер или ещё что-то, соответственно, их нужно в этот процесс сопровождать. И вот даже такую задачу с необходимостью быстрой реакции, да, быстрого разбирательства, что не так и как это исправить, э-э успешно выполнялась точно так же с использованием тех же самых подходов и инструментов из этой области. То есть никаких проблем с помощью кодового агента все эти задачи решать не э-э как бы не было. Вот.
И, э, собственно, это очень реально существенная область, инфраструктура, да, сервера и все вот эти инструменты, которые благодаря мм агентам, да, благодаря инструментам современным была также разблокирована. И по сути, ээ, вот эта вот цепочка, казалось бы, разрозненных проектов, да, как бы новый стек, первый проект, там PHP и какой-то там, э, HTML, да, фоном шли задачи и всякие проекты, связанные с искусственным интеллектом, с языковыми моделями, и они все, конечно же, на Питоне, да, инфраструктурная область И, э, это с точки зрения таких как бы скажем, это отдельных ролей, на самом деле в некотором прошлом, да, то есть этими задачами, как правило, занимались какие-то выделенные специалисты, но в моём случае приходилось эти задачи решать мне. И параллельно как бы в работе от проекта к проекту выстраивалась какая-то система ээ эффективного использования вот кодовых агентов и там больших языковых моделей и инструментов, которые это всё объединяют, типа курсора, да, и получилось, что вот ээ вот эти области и система, они так криста в какую-то такую новую роль -э автономного какого-то инженера, который может погрузиться и toнд решить фактически любую задачу, да, от там формулирования своих требований до развёртывания в любой сложности инфраструктуру, да? При том, что как бы ни в каких из этих областей у меня не было э какого-то ни промышленного, ни даже такого прикладного, где я там руками бы писал код опыта. То есть было широкий кругозор, общее как бы фундаментальное такое понимание вообще программной инженерии и опыт в этой сфере, да. но, э, там, последние годы без любых каких-то практических навыков.
И, мм, ну, и на тот момент, конечно, у нас уже ээ сформировался как бы определённый там определённое количество потоков наших программ, да, там для слушателей, как из компании, так и отдельных специалистов. И в целом, э, в применении в применении вот этих инструментов сформировалась такая как бы неправильное, что ли, представление. Вот мне нравится очень такая как бы противопоставление или метафора э некой магии, да, которую делают агенты или большие языковые модели, да, и как её противопоставление системности, да, то есть часто э вообще, когда речь заходит и о тех, кто просто на самом деле рассуждает и примерно там как бы размышляет о том, как могли бы решаться его задачи, с применением э искусного интеллекта существует ээ вот такое какое-то мнение заблуждение на самом деле, что существует некий магический промпт, да, и который вот идеально решит любую задачу или его конкретную задачу, да, или существует, э, и в определённый момент, да, повышенного интереса вообще к этой области появилось множество ресурсов, которые предоставляли возможность найти и использовать какой-то подходящий, огроменный там на три листа промт, который, значит, всё тебе хорошо сделает. Или, например, какая-то модель, которая вышла, она вот, значит, как бы убийца всех инструментов, идеальнее всех решает задачи, потому что она там по каким-то лидербордам или бенчмаркам набрала в каких-то, значит, проверках большие баллы, всех опередила. И вот она-то, если ей дать мою задачу, ээ, как угодно криво сформулированную, вот она выдаст результат потрясающий. Вот. И как бы, конечно, не надо ничего думать. Скормим или точнее скормим э свою задачу, свою проблему или вообще как бы поток своих мыслей лэмки, и она нам всё, значит, решит, сделает, выдаст и так далее. Ну и, конечно же, э вот эта вся история - это основа как бы любых разочарований, да, какого-то мм отсутствия веры в возможности, да, и тех, кто вообще пытается попробовать. И если первые какие-то результаты, да, его могут совершенно спокойно остановить, примерно как вот в моём случае в первом проекте, да, что э лэмки глупые, да, что они пишут плохой код, что это вообще плохой инструмент, он не работает и так далее.
И из моей практики, да, из этого набора проектов, про которые я рассказал, и те, которые там остались за кадром, на самом деле сформировалась абсолютно устойчивое как бы мнение, понимание, да, системности, которая в себя включает как бы ряд практик, которые позволяют давать на самом деле воспроизводимый результат. То есть от проекта к проекту, решая разные задачи в разных предметных областях, применение на самом деле, ээ, практик из, мм, классической разработки, да? То есть это практики, связанные там с правильной декомпозицией, да? Привет, первый проект, сделай всё. вот, э-э, м планированием, которое мы делаем в командах, написанием спецификации, как для людей, да, когда аналитик пишет спецификацию для разработчика и для тестировщика. Вот использование примеров, шаблонов, на самом деле, критериев, как для классического, э, тестирования, да, там приёмочные критерии любые, которые можно, а, задать языковой модель агенту для того, чтобы он сам мог себя проверить. Ну, и, конечно же, там как бы тотальное документирование принятых решений, не знаю, там как бы постановок и так далее. Ну и, естественно, уже хорошая практика, итерационный инкриментальный подход, когда ты там получаешь какой-то результат. То есть, в принципе, эта система, она, по большому счёту, как бы не отличается на самом деле от классической, только очень сильно компактизирован, да, потому что эту систему нужно применять не в команде и не как бы разнесённой по времени, а как бы самому очень быстро с агентом, э, ну, практически там мгновенно решая постепенно свои задачи И по сути вот эта система, она ээ стала основой вот ээ моего понимания какой-то новой роли, да, которую я вот так назвал ээ full cycle, э, и я разработчик, который с одной стороны благодаря языковомоделям агентам покрывают весь жизненный цикл, да, то есть э от анализа с там постановкой задачи, с системным анализом или проектированием, да, с разработкой и тестированием, в дальнейшем там развёртыванием и сопровождением, то есть весь жизненный цикл. При этом, на самом деле, внутри использую некую систему эффективной работы для агента, да, с там теми атрибутами или теми этапами, которые я уже перечислил.
Но надо сказать, что кодовые агенты, да, существенно удешевили ээ написание кода, да, его очень сильно ускорили, код вообще перестал быть, в принципе, узким местом, и сами же агенты ээ благодаря этому стали очень-очень быстро развиваться. То есть никогда за всю свою многолетнюю практику, да, в IT я не видел такого быстрого и точного, аэ, как роста зрелости инструмента, да? То есть интегрированность среды разработки, которой является курсор, она как бы оченьочень очень быстро развивается, да, в ней функции появляются новые, э, там, не знаю, ежедневно, в принципе. И такое развитие быстрое как бы инструментов и, на самом деле, языковых моделей, оно позволяет постоянно улучшать вот этот процесс работы. И вот отдельным пунктом я, в принципе, выделил, что надо уметь те возможности, какие эти инструменты предоставляют, эффективно использовать, да, и как бы фундаментом, в принципе, вот этой роли, да, и эффективного применения агентов является, конечно, понимание их как бы основы, да, что такое агент, какие у него возможности, какие у него ограничения, почему он так или иначе работает. в каких-то случаях, потому что даже те, кто используют уже инструменты, да, причём являясь, например, опытными разработчиками, они испытывают одинаковые затруднения в выстраивании вот таких системных повторяемых рабочих процессов, да, потому что они как бы не до конца понимают, как же всё-таки устроено и что влияет на вот такую предсказуемую работу с агентом. Поэтому вот этот база, не знаю, фундамент, понимание как бы просто концептуально каких-то принципов, которые в основе агентов лежат.
И по большому счёту вот все перечисленные и много других проектов, они выглядят одинаково, да? То есть, э, мы начинаем, э, всё с идеи, э, дальше по цепочке любые, э- как бы артефакты мы всегда фиксируем, да, начиная с идеи, и обязательно, э, всё итерационно планируем. Причём, на самом деле, ээ продукты, которые, э, создаются, мэторые используют большие языкомодели, это достаточно новая вообще сфера. Там появляется много новых инструментов, фреймворков, подходов, практик, каких-то задач и проблем, которые нужно решать. Поэтому практически любой продукт, э, и любая задача в вот в этой области, она, э, включает этап исследования. То есть когда ты какие-то как бы гипотезы там, какую использовать модель, будет ли она работать, как хорошо она будет давать результат, аэ ты как бы исследуешь. И вот этап исследования - это практически обязательная часть вот во всех ээ таких новых продуктах. И результат исследования - это, на самом деле, в том числе э вот такой пример, шаблон или как бы ссылка на реализацию, которую можно дальше использовать, ээ, когда ты уже будешь заворачивать всё в какой-то продукт, в архитектуру, в систему. Вот. И, ну, и дальше на самом деле классическая уже перечисленное, то есть задачу декомпозируем, пишем спецификацию, разбиваем на итерации. Часто итерации соответствуют ээ какой-то области из тех, которые мы там только что рассмотрели, да? То есть инфраструктурные задачи могут быть объединены в отдельную последовательность, да, как бы фронт отделён от бэкэнда. задачи, связанные с там, не знаю, языковыми моделями, с агентами, они тоже могут быть выделены и, вообще говоря, разрабатываться параллельно. И вот уже реализация с использованием кодовых агентов, она, конечно, должна идти с обязательным контролем. То есть ту неимоверную скорость, э-э, с которой кодовые агенты там пишут код, решают задачи, её побочный эффект - это необходимость, конечно, тотального контроля, да, потому что кажется, что э-э ну и вообще практически всегда есть ощущение, что там языковая модель написала код, он 100% рабочий, да, но надо очень сильно -э это проверять. И желательно, чтобы эти проверки стали э- возможными э-э как как самопроверки для агента. То есть надо выстраивать такие барьеры, в которых ээ агент сам себя сможет максимально эффективно проверить, да, какие-то там тестовые сценарии или как бы тесты - это отдельная, на самом деле, практика, которая, а, получила новую жизнь. То есть идея подхода тест дрин разработки, она э супердревняя. Э очень много в этом пользы, но э никто не умеет нормально эту практику применять, потому что, ну, человеку, разработчику, даже опытному это очень сильно тяжело, а агенту как бы нет. Поэтому вот старые идеи, они обретают новую жизнь с удвоенной ценностью, пользой вот в контексте применения таких инструментов.
Ну и понятное дело, что а-а документация вот ээ становится м дешёвой, да, и если раньше во всех, значит, процессах разработки -э существовало понимание, да, что любая документация, она мгновенно устревает, да, и там её надо поддерживать, и она устревает, на самом деле, в момент написания, то с агентами вот эта проблема Проблема, она с удвоеной силой, да, потому что одно дело, когда документацию написал человек, да, её как бы немного, а другое дело, когда у тебя языковая модель на любой чих сгенерирует тебе просто э как бы десятки документов, которые как бы ну часто никто не читает ээ вот как бы полноценно, да, не валидирует таким образом. Поэтому там тотальное документирование - это, с одной стороны и э большая польза, да, как передача знаний там самому себе, когда ты вернёшься к этому проекту или команде или агенту, но и типа ответственность её поддерживать. То есть это тоже зона, в которой можно и нужно стараться выстраивать какие-то вот процессы автоматизированные, да, поддержания этой документации в актуальном состоянии. Ну и всё, в общем, дальше как бы цепочка замыкается итерационно. Можно любые проекты любой сложности так развивать. Причём, э-э, как бы из моей практики, да, силами небольшой ээ команды или, вообще говоря, одного специалиста, да. Причём этот специалист это, ну, вот типа собирательный образ получается. И на самом деле это не какая-то как бы новая роль. А это огромное количество разных ролей или даже как бы уровней из привычной там IT-индустрии или смежных областей. То есть можно как бы отдельно пройтись и там рассмотреть. разработчики и в классической разработке без использования агентов основная задача, да, разработчика написать код, но а всегда существуют смежные области и даже как бы в индустрии существует понятие там T-шеape специалиста, когда разработчику надо, а, немного быть и системным аналитиком, да, там критически подумать над задачей, иногда даже же самому написать какую-то постановку или там расписать какой-то алгоритм, актуализировать документацию. Вот. Или, возможно, своё приложение, которое он сделал, запаковать для того, чтобы передать его там на какой-то стенд или доставить до продакшена, да, или в этом продакшене посмотреть, как оно вообще работает, и разобраться в проблемах. То есть получается к основной роли там много таких смежных областей, которые как бы ну в меньшей степени развиты. И как раз э вот максимальная ценность там для разработчика, она ээ возникает именно вот в этих смежных областях. Благодаря вот таким инструментам э и кодовым агентам, да, можно очень легко стать экспертом и решать задачи из вот этих смежных. И, наверное, вот разработчик - это роль, которая, э, с одной стороны получает ээ ценность и там сверх вообще скорость и сверхкачество, да, потому что есть большая экспертиза, понимание, как надо делать. И, соответственно, это помогает там быстрее, лучше, качест разрабатывать. Но с другой стороны, это, наверное, наименее такая -э роль, которая для которой создаётся прямо сдвиг какой-то парадигмы или вау эффект вот из тех примерно, про которые я на себе рассказал и прочувствовал, да.
И вот некоторые роли из перечисленных, например, да, это там системный аналитик, допустим, или продукт-менеджер, тоже айтишная роль. Основная задача которой была в том, чтобы собрать требования и зафиксировать их в каком-то документе, соответственно, там техническое задание или там как бы какой-то документ там с требованиями, со слова требования и дальше ждать, когда по цепочке команда сделает там прототип или рабочее решение для того, чтобы показать его заказчику. и там, не знаю, провалидировать гипотезу или там получить обратную связь, неважно. И вот кажется, что эта роль сейчас существенно поменяется и уже меняется, да, потому что эти специалисты, они, наверное, теперь их задача не документы какие-то, да, писать. С этим прекрасно лмка справится. А на самом деле, а-э, делать прототипы, макеты или создавать вообще продукты самостоятельно, да, потому что если ты понимаешь, что нужно пользователям, то как бы агенты позволят тебе всё это сделать. Вот. И, наверное, вот требования к этой роли, они существенно поменяются. И надо сказать, что, например, компании, которые находятся на стрие, какие-нибудь там, э, Open AI подразделения или, э, у антропик, которые занимаются там развитием продуктов, да, для разработчиков или в экосистеме разработчиков, вот те же самые кодовые агенты, да, там и разработчики, они как бы перестают писать код, становятся как бы немного такими архитекторами или, может быть, продуктами, и в то же время новые продукт-менеджеры, они как раз-таки этот код наоборот начинают писать, да, обзаводятся гитхабами, вот, и активно используют те же самые кодовы агенты для того, чтобы прототипировать или даже какие-то функции доставлять в продукт самостоятельно. Вот.
А понятное дело, что огромная ценность у всех на самом деле и за пределами IT у кого есть идеи, кто понимает боле какой-то ниши, да, кто у любого, наверное, есть какой-нибудь, значит, идея своего стартапа или какой-то там пылящийся пт-проект, под который нужно там, и это такая головная боль, что, чтобы его там реализовать, нужна команда, нужны деньги, как бы это всё сложно, непонятно, как это контролировать. И вот у всех этих людей у них возможность реализовать все свои идеи, боли, закрыть, как бы создать продукт, стартап, заработать на этом приложении миллион долларов, она становится возможным. То есть это, в принципе, вообще как бы сдвиг, а точнее это возможность приобщиться к созданию продуктов. ээ у тех людей, которые до этого момента такой возможности не имели. Вот. Ну и понятно, как бы вот я там яркий пример, о'кей, там техническое какое-то бэкграунд и образование профильное, да, позволили вернуться вот в такое ээ как-то в работу руками. Причём стать там сверхавтономным специалистом, да, который способен решать вообще любые задачи из любой отрасли, в любой теме разобраться, ну, даже которая относится там к какой-то специфике предметной области. И я тут отдельно отметил, на самом деле, начинающих специалистов. И это, наверное, там одна из самых холеварных тем, в принципе, в индустрии, там где-то в сообществе, в инфополе, вот в этой области. Все, конечно, там джунов хоронят. То есть они говорят, что начинающие специалисты, они, мол, не нужны, что любая модель, агент, они как бы лучше, вот лучше пишут код и там лучше что-то делают. Но а в нашей практике, и я в этом, в общем, тоже убеждён, что вот начинающий специалисты тоже яркий пример, да, у них нету опыта, но если ты готов там быстро учиться, быстро разбираться в каких-то вещах, то ты этот опыт э там гораздо быстрее чем это делали прошлые поколения, этот опыт получишь, да? То есть можно там учиться, делая какие-то проекты очень-очень быстро, можно промышленные. В нашей практике у нас в команде есть специалист начинающий, который, э, ну, там фантастическим образом прогрессирует благодаря как раз использованию э кодовых агентов, да, и вот он не только как бы в узкой своей специфике развивается, но и очень быстро захватывает все смежные области. То есть, в принципе, не страшно дать, э, там, как бы, инфраструктуру, разобраться и решить задачу начинающему специалисту. С ним не надо теперь нянчиться, да? Если раньше в IT-компаниях начинающий специалист, это была прямо такая инвестиция, то есть он в целом до момента, когда он будет приносить ценность, э, это пройдёт существенное время, ээ время, которое он потратит у более опытных коллег, которые будут ему передавать компетенции, знания и всё прочее. Вот сейчас всё это кажется уже избыточным, да, и там начинающий специалист, у него как бы большой потенциал для очень быстрого роста.
Э-э, и, э-э, как бы из, ээ, фактически вот нашего личного опыта, из тех проектов, которые мы делали достаточно разнообразных, да, а, выстроилась цельная система, которая стала, по сути, основой курса, который называется A Driven Fullstк разработка и который, э, по своей сути является вот таким объединением, да? То есть с одной стороны это фундамент а классической разработки программного обеспечения или там инженерии вообще, да, и э вот всех возможностей, которые дают такие инструменты, как кодовые агенты и большие языковые модели, и всякие интегрированные среды, э, типа курсора. И это, по сути, дорожная карта, э, последовательно выстроенной выстроенного пути для того, чтобы освоить ээ вот такой надёжный системный подход ээ для полноценного самостоятельного выпуска продукта, который начинается с базы, как я уже говорил, да, там понимания принципов работы больших языковых моделей и, на самом деле, возможностей и ограничений кодовых агентов, да, у которых модель - это лишь часть, да, и вторая часть это там различные инструменты и память. Ээ это основа, на самом деле, там всего дальнейшего пути, всех процессов. Э-э, очень важно понимать. Поэтому и на самом деле многообразие, да, то есть уверен, что каждый, кто там хоть как-то даже там краём глаза следит за этой сферой, слышал, да, что там этих кодовых агентов их уже там десятки всяких разных ээ консольных IDE, Spec Driven, агенты там для прототипирования и всё прочее. И понимание вообще экосистемы этих агентов это тоже основа для того, чтобы эффективно их потом в дальнейшем применять. Дальше классический как бы путь м разработки программного обеспечения по жизненному циклу, который на самом деле включает обязательные составляющие, да? Курсор как пример очень зрелого, бурно развивающего кодового агента. Да, его возможности, конечно же, там я абсолютно убеждён, что надо знать и эффективно применять. И дальше жизненный цикл, он включает любого, на самом деле, продукта, который, а, как бы не ээ не носит какой-то ярлык прототипа, да, который можно сделать как угодно, примерно как вот Сергей сделал сейчас быстренько анализ заявок регистрации на этот вебинар, да, то есть это можно назвать прототипом, быстренько показать, но это не то же самое, что создадать продукт, развернуть и отдать конечному пользователю и не бояться, что он упадёт или в нём будут ошибки или там ещё, не дай бог агент его там, не знаю, вместе с базой данных не удалит. И дальше, соответственно, жизненный цикл включает системный анализ, да, то есть это проектирование там архитектуры, проектирование э каких-то интеграций, взаимодействий, ээ пользовательского опыта, там интерфейсов, то есть всё, что, э, там выбор технологического стека, выбор инструментов и так далее. Плюс в самом начале важно это планирование разработки. Ну и здесь тоже как бы классно помогают агенты всё декомпозировать, эффективно распараллелить. Благо современные инструменты, они как бы уже, э, их основное назначение как раз-таки параллельная как бы работа разных агентов, да, над решением задачи для там максимальной эффективности, скорости. Э, после системного анализа обязательная часть и практически любое приложение, даже самый простой, на самом деле, чатбот, э, обязательно включает в серверную часть. То есть это разработка бэкэнда, это проектирование какого-то API, да, интерфейса для программного взаимодействия и дальнейшая там интеграция будь то с каким-то клиентом в виде бота, будь то там, не знаю, фронтENД или просто интеграция в какие-то системы. После этого обязательная часть, конечно же, любой системы это система хранения, да, то есть проектирование базы данных, выбор, вообще говоря, подходящий э подходящего инструмента под задачу, потому что база данных могут быть там реляционного типа, документоориентированны или вот для приложения которые относятся там категории каких-то ассистентов, агентов и там, не знаю, семантического поиска. Часто последнее время применяются векторные базы данных. Вот это тоже неотъемлемая часть любой системы. А, и как бы, конечно же, фронтEN. Все мы взаимодействуем с приложением через какие-то, э, формы, вот, через какие-то инструменты. Мы научимся как бы грамотно, эффективно создавать красивые, да, интерактивные приложения. Важный аспект в этом процессе ещё один, э, это, на самом деле, как бы погружение в новые, э, кодовые базы или, например, старые, да, это называется legacy. Но аси или старой кодовой базой или старым проектом можно назвать любой проект, к которому вы вернётесь. Даже ваш собственный, вы вернётесь спустя какое-то время, даже не продолжительное, да, вам придётся в него обратно погрузиться, какой-то восстановить контекст, вспомнить, как там всё работает. И, ну, неотъемлемая часть вот процессов, которые так сгруппированы, да, такого онбординга или там погружения, это как бы документирование, как правильно, а, на протяжении там всего жизненного цикла те или иные решения, принимаемые, фиксировать, да, для того, чтобы было потом полезно и самому, или, э-э, команде, да, там, специалистам, если вы работаете не в одиночку, закрываете весь жизненный цикл и или агенту Да. То есть документация - это основа работы с агентом, конечно же. Вот. И грамотное управление контекстом. И финальная часть создания любого продукта - это все задачи, связанные с инфраструктурой, серверами, развёртыванием. Они включают в себя задачи по как бы упаковке приложений, да. И вот, в принципе, приложение или система, которая состоит из бэкэнда, из фронтэнда, из базы данных, в принципе, можно назвать микросервисной, как бы запросто. И получается там контейнеризация, настройка, э, вот таких микросервисных систем. Это как бы первый шаг, да, там использование докер, вот для того, чтобы можно было куда-то развернуть, на самом деле, куда угодно. И дальше, если у вас активная заработка самостоятельная, э, или командная, тем более это процессы CICD, да, непрерывной интеграции, то есть сборки, например, проверки качества, проверки на безопасность. И это как раз та область автоматизации, в которой, а, можно существенно улучшить качество, да, не обладая там какими-то глубокими экспертными знаниями в каждой области. То есть можно благодаря вот таким автоматизированным процессам проверять, а там, я не знаю, качество кода, э, код на какие-то потенциальные угрозы безопасности на использование лучших практик там и, ну, и прочие вещи. и дальнейшая доставка куда-то, да, то есть это развёртывание на какой-то удалённый сервер, включая его настройку, или на какой-то облачный хостинг. И дальнейшее, на самом деле, уже промышленное э использование, оно включает ээ так называемые процессы а наблюдаемости или мониторинга, да? То есть нужно смотреть как ваше приложение, возможно, потребляет ресурсы, как, э, оно работает, нет ли где-то ошибок, да, то есть смотреть, наблюдать за метриками, наблюдать за логами, да, для того, чтобы можно было как-то реагировать на там инциденты или на нагрузку, возможно, и там масштабировать. И по сути это как бы последний шаг уже там эксплуатации вполне себе промышленных систем, а которые доступны, повторюсь, в маленькой команде или даже э отдельному специалисту, да.
В общем, на личном примере, м, надеюсь, я вам показал, что в одиночку можно стать сверхавтономным, да, делать всё, что может прийти вам в голову в качестве идеи, да, для стартапа или просто какой-то личной автоматизации или, может быть, в качестве хобби, я не знаю. Ну и, конечно же, там сверхпотенциал для применения там в любых процессах, для любых ролей, вот, и уж тем более для как бы тех людей, которые хотят э как бы оседлать эту волну, новую роль быстрее всех освоить. Вот страничка Driven Fullstк разработка. А где у нас там старт? 17 марта э будет 10 занятий растянутся примерно на полтора месяца, будут проходить онлайн, как бы, и на протяжении всего этого времени мы будем последовательно создавать и развивать сквозной, э, продукт проект, да, в основе которого обязательно будет лежать аа большая языковая модель. Вот. И тем самым мы научимся создавать такие продукты помимо освоения вот этого полного жизненного цикла с применением кодовых агентов. И, э, как, ээ, из роудмапа, да, основы, э, языковых моделей, вот, всяких разных кодовых, э, инструментов, э, bolt, lovable, реплиты для прототипирования, клоды, кодексы, варпы для консоли. Вот. Ну и вообще как бы фундаментальное понимание всей экосистемы инструментов. А, соответственно, осваиваем курсор на примере самого простенького и учимся создавать ботов, да, как первый инструмент, ээ, который станет сразу же там основой ассистентом и дальше будем учиться проектировать, ээ, ээ, формулировать требования, декомпозировать, планировать разработку, там, проектировать архитектуру. выбирать технологический стек, проектировать всякие связи, модели данных, э, обязательно на этом этапе документировать принятые решения с использованием практики р. Вот, конечно, использовать все способы визуализации, которые очень удобно как раз-таки на этом этапе делать с применением Mirmate, и агенты это делают очень как бы здорово. А разработка Кэн, э, тут всё понятно, просто научимся грамотно с агентами качественно разрабатывать. а применять, возможно, какие-то практики по рефакторингу. Разберёмся с проектированием баз данных, да, с выбором подходящей СУБД, да, и с проектированием модели, да, связей. А, конечно же, будем применять какие-то ОRM фреймворки для того, чтобы не писать там много кода. А фронт разработки идёт отдельной темой. Тоже здесь аналогичным образом, как с бэкэндом разберёмся, какой лучше стек, как выбирать, как, вообще говоря, использовать агенты эффективно, да, для того, чтобы делать интерфейсы. Именно здесь тоже очень много всяких разных практик, да, начиная от тех, которые про которые я даже рассказал, да, давать просто картиночку, как нам нравится, и много ещё чего другого. А вот про онбординг я сказал, документирование, как в новые там какие-то проекты погружаться, в них разбираться, знакомиться, возможно, там с целями обучения и три занятия из области инфраструктуры, да. А, и, кстати, автоматизация - это небольшая часть создания там йк-файлов и всяких командочек, которые позволяют тамму простить всякие как бы сложные планы запусков. Разберёмся с докером, разберёмся с интеграцией и развёртыванием, с применением GitHub Actions. Очень удобно. И последнее - это уже для как бы тех, кто серьёзно настроен решительно запускать свой продукт, э, о том, как эксплуатировать ээ его надёжно, вот следить и не бояться отдавать конечным пользователям. Здесь же можно, в принципе, ознакомиться с отзывами участников, которые проходили аналогичные программы, но не публичные, да, из корпоративной среды. Я там упоминал, то есть эти компания и в общем вдохновиться и записаться, пока действует ещё хорошая цена. Вот теперь точно всё. А спасибо.