Transcription
Юрий нам расскажет о том, как нам жить вот с этим вот всем изобретённым и как это мы можем вообще использовать в нашей жизни, в работе, скорее всего. Поэтому прошу внимания, слушаем.
А, всем привет. А, да, меня зовут Юра. Я занимаюсь более 20 лет уже разработкой программного обеспечения коммерческого. Из них более 10 лет я занимаюсь архитектурой. И, собственно говоря, в архитектуре помимо, ну, кучи нефункциональных требований, про которые обычно все знают, есть ещё такое требование, как эффективность работы команды разработки. То есть архитектура должна быть эффективной с точки зрения производства.
А, и вот именно сюда приходит искусственный интеллект и говорит: "А я могу быстрее, но только ты должен под меня адаптировать твои архитектурные процессы". И если это не сделаешь ты, то это сделают твои конкуренты.
А, ну, соответственно, как нам с этим жить? Мы, на самом деле, очень динамично сейчас развиваемся в этом плане, потому что ещё в двадцать втором году, это, кстати, единственная картинка, на которой мне удалось убедить искусственный интеллект нарисовать негров. Вот. А всё-таки в Египте исторически, да, так сложилось. А вот, ну, тогда это действительно был клинкод. Это были микросервисы и независимые команды небольшие, которые клепали каждый в своём контексте. И архитектора тогда звали, когда эти команды уже не могли сами интегрироваться между собой. А и архитектор очень часто начинал просто копить артефактную базу и какое-то время даже тормозил этот процесс. Поэтому архитектора старались назвать до последнего. Архитектура - это дорого очень.
Потом пришёл, собственно, GitHub Copilot. Он пришёл ещё в двадцать первом году, но в двадцать третьем его заметили, потому что размер LLM как раз дорос до того, чтобы какое-то какие-то осознанные куски программного кода начали пролезать в его контекст, и он начал выдавать код, который вроде работает, и все кинулись этот код постить в GitHub, в результате чего начали фиксировать резкое падение качества программного кода в в Гитхабе. А вот, а, собственно, это встречало и сопротивление у организации, потому что и секреты улетают, никто не был готов к тому, что программный код начнёт транслироваться куда-то там за океан для обработки. А эти токены потом всякие секреты начинали всплывать в контексте других команд. А, и в общем пошла блокировка этого всего.
А, но к двадцать четвёртому году ситуация изменилась. А-а, Cursor начал доминировать на рынке, он тоже появился раньше, но в двадцать четвёртом начали в его контекст парализовать целые проекты. И его подход, что я весь проект по всему комплекту описаний, а, модифицирую, он наконец-то тоже начал работать. И тогда, в общем-то, даже организациям стало очевидно, что, о'кей, мы можем сколько угодно от этого отказываться, но это эффективно, нас просто сожрут конкуренты. И первые подписки шли и корпоративные. Даже вот я наблюдал не на GitHub Copilot, а именно на Cursor.
Ну, и, собственно говоря, э то, куда мы сейчас приехали, а это вполне возможно на сегодняшний день и вполне возможно завтра придётся дорисовывать ещё какие-то слайды здесь, потому что очень быстро развивается эта индустрия. Буквально там есть вещи, которые я адресовал на последней неделе. А это, собственно говоря, мы пришли от агентов к фабрикам. А то есть тот самый bottleneck в виде human in the loop. Мы пытаемся покинуть этот loop. Мы пытаемся посмотреть, как далеко нейронка может справиться без нас, а при этом, разумеется, отвечая нашим целям. И в результате у нас смещается акцент у разработчиков с того, что он работает с программным кодом, на то, что он ставит цели, ставит ограничения. То есть, фактически, он начинает выполнять работу архитектора, тогда как архитекторы тоже смещаются от того, что они раньше ставили как раз эти цели ограничения к тому, что они теперь выстраивают архитектурные процессы по накоплению этих целей ограничений и по контролю контекста нейронок, чтобы, соответственно, нейронки продолжали долго быть эффективными на больших проектах и чтобы у нас не накапливалась энтропия.
А, вот, собственно говоря, простой старый жизненный цикл продукта, да? То есть у нас есть там какой-то там маркетинг там, OPS условный. Оттуда поступают идеи, хотелки к продакт-менеджеру. Он из этого делает бэклог. Из бэклога девтим подхватывает артефакты, выдают что-то, что работает у них. Дальше QA и UAT проверяют, что это действительно там работает и можно пользоваться. Вот. И DevOps скатывают это и отдают на следующий цикл обучения за фидбэком. Вот. Ну, и, соответственно, старые инструментарии довольно, наверное, всем знакомые. А, в общем-то, от них особенно никуда не денешься. Аа не очень здорово, потому что буквально каждый шаг здесь делается руками. Максимум - это docs as code. Кто-то автоматизировал. Ну, мы вот автоматизировали в первую очередь.
Значит, что меняется в старом цикле? Что фактически поменялось. А у нас теперь есть репозиторий продукта, в котором, собственно говоря, держится вся документация. А у нас есть с одной стороны customer operations докидывают какие-то фичи. С другой стороны, Product Owner формирует из них план и тоже докидывает сюда. А с третьей стороны у нас DEFTM докидывают некоторые ограничения, то есть фактически архитектурные задачи тоже докидывают сюда. А после чего нейронка пробует это всё дело переварить, и если у неё это получается, то ещё вот есть QA UAT. Это в последнее время начали мы делать в командах, чтобы нейронка не сама придумывала тесты. Вот это тоже вариант её ограничения такого. И, собственно говоря, DevOps тоже теперь не руками развёртывает, а тоже докидывает сюда требования к процессу развёртывания. В результате здесь образуется такой компот из фич, адрников, планов тестирования и ограничений и планов развёртывания. Вот. А у такого проекта есть одна проблема. У него контекст - это, собственно говоря, весь репозиторий продукта. А, и контекст меньше сделать не получится, особенно на этапе программирования уже, потому что на этапе имплементации надо учитывать и то, что надо протестировать, и то, что требуется по фичам, и то, что требуется по ограничениям, и чтобы это ещё и в коде работало. Вот. А поэтому, собственно, вот по этому старому принципу команды упираются в вот этот размер контекста, и приходится переходить к более сложному процессу. Мы сейчас этот кризис роста уже достигли.
А, вот такая вот страшная картинка. А я вижу улыбки в зале. Кому-то знакомо, что это такое? Значит, это более полный архитектурный цикл, называется TOGAF. А, соответственно, а у него есть также более подробный жизненный цикл. И у него также есть такая дружественная нотация, ArchiMate называется, которая, ну, собственно говоря, кто работал с UML, да, нечто похожее. То есть мы представляем всю архитектуру проекта в виде вот таких вот блочков и связи между ними. А в эпоху, собственно, это заиграло неожиданно новыми красками, потому что вообще у TOGAF есть всего один минус. Он очень тяжёлый, он работает только в очень больших компаниях, в которых действительно продукту никак не может пролезть в голову отдельно взятого человека. И поэтому, собственно, он адаптирован под то, что человек человека больше не видит. Человек теперь видит вот эту вот базу архитектурных артефактов. И, собственно, в этой базе архитектурных артефактов выполняет какие-то свои локальные задачи, которые, будучи влитыми в общий репозиторий, внезапно срастаются. Они срастаются именно потому, что есть вот этот вот общий архитектурный проект.
А, собственно говоря, в LLM это заиграло новыми красками. А как это было устроено раньше? Да, страшная картинка, но, э, на самом деле она гораздо более дружественная. LLM. Тут надо думать немножечко, как нейронка. А суть заключается в том, что внутри этого процесса есть строго поделенные не только роли, но также мы знаем, кто откуда читает и кто куда пишет. И таким образом у нас перестаёт контекстом быть весь проект. Мы как минимум можем по своей роли срезать ту часть репозитория, которая нам нужна. А, и это нам позволяет модифицировать этот процесс ещё в более страшную диаграмму, когда у нас вместо людей, а, собственно говоря, приходят скилы и приходят, а, взаимодействие с этой системой через агента. То есть у нас больше нету рисовалки диаграммок. У нас теперь есть агент, через которого мы заполняем эту базу, формируем эту базу артефактов. И в итоге у нас появляются дополнительные инструменты, а, такие как требования как реестр, а метрики тоже как показатели, архитектурный проект в виде docs as code, но его можно загрузить в базу и проиндексировать, что важно. А, и у нас появляются, собственно говоря, дополнительные средства, как LLM-вики, LL-graph для индексации и ArchiMate Viewpoint в качестве системы ограничения контекста. И вот тут вот, ну, если кто-то работал даже с ArchiMate, то с Viewpoint работали прямо вот явно не все. У ArchiMate вообще есть два забытых, очень важных уровня. Это стратегия и Viewpoints. Вот почему-то все рисуют только вот бизнес, архитектура, информационные системы, Technology, а всё остальное как будто бы. А, вот всё остальное - это как раз то, где нейронки начинают очень сильно бенефицировать. Поэтому даже те, кто осваивал TOGAF и ArchiMate, очень рекомендую освоить их снова вот уже в этом новом ракурсе. И мы таким образом получаем, что вот эта вот метрика хаоса, она в какой-то момент выходит на плато, а просто потому, что у нас есть вот этот самый граф знаний явно, который можно проаудировать человеком и явно выделить, э, где нейронка права, где нейронка не права.
Кроме того, а тут есть некоторые такие выкладки по поводу того, вообще, что с Harness происходит в данный момент. Его очевидные плюсы - это полная автономность, это возможность выбирать разные нейронки под разные задачи, в отличие от простого агента, который куда подключен или там забыл переключиться, потратил все токены на самую дорогую. Вот. И, а, возможность автономной настройки скилов. Э то есть как бы эта нейронка может какое-то время действовать без вас. И, ну, например, у Harness есть, э, прям, а, отдельный этап, когда он проделал какую-то работу, после чего она аудирует, где у него были лишние, как ему кажется, частые этапы reasoning, и он сразу прописывает скилов, которые этот reasoning захватывает целиком. А вот, но есть вот минусы, соответственно, это они потребляют много токенов, то есть они готовы решать твою задачу до буквально последнего токена, пока не получится. А, а если долго не получается, то они такие, они за ваши токены готовы работать хоть днём и ночью. А, и второе - они могут повредить среду. То есть тут штука такая, что когда мы работаем с обычным агентом, то обычно он у нас спрашивает: "А можно в этот файлик слазить? А можно в тот файлик слазить?" Ну, вне проекта Git, вне контекста по умолчанию. А эти ребята спросить не могут, они автономные, они просто лезут туда, куда им надо. И иногда это реестр, иногда это секреты, иногда это ещё что-нибудь. Вот. И в частности модифицируют. То есть если у них что-то не работает и им кажется, что виновата в этом операционная система, то они операционную систему тоже пробуют починить. Вот.
А, решения, собственно говоря, простые. Это мы пытаемся изолировать среды. То есть мы используем либо sandbox там на WSL какие-то, у Linux тоже используем изоляцию, либо используем просто devcontainers. Сейчас devcontainers довольно хорошо развиты, и прелесть в том, что под каждого агента можно конкретно его среду собрать, в которой его скилы и инфраструктура, среда окружения будут отвечать друг другу. Вот. И второе - это использовать дешёвые или даже бесплатные, а, нейронки для рутинных задач. То есть тут как раз прелесть, э, вот где вот эта картинка перестаёт быть страшной, начинает быть красивой именно в том, что вот эта куча операций, они очень маленькие. И, а, у меня буквально часть операции выполняет просто локально катающийся Gwen Similarity. Вот. То есть он прямо бесплатный. А, и, собственно, здесь я призываю слазить на сайт. В списке литературы будет ссылка, а, который, собственно говоря, позволяет посмотреть, какие вообще сейчас бенчмарки по нейронкам. Вот этот бенчмарк появился буквально на этой неделе, а, его проиндексировали. То есть до этого я я бы вам рассказывал ещё неделю назад, что, ребят, давайте дорогие нейронки использовать только для того, чтобы осознавать предметные области, потому что мы хотим пользоваться тем корпусом знаний, которые у них есть. А вот, но появилась нейронка, которая тоже это хорошо знает и при этом стоит в несколько раз дешевле.
Аа, далее то же самое про код. Она оказалась хороша в коде. До этого здесь был только DeepSeek. А, то есть тоже можно заменить, когда у нас уже есть полный архитектурный проект и когда нам чётко известно каждую единицу кода в какой компонент класть, как interaction проходит, какие у нас граничные условия, то, в принципе, DeepSeek очень хорошо всё это дело делает. А на самом деле первое, что я закодировал DeepSeek'ом, это тоже был локальный DeepSeek, и он мне сделал NFT для Solana на Rust. Вот за выходные выучил Rust и сделал на нём смарт-контракт. Вот. А, ну самое главное - это описать, как он должен себя вести. Чем точнее вы опишите граничные условия, тем лучше он их сделает.
А, далее аджентик поведения всё равно нужен, потому что мы всё равно хотим как бы в этот loop иногда вклиниваться. Вот. И здесь тоже опять же DeepSeek себя как аджентик хорошо показывает. И вышла ещё новая нейронка Minx. Довольно дешёвая. Вот, можно пробовать её подключать к OpenCode тому же самому, и вперёд, в общем-то.
А, и, собственно говоря, ещё одна штука - это многоязычность. А у нас сегодня доклад на русском языке, но на самом деле с нейронками лучше общаться на английском. Это экономит приблизительно 40% токенов просто за то, что они читают на языке, который токен-оптимизирован очень сильно. А, поэтому мы делаем такие штуки. Если в команде есть кто-то, кто не разговаривает на английском достаточно хорошо, чтобы быстро отсматривать документацию, то мы просто пишем MD: "Чел, у тебя единственный источник правды - это документация на английском языке, но каждую статью ты должен дублировать на русском". Вот у нас есть такой опыт. И при этом дублировали эти люди общались с нейронками на русском языке. Она всё это дело документировала на английском, программировала. Это всё равно всё работало. И кодинговые нейронки, поскольку мы хотим, чтобы они были тупые, хотя здесь умные, но возможно можно ещё сэкономить на их, а, дальнейшем поглупении, но обычно кодинговые нейронки гораздо лучше пишут, если на английском всё написано.
Вот. Ну, собственно говоря, что у нас меняется, да? То есть, э, если раньше архитектурный процесс это был про то, что мы говорим, какие есть артефакты, как устроено CI/CD, какие стандарты кодирования и так далее, то теперь мы говорим, что мы наполняем базу скилов. А, то есть мы делаем так, чтобы нейронки работали за нас, но мы им, соответственно, даём какие-то примеры, мы им выстраиваем ограничения, мы им формируем скилы, чтобы они правильно захватывали контексты. А мы настраиваем агента, чтобы они работали без нас, с нашим минимальным участием. И мы также, а, делаем, формируем вот эту вот базу знаний общую, чтобы нейронке было удобно ей пользоваться.
А, вот, э, ну, и, соответственно, что теперь архитектор делает? Архитектор теперь как раз-таки делает, он проектирует саму базу знаний, э, на которой дальше нейронки автоматизированно работают. Это новая роль архитектора.
Немножко что почитать. А, значит, если у вас менеджмент всё ещё против ИИ, я не знаю, такие сейчас есть или нет. Сейчас скорее менеджмент приходит к пониманию, что ИИ революция уже совершилась и надо запрыгивать в последний вагон. А, вот, но тем не менее есть некоторый обзор, потому что вообще плохого наделали нейронки с качеством программных продуктов. А хорошо помогает аргументировать, как как с этим справляться.
А что? Опа. Ну всё, всё, всего хорошего. Нененен, не не стоп. Ну крестик у меня. У меня нету крестиков. У кого мышка есть, можно? Это последний слайд, но я не закончил его читать. [смех] Вот. А, значит, вот этот TOGAF туториал, очень рекомендую его посмотреть, а что делается на разных этапах, чтобы вы понимали, как формируется этот процесс. А и для ArchiMate, даже если кто-то работал, это ссылка отдельно прямо на Viewpoints. И я очень рекомендую посмотреть по Viewpoints, потому что они позволяют очень хорошо контролировать размер контекстного окна. И там вместо 10 миллионов, да, сейчас уже там есть рекордсмены, они вполне позволяют оставаться в 200.000 и позволяют удерживаться в подписках типа Copilot Business за 21 долларов в месяц. Вот. И здесь ещё выложен TOGAF Ali. А-а, значит, это описание архитектурного процесса для TOGAF именно как ну, с чего начать строить базу. Поэтому качайте себе этот preliminary. Э ээ и пробуйте, собственно, перевести ваш продукт на этот процесс. Посмотрите, какие артефакты он вам, э, предложит. Спасибо.
Раз- раз. Слышно хорошо. Так, я надеюсь, всем нравится, да? А то я вам Ладно, хорошо. Вопросы? Руки. Руки есть? Так, спасибо за доклад. Особенно интересно понравилось про Hermes. И я, наверное, несколько вопросов задам, а немножко дополню минусы Hermes. Из живой практики на этой неделе я его уболтал взломать свои конфиги и добавить меня админом, просто общаясь с ним. Вот. Да-да. Да. Могут повредить среду файлы, конфиги. А изолированная среда? Нет, он был продакшнский, он использовался для работы с документацией, ни с кодом, ничего. Но и, собственно говоря, я к тому, что работая с такими агентами, вопросы их доступов почему-то никогда нигде не озвучиваются. Их просто добавляют, дают им хорошо в изолированной среде, но он будет работать с документацией, с каким-то куском кода. Но при этом сами конфиги, я нигде просто много видео смотрю про работу с агентами и то, что запрет им менять свои настройки, почему-то никто из спикеров никогда не говорит. Почему?
>> Как мы выходим из этого положения? Собственно говоря, сам по себе Hermes, ожидать от него, что он самого себя ограничит, нельзя. А, к сожалению, любые ограничения по безопасности могут быть только внутри того тулинга, который, собственно говоря, находится вне контроля Hermes. А, и в этой ситуации мы просто говорим: "О'кей, чел, ты можешь это дело записать сюда". Но это proposal. Это proposal. И ты дальше, да, ты этим proposal'ом можешь далеко уйти, ты можешь сделать pull request, но всё равно должен быть в какой-то момент человек, который его смотрит. Другое дело, что этот человек может, например, просто согласиться с уже готовым работающим результатом и какие архитектурные артефакты к нему привели. Ну, как бы потом посмотрим, потом уберёмся.
>> Понятно. Всё ходится на человека и на потом. [смех]
>> Вся архитектура, да, про то, чтобы откладывать все важные решения на потом.
>> Спасибо.
>> Так, вот ещё вопрос.
>> Давайте. А скажите, пожалуйста, вы какие системы разрабатываете?
>> Банковскую и CRM.
>> А, спасибо за доклад.
>> У меня такой вопрос, на самом-то деле, про человека. Вот это прекрасная диаграмма. А в какой момент тут возникает человек, чтобы подправить субагента, если он там зашёл куда-то далеко или просто закрутился в loop?
>> А в любой человек может с любым этим субагентом поговорить.
>> У него есть связь.
>> Ну, конечно, это всё репозиторий, это всё MCP-сервер. Туда весь этот тулинг доступен там и в OpenCode, и Hermes'у, пожалуйста. А можно, то есть это же всё база артефактов. И да, тут прелесть заключается в том, что это не внутренний контекст. И вообще, в принципе, даже в предыдущем докладе я не знаю там, насколько это было понятно или нет, но дело в том, что контекст, вообще говоря, находится вне самой нейронки. Он внешний по отношению к ней. И поэтому, собственно, вот этот вот сам проект, как контекст, а его можно менять совершенно независимо, без нейронки. Хотите, хоть руками подковыряете. Другое дело, что это не нужно, потому что, а, вот почему есть сейчас у нейронок такая метрика, как мозг. Вот эти вот умные нейронки мы хотим использовать ровно для того, чтобы формировать этот контекст с их помощью, потому что они хорошо знают предметные области, они могут хорошо предупредить. Вот вы там нервно посмеялись насчёт банковской системы, а вы знаете, сколько тестов они предлагают по этой банковской системе? Какие кейсы они предлагают протестировать им? Да. После этого мы мы формируем эту базу тестирования, мы формируем вместе с ними Case coverage, и они бегут делать эти тесткейсы. Они делают полностью evidence, а того, что-то реализовано, работает и работает правильно, будет работать завтра. Послезавтра тоже.
Раз. Раз. А можно ли вернуть на слайд с вот этой всей большой большим графом?
>> Да? То есть можно ли сказать, что у нас это в некотором роде GitOps? То есть мы собираем все метрики в одну штуку куда-то в репозиторий, а из него уже потом как источник правды агенты сами там.
>> Эта штука начинается с Git действительно. И, ну, собственно говоря, а вообще такую штуку никто не строит сразу, да? Начинают всё-таки вот с этого простого. И вот у вас в какой-то момент есть репозиторий, в котором есть доксы с тремя папочками. Это фича и тесткейсы. И дальше вы просто говорите: "О'кей, я закачиваю вот этот вот preliminary вот этой вот сложной штуки суровой, и говорю просто: "А теперь разложи мне вот эти вот три папочки на этапы работы TOGAF". И он это, в принципе, делает. Ну, то есть это делает GPT-4 через OpenAI, например, легко. А, соответственно, дальше следующий этап - это когда вы съезжаете с просто Git'а. Потому что просто Git всё равно требует себя как-то проиндексировать. И вы дальше начинаете выстраивать графовые базы, вы начинаете выстраивать LLM-вики поверх этого всего дела. А причём графы тут нужны потому что, собственно, вот здесь хоть мы и с диаграмм переезжаем на статьи в Markdown, но это всё равно связанные между собой элементы. То есть там внутри Markdown, если почитаете preliminary, там прямо сказано отдельно relationships. Relationships, который прямо перечисляет ArchiMate-овые отношения данного элемента с остальными элементами. То есть мы оставили метамодели ArchiMate, мы просто избавились от диаграмм, потому что больше не человек их рисует, а LLM пишет. Она с Markdown'ами лучше работает.
>> О'кей. Ещё вопросы есть? У меня сейчас, Ладно, вы поздно среагировали. У меня тогда ещё вопросик короткий. Роняли ли вам ваши агенты Production и какие вообще факапы у вас были?
А, нет, до этого не доходило, потому что, ну, они могут уронить QA, они могут, а, не протестироваться. Плюс к этому у нас динамические среды есть. А вот, ну, динамическая среда может упасть, потому что туда мы ставимся без тестирования иногда. То есть у нас есть, да, такая штука, что все тесты не прошли, но нам надо протестировать какую-то отдельную фичу, поэтому мы едем на динамическую среду без полного тестирования.
>> Понял, спасибо. Так, у нас раз два вопроса.
>> Да, привет. Одна из вещей, которые мне интересно, как изменилась коммуникация, как раз благодаря тому, что есть гипотеза, что часть коммуникации можно передать на скилы. То есть, в частности, как разработчикам соблюдать, коммуницировать вообще о том, что для нас какие-то нефункциональные требования важны, и как это конкретно в коде.
>> Значит, самое интересное, что самое большое сопротивление вся эта штука вызывает именно среди разработчиков, потому что разработчики привыкли решать все свои проблемы через код. Все остальные смотрят на это, на всё дело гораздо веселее в том плане, что коммуникация с людьми теперь больше не нужна. Достаточно просто, чтобы люди просыпались по утрам и садились за компьютер и что-то там начинали генерить. А, ну, и, соответственно, поскольку проиндексировать это всё дело позволяет весь проект целиком, то теперь можно просто взять, задать вопрос и получить ответ, где такая-то фича реализована, как она реализована и какие неожиданные места там есть. То есть мы видим, что LLM находит какие-то косяки внутри там SQL или скриптов системы 20 лет. Там есть legacy код, и она в нём разбирается гораздо лучше, чем мы.
А кто тогда выигрыши, экстраверты или интроверты? Я так и не понял.
>> Ну, ну тут, мне кажется, выигрыши все, потому что дело в том, что для экстравертов здесь тоже есть одна интересная мета, поскольку эта штука в качестве proposal'а может пробежаться и проектировать вот эту всю штуку. Она же может и сказать примерно какова сложность решения задачи.
Ну вот, кстати, вопрос есть связанный. А если системе 20 лет, у нас огромная база знаний, вики концепты устаревают, какая подсистема отвечает за поиск вот этих порванных связей, там каким образом старые архитектурные решения отслеживаются, как это, как это сделано на практике.
Есть специальный этап implementation governance, который отвечает ровно за то, чтобы был evidence на реализацию каждого компонента. И плюс к этому опять же скачайте preliminary, там сказано у каждого Markdown'а прямо рядышком с relationships evidence в source code должно быть указаны имя, файлы и строки, в котором этот элемент по утверждению системы реализован. Он, конечно, наверное, не на 100% правда, но лжи в нём гораздо меньше, чем у людей. Базовый цикл знаний. Этот цикл получается? А самое интересное, что кодовая база от этого уменьшается, потому что самая большая проблема legacy проекта - это код, который стрёмно было удалять.
Последний вопрос.
>> А, да, спасибо. Я даже встану. А мы тут говорим про разработчиков, про то, что мы все понимаем, что это надо делать. Я расскажу другую штуку. Вот я руководитель и инженер с опытом. И я со своим опытом и с ChatGPT разработал процесс. Я неделю думал, придумал сложную систему, нарисовал это в Confluence и пошёл продавать это главному там условно руководителю какому-то. Он не понимает в этом ничего. Вот он смотрел, смотрел час слушал и говорит потом в конце: "Я ничего не слушал, даже не пытался вникать, потому что я вижу, что это какой-то нейро-слоп, там у тебя красивые картинки. Я в это не верю. Там в ChatGPT забил это и всё придумал. Но ChatGPT только условно для агрегации и для помощи, чтобы это всё правильно сформулировать. Вот как такую сложную махину продать бизнесу? Ээ есть ли какие-то истории или трюки или как это вообще продаётся сейчас?
>> А, ну, собственно, продаётся она по частям. То есть сначала всё-таки продаётся простой процесс, если в контекст пролезает вся система. Сразу строить полный TOGAF смысла нету. Есть смысл более маленькими порциями. То есть первое, с чего мы начали, это мы начали с того, что убедили: "Давайте 34 ещё тогда доллара на Copilot на лицо. Давайте попробуем подписать там core-команду из десяти человек и посмотрим, что будет с производительностью". У нас появился рост производительности от 30 до 50%. Дальше можно продавать следующий кусочек этого слона. Что? Дава давайте мы построим архитектурную базу всего этого дела. просто проиндексируем, чтобы можно было спросить про проект, где что реализовано. А появляется прозрачность проекта, появляется возможность что-то такое поспрашивать, поузнавать про систему. Им это повышает прозрачность, повышает качество решения. А плюс к этому а мы продавали эту систему ещё и с некоторым внешним опытом, да? То есть вот, э, грубо говоря, сама вот эта система с адрниками, она пришла к нам из Replit, который, собственно говоря, с ним обсуждаешь, обсуждаешь, потом выгружаешь этот проект и видишь, что у тебя там действительно есть адра, есть фичи, тесткейсов нету. Вот тесткейсы мы додумывали уже сами, потому что видели уже, что там, где есть ограничения, там нейронка себя хорошо ведёт, где нет ограничения, там она себя ведёт плохо. И заранее надо быть реалистом. Аа в том плане, что если вы не можете отстроить ограничение для нейронки где-то, то значит она будет галлюцинировать там. А, например, э она не знает, что такое удобно, она не знает, что такое красиво, поэтому лучше построить UI тулки из кучи кубиков и дальше просто нейронке сказать: "Нейронка, пользуйся вот этими кубиками". И, собственно, Replit тот же самый. Очень хорошо это делает. То есть там видно, что все интерфейсы плюс-минус одинаковые из-за этого.
Вот вы как-то замеряете и есть ли метрики, чтобы показать там условно руководству компании, что вот эти все изменения они приносят пользу?
>> А очень сложно замерять из-за того, что, собственно, задача немножко уникальные всё-таки, но мы видим, что если раньше мы еле-еле попадали в оценки, то теперь мы, собственно говоря, пролезаем в оценки дешевле. То есть это упростилось. Плюс к этому, а-а, упростилась постановка задач, потому что нам, собственно говоря, менеджмент может выйти уже с определённым sandbox'ом каким-то.
>> Спасибо.
>> Ну что, ещё вопросы? А, уже всё. Нам пора на перерыв. B