Transcription
Но я там человек, который уже там 7 лет занимаюсь обучением разработчиков. Я понимаю, что разработчик разработчику рознь. И все те же самые проблемы, что мы сейчас видим при ИИ-генерации, когда там не хотят поспрашивать у ЛМки, не хотят почитать, то же самое было. Не хотели читать документацию, не хотели читать фундамент, хотели быстрее в какой-то высокоуровневый инструмент залезть, изучить его. 5% разработчиков являются действительно разработчиками. Так и здесь вот пришла ИИшка. Что бы там ни было, как бы это легко не было, как бы все не стали там суперразработчиками, только 5% будет действительно работать хорошо.
Привет, меня зовут Пётр. Если тебе всегда интересно было нейросети и как это можно применять в бизнесе, каким образом новые функции использовать, какие не использовать, то заходи ко мне в Telegram-канал. Я там выставляю мои последние какие-то выводы, какие-то лекции, какие-то лайфхаки, ссылочки и так далее.
Ребят, всем привет. Сегодня будет видео про интересный проект i Factory. Это новая репа. Это открытый проект. Мы сейчас поговорим с его разработчиком. Разработчика зовут Даниил. А мы с ним поговорили, ну, около 2 часов, наверное. Я задал ему много вопросов. Я надеюсь, они помогут вам понять, что это такое.
Есть вайпкодеры, и это слово уже, наверное, заеженное, да, и это какое-то пренебрежительное, да, это слово. А есть какие-то разработчики, которые используют. И на самом деле разницы никакой нету. Главное то, что какой у вас уровень скила, когда вы можете использовать тот же код-код на 100%, а не на 10%, используя все его возможности.
У Данила есть четыре продукта, которые он делает, но не надо спешить устанавливать их все. Главный вывод, который я сделал - это то, что если вы только начинающий вайпкозер, программист, который только-только пробует курсор, cld или что-то ещё, вам не нужно это всё. То есть вам ещё рано это. Но если вы уже хотя бы на втором уровне, вы уже понимаете ограничение ЛМк, вы часто наступали на грабли, то опять же не нужно всё устанавливать. Установите только i Factory и попробуйте с ним поработать. А первое, вы поймёте, что за инструмент. Второе, подходит он вам? Не подходит. А в чём его плюсы? В чём его минусы? И главное, что вы можете использовать его вместе со своими стандартными скилами. Любыми скилами, они друг другу не противоречат.
Я уверен, что много ещё вопросов останется, поэтому пишите, связывайтесь с разработчиком, он всегда рад ответить. А если вы готовы даже контрибьютить туда, милости просим, репо я пошарил. В принципе, можете заходить смотреть. Он действительно опирается на спецификации. Он идёт дальше, чем просто спецкит. А, и много чего ещё. То есть надо просто погружаться, понимать эту логику. Но для меня это очевидно, что код - это не главное. Главное спецификации.
Итак, давайте перейдём уже к делу. А надеюсь, видео будет вам полезно. Спасибо за просмотр.
>> Основное просто вот изменить мышление. Вот это самое сложное. Это вот как раз то, то, что я говорил для людей, которые думают, что в любой момент они вкатятся просто вот так вот по щелчку, когда ээ весь мир там, ну, не знаю, государство, где они работают, скажут, что всё, теперь вот на уровне собеседований это 100% нужно, мы переходим на это, и они такие: "Всё, а, ну о'кей, тогда вот я удаляю айдешку и перехожу там на Open Cod, но не получится". Э, у меня, я прошёл там через мигрени, скажем так, чере, у меня у меня болела голова, пока я вот всё это интегрировался полгода и пытался изменить мышление, потому что, особенно мы разработчики, нам нам это особенно сложно. Я как бы прошёлся по граблям вот этих всех SD, которые были там до Superpowers, и создал i Factory, потому что, ну, я как не просто пользователь, ээ, большинство людей, которые доходят до SD, как правило, это на старте это просто пользователи, они что-то выбирают, что им нравится, и начинают бездумно дёргать вот эти команды, думая, что уже их workflow изменился, уже как бы они вышли на новый уровень. На самом деле это не совсем так. А я более осознанно к этому подходил. И вот как раз на уровне практики и проверки я пришёл к Factory. Но это опять-таки это мой это мой опыт. Он может с кем-то другим быть совершенно иным. И кто-то скажет с ходу, что вот он использовал IFORY, ему категорически не нравится и ему больше нравится там подход из какой-то другой. Ну, тут нужно аргументировать, тут нужно общаться с людьми, которые используют, э, вот как, например, те, которые, ну, мои знакомые разработчики, они говорят: "Вот super Persс хорош в этом". И мы начинаем дискутировать, и я начинаю понимать, а в чём он именно хорош? И там в какой-то момент, например, я понял, Superpers нравится людям вот именно вот на этом на дофамине, то есть он генерирует кучу э диаграммок, там, всяких отчётов, которые, ну, по факту являются только шумом. То есть они его они его в итоге не будут использовать. То есть пройдёт вот там, не знаю, какой-то период, месяц, а, наслаждение этими отчётами, а потом это будет всё только удаляться. Вот как раз то же самое, что у меня было со спеккитов. Он генерировал кучу шума. Это как будто бы круто на на старте, а потом это ты понимаешь, ну, как устроены вообще ЛМки, как они подтягивают все вообще MD файлы, сколько токенов это всё сжирает, а сколько шума это всё создаёт, и ты уже понимаешь, что это, ну, не совсем то, что нужно.
>> Ээ, то есть есть три твои проекта, то есть вот этот самый основной, да, и, собственно, у нас есть что-то похожее, я взял три. То есть просто что для сравнения? Почему главный вопрос такой, это прикольно, всё прикольно, но у нас же есть уже спецификации, есть какие-то наработки. Собственно, чем отличается и что можно скрещивать с твоим, да, а что нельзя скрещивать и чем они отличаются. А, допустим, ifory, я так понимаю, можно, в принципе, совместить с бимадом, например, или же нет. То есть тут поясник, ээ, для тебя вообще какая разница между вот этими проектами и твоими проектами?
>> Совмещать можно вообще всё. То есть можно и все сюда закинуть. Плюс ещё там Superpers, которого здесь нет. Хотя, я думаю, он он сейчас более популярный среди таких проектов. И у меня есть много ребят, которые генерируют код с Иишкой, и они используют часто и гибриды, то есть A Factory вместе с Superpowers, то есть какие-то вещи берут оттуда, какие-то оттуда. Тут фишка в том, что все вот эти SDки, они, ну, хороши в каких-то моментах. То есть у них может быть какая-то какой-то скилл внутри, либо команда, которая вот, ну, действительно крутая и которой нет там Factory и и можно юзать только её. Вот как раз то, о ком я говорил, он юзает из Super Pers Brainstorm Skill. Ему нравится, что там идёт на выхлопе с со всеми вот этими диаграммками. HTMLками и со всем остальным, но при этом он использует T Factory на вот имплементацию, на планирование и так далее. То есть он не юзает Explore из A factory, но юзает explore из вот Superpers. Ну и в какой-то мере никто не мешает вот все заюзать. Например, вот я уже, то есть я начинал со спеккита и Openспека, по-моему, так называется, но, э, когда я начал уже разрабатывать I Factory, я немножко отстал. Я уже я уже не помню, что там, и я не знаю, а как они сейчас развиваются. Только то есть сейчас всё, что я знаю, их развитие и исходит из коммьюнити, вот из контрибьюторов, которые приходят и говорят: "А давай добавим в Factory вот это, потому что это круто сделано в спекките, к примеру". А, ну, по факту я вот IF поставил, по сути, это, ну, такой набор скилов, да, обвязка там и так далее. То есть, и у меня сразу первый вопрос: о, а если я хочу добавить что-то своё, каким правильным образом двигаться?
>> не, это всё просто потому, что это всё изолировано, у них нейминги не пересекаются. Как раз поэтому, когда я там тот же самый A Factory делал, я делал нейминг скилов, не аля просто имплемент, там пн и так далее, а я делал префикс. Варианта пересечься нет, но вряд ли в спекките, либо где-то там будет тоже A префикс.
>> Они по факту никак не пересекутся. То есть Factory, потому что набор скилов, мы можем добавлять другие скилы, и они, в принципе, друг другу не противоречат. Единственное, если это не поднят на верхний уровень, что в таких-то ситуациях используют то, и они могут друг другу немножко противоречить.
>> Ну, Aкторе ещё так устроен, что он кастомизируется хорошо. Можно вот п планы там куда угодно затаскивать. То есть по большему счёту, даже если использовать там с киIT со своей спецификацией расположения вот этих артефактов в виде планов и всего остального, можно настроить i factory, чтобы он туда клал планы. То есть он может быть частью даже спеккита в какой-то мере. Ну я просто так образно говорю, спеккит, потому что тот же самый JSD я вообще не знаю.
>> А как правильно, кстати, это делать? Могу ли я просто, грубо говоря, на уровне морда файлов заходить, что-то править, либо это всё-таки надо как-то централизованно делать через что-то?
>> Там документация есть. расширение пишешь, это отдельный, скажем так, отдельный пакет, который может интегрироваться. Вот он он устанавливается, и он после установки может добавить какой-то скилл, либо добавить какую-то инструкцию в скил.
>> Это это нужно для того, чтобы если у тебя обновился, чтобы всё было Ну дада, да, нельзя заменять сам эффекто при апдейте он перезапишет, а на уровне на уровне экстеншенов он перезапишет и потом перезапишет экстеншнами. А не иметь экстеншен - это, ну, как мне кажется, плохо. Всё-таки, ну, в любой команде есть свои уже сложившиеся правила. Может быть, ещё нет, но они появятся. И то, как будут выглядеть артефакты, спеки и так далее, они могут отличаться от того, как вижу я. Но не 100% будут. Кстати, почему вообще я к этому всему прихожу, к этим расширениям вот этой гибкости, свободы, свободе внутри Factory? Я понимаю, что сейчас любой человек, который генерирует код ишкой, он видит крутой проект в виде хендофа, и он не думает о том, чтобы там его контрибютить, расширять, писать полуреквест, он его форкнет.
>> Я как получается хочу пробежаться ещё верхнего уровня сейчас, чтобы понимать вообще о чём речь. Увидел репа и начинаю устанавливать, да? И дальше у меня вопросы такие технические, типа как это правильно установить. Разница, по сути, это просто набор скилов, которые увязаны между собой. Вот это вот первый продукт. Потом второй. У нас есть обёртка удобная, типа в виде конван доски, которая подключается к нашему там open-коду. Удобный интерфейс вместокода. Но для чего? Для того, чтобы управлять субагентами, когда у нас там куча там, ну, не знаю, 10 одновременно нам работает или там два проекта одновременно работает. Вот. И третья штука - это, а, проверка нашего кода уже глобально. эээ, очень жёсткие ограничения, ни влево, ни вправо. И самое главное для меня, по крайней мере, фича - это то, что, э, не сломать предыдущие шаги, если мы делаем новую фичу. А каким образом устанавливать? То есть сначала надо установить, допустим, вот один этот, потом к нему вот этот или вот или они вообще настолько не взаимосвязаны?
>> В зависимости от того, что ты хочешь получить. Кто-то придёт, посмотрит на эти продукты и выберет AI Hand of и понятия не будет иметь II factory и что оно там вообще существует под капотом. Кому-то концепция Aendof вообще будет не понравиться. Как-то так там всё за меня будут делать, я должен контролировать. И он выберет A Factory. А кто-то поймёт, что A Factory всё-таки уровень инструкции ещё ээ не то, что хочется. хочется больше добавить контроля и возьмёт HLV, потому что там есть вот ещё программный контроль с валидацией, но это уже совсем другое другой проект по потреблению токенов, по трате ресурсов временных там и так далее. Ну как бы на лендинг такое не поставишь. И здесь проект, который нужно, то есть тебе здесь надо стать экспертом, понять вообще его концепцию, понять, как с ним работает. Не просто зайти, там установить и начать слэш писать там. Если мы говорим проof, то это просто как уже дополнительное приложение, которое поверх A Factory даёт определённый веб-интерфейс, чтобы, ну, визуально визуализировать не не на уровне там те консоли, терминала писать команды, а уже в более привычной манере, в таск-менеджере, создавать задачи и как бы отправлять их в путешествие, в этот workflow. под капотом будет то же самое, когда мы просто на тех же самых промтах можем работать, когда мы там, не знаю, explore вызвали и пишем: "Я хочу сделать такое-то, такое-то". Опять-таки ты начал с непонятного промта и пришёл к качественной задаче. Ну, насколько это возможно. А если мы говорим очеви, то здесь так не получится. Здесь тебе нужно все эти артефакты подготовить самостоятельно. Как ты их будешь готовить, возможно, там и что-то подключишь в виде там A Factory и сгенерируешь. Но факт в том, что артефакты в виде там ТЗХ, PRD и так далее, всё это будет генерироваться человеком и просто потом запускаться в workflow и ЛМка будет делать код. То есть здесь как бы просто упор на на спеки, на на артефакты, на на слой с человеком. Код мы делегируем ЛМке, и мы за ним не следим. То есть к тому, как он там написан, придерживается ли он там всех там паттернов и каких-то правил. Это полностью слой, э, за ЛМкой. И третий слой с валидацией - это уже программный слой, там бинарно расте. Он валидирует всё, всё, что сгенерировала ЛМка. Как он появился? Вот, возможно, это будет интересная тема. А когда я делал HLV, э чем она отличалась от A Factory? Там появился программный слой, то есть там появился туи терминальчик, где можно было посмотреть на каком мы этапе сейчас располагаемся, какой статус у задачи. И тогда я понял, что в целом, скорее всего, будущее за спецификациями, когда не сам проект важен, а именно важна продуманная спецификация, как он должен работать, какие у него должны быть ограничения, как он должен тестироваться, какие там подводные кони, камни и так далее. И вот прямо внутрь челv я вшил спецификацию и в процессе я подумал: "Да, интересно, но но это довольно сложно, а почему бы такое не сделать для вот factory, где это прямо идеально ложится и это ложится локально. И вот как раз так появился". Инof ещё почему появился? Я в процессе я использую A Factory. Вот любой проект, там буквально начало проекта, я сразу пишу A Factory Init и пошло. То есть это прямо стартовая точка. И получается, я в этом лупе сильно интегрирован. То есть помимо того, что мне приходится запускать workflow, а чекать план и всё остальное, мне ещё приходится перемещаться между сессиями в включать то кодекс, то клод. Я подумал, как бы было круто, если бы это было на уровне веб-интерфейса.
>> Человек, который только начинает, то есть что ему сначала поставить? То есть он ставит первое что-то для чего, второе для чего и третье для чего? То есть как бы ты это вот ответил на этот вопрос?
>> А я бы я бы всё-таки посоветовался. Зависит от того, от его целей. Если он действительно хочет развиваться вот в их генерации, как-то вообще прокачиваться, то я бы посоветовал ему ничего из этого не ставить и пройтись немножко вот по граблям и понять, как работают ЛМки. Ну, чтобы не думать, что это искусственный интеллект, как бы более приземлённо к этому относиться и понять вот эти все все проблемы эволюции, да, от этапа, когда ты думаешь, что промт всё решает, когда там далее там ээ как работать с контекстом, как выстраивать workflow и на этих шишках вот прийти какой-то такой SDD. Потому что даже когда ты придёшь к A Factory, это всё равно не, ну, не серебряная пуля там. То есть Factory в целом можно сделать расширение под себя, и оно будет не только что-то дополнять, оно может, а, перезаписывать вообще скилы, которые есть, дополнять их. Ну, невозможно просто взять и сказать: "Ребята, вот берёте, используйте вот эти вот скилы, между скилами обязательно сбрасываете контекст". Это было актуально вот ещё там пару месяцев назад. Пришли модели с с миллионным контекстом, и уже так нельзя делать. В в каких-то моментах нужно нужно думать: "А сколько вот я потратил там токенов?" То есть здесь, ну, вс не получится прямо без головы работать. Я общаюсь с некоторыми людьми программистами, и я не понимаю, как они могут не понимать банальных вещей, которые решаются за два вопроса. То есть, если он чего-то не понимает в проекте, он может спросить свой там идшку, что угодно там, даже GPT спроси, он ты сразу же получишь ответ на свой вопрос. Они почему-то это не делают. Но я там человек, который уже там 7 лет занимаюсь обучением разработчиков. Я понимаю, что разработчик разработчику рознь. И все те же самые проблемы, что мы сейчас видим при и -генерации, когда там не хотят поспрашивать у ЛМки, не хотят почитать, то же самое было. Не хотели читать документацию, не хотели читать фундамент, хотели быстрее в какой-то высокоуровневый инструмент залезть, изучить его и получать высокие красивые картинки. То же самое здесь. Мы хотим быстрее красивые картинки и тем самым, ну, скатываемся в уровень балбеса. Как бы 5% разработчиков являются действительно разработчиками. Так и здесь вот пришла ИИшка. Что бы там ни было, как бы это легко не было, как бы все не стали там суперразработчиками, только 5% будет действительно работать хорошо.
>> Ну, я встречаю очень мало кому, а кто поймёт вообще о чём речь и кто поймёт. И самое главное, что я бы хотел, ну, пусть тоже в этом видео хотя бы стереть немножко грань сложности. Потому что аа вот эти программисты, которые в принципе обычные люди, паттерн такой: я попробую установить, если у меня первый не получилось, второй раз не получилось, я третий раз пробовать не буду, потому что и так куча дел всяких. Собственно, самая сложность вот это вот в самом начале вот я что пытаюсь мм как бы подсветить, это что это, для чего это, как это использовать, как они увязаны между собой. Допустим, 10 уровней там вайбкодера, там программиста. То есть начально это только только что там курсор установил, да, или антигравити какой-нибудь, потом у него есть какие-то там, не знаю, полгода работы с ним, он освоил, допустим, он перешёл на второй на второй уровень.
>> A Factory, ну неважно, там второй уровень пускай будет. То есть первый уровень - это вот вообще понять, что из себя представляет ЛМки, как они генерируют, какие есть проблемы и что вообще вот в этом, как в этом хаосе выживать. приходит A Factory, он как бы вносит первую заплатку, и эта первая заплатка решает определённые проблемы, качества улучшаются, а при этом там потребление токенов и время на производство увеличивается, но как бы в перспективе оно всё равно даёт буст. А HLV - это как следующий уровень A Factory. То есть те, кто пользовался A Factory, те, кто пользовался SDD, они понимают, что как бы от хаоса мы всё равно никуда не уйдём. HLV как бы это следующий уровень, который пытается вот эти проблемы закрыть. Но при но при этом с ну то, как обученные ЛМки, а то, как они вс всё ещё пытаются придерживаться стека, да, который на котором они обучались, там не отходить от best practice, которые они там видели, на которых они обучались. А аof - это не это не уровень, это просто удобство. Это это дополнительный слой. Вот по D Factory, мы с тобой в прошлый раз общались, когда Handof только появился, и я тебе рассказывал, что а скорее всего останется только Клод, так как они там впереди всей планеты и так далее. И прошла там буквально неделя, и, в принципе, можно уже всё наше то общение с тобой забыть, так как хндоofф уже совершенно другой. Ну, у меня ваша скорость просто, я не знаю. Ну, короче, я так Давайте Open Cod, я только мыслю закинул, буквально там 3-4 дня, и ты говоришь: "Всё готово". Ну, типа это же не просто так. Это потому, что ты настолько заточил эти инструменты для себя, у тебя было всё заточено на клода, а потом ты бах, через 3 дня ты говоришь: "О, ну, OpenCд тебе поддерживается". Ну, то есть для меня это как показатель того, что у вас инструмент действительно не то, что работающий, он действительно вам, конкретно тебе помогает в этом же продукте. То есть это получается такой маховик раскручивающий. Вот это самая такоя поразительная штука.
>> Я сейчас наблюдаю, то есть, ну и я ещё PHP комьюниity большой вклад вносил в open source, там, в развитие и продолжаю общаться с людьми вот из PHP комmюниity. Есть вот ээ крутые авторы, крутые разработчики, которые только сейчас вот интегрируются, адаптируются с Иишкой. И вот недавно был такой момент, один из известных авторов написал, что вот Иишка всё ещё это полный хаос, так как я вот гулял там с собакой, скажем так, и мне пришла мысль о том, что я допустил ошибку, там возникнет Race conditionition в одном моменте, я там пришёл и, соответственно, пофиксил. А, а Иишка мне об этом даже не сообщила. И, и с его стороны это вот такой вот как бы пунктик минус выишку. А вот у меня точно такие же процессы происходят. Я такой могу гулять там тоже и думаю: "О, я там мы там упустили Race Condition, но я приду и добавлю инструкции и в будущем вот будем дополнительно проверять, и моя система будет развиваться. Это другое мышление, не ломать". ломать в любом случае, как бы мы от этого не уходим. Мы ломали и когда были просто там занимались крафтовой разработкой, руками всё писали, периодически что-то ломали. Так и здесь как бы ничего не изменилось. Мы что-то ломаем, но здесь уже более интересно. Здесь можно делать аудит. То есть,
>> ну вот этот подход мне очень нравится, потому что мы по факту получаем копилку опыта человека машина, человека машина, и они пересекаются. То есть человек такой: "О, я понял, что надо было вот так сделать". он записал и по сути он поделился своим опытом с машиной. То же самое машина тоже как бы там поработала, поработала, говорит: "Вот я там то-то, то-то нашла, обрати внимание, что теперь мы будем так делать, потому что по-другому не работаю". И таким образом мы, получается, переносим наши знания в нашу систему. И, собственно, из этого вопрос только получается, что мы должны сохранять на уровне чего? Спецификации, скилов или чего-то ещё?
>> Я как работаю, я каждый раз вот, например, даже выставляю сейчас лреквест. И появились контрибьюторы, которые мне помогают, а они делают ревью на на своих агентах и прикрепляют аудит. И я по я после захожу, пишу там в агенту посмотри, что что за комменты пришли. Давай пофиксим. Он фиксит, и я с ходу его переспрашиваю, почему так вышло, что мы пришли к этим проблемам. Как так вышло, что а мы вот эти моменты упустили? А он мне там начинает давать какие-то ответы. свой хаос присылать. И я начинаю, ну, в процессе понимать, что вообще происходит. И организационный момент в рамках этого openсорса также развивается. То есть у меня появились, например, чек-листы в каждом слое, в каждом пакете. Вот там архитектура разделена на пакеты. То есть - это отдельный пакет, а агентский код - это отдельный, там MCP - это отдельный. Всё это разделено. И внутри каждого присутствует чек-лист MD. И в корне присутствует чек-лист MD. увидит этот чек-лист и как бы есть вероятность, что он его пройдёт. И вот эта эволюция тоже происходит. То есть это это не просто мы сидим такие, нам сказали рантаймов не хватает, давайте напишем промт добавь рантаймы. Это это не так работает. Каждая задача, каждый фикс, он меняет само ядро организационное. Как как мы с этим должны вообще дальше жить, работать? Потому что как когда проектом занимаешься только ты, это одно, когда им занимается, его используют много людей, это универсальный проект, у них у всех свои хотелки, у них у всех свой стек, операционная система, там что-то ещё дополнительно. Это совершенно другой уровень, там начинает всё сыпаться. Невозможно просто взять какой-нибудь A Factory, HLV, Handf, и это не закроет твоих проблем опыта работы с их генерацией. То есть здесь нужно набивать шишки.
>> Ну тут тут в любом случае это не золотая пуля, потому что шаблона универсального не будет вообще никогда. То есть это какой-то точка старта, которая может облегчить,
Да? А потом ты на эту точку старта всё равно наслаиваешь свои какие-то хотелки, ну, то есть специфический опыт, там что угодно туда. То есть всё равно мы не получаем какой-то шаблон, который типа вот шаблон установил и всё у тебя будет всегда хорошо. Нет, скорее это стартовая точка, после которой ты всё равно слои вот свои добавляешь, добавляешь, добавляешь, и ты вот только ответственные, какие ты там добавил, какие убрал и так далее. Но просто стартовая точка уже есть. Тебе не надо как бы прямо с чистого листа начинать. Вот это самое приятное.
Есть ещё Aworkspace у меня проект. Я его я его тоже вот, например, использую. То есть он не обязателен, но я создаю внутри вообще всех своих проектов единую сеть в виде AI Worksспейса. Я просто создаю вот этот проект, объединяю в группу, там AI, там какой-нибудь проект, например, и расшариваю какие-то общие артефакты, спецификации директории. Там есть и поиск по директорин скан и полнотекстовой поиск. Вот сейчас добавил по MD файлам и тем самым там работая, ну, скажем так, а в определённом проекте, который объединён там, ну, это просто мо можно сказать микросервис, да, и есть и есть какой-то ещё сервис, который вот поставляет определённые данные. И вот поркспейсу я забираю вот из этой сети как бы спеки по тому, как это всё должно быть устроено, и быстро генерирую новый сервис. Ну вот, вот, скажем так.
А либо ещё момент, я сейчас пишу книгу по как раз генерации и генерации, и я туда добавляю советы. Вот я прямо в в процессе я я до сих я до сих пор считаю себя, ну там, суперджуном в плане и генерации, и постоянно сталкиваюсь с какими-то новыми проблемами, но я при этом стараюсь сейчас не ходить по одним и тем же граблям по кругу, а я вот как раз всё это записываю в эту, ну, скажем так, книгу. И она тоже объединена через AWorkspace. И у меня есть глобальный скилл э для добавления нового раздела в эту книгу. И и скилл работает так. То есть на уровне скила там инструкция следующая. Зайди в Aworkspace, посмотри, что там расшарено. А там расшарена типография, как правильно писать новый раздел, правила, там сохраняй лаконичность, добавляй в навигацию и так далее. И он в этой инструкции, в глобальном скиле всё это смотрит. И как бы мне вот за один промт я просто там на что-то наткнулся, быстро вызываю скилл, пишу эту проблему, он мне создаёт раздел в этой книге. Я там потом захожу вли.
Правильно я понимаю, что у меня просто один из вопросов был такой, что о'кей, типа внутри скилы отдельного проекта, о'кей, а как мы мы можем организовать, если я хочу глобально настроить свою систему под все мои проекты, да? И я так понимаю, что Workspace это тоже делает, собственно. То есть ты делаешь как бы связку, есть какое-то глобальная репа, где все твои там правила, хотелки, привычки, там что что угодно, и ты можешь к нему подключаться из любого другого проекта. по сути такой коннектор к к чему угодно. Получается, он решает эту проблему в ядре, как бы МПшка, как раз, чтобы получать эти данные. И это не совсем скилы, то есть скилы скилами это дополнительный инструмент, чтобы вот получать данные. То есть у тебя может могут быть может быть скилл, который говорит: "Вот делай, делай, делай", а, например, референсы аэ будешь получать из Workspace. То есть, чтобы не дублировать, к примеру, вот есть какие-то данные, которые нужны там куче проектов, они они они не в не в скопе, не не в одном скиле, да, они вот много где нужны. Как раз этот workсpace создаётся, чтобы чтобы его расшаривать. Это это может быть и на уровне скилов, и на уровне проектов. Ну тут уже куда фантазия и как с этим взаимодействовать.
>> Действительно, от задачи сильно прямо зависит. Смотря, что мы делаем. Очень бы хотелось какой-то, скажем так, чтобы элмка помогала тебе в зависимости от твоей задачи, а она сама решала тебе пять вопросов задать или 25 или там 35 и так далее.
>> Ну, вообще там есть Skill Explore, который, ну, я использую. Вот я буквально перед созвоном э использовал на на простецкой задаче просто добавить день открытых дверей, когда подписка бесплатная, и он мне около двадцати вопросов задавал. То есть не могу сказать, что мало. Просто он так устроен, что не столько эффект вау, а сколько, ну, по факту, чтобы вопросы действительно влияли на то, что требуется. Но и при этом нужно нужно не забывать, что ЛВМКА не способна ээ затронуть сразу всё. Даже любое выполнение задачи, она не она не сможет, скорее всего, выполнить с первого раза идеально. То есть это лотерея, как как не старайся, это будет лотерея. Может быть, получится, но скорее всего нет. И дальше, если вот итерировать там, верифицировать, валидировать этот результат, и иной раз можно там, не знаю, 10 циклов пройти, и она на и она на каждый при очищенном контексте, именно при очищенном, если он не будет очищен, она будет пытаться бороться за свои решения, она будет находить какие-то проблемы вот там, вот там, вон там. То есть, ну, они они в целом так устроены, что она должна дать какой какой-то ответ. и сказать, что всё супер, ты молодец. Там как бы
>> то есть у меня представим, что в доках написано всё, что я хочу, да, возможно, что-то я упустил, но не глобальное что-то. Вот если у меня есть в своей какой-то форме, неважно в какой. Вот дальше как я должен поступить вот с этим у меня в папке, допустим, там 15 marдау файлов. Вот ка какой пайплайн самый простой для меня, когда я уже полностью продумал весь проект, но не в таком виде, как Factory. Вот дальше какие следующие там три шага я должен сделать, чтобы, ну, правильно поступать именно используя Factory?
>> Основной главный скилл запустить, который AVE, чтобы определить вообще на основе документации, какой стек будет использоваться, а какая инфраструктура будет использоваться и вот какие-то общие вопросы будут заданы и будет сгенерирована стартовая структура проекта. А раз уже вся документация продумана, в принципе, уже там эксплор не нужен, можно будет сделать milстоны, то есть roadmap, есть такой скил roadmap, то есть это это документация целиком про проект. Нужно разбить на фазы. Вот будет разбив разбивка на фазы. И, соответственно, начинать нужно постепенно вот с первой. Первая загоняется либо в эксплор можно снова пройтись. И вот есть фаза, вот нужно сделать такое. Есть документация, как референс. Кстати, можно даже вынести там что-то важное в референсе. Есть такой тоже Skillway Factory. И далее можно сделать экспор вот по именно по этой фазе. В процессе будут ещё заданы какие-то вопросы. А самое важное понимать, что э вызов скила и итоговый сари - это ещё не не конец. Это не факт, что всё было хорошо. Если есть время, если проект важный, желательно можно ещё раз прогнать. можно прогнать несколькими, там, в нескольких сессиях, несколькими моделями, там и клодом, и джептишка, и чем-то ещё. Каждый хорош там по-своему, каждый рандомит по-своему и будет задавать разные вопросы. И в итоге прийти там, ну, понять, ну, насколько есть время. Вот всё, все вопросы заданы, меня устраивает. Главное же при этом, чтобы у вас тоже в голове была картина, что вообще происходит, как с какими проблемами можно столкнуться при реализации. То есть всё-таки это нужно фиксировать, а-а, чтобы потом это перепроверить. И дальше уже составление плана. План составляется, есть skill improve, который улучшает план. Это, опять-таки, это всё создано только вот и по специфике работы с лмкой, чтобы она на второй итерации могла что-то ещё охватить, увидеть и, возможно, дополнить. Поэтому и контекст лучше очищать, чтобы раньше я брал все эти 20 пунктов и запихивал все там с клотом и говорил: "Давай, дружок, фикси, если всё это актуально, ну, перепроверишь на всякий случай, мало ли, это чушь". И и он всё это дело фиксил. А уже сейчас я пришёл к то, что это тоже неправильный подход, что нужно брать не весь вот этот сам арест двадцати пунктов, а только первый пункт, отдавать его. Он там делает обратно возвращать. Точно сделал. Да, теперь сделал. Всё, теперь второй пункт. Итак, каждый пункт, они бывают там по три, по четыре раза, он, ну, никак не может справляться. А что говорить о двадцати? Нужно при приходить из проблем. Вот есть проблема, я работаю, я понимаю такую-то проблему, я вижу, что есть вот такой вот инструмент. Интересно, а он мне вроде как подходит. Я пробую, он решает проблему? Не решает. Как он решает? Хорошо, плохо, какие-то альтернативы, возможно, посмотрю. Итак, со всем остальным. Следующая проблема, там, а как мне вот шарить контекст? У меня он и там, и там, и там, и там какие инструменты есть? О, Workspace, ну, либо что-то ещё. А, попробовал, решила проблему, не решила. И так дальше. То есть исходять исходить исключительно из проблем. Я я точно также действую. HF тоже самая история. Если тебе нравится всё контролировать, э, через терминал там писать команды, скилы вызывать и видеть, следить за всем процессом и изучать планы, смотреть, что там происходит, даже, ну, возможно, и смотреть код, как-то дополнять его, тебе и не нужен хндоof, получается. Вот он лиш лишнее усложнение в твоей жизни, которое тебе не требуется, которое вызовет кучу дополнительных вопросов. Если у тебя нет проектов, которые нуждаются в свой челове, это, ну, вообще сложная архитектура. Зачем тебе вникать? А ты можешь просто держать в голове, смотреть как бы вот подобные видео, которые мы с тобой выпускаем, и знать, что такие инструменты есть, и в какой-то момент просто вспомнить,
>> что просто знать про инструмент - это одно, но если ты один раз его хотя бы попробовал, поня понял как бы суть, да, да, ты можешь его не использовать. Ну, как бы взял бн запилу, поигрался, посмотрел, что она может, что нельзя, такой: "О, понятно, она существует, если что, вернусь к ней". Но если ты не попробовал, ну, прямо руками, я думаю, что человек, ну, даже не вспомнит потом про это. То есть именно я я к тому, что именно попробовать, именно как оценить, что может, что нельзя, удобно, неудобно, ну, и хотя бы запомнить на уровне, когда это можно и где использовать на будущее. Ну, возможно, будет как бы ээ оно иногда не выгодно совсем, особенно если ты там делаешь очень что-то простое. То есть если ты делаешь какое-то действие один раз или два раза в год, зачем эту штуку автоматизацию вообще за
>> Ну, >> а вот как раз разработчик, да, ему особо и не нужно об этом думать. Автоматизация какая-то, какие-то спеки. Это пусть человек выше думает. Я вот код написал, код работает, я его ещё и тестами покрыл, как бы чего, чего вы от меня хотите. А, а когда ты именно вот занимаешься проектом, то помимо всего прочего тебе там документацию нужно поддерживать, у тебя там докер конфиги, которые нужно постоянно там подгонять под какие-то изменения, у тебя там C слой, у тебя билд, вот эта автоматизация с мейк-файлами, и ты сделал фичу, у тебя всё это устаревает. ЛМКА не может это запомнить. Как раз вот A Factory всё это дело держит в тонусе. Имплементацию ты вызываешь и дальше идут чек-листы. А документация, а тесты, а на уровне логирования, всё чётко. Вообще держать проект в тонусе. Вот что важно. Как раз когда он нарастает кодом, логикой, э не уйти в этот хаус, когда его невозможно поддерживать, когда одно лечим, другое колечим. Мы там и приходим в какой-то момент вот HLV, а до этого я использовал флт архитектуру, ну это я её так назвал, там фича слайд, можно её назвать вертикальные слайсы. То есть суть в том, что у тебя все фичится на отдельные модули, ну, можно сказать, модульная архитектура. И вот в и всё работает внутри контекста этих модулей. Там у каждого модуля своя документация, сво свой entry point с каким-нибудь там RIDMI и так далее. И в идеале запускать там агента вот именно в этом модуле, чтобы он вообще не знал о в верхнем мире. Тогда ему будет проще и и контекста-то будет меньше.
>> 100% согласен. Я всегда стремлюсь именно к этому, что если мы решаем задачу, там должен быть минимальный контекст только для этой задачи и всё.
>> Да, в целом, если и присутствует, вот фича, если присутствует и, то есть она делает вот это и вот это и вот это, это уже это уже как бы её нужно разделять. Вообще лю любая задача Лэмки, если там присутствует и - это уже проблема. Если ты говоришь: "Нужно проверить вот это и вот это", то ты уже спешишь, то ты уже как бы получишь не очень хороший результат. Вот как раз не получится. Но это эта проблема присутствовала всегда. Она она не только вот у нас сейчас, когда мы начинаем генерацию кода, она она была и у разработчиков.
>> Как ты сейчас на Open Source в целом смотришь? Потому что он же как бы глобально, то есть с одной стороны раньше, если кто-то сделал какую-то функцию, она супер ценная, потому что он потратил там 50 часов на неё, и другой эти 50 часов не будет тратить. Это супер ценное. Ну то есть совсем уже по-другому всё. человек, который Open source сделал уже там 5 лет назад, и у него проект текущий есть, он же по сути свой же проект может настолько будет стануть вперёд, а что в целом не особо я, кстати, наблюдаю, но факт такой, что это же можно сделать. И третье, то, что, собственно, надо же эту проверку делать и так далее. И это тоже отдельная как бы отдельная работа. То есть, на твой взгляд, вообще, а, open source куда пойдёт, в какую сторону? Потому что вроде как надо пересмотреть вообще в целом отношение, которое раньше было к
>> вообще это, мне кажется, моя первая депрессия. Вот когда появилась яишка и когда она дала такой буст в развитии, я понял, что у меня там есть проект adдминпанель Moun Shine, который уже 5 лет, и я просто, ну, не знаю, там день и ночь её разрабатывал, и я понимаю, что она больше, ну, не настолько нужна. Она вот она умирает. А, то есть то же самое уже можно сгенерировать, и это прямо меняет правила игры. Правила игры изменились, Open source изменился, но он всё ещё живой. И это можно смотреть вот по по A Factory, по подофу, по Open Clow тому же самому. То есть как будто бы стало даже лучше. Комьюнити нужно серьёзно перестроиться. Как раз чем я сейчас и занимаюсь в своём комьюнити, и какие-то плоды уже есть. коммьюнити подключаются, они они ревьют дополнительно, тратят свои токены, и результат получается даже лучше. Другие подходы получаются в организации. Они она и раньше организация была суперважна и кучу времени уделяла, а теперь ещё больше, потому что вот этот весь хаос, который тебе присылают, нужно как-то контролировать. Нужно, потому что если раньше там пулреквест - это был пять файлов, потратил на это, а сейчас приходит там сразу по 100 файлов. Всё, всё там изменено. Ну ты не можешьто ревью никак. Ты ты можешь ревью только иишкой, чем я, собственно, и занимаюсь. Там я не я не выдумываю проекты. Я не выдумываю проекты с с целью: "О, какой бы сделать проект, чтобы у меня там звёздочки были на гитхабе или чтобы люди думали, что я более крутой эксперт, там я смог им что-то продать". Я просто сам развиваюсь, и я в процессе сталкиваюсь с проблемой. И это просто уже мой опыт. Я знаю, что если решение сделать открытым, оно будет более более крутым, потому что народ извне найдёт кучу проблем.
>> Вести себя в этом комьюнити. То есть какие правила ты для себя выработал, да, чтобы а openсорсный проект правильно поддерживать, чтобы люди, которые хотят именно что-то полезное принести, чтобы они не проблему приносили, ну, в смысле, разгребая потом за ним, а именно как бы, чтобы это нормально всё работало. То есть, ой, как бы простые человеческие правила, культура, уважение. И пускай приносят проблемы. В процессе того, как они принесут проблемы, мы с ними пообщаемся там на уровне комментарий, и они для себя сделают вывод и также также прокачаются.
>> Вот. И здесь у меня такой вопрос ещё рождается. О'кей. Если у тебя контрибьюторов, допустим, 100, они выкидывают что-то там прямо, ну, много всего, то, чтобы это за всё проверить, у тебя же токенов прямо может съесть прямо очень много.
>> Ты должен принять такое правило игры. Сейчас токены, раньше время, как бы в Онрсе, когда я писал, тоже как бы я там работал в найме ещё в то время, и мне надо было выделить день, например, чтобы какие-то, ну, и что-то самому написать, и поревьювивить. Тем более раньшемок не было. Надо, надо было каждую строчку там смотреть, разворачивать, потому что на гитхабе сложно смотреть. Надо смотреть вдэшки, а ждать, пока человек потом ответит на твой фидбэк, да.
>> То есть я ещё не видел он сорса, который, ну, как бы двигается через лмки. Ну, по факту так и есть. То есть ты не пишешь, они не пишут, у вас взаимодействие между лмками, и это некий другой, ну, вообще всё другое. Это это коммьюнити вот, который я сейчас создаю в плане и разработки вот и мира. Она мне даже больше нравится, чем комьюнити, которая была среди разработчиков, так как здесь более большее количество интересных людей. Вот мы с тобой познакомились, да, вот и мы на одной волне все общаемся. Это супер интересные люди, кто-то с большой аудиторией уже есть там медийные. И все делаем вот определённые проекты, автоматизируем там наш бизнес, который уже был, улучшаем, да, ну, местами, может быть, даже хвастаемся. Это вот тоже пришла такая интересный момент. Мы там периодически вообще не чем-то хвастаемся. Там вот смотрите, я такое-то сделал, такое-то сделал, столкнулся там с такими-то проблемами, а вот смотрите, как вот такая моделька себя ведёт там.