Transcription
Коллеги, я вас приветствую на канале Каткод. Сегодня мы поговорим о новом радикальном подходе, радикальной архитектуре, которой я шёл последний год. И я думаю, она серьёзно изменит правила игры взаимодействия с лэмками. Поэтому, если вы сейчас настроились на развлекательный контент, лучше пойдите, примите душ, приготовьте кофе и начнём погружение.
Друзья, давайте начнём с предыстории, как я вообще пришёл к этому подходу, к этой архитектуре, к тому, о чём мы сегодня с вами поговорим. Изначально я, как и вы, начинал знакомство с ИИ, с лмками на уровне Google 2.0, когда у меня был просто чат GPT, и я задавал какие-то вопросы, где-то в чём-то сомневался, где-то какие-то моменты забывал и переспрашивал. И, соответственно, это был этап ещё даже не промт инжиниринг, а скорее такое небольшое дурачество.
Чуть позже я уже добавил туда контекст, скажем, перекидывал файл с кодом, задавал вопросы, как пофиксить тот или иной момент, и это уже обретало какой-то вид, уже было похоже на промпт инжиниринг. Позже появились кодигагенты. Я уже запускал кодинг агент внутри проекта, уже автоматически на уровне агента и его тулингов получал определённый контекст, с чем работаю, с кодовой базой. Соответственно, дополнительно скармливал свой контекст, чтобы как-то ограничить и расширить знания при генерации кода с лмкой. Это был второй этап, уже больше похожий на контекст инжиниринг в каком-то таком упрощённом виде.
Следующий этап. Мы уже поняли, как работает лэмка, что задачи нужно декомпозировать, каждую задачу нужно итерировать, невозможно получить сразу результат при первой итерации, нужно делать аудиты, ревью и внутри цикла решать даже мелкие задачи после декомпозиции. Таким образом, на этом этапе мы пришли к workflow, когда нам необходимо было ресерчить, составлять планы, проверять планы, делать имплементацию этих планов, валидировать, всё ли хорошо. Итак, по кругу. Да, на первом этапе мы делали свои директории, создавали кучу заготовленных промтов, по которым гоняли этот цикл. Чуть позже пришла стандартизация, у нас появились команды, у нас появились скилы, субагенты и прочее. Всё это привело к красивому workflow. Speek Drive SD, появились GitHub Spec Kit, Open Kit, My AI Factory. И, соответственно, этот процесс уже получил некую автоматизацию. Работать с этим стало приятнее.
Но при таком контекст-ненеринге плюс workflow мы никак не избавились от основной проблемы, что у нас лэмка - это рандом, это недетерминированный результат. Да, у нас есть workflow, у нас есть скилы, но это всего лишь инструкции, когда у вас огромный контекст, когда у вас нарастают инструкции, внутри присутствуют ограничения определённые: не делай так-то, не делай так-то. Плюс какие-то процессы после завершения, вызови тесты, пройдись по определённому чек-листу и так далее. И у нас на уровне инструкции всё ещё присутствует рандом. Лэмка может часть инструкции проигнорировать, и это вполне себе нормально. Да, мы workflлоow добавляем дополнительные итерации, проверяя, проверяя, но всё равно у нас есть только вероятность, выполнятся все инструкции либо нет. Плюс в процессе у нас автоматизация нарастает. По завершению необходимо исправить документацию, внести что-то в CI и так далее. Какие-то моменты мы упускаем, соответственно, хаос нарастает и в процессе бьёт по нам снежным комом.
Друзья, так, после контекст инжиниринга мы пришли к харнес-нжинирингу, чтобы обмазать лэмку управляемым контуром, добавить ей ограничение управлять её результатом и прийти к детерминированному результату. Соответственно, это то, о чём я сегодня вам расскажу.
Итак, друзья, я рад представить вам подход следующего уровня. Называется он HLV. Это не только подход, это архитектура, это тулинг, это в целом пересмотр правил взаимодействия, генерации кода, работы с LM. Если коротко, то я пришёл к тому, что для разработчика хорошо, то для Лэмки в целом смерть. Многие паттерны, которые мы долгие годы вырабатывали для разработки, являются для лэмки антипаттернами. И сейчас я вам объясню, почему.
Что из себя вообще представляет HLV? Во-первых, это новая архитектура, которая разделяется на три слоя. Human - человеческий слой, слой, где мы будем собирать с вами контекст. Этот слой отвечает на вопрос, что из себя этот проект, эта задача представляет. То есть здесь у нас артефакты, здесь у нас ограничения, всё в свободном формате. Если мы взглянем на то, как это выглядит в коде, вот они три уровня. Соответственно, уровень human, есть артефакты. И здесь в свободной форме мы собираем контекст. То же самое по этапам разработки. Также присутствуют артефакты. Они также в свободной форме. То есть этот уровень в свободной форме и он полностью ложится на нас. Мы здесь собираем, разрабатываем необходимый контекст.
Следующий слой LLM - это то, как делается. Здесь уже LLMка генерирует код. Если мы посмотрим опять на код, мы увидим директорию LLM. И вот за эту директорию в подходе HLV полностью отвечает LLMка. Мы не смотрим на то, как выглядит код. мы только создаём контекст и только его валидируем.
Соответственно, третий слой, самый важный - это слой валидации. Точно ли результат LLMки был таким, как мы ожидаем? Точно ли он был в рамках ограничений и правил, которые мы диктовали на уровне контекста. Соответственно, здесь у вас должен возникнуть вопрос: а каким образом? Если ты уже говорил о том, что инструкция - это всего лишь инструкции, они могут игнорироваться. Вместе с HLV поставляется binary, который валидирует, точно ли всё выполнено. Как он это делает, спросите вы. Давайте посмотрим. Мы можем даже в этом проекте запустить HLV check. И мы с вами увидим множество проверок. Каждый артефакт, каждые контракты, каждые ограничения будут проверяться на этом уровне валидации. Также присутствуют гейты, которые мы в процессе задаём. Как видите, у нас здесь тесты, то есть в процессе workflow LLMка будет указывать, какие именно команды. Никакой этап не будет являться пройденным, пока LLMка не пройдёт этот чекер. То есть в каждом этапе workflow, а их здесь всего четыре основных - это создание артефактов, generate, то есть из артефактов, чтобы мы создали уже контракты, конфиги для LLMки. И, соответственно, проверка этих конфигов, имплементация и самый важный этап валидация.
Помимо гейтов, которые из себя будут представлять различные тесты end to end, интеграционные юнит-тесты, перформанс-тесты, у нас также присутствуют и ограничения. Скажем, чек-листы по безопасности также присутствуют, что нужно что-то логировать и так далее. Как это достигается? В процессе на уровне кода LLMка обязана проставлять маркеры вот такие HLV, которые будут соответствовать определённым чек-листам, определённым ограничениям. Также присутствуют маркеры CTX, чтобы LLMка понимала, о чём речь. Тем самым, если вы взглянете на код, в большинстве случаев он будет линейный, тесты будут прямо в коде, и множество других непривычных для вас правил будет реализовано.
Стартовая точка Mapam, от которой будет работать LLMка, и уже на уровне этого Ямла она получит всю карту. Какие за что файлы отвечают и что именно в них будет. Для человека код в итоге может быть нечитаемый, но для LLMки он будет идеальный. По сути, ей даже не нужно указывать логические имена для файлов. Они будут указаны в карте. На уровне маркеров и комментариев будет информация о том, что от чего зависит и как это всё работает. И, соответственно, результат будет идеальным.
На уровне лендинга также мы видим, как выглядят эти слои, как они выглядят на уровне структуры. Помимо архитектуры здесь также прописываются и правила о том, что для LLMки лучше будет выбрать строгий язык, компилируемый, со строгой типизацией, чтобы в нём было меньше хаоса в рантайме, чтобы поведение было предсказуемым. Поэтому на уровне HLV вам, скорее всего, будут предложены языки Rust, Go. Ну, соответственно, мы понимаем, что Web UI на этом делать плохая идея, поэтому как бы JS с TypeScript'ом всё ещё будет использоваться.
А также, друзья, вместе с HLV поставляется MCP интеграция, благодаря которой вы сможете сделать комбандоски для handoff систем, для оркестрации, веб-дашборды и ассистенты. В коробке уже есть CLI dash, CLI команды, но вы также будете вольны всё это переделать под себя. Вместе с HLV я также поставляю две спецификации: спецификация по разработке веб-дашборда и спецификация по разработки собственной системы с оркестрацией, чтобы вы могли создать собственную оркестрацию и она была подкреплена архитектурой и подходами HLV с валидацией и с практически близким к нулю шансом допускать ошибки.
Итак, друзья, много всего вам рассказал. Давайте ещё немножко пройдемся по лендингу, который ещё в процессе разработки. И далее мы с вами разработаем небольшой простой проект, чтобы посмотреть на то, как это всё выглядит, как это всё работает. Также на уровне лендинга рекомендую вам ознакомиться с таблицей сравнения, то, о чём я вам говорил. То есть современные паттерны разработки часто являются антипаттернами для работы с LLMкой, хотя это тяжело понять. DI будет являться больше магией для LLMки. Огромные слоистые архитектуры, это лишний шум, абстрактные фабрики и так далее.
В какой-то момент, если вы ещё находитесь на этапе до контекст инжиниринга, либо там где-то Google 2.0, вы рано или поздно всё равно придёте к тому, что будете писать архитектуру, что-то вроде feature sliced. Когда у вас будет разбиение на фичи, внутри, в каждой фиче будет Makefile, как отправная точка, чтобы понять, что это за фича и как с этим взаимодействовать. Я приходил и к этой архитектуре, я называл её FLT, но в процессе я также понял, что она не закрывает все проблемы. Собственно, таким образом я пришёл к HLV.
Что касается спецификаций, я вам показал, что в коробке есть спецификация по Web UI, по дашборду, есть спецификация по handoff. До записи этого ролика я реализовал dashboard спецификацию. Соответственно, как я действовал? Я сделал init проекта с HLV. Мы до этого ещё дойдём. И в стартовый milestone я просто добавил в артефакты эту спеку. Всё, что у меня было на старте - это спека из коробки. И, соответственно, я ещё добавил доку MCP. После этого я запустил генерацию по скилам через Artifacts и Generate. LLMка мне перестроила структуру, добавила глобальные артефакты с ограничением, с выбранным стеком, с дополнительным контекстом, чек-листом по безопасности, перфомансу и так далее. И, соответственно, я получил план. План выглядит следующим образом. У нас план MD в виде оглавления. Каждый план разбит ещё на фазы, на стейджи из уже внутреннего количества задач. В процессе есть блокеры, есть открытые вопросы, на которые нужно ответить либо поставить что-то, чтобы продолжать двигаться дальше. И в итоге был реализован код. В данном случае это был TypeScript.
Если мы взглянем на то, как это выглядит, вот у меня запущен MCP сервер HLV и, соответственно, npm run dev. Я получил благодаря спеке и HLV вот такой даш, где я в реальном времени благодаря SSE вижу, какие сейчас задачи стоят, сколько этапов, какие гейты проверок есть, какие присутствуют ограничения и что там за рулсы. Соответственно, я могу все эти гейты в виде тестов запустить либо какие-то выключить, посмотреть на контракты, посмотреть на текущий план, что он из себя представляет, возможно, добавить задач, переформировать задачи. Такую силу даёт HLV. Ну и в коробке без дополнительной кастомной имплементации вы можете получить команды, например, HLV status, увидеть, какие гейты завалены, на каком этапе мы сейчас находимся, что уже выполнено, имплементировано, провалидировано. Есть и дашборд, есть и план вот в таком виде, есть отображение workflow, чтобы понимать, что вообще происходит, в каком этапе цикла вы сейчас находитесь, что делать дальше, всегда будет подсказка. Но есть и TUI dash. Вот так он выглядит. Можно прямо здесь отслеживать, с чем мы сейчас работаем, какие есть контракты, что у нас по плану, что у нас по гейтам. Причём вы видите, что есть соответствие с командами, которые можно указывать. Если вдруг LLMка нарушит свои инструкции и не укажет, вы сможете это сделать вручную. Ограничения, открытые вопросы. Всё это работает также и через HLV binary. Соответственно, прямо через него можно делать трассировки, указывать конвенцию комитов, создавать новые майлстоуны, добавлять таски, менять их статусы, ну и, соответственно, запускать MCP. Можем также выполнить чек и увидеть по этому проекту какие-то ворнинги. И мы также видим, что HLV у нас на уровне чекат определённые гейты. И, соответственно, в процессе взаимодействия с LLMкой ей будет достаточно выполнить одну команду, чтобы понять вообще всё, что есть в проекте. все гейты, все ограничения, все ли маркеры проставлены.
Соответственно, я вам уже показывал проект, вот, например, на GO, где мы с вами увидим помимо кода также дополнительные маркеры, что это из себя представляет, с чем оно связано, плюс маркеры по тестам ограничений и так далее. Всё это будет связано с конфигами и в связке работать. Посмотрим, как это работает. Соответственно, в описании к этому ролику будет ссылка на лендинг, будет ссылка на GitHub репозиторий. Вы сможете перейти и скачать binary HLV. После скачивания он у вас будет доступен глобально, и вы сможете его инициализировать в любом проекте. Скажем, вот у нас пустой проект. Мы делаем HLV init. Указываем имя проекта, пусть будет Hello World. Соответственно, название владельца, какой агент мы будем использовать. И по умолчанию нам предлагается сразу gate profile из трёх видов. Здесь указано для каких проектов что использовать. В большинстве случаев вы будете использовать standard либо minimal, minimal, full уже для более серьёзных проектов. И даже если вы здесь ошибётесь и поставите full либо minimal, в процессе генерации с помощью LLMки она всё равно пересмотрит, исходя из контекста, и переключит gate. О'кей, давайте оставим minimal, так как у нас будет просто CLI приложение для демонстрации workflow, которое будет выводить что-то вроде Hello World. Скорее всего, так оно и будет. И, соответственно, первый milestone, так и назовём, init, то есть инициализация проекта. Можно назвать MVP, тут уже что вам больше нравится. Соответственно, после init'а мы с вами видим подсказку по workflow, что мы сейчас находимся на старте, нам необходимо выполнить фазу один, сбор артефактов и, соответственно, уже в агенте вызвать Skill Artifacts. Если мы сейчас реально бы делали с вами проект, мы бы начали с артефактов. Здесь мы бы в свободной форме начали создавать markdown файлы с контекстом, с описанием нашего проекта. Добавили бы сюда ТЗ, возможно, какие-то ресерчи по стеку, по архитектуре и так далее. В свободной форме markdown файлы все бы находились здесь. Также мы бы создали с вами какие-то артефакты, уже привязанные к этапу, если это требуется.
О'кей, друзья, это важный этап, и в большинстве случаев, скорее всего, вы будете готовить контекст самостоятельно, но на уровне HLV есть workflow, есть, соответственно, и интерактив. Вы можете запустить и агент, далее вызвать artifacts. Я был близок к лимитам по cloud, поэтому переместимся на codex. О'кей, вызываем skill artifacts без каких-либо аргументов. И в процессе нас с вами ждёт интерактив, и LLMка попробует собрать с нас необходимый контекст, чтобы сгенерировать все ограничения, все правила валидации и так далее. После вызова команды artifacts LLMка определила, какой у нас milestone, что у нас глобального контекста пока что нет, как и контекста в текущем milestone. И мы начинаем с первого блока, с короткого описания, что именно у нас за система. Мы сейчас с вами просто смотрим workflow, чтобы понять, мы не будем сейчас сидеть и часами генерировать определённый проект. Мы с вами сделаем учебный проект, который выводит Hello World в консоль. Давайте сделаем, используем TUI. О'кей. Соответственно, просто, чтобы посмотреть workflow. В целом, до этого у нас уже был AI Factory. Это отличный проект в рамках workflow, готовой генерации скилов с эволюцией, с готовыми скилами под докеризации и прочее, что необходимо для разработки. но без вот этого дополнительного контроля с валидацией. Но что нам ещё даёт контроль с валидацией? Я уже запускаю и работаю с HLV в нескольких проектах. За счёт того, что LLMка каждый раз, выполняя имплементацию, упирается в гейты, она не может пройти дальше, пока действительно не реализует задачу. И если у вас на уровне проекта крутые ограничения, правильные ограничения, присутствуют контракты, присутствуют гейты, она не сможет вам отчитаться и сказать: "Задача решена, принимай". и вы дальше её итерировать ещё десятки раз, пока она действительно не будет выполнена. Тем самым выполнение milestone может занять и час, и 2 часа, сожрать больше токенов, чем обычно, но это будет результат близкий к идеальному. Конечно же, вам придётся ещё сверху работать с UI, если такие задачи есть, но в целом вы будете ошеломлены от результата. Но вы это будете видеть уже в процессе, друзья. У меня сейчас, да, собственно, как и обычно, ужасный интернет. по 3 минуты отвечает Open AI. Поэтому эти моменты буду проматывать. Соответственно, по каждому блоку интерактивно будут заданы вопросы: кто пользователь, только я и так далее. HLV с codex'ом с GPT 3.5 понял и как раз спрашивает: "Зачем вообще нам такой проект? Вот мы хотим просто изучить HLV процесс." Да, всё так. Немножко самостоятельно поотвечал на неинтересные вопросы. Блок первый завершён. Контекст MD в артефактах создан. Соответственно, у нас есть summary о том, всё ли корректно. Говорим, что да в текущей ситуации и переходим к блоку 2. Соответственно, LLMка не понимает, что у нас настолько простой проект в рамках HLV, начинает задавать много вопросов, которые нам не интересны. Соответственно, в реальном проекте эти вопросы будут более важные и на них нужно будет отвечать тщательно. Но если вы идёте таким простым путём через автогенерацию, идеальный путь, конечно же, разрабатывать контекст самостоятельно, продумывая каждый его шаг. Поотвечал на бизнес-вопросы, которые в данном случае не актуальны, мы перешли к блоку три. Инфраструктура и ограничения - это уже важный блок. И обратите внимание, что он также изучает на уровне скилов Strict Language MD. Это как раз то, что диктует архитектура HLV. Использовать строгие языки, и они будут в приоритете. LLMка по большему счёту обучалась на данных с Python'ом, с TypeScript'ом. Соответственно, всегда практически рекомендуют именно эти языки, даже тогда, когда они не особо подходят. Здесь же приоритет будет немножко иным. Будут строгие языки, а уже потом, исходя из здравого смысла, там, где они не подходят, будут предложены уже языки с хаосом в рантайме. Без этого никуда не деться. Универсального стека не существует, поэтому результат будет отличным. Соответственно, в данном случае предложен язык GO. Библиотека для TUI. Определённые ограничения. Подтверждаем. Двигаемся дальше, друзья.
Итак, мы прошли этап артефактов. Это первый этап, самый важный. Мы его автоматизировали, но, соответственно, так делать нежелательно. Но я прекрасно понимаю, что часто мы с вами лентяи. Но давайте, прежде чем мы будем двигаться дальше, мы посмотрим, что у нас получилось. То есть это часть с артефактами, которую в свободной форме мы должны сделать самостоятельно. То есть мы вот эту часть можем сделать самостоятельно. В процессе генерации LLMка уже чего будет не хватать, она задаст вопросы. Проект простой, но даже исходя из этой простоты мы с вами имеем определённый контекст, как глобальный, так и в рамках фичи с выводом Hello World, какие-то неизвестности и так далее. Но что для нас самое важное - это основные конфиги Project'а и Milestones, которые пока что ещё не сгенерированы, есть только контекст. Давайте сейчас запустим ещё раз сей агента. Я переключусь на cloud, так как с текущим коннектом, который у меня сейчас есть, codex работает очень медленно, и выполним генерацию. Это уже важный скилл, важная часть workflow. Теперь, исходя из контекста, который мы с вами тоже сгенерировали, а должны были бы написать самостоятельно, мы получим уже контракты, ограничения, конфиги для LLMки.
Друзья, также важная часть. У нас генерируются контракты, ограничения, всё это в виде YAML конфигураций. Также у нас прямо сейчас в процессе генерируется карта нашего проекта вот здесь. И я думаю, у вас уже в процессе могут возникнуть вопросы: а как LLMка с её рандомом здесь не допустит ошибок? Как видите, в конце она запускает HLV check на валидацию. Валидируется не только ограничения, не только гейты, валидируется также и схема каждого контракта, каждой конфигурации. В итоге, если вдруг что-то где-то пойдёт не по плану, не так, LLMка сразу увидит и начнёт итерировать, сравниваться со схемами. Схемы также здесь доступны по каждой спеке, то есть ошибиться ей здесь практически нереально. У неё всегда есть слой валидации. Если мы сейчас с вами посмотрим на HLV status, то мы, в принципе, уже с вами видим предварительную первую организацию, первую генерацию. У нас есть stage всего с одной задачей, так как супер простая программа. Есть определённые контракты, есть два гейта по тестам и по безопасности. Всё ещё присутствует. У нас уже наполнен Project Yam. Мы прямо здесь видим, где что находится по перформансу, по безопасности, какой язык выбран, что именно за тип компонента. То есть в рамках одного проекта может быть несколько компонентов с разными языками, с разными зависимостями. Всё это будет здесь указано. Вы прямо здесь через конфиги можете указать политику по гиту. Будете ли использовать для майлстоунов отдельные ветки, какую конвенцию будете использовать. Если используете по стандартам, то какие скопы при этом будете использовать? Соответственно, всё это будет здесь на уровне конфигов. плюс вспомогательных инструментов.
Давайте посмотрим workflow. Мы с вами увидим, где мы сейчас располагаемся, что мы прошли этап артефактов. У нас сейчас генерация, от нас ожидают либо имплементацию, либо верификацию того, что мы сделали. Соответственно, мы можем также с вами посмотреть план, увидеть, какие сейчас у нас этапы, что они вот в режиме ожидания, что за таски, соответственно, дашборд. Всё это у нас здесь присутствует. При этом контракты по гейтам также отмечаются на обязательность. То есть, если у нас совсем что-то простое, какие-то контракты могут перестать быть обязательными. Либо вы здесь вот видите снизу навигация, можете что-то включать, выключать. Пока что ничего из этого не вызвано. Мы просто имеем всякие моменты, имеем вот вопрос, который рекомендовано нам закрыть, прежде чем приступать к следующему этапу, но он у нас не блокирующий. О'кей, давайте двигаться дальше. Каждый раз нам рекомендуют очистить. И, соответственно, дальше давайте выполним верификацию. Это опциональный этап, но желательно его также вызывать. Что он из себя представляет? У нас были артефакты, мы сгенерировали с помощью них контракты и конфигурации для LLMки. И теперь мы этот результат верифицируем. Всё ли там хорошо, всё ли правильно, у всех ли задач стоит правильный статус на старте, есть ли какие-то незакрытые вопросы и так далее. Ну и, конечно же, каждый этап workflow у нас завершается HLV чеком, чтобы LLMка точно нигде не допустила каких-то ошибок.
Верификацию мы прошли, мы готовы к имплементации. У нас создан репорт после верификации есть один неблокирующий вопрос, отложенный. Мы его игнорируем. Но при этом, если мы сейчас с вами самостоятельно будем вызывать чеки, мы увидим ту же самую картину. Есть ворнинги, но на данном этапе они не блокирующие. И, соответственно, мы видим, что у нас происходит по workflow, что мы уже на этапе верификации, что у нас уже stage верифицирован. Есть подсказка, что делать дальше, переходить к имплементации. В общем, мы можем работать и при этом видеть информацию о том, что происходит. Да, не забываем, что у нас также есть MCP, который даёт возможность добавить интеграции. И помимо проектной работы здесь также присутствуют и workspaces.
О'кей, давайте сделаем clear, давайте сделаем implement. Ну и само собой, это важнейший этап. Он проставит нам гейты, с которыми мы в последующем будем также взаимодействовать. Друзья, мы уже видим с вами, что задачи перемещаются в статусы, что у нас на уровне кода проставляются маркеры по контексту, HLV маркеры, которые отвечают за тесты либо какие-то ограничения. Всё работает по привычному нами подходу spec-driven workflow, но при этом есть ещё дополнительный слой с валидацией, который суперважный и который уже включён в тулинг подхода HLV. То есть три слоя, один из них наш, где мы с вами разрабатываем контекст. слой LLM с кода, который нас абсолютно не интересует, и слой валидации с HLV, которая будет валидировать код не только тестами, а ещё маркерами. Даже на уровне логирования будут проставляться маркеры. Если их нет, то HLV чек будет нам трубить тревогу и, соответственно, LLMка будет тоже это видеть и пытаться пофиксить. Соответственно, мы видим с вами, что первый этап завершён. Можем поперемещаться, посмотреть, что у нас здесь происходит, что у нас вот как раз implemented на уровне плана, что у нас stage завершён, но ещё не провалидирован, и все задачи выполнены. Соответственно, и в дашборде мы тоже что-то с вами увидим. Помимо всего прочего, мы видим, что гейты у нас были запущены, они пройдены. И обратите внимание, мы видим на уровне гейтов, что LLMка нам уже проставила, где у неё entry point, что за команду вызывать. Если мы сейчас с вами запустим чек, помимо всего прочего, мы видим с вами, что были запущены и гейты. Давайте ещё раз. Вот они запускаются. Мы даже с вами ничего не указывали, но умки просто нет шансов. Она обязана всё это выполнить. Если она не выполнит, у неё упадёт чек.
О'кей, давайте приступим к последнему шагу. Validate, который дополнительно всё провалидирует. Точно ли чеки пройдены? Точно ли все маркеры по всем ограничениям присутствуют? Точно ли у нас обновлена source-карта? Да, по нашему коду. Точно ли всё у нас в рамках архитектуры HLV, в рамках всех подходов, всех правил и принципов, которые описаны в инструкциях. Да, помимо всего прочего с HLV вы увидите системный PRO SGM MD, где вы можете писать всё, что угодно. Он меняться в процессе апдейтов HLV не будет, но будет также референс в виде HLV MD, вот этот, который трогать не стоит. Это уже правило самого подхода по маркерам, по архитектуре, по многим моментам, которые с апдейтом HLV также будет обновляться. Вот такая вот история.
Соответственно, то, что я вам показывал ещё ранее, пока здесь идёт генерация, что HLV также поставляет спеки в виде спека на dash. Я уже показывал её реализации. Я просто загнал яишку и получил real time dashboard по проекту. И такая же штука по handoff, по оркестрации тоже присутствует. Я думаю, за этим также будущее. Мы уже видим, что Open AI свой проект Symphony по оркестрации не сделали как готовый инструмент, как готовое решение, а дали только спеку. Так как сейчас мы все делаем решение под себя. Мы видим, что вышел какой-то инструмент, нас что-то не устраивает, мы его переделываем, пишем под себя с нуля. И возможно в этом будущем уже нет смысла поставлять нам готовые какие-то инструменты высокоуровневые. Нам достаточно дать спеку, чтобы мы понимали все подводные камни. точнее, не мы, а LLMка и могли беспрепятственно реализовать под себя, уже сверху нарастив жира, как мы себе видим, добавив логики. Соответственно, таким же подходом сейчас идёт и HLV. Если вам нужен веб дашборд или handoff, берите. Есть спецификация со всеми возможными проблемами и рекомендациями, и вы можете её реализовать, как это сделал я. И также с помощью HLV. Если вы посмотрите дашборд у нас тоже в рамках этой концепции, которую я вам показывал в начале, вот спека лежит в milestone, и, соответственно, это полностью выполненный проект.
О'кей, мы видим, что чек пройден, что все гейты пройдены. Мы также можем с вами это всё посмотреть и увидеть, что действительно они пройдены и проект завершён. Если мы с вами сделаем workflow, то также увидим, что у нас фаза validated, и нам предлагают сделать HLV milestone done. Тем самым на уровне HLV мы с вами пометим, что milestone выполнен, так как в процессе возможны какие-то баги, и вы также через HLV сможете синхронизировать задачи, добавлять новые таски, менять статус тасков. Всё это есть в документации и, соответственно, на уровне хелпа.
Друзья, давайте ещё раз затронем тему сравнения AI Factory и HLV. А то может показаться, что меня уже понесло и что-то ещё после HLV будет, но это немножко разные инструменты под разные задачи. На лендинге есть вот такая вот табличка сравнения AI Factory и HLV, где у каждого есть свои преимущества, свои особенности. Если мы говорим про AI Factory, то это подойдёт под 90% проектов, где нужно быстро прокликать workflow и получить качественный результат. Но при этом HLV - это уже следующий уровень, где качество проекта критически важно, причём не на старте, а уже в процессе доставки, масштабирования и так далее. Также по типу проекта. AI Factory работает и с новыми проектами, и с уже существующими. HLV - это радикальная концепция, она подойдёт только для новых проектов. Так как здесь нужно принять ту особенность, что слой с кодом, который генерирует LLM, он полностью уходит на сторону LLM. Человек его никак не контролирует. Здесь фокус именно на слой с разработкой контекста, с разработкой ограничений, конфигурирования гейтов и так далее. Также по начинке. Если мы говорим про AI Factory, это только Workflow плюс дополнительный помощник по конфигурации, по конфигурированию, когда на старте вы уже получаете определённую стартовую структуру и набор скилов. В HLV сам Workflow упрощён только под генерацию артефактов в LLM формат, имплементацию и, соответственно, итоговую валидацию. Здесь весь фокус на контекст инжиниринге. Соответственно, AI Factory - это быстрый старт под все виды проектов. Когда основная рутина перекладывается на workflow, HLV - это упор на слой, где человек основа, человек занимается дизайном контекста, архитектурными решениями, конфигурацией гейтов, ограничений, контрактов, огромный пласт работы, от которого будет зависеть качество проекта. Мы полностью убираем фокус с части кода и перекладываем его максимально на человеческий слой. То есть HLV. Здесь уже нет никакого разговора про wipe coding. Здесь только осознанная разработка. Причём каждый шаг на уровне контекста. Да, на старте я добавил скилл по быстрой разработке артефактов, но это только для того, чтобы влиться, посмотреть, как это работает. Ну либо, возможно, чтобы получить какой-то стартовый скелет при начале работы с HLV. В дальнейшем нужно понимать, что это совсем не про wipe coding. Я думаю, эта таблица отвечает на вопрос: в чём разница и когда что применять. То есть HLV не заменяет AI Factory, это совершенно другой уровень. Здесь у нас, как языки программирования, AI Factory - это, скажем так, PHP, HLV - это C++. И уже исходя из этого, решайте, когда вам что использовать.
Давайте подытожим. У нас уже с вами были workflow. Возьмите любой, который вам нравился, которым вы пользуетесь. Spec-driven подход. Вы знаете, что контекст важен, но, соответственно, постепенно вы придёте к тому, что независимо на ваш контекст все эти промты никаких гарантий не дают. Вы можете это исправить за счёт итераций, за счёт workflow, чтобы постоянно перепроверять, точно ли эта вероятность покрывает весь чек-лист, который необходим, соответствует всем проверкам качества, соответствует всем ограничениям, всем контрактам, которые у вас есть по этому этапу. И, соответственно, возможно, придёте к результату, возможно, нет. HLV даёт архитектуру, даёт более упрощённое понимание, кто за что отвечает. У вас есть три слоя. Слой, где вы главный, где вы рассказываете, что именно должно быть. В свободной форме генерируете, создаёте контекст с ограничениями, с описанием задач, с речем и так далее. Слой LLM нас мало интересует. Он отвечает на вопрос, как он генерирует код, основываясь на те спецификации, которые вы ему предоставили. И HLV подготавливает слой валидации, чтобы проверить, что результат LLM действительно верный, что все контракты, все конфиги были валидными и правильно сформированными. И результат проходит все проверки, все гейты, все тесты, сравнивает маркеры, что логирование, что все ограничения, все security чек-листы пройдены. держит рандом от LLMки в контуре валидации, что приближает максимально к детерминированному, качественному, предсказуемому результату. Соответственно, у нас здесь есть привычное нам workflow, есть новая архитектура, есть дополнительные принципы и подходы, исходя из того, что паттерны разработки, которые у нас были ранее, которые супер эффективны и подходят для разработки по старинке, уже не совсем подходят для разработки, когда у нас часть кода полностью делегирована LLMке. Не частично, а полностью. И в такой ситуации HLV работает идеально. Мы отвечаем за свой слой, LLMка за свой слой. и Тулинг с приложением всё это дело валидирует, контролирует и даёт нам ещё дополнительный интерфейс, где мы с вами видим, что сейчас происходит, какой шаг предпринять далее, в каком статусе, текущий план, текущие задачи и дополнительная интеграция в виде MCP и готовые спеки, дающие возможность это я накидал здесь MVP'шку по-быстрому, вот так вот некрасиво, вы на уровне спеки можете сделать под себя идеально, так как вы это видите. То же самое с handoff оркестрацией.
Да, и ещё что важно, друзья, часто я вижу в комментариях, что вы меня спрашиваете, почему я должен выбрать. Я вас не принуждаю к инструментам, которые я делаю под себя. Я просто вам рассказываю, к чему я прихожу. Я сталкиваюсь с проблемами, у меня определённый бэкграунд взаимодействия с LLMками. И я в процессе постоянно анализирую, рассуждаю и прихожу к таким инструментам. Первый большой был AI Factory, теперь же это HLV. Но это радикально другой подход, совершенно другой уровень, который не был ещё представлен ранее, и сейчас мне его предстоит развивать. Если вам этот подход близок, если вы во всём этом увидели и свои проблемы, и увидели при этом решение в рамках того, что я предлагаю, я приглашаю вас в команду разработки этой концепции, а, в репозиторий, публичный репозиторий. приходите, давайте вместе пользоваться, давайте развивать, улучшать и делать разработку с помощью LLM детерминированной, предсказуемой, качественной, выходить на новый уровень. Соответственно, этим я прямо сейчас и занят.
На этом всё, друзья. Не буду против вашего лайка, соответственно, комментария. Критикуйте, пишите, что вам не нравится, какие вопросы у вас ещё возникают. Приходите в нашу тусовку, в наш AI комьюнити чат, давайте вместе там обсуждать. Там формируется уже отличная, крепкая комьюнити, с которым можно обсудить разные проблемы, найти ответы на различные вопросы. Так что вступайте. На этом всё. Увидимся в следующем ролике на канале Кат код.