Spec-Driven Development: как писать код с AI-агентами в продакшене | Сергей Белов, Яндекс

Ну, я для себя различаю типа вайпкодинг как такой промышленной разработки с лэмками. ПЛэмки как инструмент они мульти мультиплицируют скилл человека быстро, эффективно, типа получив вот этот вот в процессе вау эффект, удовольствие и так далее и тому подобное от работы. Я увидел вот для себя вот этот кратный профит, который, ну, 100% окупает усилия, затраченные на изучение этого этого инструмента. Вот когда я приходил с этим в команду, особенно на ранних этапах, я сталкивался с сопротивлением в этом месте.

Всем привет, дорогие теле и радиозрители подкаста Гриненко Pro. В этом выпуске хочется раскрыть Spec Driven Development. И для этого, а, я пригласил в виртуальные гости Сергея Белова, который на практике с этим разбирается. Серёга, привет, спасибо, что пришёл.

>> Привет, Вова. И привет, радио и телеслушателям.

>> Расскажи, пожалуйста, немного про свой опыт в разработке и, в частности, свой опыт с агентами.

>> Про опыт разработки. Ну, в двух словах. С года, наверное, 2003 я занимаюсь коммерческой разработкой в том или ином виде. Из них в Яндексе работаю с 2008 года, там с июля. Ну, то есть уже там полжизни сознательной, кажется, даже больше. Как это? Всю дорогу я был многоночником. Сначала занимался бкэндом, потом около фронтэндом, потом инфраструктурой. около инфраструктуры, потом инфраструктуры в полный рост. Самый длительный мой период был- это в Яндексе. 6 лет я занимался построением инфраструктуры фронтенда.

>> Всё, что связано с автоматизацией тестирования, CD и так далее. Вот. И после этого >> понял, что хочется чего-то поменять. Пошёл искать работу поближе к железкам, ну, к железкам, работающим в реальной жизни. на стыке с автом немного поработал в команде где-то полтора полтора года в общей сложности или год а который занимается в яндексе постро построением инфраструктуры центров то есть начиная проектирование серверных стоек серверов в том числе на уровне железа на уровне схемотехники и после этого >> а где-то в середине двадцать третьего года пришёл в команду дома Яндекса, где занимаюсь руководством команды разработки прошивок умно-домовых устройств. Такой Shift из около фронтэнда в хардварную, хардкорную разработку.

>> Класс. Очень широко успел захватить. А расскажи про путь в нейронках. Я понимаю, что он сильно короче.

>> Гораздо короче. Всё. Так. Я пропустил вот этот вот начало, короче, рассвет. В общем, можно сказать, я не застал такой ранний. А я скептически был настроен поначалу. Примерно в середине, ну, где-то в августе двадцать пятого года я первый раз попробовал курсор. Ну, у меня такой был смешанный опыт, что-то вроде получилось, что-то вроде не очень. А-а, кого-то быстро заканчивалось. Ну, какие-то сложности там были. В общем, отложил в сторону. Было много проектов осенью запускали много унывых устройств, как всегда у нас традиционно перед Новым годом, короче, было не до этого, не до изучения инструментов, не до адаптации их к собственному workкflow.

>> Вот. Но вторую попытку я предпринял где-то после новогодних каникул, после отпуска своего.

>> И с точки зрения опыта и, ну, такого качественного результата на выходе, это было небо и земля по сравнению с тем, что я пробовал раньше. Модельки за это время успели сильно подрасти в качестве, а, в возможностях. Вот. А, ну и в компании у нас появилась, э-э, как программа выдачи квот токенов и всего такого. Грех этим было не воспользоваться. Можно было попробовать разные инструменты. Я, собственно, пробовал разные инструменты. Помимо курсора я пробовал sourceный. Вот в Яндексе есть Яндекс Cд Assistant, который на базе руккода, который я уже всё аа пробовал. И сейчас использую плоткод в как это его вариацию в виде экстеншна для кода. Ну то есть не консольную версию, а extension. Сразу же осознал, когда начал пользоваться, вот получил какие-то первые позитивные результаты, сразу же осознал, что есть проблемы с со стабильностью уровня качества на выходе. Ну, то есть, как это сказать, сессия, от сессии к сессии качество сильно плавает. И, э-э, иногда условно эту какую-то задачку можно решить даже более-менее сложную, а, за предсказуемое время, типа там сел, часик, что-то поделал, и через часик есть осязаемый результат, которым можно поделиться там за комишить, запушить транк и так далее. А иногда, ну, прямо нет. Вот. Мне захотелось сразу что-то с этим сделать, и я начал изучать и смотреть по сторонам, что индустрия уже предлагает из решений. Тогда ещё скилы, по-моему, только-только заанонсили их. Ээ вот я не помню только, где они первыми появились, в курсорели или в или он тропиков, да. Ну, в общем, как-то это было то >> прямо вот только-только зарождалась, короче, вот эта история с какой-то реюзабельностью. То есть до этого были только рулы, которые ты кладёшь себе в проект, и вот они типа всегда у тебя в системном промпте. И погнали. Вот. А, ну понятно, у них есть ограничения. Потом начали появляться скилы, и я обнаружил, что на базе скилов, а, хуков, которые тоже не у всех были в тот момент, в какой-то дикой связке, типа клишка, плюс хуки, плюс набор скилов, как-то заточен вот под какой-то некий флоу, >> а, появилось достаточно большое количество, ну, там я сходу нашёл там больше пяти разных фреймворков. Я их для себя назвал типа аи агентик фреймворки, не знаю, как они на самом деле правильно называются. Вот. И составил себе toлиist, что вот типа я хочу все попробовать на реальных задачках прикладных где-то эта реальная задачка была моя типа продакшн задача в основной работе в Яндексе. >> Где-то это был какой-то типа project или какой-то эксперимент. А мне важно было просто получить какое-то внутреннее ощущение законченности задачи, где я понимаю тот результат, который я хочу получить. Вот как только я такую задачку смог у себя в голове формировать, я садился и вот пробовал что-то новенькое, какой-то новый новый подход, новый инструмент, вот типа для новой фреймворк.

>> Ты говоришь, что а выбрал вот какие-то какой-то набор, с ним поэкспериментировал, потом в итоге к чему-то ведь пришёл и остановился. Вот расскажи. Что стало победителем, почему и как именно при

>> Я действительно к чему-то пришёл, но не остановился. А не могу сказать, что текущий сетап меня полностью удовлетворяет по многим аспектам. Но давай начнём с того, что из себя представляет текущий сетап. То, что для меня является state of the art, но как бы удовлетворённость примерно процентов 70-75. Вот так этим сетапом. Я использую клодкод, как я уже сказал, в виде экстеншена для йс-кода. А с этим, конечно, есть проблемки разные связанные, но вот с терминалом как-то мне не очень удобно. Хочется видеть всё в одной среде перед глазам перед глазами в одном окне буквально, чтобы можно было как-то очень быстро поменять соотношение к окон. То, что переключаешь всё где-то читать надо много текста, хочется побольше. А я работаю не на большом мониторе, как многие разработчики это делают. Я работаю на ноутбуке. Вот у меня есть MacBook снацати седьюмо, а, >> который всегда со мной везде, в любой ситуации. И вот, собственно, я и пытаюсь постоянно какой-то сетап адаптировать под под него. Вот с монитором было бы сильно проще. Я вижу, как мои коллеги делают, покупают широкоформатные такие формы монитор, на котором помещается гигантское окно в ширины. много панелек, типа, и это классно, конечно, решает задачку, но нет.

>> Давай сразу обсудим, почему тебе нужно много панелей. Ты, получается, постоянно погружаешься в сгенерированный код, не отдаёшь это всё на откуп полной автоматики, а тебе вот надо контролировать реально всё, что сгенери.

>> Честно скажу, код я практически не читаю уже. Ну, то есть мой уровень доверия к результату. Мне нужно читать спики, которые генерирует лмка. Потому что давай вот сейчас расскажу про сетап как бы и расскажу немножко про флоу, который вот для меня кажется достаточно эффективным. Проходкод я сказал, в качестве Gentic фреймворка я использую Open Spec. Я посмотрел сразу же на несколько и для себя выставил какой-то вот хит-парад по на основе того, что я прочитал, да, про него на сайтах, документации там и так далее. А Open Spec мне показался самым, ну, как сказать, это типа, если сравнивать его с Super Powers, я думаю, большинство знает их самый популярный в маркетплейсе антропиковском вот ientic framework. А я начал с него, ну, изучать его с точки зрения, что он из себя представляет, увидел внутри очень много вещей, которые не относятся к моему >> сетапу вот с точки зрения разработки кода, который я пишу. То есть что-то там было про Рубии, что-то там было про гит прямо в скилах, ну, типа общих, как решать задачу. Так как я пишу ход для Яндекса 95% задач у меня, то вот это всё нужно было бы как-то дополнительно обыгрывать либо делать форк, а, править, поддерживать актуальность. Ну, короче, мне этого не хотелось этим заниматься, поэтому я посмотрел, а что же есть вот такого типа агностик, да, или там language агностик. Open оказался таким решением. А плюс мне это решение показалось даже по документации, как бы следующим шагом после. Вот типа люди что-то попробовали стихийно, а потом такие: "Так, ладно, давайте теперь попробуем сделать хорошо, ну, как бы вм background up, что называется, и сделали Open spec. А я начал пользоваться, решать задачу. Вот буквально этот фреймворк предоставляет такой онбординг очень понятный. Ты типа пишешь Open specбоardдинг. Он такой: "А мы сейчас изучим твой проект, найдём парочку задач, которые можем решить простых". И вот типа попробуем зарешить. Он там начинает с того, что крепает тудушки по твоему коду. Он находит там несколько, предлагает тебе на выбор. Ага. >> Ты можешь там сказать не что-нибудь другое. Вот конкретно вот это и всё. И очень быстро провод тебя по флоу. Ну там буквально за 15-20 минут можно, ну, понять и почувствовать, что из себя предлагает процесс, ой, представляет процесс работы с Openect. Ну и вот, короче, и я попробовал, мне понравилось. Ну, в смысле, когда я увидел, как выглядят артефакты, какой объём у этих артефактов, там есть ограничения. Ну, то есть он прямо задаёт какие-то правилам, по которые по которым артефакты генерируются, не только с точки зрения контента внутри, ну, в смысле, про что, да, будет этот артефакт, а в том числе там есть строгая структура, есть ограничение не больше, чем какое-то количество слов. Вот. Это помогает, потому что артефакты не раздуваются, как с некоторыми агентами в режиме пленинга. Они могут тебе просто там вот так вот генерить несколько килобайт текста, и ты потом всё это читаешь.

>> Практически сейчас уже любой интерфейс для работы с агентом предполагает, что у него хотя бы как минимум есть два режима. Есть режим собственно планирования и режим фигач задачу. И вот режим планирования, чем принципиально для тебя отличается от подхода Open Spec и вообще вот Spec Driven Development, что ты в это вкладываешь? Потому что сейчас есть как минимум три разные школы подхода. Там большинство, наверное, в итоге пришли к тому, что планирование - это о'кей. Но вот кому-то хватает просто переключаться между двумя режимами по ходкею и всё. Кто-то говорит, что важно всё-таки, чтобы у нас сохранялись спеки в виде маркдауна. И дальше этот эта школа форкается на тех, кто говорит: "Маркдаун устарел, нужно всё в HTМле делать". А и есть те, кто говорят: "Зачем нам вообще какие-то текстовые файлы, если мы генерим код, нейронки прекрасно читают код. Код - это и есть отличная спека, и этого ровно достаточно. и в случае проблем, чтобы люди смогли туда заглянуть, и абсолютно идеально для самих нейронок. И вот ты выбрал вариант, когда ты генеришь специально сформированный marкдаун, но ты используешь его как источник истины, если пользуешься подходом Open Spec. Вот почему из этих вариантов такой?

>> По сравнению с первым, где у тебя просто есть режим плнинга.

>> Разница в чём? Даже у меня в команде разработчики пользуются разными агентами. Ну там в силу привычки, в силу того, у кого какие квоты сейчас доступны, ну и так далее. Не все пользуются клодкодом, кто-то пользуется там Яндекскода системе, например, который как бы как базовый продукт в основе Rкод уже не развивается. А кто-то пользуется курсором, кто-то пользуется, я вот знаю ещё ребята кодом. Это не скорее не не непосредственно про мою группу разработки, да, но ребята рядышком в средних подразделениях используются кодом тоже. И у всех этих агентов режим планирования работает по-разному. Ну, типа и с разным уровнем качества, потому что с разной структурой на выходе, потому что у всех разные промты про этот режим планировали, ну и так далее и тому подобное. То есть и мне самому иногда приходится переключаться между, когда там антропивковские модели недоступны, какой-то причине работать, продолжать хочется, я переключаюсь на курсор и, ну, там, пользуюсь, например, его композером. Ну, соответственно, мне хочется какой-то предсказуемости в процессе вот той, к которой я привык. Open spec в этом смысле, так как это внешнее по отношению ко всем агентам решения. Оно позволяет эту предсказуемость получить. А второе, а ты ещё говорил про школу мыслей, что типа вот код - это спецификация, да? Тоже такая школа мыслей, где-то там есть, присутствует. Вот кода лэмки генерируют очень быстро и очень много. Спецификация в этом смысле как промежуточный документ достаточно она сильно короче, чем код и более понятна человеку. Ну, то есть на естественном языке понятно, что с какими-то правилами, может быть, с какими-то словами, маркерами специально там с какой-то структурой в каком-то смысле, возможно, избыточно с точки зрения вот именно формулировки текста, но тем не менее типа читать спецификацию, читать дизайн, документы, построенные в определённом формате и понимать, что самое главное. То есть человек читает код же не просто для того, чтобы его попарсить, там как-то поинтерпретировать и и всё. Типа он пытается понять, что этот код делает на более высоком уровне и как он встраивается в систему целиком, там как он взаимодействует с соседними какими-то частями. И в этом смысле, если в результате работы с, ну, в диалоге с лмкой у нас есть не только код, но и, э, какие-то промежуточные документы, которые перевели к этому коду, это упрощает, во-первых, код preview. То есть мы по-прежнему перед Мёрджем, когда решаем сложную задачу, хотим, чтобы кто-то из наших коллег посмотрел на результат вот того, что мы сделали, и провалидировал, что мы там наделали не херню какую-нибудь, вот, а то, что нужно. И спецификация, которая вливается в код вместе с пулреквестом, в смысле, вместе с кодом в пулреквесте, она помогает быстрее погрузиться в контекст. Вот прямо буквально я, когда только-только начинал в команде рассказывать про Open SPC, когда делал полреквесты, я просил человека, говорю: "Вот смотри, есть папочка Opensпе. Сначала прочитай то, что там поменялось". Вот если там есть у тебя какие-то вопросы, откоменти и можешь даже дальше не смотреть. Потом я сделаю вторую итерацию, исправлю вот эти вот смысловые замечания, переделаю код. После этого можно будет посмотреть и дальше, если тебе хочется, как бы. Но вообще, типа, я говорю, мне нужно от тебя не ревью кода, насколько он хороший, насколько он решает вот ту задачу, которая описана, а провалидируй, пожалуйста, постановку самой задачи и ээ в формате спецификации то, как смыслово должен быть устроен под типа решение этой задачи выраженной в виде спецификации.

>> Вот. И ээ обратную связь, которую я слышал от разработчиков, они говорили: "Да, прямо круто". Ну, то есть вот там полреквесты я делал, ну, большие, типа там почи строк плюс сразу, ну, там какие-то рефакторинги, какие-то там причёсывание там и так далее. Так что не могу согласиться, что код и есть спецификация. Код может быть, ну, в реализации в виде кода может быть упакована дополнительная сложность. Вот, например, мы делаем проекты. И наш код должен работать под разные аппаратные платформы. И спецификация будет описывать логику этого кода вот на уровне как бы постановки, да, и каких-то требований там на уровне дизайна и на уровне флоу выполнения кода. И в зависимости от платформы отличий не будет. А вот то, как будет написан код, он будет пронизан как раз-таки вот этой разницей между разными аппаратными платформами, фреймворками вендеров, там, не знаю, версиями библиотек каких-то общих, которые там в этих фреймворках есть там и так далее и тому подобное. И вот эти вещи, на мой взгляд, человеку даже не обязательно ревировать, потому что их должны валидировать тестами автоматически. То есть, если мы, а-э, код, написанный нейронкой, можем скомпилировать, прошить ээ в МЦУ автоматически желательно, а не руками, перезапустить сок, по логом, понять, что в целом программа выполняется, и увидеть в логах какие-то маркерные точки, ну, связанные с изменениями, которые мы сделаем. На мой взгляд, этого достаточно для того, чтобы не смотреть в деталях, что там написано, типа не тратить на это время.

>> А вот чтобы добиться такого, а как вы валидируете полноту и качество тестов? Они тоже генерятся по такому же подходу, когда вы сначала накидываете требования в диалоге с Open Spec, потом рендерите сами тесты и дальше уже ими валидируете код. Или это какой-то другой процесс?

>> Это тот же процесс в рамках, э, вот разработки с Open Specмка генерит не только код, но и тесты к этому коду. Вот что прикольно с Openспеком. С лмки есть, ну, некая постановка в задаче, да, разбитая на конкретные требования вот этой спецификации. Ну, они такие достаточно точечные формулировки. А, ну я не знаю, нужно тут рассказать, как выглядит вообще спецификация и вообще какой набор документов генерирует Open Spec.

>> Да, давай расскажем. И есть смысл ещё раскры, да, раскрыть ещё, как оно в Brраун работает, когда у тебя уже есть большой проект и ты вносишь какие-то точечные из

>> Вот, кстати, про Brownfield - это как раз ээ одна из фишечек Опспека. Они у себя прямо на сайте говорят, что вы типа можете делать не только новый проект, начинать использовать OpenSP, а в проекте, который у вас уже давным-давно существует, написано какое-то количество кода, просто берите и следующую фичу делайте при помощи OpenSP. Это нормально работает. А и при этом не надо, типа для всего существующего кода писать эти спецификации, ну, типа из кода вытаскивая эти Openпеки. Типа так тоже можно, но не обязательно это делать. можно ограничиться вот только новым кодом и всё. Немножко про структуру документов. Тут важно говорится, что OpenS эту структуру не диктует. Он предлагает стартовый пресет с этой структурой. Но если по какой-то причине эта структура э не работает в вашем случае там или работает не во всех случаях, можно эту структуру помофицировать. Ну, прям как угодно. То есть там есть конфик, через который можно сказать, а какие документы в какой последовательности получаются и какие документы, какие артефакты от каких зависят. Вот. И дальше уже клишечка онспековая будет гарантировать, что эти документы будут рендериться, ну, даваться, короче, на рендеринка ровно в той последовательности с теми зависимостями, которые вам нужны. Вот эта гибкость меня тоже подкупила, но при этом я не делал свой пресет в итоге, пока, по крайней мере, возможно, когда-нибудь потребуется. Про артефакты, э, в стандартном пресете четыре. О, сейчас 3че сейчас начну перечислять и вспомню. Я как это не считал, а заранее. Значит, есть проповый документ, который по flow появляется. До того, как создать этот документ, а с точки зрения flow Open Spec можно с лмкой поисследовать задачу. То есть там есть некий некий шаг Exploration, буквально команда называется Open Spec Explore. Она на выходе не даёт никаких артефактов. По сути, она наполняет контекст сессии нужными какими-то знаниями, там, типа условным пониманием, да, как, э, что мы хотим сделать в рамках решения конкретной задачи. И вот этот шаг можно пропускать для простых задач, можно его делать, когда вот, например, я им пользуюсь, когда мне самому не до конца понятно, какой образ результата я хочу получить. То есть я просто начинаю с какой-то потребности, типа вот, я не знаю, делаю тулу. и хочу там в конфижик добавить возможность настройки какого-то аспекта. Я даже не знаю, как я это поле хочу назвать. Вот условно я просто начинаю с того, что типа вот смотри, есть конфиг, вот там вот где-то в структурке хотелось бы уметь настраивать вот такую вот там поведение какое-нибудь или аспекта какой-нибудь работы этой туловины, как это лучше всего сделать. Ну и всё. И с этого начинается диалог. Потом оно что-то там почитает, код предлагает, как обычно, какое-то решение. Оно ещё не правит ни артефакты, ни код не трогает, ничего не пытается глинерить. Ну, в какой-то момент предлагает, типа, кажется, всё понятно, давай припозл, может, сделаем. Вот с этого момента начинаются цепочка артефактов. На первом шаге появляется документ пропон формализует задачу какой-то текст. Там есть структура обязательная про то, что мы хотим сделать, что мы не хотим сделать в рамках этой задачи. То есть что является целью, что не является целью. И какое-то описание достаточно короткое, но ёмкое. А для того, чтобы как это вход для следующего шага проработки был, ну, чуть более качественный, чем обычный промпт, который человек, скорее всего, напишет ручкой.

>> Вот этот документ фиксируется как один из артефактов Ченджа. Следующим шагом на основе вот этого пропозла генерируется дизайн-документ,

>> который пропозл приземляет в конкретную кодовую базу. Вот если у вас ещё проект существует и вы делаете первый чейндж с использованием подспека, то он изучит кодовую базу вашего проекта и расскажет в дизайн-документе, как именно он будет реализовывать эту фичу с точки зрения кода. Там уже могут быть какие-то упоминания классов, каких-то файлов, вот как оно там может быть примерно разложено. Но этот документ тоже такой достаточно короткий, но при этом ёмкий. А его можно провалидировать. Вот я в обязательном порядке валидирую пропозл, чтобы убедиться, что там всё, что мне нужно, учтено и нету лишнего. Или вот то лишнее явно сформулировано в разделе, что это не является целью вот этого ченджа. и потом валидирую дизайндокумент на предмет того, что он адекватно понял структуру кода и изменения те, которые он предлагает, но в целом как бы адекватный. Я бы, наверное, тоже так сделал, если бы сам рассуждал или вёл этот диалог с коллегой у доски, да, или что-то придумывали, маркером рисовали и пришли примерно к этим заключениям. Вот. И после дизайн документа формируются уже два артефакта. А это спецификация и файл с тасками. В спецификации буквально дизайн раскладывается на требования такие очень гранулярные

>> и валидируемые. То есть каждое требование - это некое утверждение, типа, в каком случае что должно быть. То есть when и там when может быть несколько там типа условий. Условие это and условия это and условие это then типа то-то and то-то and тото. Вот такая понятная простая структура, но при этом она это не код. Ну то есть там нету в в спеке упоминаний кода и каких-то сущностей в коде вообще, по-моему. Вот, насколько я помню, там, наверное, может зависеть от задачи. Я вот сейчас сходу вспомнить не могу. По-моему, если мы там, э, какую-то ставим задачку, в которой нужно помодифицировать конфиги, он может там чего-то в спеку задыхать, каких-то названий конкретных полей или каких-то структур или ещё чего-то. Ну, по-моему, про код конкретно вот про функции, да, там или про какие-то объекты, классы, он не пишет. Вот я сейчас что-то засомневался. Надо бы провалитировать, но, по-моему, нет. А, и вот параллельно со спецификацией он пишет документ tasks, в котором буквально по пунктам сгруппированным по разделам перечисляет, как именно он будет решать задачи. Ну, то есть буквально, что ему нужно сделать по шагам для того, чтобы решить задачу, описанную, соответственно, в пропозле, дизайне и вот наборе спекфайлов. Спецификация - это набор файлов. Про каждый аспект он создаёт новый файл и группирует э-э требования в рамках этого файла. Ну, про конкретную область, если он про что-то прос он там выдумывает, грубо говоря, эти области сам, но на это тоже можно влиять. Ну, при ревью я это делаю, так смотрю, мне не нравится, например, как он декомпозировал это всё булочкам. Я ему говорю: "Нет, давай так, типа, есть вот такие сущности, перегруппируй, пожалуйста, под вот такие сущности".

>> Мм, короче, это про вот артефакты и про флоу я рассказал. А

>> дальше после того, как готовые таски и спецификация, можно выполнить ээ команда, команда называется Open Spec Apply, и она применяет вот эту вот этот change к текущей кодовой пасе. Уже начинает редактировать файлы, создаёт новые там типа и э в рамках этого же процесса пишет тесты. И так как у нас требования сформулированы достаточно гранулярно, он может в процессе этой работы свериться с тем, что на все спеки написаны тесты. То есть здесь за счёт вот самой постановки FL и структуры артефактов мы, ну, условно, автоматически получаем какое-то адекватное покрытие кода- тестами. Вот если мне этого недостаточно, а мне почти всегда этого недостаточно, я использую ещё такой подход. Я прошу его запускать тесты, генерируя coverage отчёт, и добивать покрытия, например, по брончам в коде до уровня 80%. И вот этот дополнительный шаг валидации,

>> который я

запускаю уже после того, как он код написал. Там ещё есть после apply команда verify, которую можно запускать, можно не запускать.

Он обычно сам что-то проверяет, но если задача более-менее сложная, то я запускаю команду verify дополнительно. Он, ну, в определённой структуре делает проверку. То есть там есть какой-то кастомный промт, что он делает проверку по нескольким аспектам. И основная задача — это провалидировать, что всё то, что написано в пропозл, в дизайне, в тасказках и в спеках, действительно попало в код, и вы ничего не упустили. Вот.

И после вот этого шага валидации, который в рамках флоу, я уже делаю дополнительный шаг про покрытие кода тестами. И это позволяет как раз-таки держать покрытие на приемлемом уровне. При этом, ну, условно, не самому его оценивать, по-прежнему делать это при помощи агентов, потому что все современные инструменты запуска тестов позволяют это покрытие посчитать.

А я тут поуточняю ещё. Во-первых, когда у тебя готова спека и уже, ну, буквально понятно, что дальше делать, меняешь ли ты модель для экономии или у тебя всё делает Opus?

Я тут, наверное, сейчас кащу вещь скажу. С Онспеком у меня всё делается на этом. Ну, как раз-таки для экономии в какой-то момент я начал пользоваться неопусом, а сонетом для того, чтобы понять, а разница-то вообще будет какая-нибудь?

И увидел, что разницы практически нет. А при том, что Opus вот этот 4.7 с миллионным окном, он тупо там в 2 с половиной раза дороже. Ну, короче, как будто бы оно того не стоит. И вот если я действительно хочу немножко поэкономить клоту, я переключаюсь на Sonnet. Если у меня условно начало месяца, кто-то ещё свеженькая, короче, я пробую разное. И у меня тут строгих каких-то правил нет, что вот этот этап надо делать с Opus, а вот этот этап надо делать какой-то более дешёвой моделью. Я экспериментирую, продолжаю экспериментировать, скажем так. И скорее я вот как это склонен, наверное, использовать не самую дорогую модель до тех пор, пока она работает. А вот если мне результат по ощущениям перестаёт нравиться, тогда я переключусь на, например, Opus 4.7, 4.7 с миллионным окном.

Там ещё же есть момент, связанный с тем, что вот... мм... кажется, если пытаться прямо выжать максимум экономии, да, из этого процесса, нужно несколько раз переключаться туда-сюда. Например, на этапе Explore достаточно какой-то более дешёвой модели для чтения файлов, для того, чтобы понять, как решать задачу там и так далее. Возможно, на этапе дизайна, вот когда пропозди на основе пропоузла, где мы планируем конкретные изменения, как их встроить в архитектуру, там уже может быть нужен Opus, а потом на имплементации, когда уже список тасок подробный и спеки, можно опять вернуться на Sonnet. Но, ну вот лично мне, например, сложно это держать постоянно в фокусе внимание, что нужно туда-сюда переключаться. И, короче, я тут больше верю в то, что в какой-то момент ээ вот эта вот история, она будет встроена в сам инструмент, который будет драйвить весь флоу.

Вероятно, уже сейчас на хуках можно её... ну, вот на хуках не знаю, там вот есть же субагенты, да, в которые можно, ну, по крайней мере, в кладкоде можно делать субагенты и явно говорить ему, что вот этот субагент должен работать вот с такой моделью. Но я пока не пытался самостоятельно заточить, например, Open под такой флоу, чтобы условно у меня был, ну, стартовая сессия это была типа такая общая сессия некого оркестратора, в которой я запускаю, например, Explore, а он такой: "Вот давай сейчас субагентом мы тебе поресерчим". Просто ещё вскодовом экстеншене кладкодовском это всё плохо работает. Ну, то есть все субагенты, которые запускаются в оскодовом экстеншене, они ничего не показывают назад. Ну, то есть ты видишь, что стартанул супагент, и, ну, мы просто типа ждём, а что там происходит, оно не видно. То есть здесь надо всё-таки использовать терминальный кладкод. Вот, тем более с последними изменениями, которые они сделали, они там классно сделали, что можно сессию каждого субагента, даже в режиме вот, где он там спаунит несколько агентов одинаковых, одноранговых, которые просто пол задач разгребают, и можно в каждый, ну, в сессию каждого агента отдельно провалиться и посмотреть, что там вообще происходит, умешаться и так далее. Я пока не попробовал этот режим, видел только его на видосиках, но я подумываю уже и как раз вот пытаюсь придумать, а как же ж мне использовать вс-коде всё-таки с терминалом, чтобы это было удобно, чтобы, ну, бонусы получить от этой фичи новенькой. Вот, короче, если я освою такой способ использования, тогда будет смысл попытаться заточить вот этот опытспековый флоу под разные генты, чтобы, ну, условно, вот этот тюнинг случался сам, чтобы не надо было тратить на усилия, помнить, вспоминать.

А хочу тут ещё кусочек доуточнить про управление контекстным окном. Получается, что ты вот на каждую такую фичу итерацию используешь одну сессию, в процессе её не очищаешь?

По-разному бывает. А разработчики OpenS рекомендуют либо начинать каждый этап в новой сессии, либо в случае с клод-кодом клир вызывать. Я если решаю маленькую задачу, сравнительно маленькую, я знаю, что типа полностью до конца я в этой задаче смогу добежать без компакшена. Я делаю всё в одной сессии. Не, ну, не вижу смысла, не вижу смысла терять контекст. Ну, там как бы, если даже explore, у меня стадия была, она такая достаточно прямолинейно прошла, потом мы сделали пропози. Даже если я там делал какие-то уточнения в процессе, ну, я не вижу, я не видел влияния на качество результата, если я не очищаю сессию. А вот если я на эксплоре или пропозиле уже съел практически весь контекст, то вот здесь я, скорее всего, ну там даже если осталось процентов 20, я скорее всего начну либо новую сессию, либо сделаю клиент просто, чтобы в процессе имплементации не упираться в компакtion.

А если ты перейдёшь на схему с субагентами, то фактически же у тебя будет постоянная новая сессия. И вот эти передачи контекста кусочечно с потерями в каждую сторону. Ну, то есть это будет достаточно сильно отличаться от того, как оно работает сейчас. Интересно будет посмотреть, как это скажется на результате.

Вот мне тоже интересно, потому что на вот этих запусках субагентов я пробовал, а я потом чуть позже расскажу про следующий шаг, который я пробовал после Опенспека, и как раз поделюсь своими соображениями на этот чёт. В общем, вопросики у меня есть к такому подходу. Я не уверен, что будет классно. Мне пока не очевидно, что лучше. Типа миллионное окно контекста, в котором, ну, как бы тоже там есть ээ спецэффекты, да, когда мы приближаемся к концу и когда внутри этого окна есть уже противоречивые знания и или вот такое очищение постоянно на каждой итерации, на каждый следующий шаг. Мне кажется, что, ну, в большинстве случаев будет работать какая-то золотая середина. А вот где она? Мне кажется, её даже в некоторых случаях автоматически не вывести, не сформулировать. Ну, то есть можно самому принимать решение, как действовать, в каком случае, и вот только так, а, получать какой-то результат удовлетворяющий.

Ну, посмотрим. Вот у меня как раз в этом же ключе ещё одно уточнение про то, когда в рамках одной сессии ты и фичу генеришь, и сразу же тесты к ней. По практике периодически агент начинает читерить. Он видит, что ему нужно решить вот эту верхнеуровневую задачу про фечу и... подтасовывает тесты так, чтобы всё сошлось. А когда это две именно полностью независимые истории, вот он такой сделал фичу, потом всё забыл, и он не фичу пытается дотащить, а именно по-честному решить задачу с тестами, то там никакого читинга, он прямо будет по-честному биться над тестами. Вот ты не сталкиваешься с вот этой проблемой?

Мне кажется, я не сталкивался с этим, когда использовал OpenSPC по той причине, что он пишет тесты буквально по спецификации, то есть он спецификацию превращает в тесты. И у него как будто бы, ну, то есть у него точка опоры — не код, который нужно провалидировать, что он правильно работает, а точка опоры — это спецификация. И в том промпте, который вот Open Specли докидывает в контекст, про это написано. Мне кажется, поэтому я не попадал в такую ситуацию. Там по-прежнему бывают стран странности с тем, что тесты очень поверхностные. Ну, то есть они буквально вот проверяют как-то супер дословно следуют спеки и ну туда приходится вмешиваться. Но вот туда приходится вмешиваться как раз, когда покрытия по коду недостаточно. Я это как-то замечаю и прошу его именно по отчёту о кардже дозакрыть какие-то ветки. Вот. А а там у него не остаётся шансов уже, ну, там срезать углы. То есть он буквально должен в отчёте увидеть, что эти ветки кода теперь тоже покрыты. И, короче, задача, постановка, мне кажется, важна. Вот, ну, главное в этой постановке, да, на что опираемся.

Ты сказал, что выбираешь OpenК и формат Маркдауна именно по причине того, что он легче воспринимается человеком. Это в каком-то смысле созвучено с тем, что, например, делает Бреслов в кодспик, где он говорит, что нужно изобрести такой специальный язык, который бы нам как раз позволял достаточно лаконично, но при этом полно ставить задачу, а чтобы и человек был в состоянии её осознать, и чтобы из вот такой постановки можно было более-менее уверенно гарантировать результат. То есть, чтобы у тебя источником истины в полной мере стала спека и тебе код можно было каждый раз выкидывать и генерить условно заново. И с таким подходом уже появляются какие-то репозитории, где кроме спеки ничего нету. И в качестве способа установки написано: "Скажи своему агенту вот поспеке всё это собрать под себя". И это прикольно. А, но я так понимаю, что в твоём случае всё-таки это ещё не так, что всё-таки финальный артефакт — это код, а спек как бы дополнительный такой инструментик, упрощающий кодрев.

Не совсем. Вот про код давай чуть вернёмся. Я, когда его заанонсили, пошёл смотреть, что это из себя представляет, я не увидел там никакого языка, который описывает вот что-то, ну, условно, да, вот как был переход в своё время от ассмблера к высокоуровневым языкам, типа C, а потом и C++. Там есть какие-то чёткие правила, как конструкции языка в итоге превращаются в ассемблерный код под каждую архитектуру. Это правило трансляции типа однозначное. Вот CД Speak больше похоже всё-таки на Open Spec в том смысле, что там заданы правила, ну, формирования документов. Ну, типа как, я не знаю, ну, короче, я не увидел там какой-то особой разницы. То есть это не про язык ээ не про язык программирования более высокоуровневый, вот в том смысле, в котором, э, языки высокоуровневые являются вот таким, как это сказать, способом описать ээ типа тот код в виде машинных кодах, которые непосредственно там процессор будет исполнять. Ну совсем нет. То есть, может быть, там цель такая и стоит, но мне кажется, для того, чтобы это действительно так заработало, нужно очень хорошо затюнить модельки, которые будут генерировать код про под этот язык. Ну, то есть, чтобы они как-то однозначно, ну, или там в каком-то очень узком коридоре превращали конструкции из вот этого CДS языка в конструкции на разных языках программирования. Что, я так понимаю, там идея в этом, чтобы можно было из исходной спецификации код получить, ну, типа, под любую платформу, под которую тебе надо. Хочешь веб-приложение, хочешь приложение в телефоне, хочешь там, я не знаю, дисктопное там и так далее, на разных языках, в том числе. Короче, я тут пока скептичен в эту штуку не очень. Ну, ну, в смысле, не то, что не верю, мне кажется, сейчас мы мы не там вообще. И если как надо дать вырасти, подрасти немножко вот этим инструментам, посмотреть, как они действительно будут решать задачи. Может быть, действительно у кого-то найдутся ресурсы на то, чтобы позатачивать модельки под вот это. И оно действительно будет работать лучше, чем то, что есть сейчас. Пока. Пока.

Да, я смотрю на спецификации того же Опспека как штуку, которая дополняет код и которая, если она вместе с кодом комитится в репозиторий, а разработчики Опенспека говорят, что типа оно должно, ну, в смысле, не надо эти артефакты выкидывать. Вот, кстати, ещё одно отличие других инструментов планирования в иагентах. Они создают планы по умолчанию, по крайней мере, курсор, clotкод где-то, ну, типа там в Users, в Homeки точка что-то с/poject. Пойди найди, короче, где это место ещё лежит, потому что там какое-то странное имя с этим уникальным идентификатором в пути.

Бывает даже очень сложно потом сопоставить. Вот я вижу какие-то планы есть, а к каким проектам они относятся без заглядывания в них бывает невозможно. Вот. И OpenSP как раз вот перемещает вот эти артефакты прямо рядом с кодом кладёт, и они являются тут как документацию написать. Ну, то есть, если по старинке, типа, как мы писали код, да, там можно было просто сесть и начать фигачить, а можно было там посидеть, подумать, что-то пописать, потом сделать дизайн-документ, оставить его в репозитории как как какой-то артефакт, который фиксирует в более простом для восприятии какой-то аспект системы. Ну, типа, как она устроена, как устроены потоки данных там между разными компонентами и так далее. потом вернуться к написанию кода, опять вернуться к этому артефакту и типа в параллель вот разрабатывать систему так, чтобы этот артефакт тоже жил и актуализировался вместе с изменениями в системе. Вот OpenS — это такой артефакт, который не нужно поддерживать руками, который в актуальном состоянии как раз-таки агент поддерживает за разработчика, но разработчик при этом тоже участвует в момент постановки очередной задачи и в процессе валидации результата. Ну, то есть где-то он там своим экспертным взглядом и какой-то технологической интуицией замечает странное, вмешивается в нужные моменты и докручивает, в том числе эти артефакты до валидного такого состояния, с которым можно дальше проект развивать успешно. Да. Вот так я отношусь к Open Spectртефактам как части проекта. То есть пока что всё-таки этого недостаточно, чтобы опубликовать на гитхабе только спеку и сказать, что, ну вот там сам код не имеет значения, каждый сам себе под свой кейс из него соберёт то, что счита.

Ну, мне кажется, нет, потому что разные модели из этого получат разный результат, в том числе с точки зрения качества, точности. А, ну даже буквально как бы если требования будут описаны максимально подробно, но не факт, что...

Да, да, я даже не верю, что та же модель сделает в следующий раз всё ровно так же, а не хуже.

Но при этом ты ведь сам говоришь, что не читаешь практически никогда сгенерённый код. Да, но ладно, давай так, типа, ээ здесь у меня, да, скорее такое эмоциональное ощущение и больше, типа, я не верю, что это нормально будет работать, но есть ещё второй фактор, как бы, а зачем так делать? Ты же каждый раз на то, чтобы получить код, будешь сжигать токены, и это дорого будет каждый раз воспроизводить этот код. Ну, типа, почему почему вообще хотять это делать? То есть токен — это же какой-то ресурс.

Вот тут может быть несколько причин. Если ты это публикуешь э для конкретной какой-то платформы, это одно. Если ты, э, публикуешь только спеку, то под платформу агент соберёт под целевую, точечно, ровно так, как нужно потребителю. Это раз. Второй момент. Если, допустим, твой любимый язык you name it, а у потенциального пользователя какой-то другой вообще набор пожеланий, он сгенерит под себя и так далее. И вот разных каких-то таких вот кастомизаций, которые можно получить из спеки под свои предпочтения, их достаточно много, и ты их никогда не сможешь учесть, если уже даёшь финальный отлитый код. Ну и к тому же, как ты сам говоришь, разные модели делают по-разному. Очевидно, что завтрашняя модель будет делать лучше. Если ты положил спеку, а человек только завтра её добыл и по ней сгенерил, то, возможно, у него даже лучше будет код, чем тот эталонный, который был у тебя.

Мне кажется, всё зависит от продукта, в том числе, ну, и от решения, которым ты таким образом хочешь поделиться с миром. То есть условно вот там это была история слм вики, да, которая описана в виде геста. э-э, Карпаты, по-моему, выкладывал. Тут понятная история. Он делился некой концепцией. Вот когда ты делишься концепцией, наверное, есть смысл опубликовать её в виде наборе спецификаций каких-то. И при этом тре, ну, сами спецификации могут быть не суперподробными, а такими достаточно поверхностными на уровне просто, ну, какой-то такой детальной постановки более или менее системы. Ну, то есть которая затрагивает разные аспекты поведения этой системы. Но без деталей, как конкретно это реализовать. Ну, буквально, ну, там, не знаю, какие поля быть должны у заголовков этих викидокументов там или что-нибудь в таком духе. То есть здесь остаётся простор для творчества, и модель типа может сама это как-то заполнить. И вот у тебя будет уникальное решение на базе какой-то общей спецификации, которую ты посмотрел. Но мне кажется, таких, ну, проектов на общем фоне типа меньшинство, ну, какая-то маленькая доля, но да, для них вполне в текущей в текущем контексте типа эри лмок инвалидный валидный способ делиться с миром. Ну, условно, как бы я бы совершенно точно не не выкладывал какой-нибудь проект в духе там прошивки для какого-то устройства, которое должно поддерживать какой-то протокол.

Ну как это? Это будет оченьоченьочень детальная спецификация в таком случае. Ну, типа максимально детальная, которая будет, по сути, пересказывать код. Ну там она может быть компактнее, особенно если это будет какой-то какой-то язык специально заточенный. Но, ну, короче, пока для меня это странно. Не было, видимо, примеров таких проектов.

Пример, где сами Open AI в таком ключе пытаются продемонстрировать возможность — это их framework Symphony, который вот ровно так опубликован. Они рядом положили папочку с какой-то конкретной имплементацией. Говорят, что, ну, в принципе, вы, конечно, можете взять готовый код, но вообще по дефолту просто скажите своему агенту, мы как раз на ваших токенах немножечко ещё подзаработаем.

Так что обязательно пользуйтесь, хорошая история.

А, о'кей. А давай тогда вот такое ещё уточнение. Сейчас, э, относительно недавно в терминах времени, но бесконечно давно в контексте того, как меняется всё в районе искусственного интеллекта, а стали говорить о том, что а зачем писать спеки в Маркдауне, который недостаточно выразительный по сравнению с HTМом, где ты можешь себе генерить прямо интерактивные дашборды и в них гораздо быстрее. Ну, то есть вот ты говоришь, что спека решает задачу гораздо быстрее погрузить человека в контекст происходящего, а HTML с возможностью там сложной вёрстки каких-то виджетов и так далее ещё упрощает эту задачу. Не пробовал ли ты от Маркдауна перейти к htмlльному представлению?

Давай с двух сторон отвечу на этот вопрос. С одной стороны, м вот когда мы говорим про спекипековый, там же есть некоторый флоу, по которому база спеков проекта наполняется. То есть там есть спеки, описывающие существующий код. И когда ты вносишь изменения в этот код, ты заводишь такую сущность, как change. То есть change начинается с пропозла. В нём есть дизайндокумент, в нём есть набор тасок и есть дельта спекс, так называемый. То есть это формат, в котором описывается, какие требования изменились, какие удалились, стали неактуальными, а какие добавились новые. И в процессе, вот я, кстати, не сказал же, когда рассказывал про флоу, там после аплая есть важный шаг. МР называется. Там происходит применение вот этого ченджа на существующие спеки. То есть вот как раз дельтаспеки творческие при помощи лмки применяются на существующие спеки, которые лежат рядом с кодом. То есть он буквально читает, какие новые, какие модифицированы, какие добавлены, смотрит так, чтобы типа внести эти изменения без противоречий там и модифицирует файл со спеками. М, ну, выкидывая куски ненужные, модифицирую нужные, добавляю нужные, а саму папочку с чейнджом складывает в архив. И вот когда ты делаешь лреквест, у разработчика есть возможность, в том числе не только папочку в архиве увидеть, как добавлена куча всего какого-то текста, а в том числе посмотреть и провалидировать, как изменились Markдаун файлы со спеками. Вот.

Давайте теперь посмотрим. Если спеки — это какой-то HTML, и в этот HTML вносятся изменения сложное, как оно будет выглядеть для человека на кодрев. Он будет вынужден глазами парсить какой-то достаточно вербозный формат для того, чтобы в нём разобраться, что там конкретно поменялось. Ну, мне кажется, менее удобно. Типа, собственно, Маркдаун поэтому и появился, несмотря на то, что уже существовали какие-то языки разметки текста, появился маркдаун как типа такой более простой для восприятия. И там потом и инструменты подтянулись, ээ, что они могут показывать диф в маркдауне, в том числе в визивик формате. То есть ты видишь даже с форматированием, как у тебя там заголовочки подвигались, там списочки появились, где цвета, подсветка и так далее. Даже таплицы есть. Ну, такие дифвизуалайзеры, которые нормально тебе покажут, как поменялась таблица, а не вот это вот там палочки непонятные. Вот, короче, мне кажется, HTML здесь просто тупо проигрывает в удобстве такого представления.

А вторая часть твоего вопроса про то, что пробовал ли я, я попробовал в курсоре. Я вот в какой-то момент, ээ, когда антропиковские модели у нас были недоступны, я вот решил: "А что, курсор есть, кого-то есть, надо не останавливать же работу". Типа посмотрю, там как раз прилетел апдейт, в котором они, ээ, добавили канвас. Это называется вот канвас — это же как раз ээ интерактивный план. То есть ты можешь не в Маркдауне получить план, который текстом тебе описывает и там студу списком в конце, а сгенерировать канвас, в котором будет что-то описано. И у них там, ну, как я понял, в тот момент, вот когда я этим пробовал пользоваться, это типа что? Это они сделали какую-то НПмовскую либу с какими-то компонентами на реакте. И вот заточили, значит, свой композер под то, чтобы он мог эти канвассы как-то генерить. Ну, типа, обладая знаниями про то, из чего этот канвасс можно склеить, из каких верхнеуровневых сущностей. Ну, по сути, это на выходе получается приложение на реакте. То есть это даже не HTML, потому что, ну, голый HTML интерактивный генерировать, ну, очень сложно и вербозно. Ну, то есть это, во-первых, дофига токенов сожрётся на то, чтобы JavaScript весь нужный для интерактивщины сгенерить CSS какой-то повторяющийся, я не знаю, ещё что-то. Вот при таком способе, ну да, вот так оно работать будет. То есть у тебя на выходе будет получаться какая-то программа, которую нужно пойти и смочь попарсить, почитать. Ну, можно её и в интерактивном виде наглядно там потыкать, посмотреть какие-то таблички. Он там табы делает там для того, чтобы компактнее тебе что-то представить. какие-то варианты там, так далее, где-то текст есть. Ну, штука прикольная, но вот я пока не понял, что она там, ну, не ощутил, что она сильно удобнее, чем обычный план в Марктауне. Ну, то есть, возможно, для каких-то кейсов, где, ну, я так понял, что, ээ, они предлагают этот канвас сгенерить на выходе ну не в процессе планирования, типа на разных этапах. То есть, если нужно что-то визуализировать для человека, то, возможно, вот такое представление в виде аппликейшена на базе вот этого вот набора компонентов, который они назвали канвас — это типа более наглядный будет способ с какой-то предсказуемостью там и так далее и тому подобное. Но вот так, чтобы прямо спеки писать в этом, мне кажется, это, короче, про разные, ну, типа неподходящий инструмент.

Как будто бы спеки должны быть именно такие аликстовые.

Вопрос, да, какую задачу решаешь? У тебя задача по сути именно сопроводить div, а там скорее такое bird viw, когда у тебя вот большая кодовая база, ничего непонятно, и ты такой: "Нарисуй мне вот красиво, как всё устроено со схемками и кнопочками".

О'кей. В общих чертах, мне кажется, ну, по крайней мере, ту часть SPC Driven Developмента, которая покрывается Openспеком, мы раскрыли. А давай тогда про то, вот у тебя есть опыт с созданием каких-то openсорсных вещей самостоятельно. И есть опыт работы с большой командой над большим сложным проектом. Давай поговорим про разницу между подходами. Что работает там, что работает не так или вообще не работает, когда становится слишком много, э, частей участников. И почему так?

Сейчас я думаю, с чего с чего тут. Ну, в смысле, разница-то есть. А, думаю, с чего начать. Давай как это на шаг назад мысль проговорю. Где-то я у кого-то её услышал, мне она зашла. И мне кажется, так сейчас и есть, что типа лмки как инструмент, они мультиплицируют скилл человека. То есть, если у человека мощный скилл разработчика, архитектора, он хорошо понимает предметную область, в которой он пытается решить задачу, то, ну, с очень высокой вероятностью опыт использования лмки для решения этой задачи у человека будет супер позитивный. Типа будет очень рад.

что у него этот инструмент есть, что он ему суперсильно помогает и так далее и тому подобное. Если скилл отсутствует, ну или там достаточно низок, то, ну, тут непонятно.

И если сравнивать вот по этому аспекту разработку каких-то проектов индивидуально Openourсонах, м >> там нужно обладать соответствующим скилом на высоком уровне для того, чтобы мочь задачу действительно решить быстро и эффективно, типа получив вот этот вот в процессе вау эффект, удовольствие и так далее и тому подобное от работы с лмкой.

И весь мой опыт, ну, при внесении изменений в какие-то openсоourсные проекты. Вот я там делал свой плагинчик, ээ, ну, пока ещё не доделал, но типа сделал прототип. Вот как ты там упоминал, не упоминал. Там с тобой до встречи разговаривали. Да, у меня был опыт, я как раз на нём хотел обкатать новый, >> ну, типа Framework, он называется All My Outpot. >> А я попытался найти какую-то замену Openспеку, посмотреть, что ещё есть, какие задачи она решает, какие не решает, какие решает лучше там и так далее.

Я у меня была задача, которую я вот как-то достаточно быстро сформулировал для себя, там выбрал. >> Был готовый готовый фреймворк или даже продукт, для которого нужно было написать плагин. Вот есть такое средство автоматизации умных домов проводное, называется Нonбор к нему устройства подключаются по разным протоколам, включая там мопа по RS485 проводному соединению, там, Zigb и так далее. И я захотел, а, пробросить все эти устройства вот со своей унодумовой автоматизацией в экосистему Яндекса через Metкол. И там есть программка тире библиотека тире whatever. Короче, какое-то готовое решение на гитхабе называется Bridge. Напскрипте написано, реализует протокол, использует open sourceную реализацию тепскриптовый мето и так далее и тому подобное. И вот типа я обнаружил, что можно сделать плагинчик, через который можно зарегистрировать все нужные тампоинты, устройства и потом этот бридж зарегистрировать закомишнинуть в экосистему Яндекса, и в этом эти устройства прорастут и будет доступно локальное управление.

>> Я понимаю все аспекты этой системы. Ну то есть я сам разрабатываю умный дом, я закоп с протоколом. Я, ну, даже типа не сталкиваясь с самой реализацией на тепскрипте, я прекрасно понимаю, как она будет устроена. Ну, типа в терминах высокоуровневых, какие там сущности есть, как они между собой связаны там и так далее. Мне не нужно тратить кучу времени на то, чтобы разобраться в этой предметной области. там ironбоards.

С другой стороны, я уже там на тот момент потратил какое-то время для того, чтобы развернуть свою инсталляцию домашнюю, подключать какие-то устройства, увидеть тоже, как они там выглядят в системе вот в айронбордовской на уровне конфигов, как их настраивать, какие сущности там есть, там типа регистры. Ну, по сути, регистры на общей шине. У каждого адреса есть, у каждого устройства есть уникальный адрес там в пределах какой-то размерности. и так далее и тому подобное. Вот. И как бы, ну, для меня эта задача абсолютно понятна с точки зрения постановки. Я понимаю на старте, э, понимал на старте, что для того, чтобы её решить, нужно написать много кода. Ну, реально много кода, поддержать все типы устройств. Ну, как бы, >> ээ, причём у каждого устройства там есть свой набор регистров, да, есть документация про это. Всё.

Вот это вот эту вещь я, например, не, ну, в деталях не знал, естественной, но, ээ, как бы обладая опытом, пониманием, как как система должна быть ну как разные части системы работают поразень, типа, как их именно объединить концептуально, мне оставалось только решить достаточно большое количество механистических задач, переложить документацию на каждое устройство. типа изучить её, да, переложить в конкретный способ делать маппинг, там разобраться детально в устройстве топиков у айронта, чтобы по этой структуре автоматически генерить тампоинты, кластеры, атрибуты и вот это вот всё. И вот этим с этими задачами прекрасно справляется лмка, то есть с механистической работой. Здесь посмотри документацию на каждое устройство, на карту регистров, там, на ещё чего-то. Вот здесь тебе доступ к компьюте серверу на, пожалуйста, беспарольный специально, чтобы можно было там, выполняя москито, запуская москито клиент делать любые выборки, читать любые данные, типа, если тебе не хватает знаний из документации, вот тебе типа плагин, вот его код лежит специально для тебя счекаутил, чтобы не надо было на GitHub лазить. Вот здесь вот есть документация, вот здесь есть пример рядышком в папочке лежит такого же плагина. похожего там. Вот, пожалуйста, изучи и всё.

То есть сколько там я за от старта работы до получения первого работающего решения, когда я прямо запустил и увидел эти метерные устройства, у меня там прошло, ну, заняло где-то часов 8-9, ну, такого нон-стоп кодинга. Я бы не назвал это, причём вайп-кодингом, потому что, ну, я для себя различаю типа вайпкодинг такой промышленной разработки с улмками. А-э, в чём разница, собственно, когда я решаю задачу с лэмками, я структурированно подхожу к процессу работы. То есть я пытаюсь декомпозировать задачу на какие-то части, не пытаясь сразу же такой типа: "А вот напиши мне финальный результат, всё, я пошёл пить чай, приду, проверю". >> Типа нет. Я понимаю, что это, скорее всего, быть невозможно. Она где-нибудь споткнётся, там, начнёт ходить кругами, типа, и мне придётся всё равно вмешиваться, понимать, где мы находимся сейчас, как-то ситуацию разруливать.

Вот я бил задачу на куски, типа, сначала вот там занимался тем, что в диалоге с лмкой проектировал архитектуру. >> Много времени у меня ушло на только на это. То есть часа три, наверное, а я проектировал архитектуру. использовал вот этот новый инструмент All My Clot Code. Его режим планирования, он не такой структурированный, как Open Spec. Ну и там вообще нету понятия спецификации. И там вот как раз более привычные планы на выходе. Но Open Spec я использовал для валидации. Мне хотелось понять, насколько ойдко в сравнении с Он спеком, типа с тем опытом OpenСпека, который у меня есть, будет выдавать результат, ну, типа более лучшего качества или более низкого качества. А придётся ли, короче, за ним пристальнее следить и там внимательнее принимать результат и так далее.

Я какой подход выработал? Я основную работу делал в одной сессии при помощи вот по myot код и шёл по его flow там типа вот мы планируем сейчас вот там же несколько итераций, по-моему, девять итераций было, формируем вот этот план тире дизайн документ. Там тоже какая-то более-менее структура есть, не очень строгая, но это один документ. в сравнении с Онспеком. А потом, когда я этот план финализировал, вот мне как раз хотелось ээ провалидировать, что код на выходе, ну, я же в итоге плагинчик пишу, да, мне важно не то, что я его прекрасно проработал, а то, что он будет прекрасно работать в итоге, нормально решать все задачи интеграции. Я использовал план, который при помощи у Майкла кода сформулировал, как вход для Openспека. Я ему говорю: "Вот есть документ". >> А там максимально подробно было расписано вот MyClot Code, у него как бы фишечка и заточенность под параллельное выполнение плана. И для того, чтобы мочь параллельно писать код в несколькими агентами, там решать задачи с формом агентов, он план составляет и задачи, а очень опираясь на кодовую базу. То есть он буквально в задачах пишет, в какие классы, какие изменения он будет вносить, в какие методы заводить, с какой сигнатурой там и так далее и тому подобное. То есть вот там часть программирования уходит на этап проработки планов. Это тоже интересный подход. Ну вот мне как раз хотелось увидеть разницу, в чём она будет и за счёт чего эта разница будет, какие сайдэффекты у у этой разницы.

Вот вот там сайд-эффект - это возможность потом запускать ээ разработку параллельно. Какие-то агенты идут, пишут тесты, какие-то агенты в этот же момент пишут код. Потом в конце агент, оркестратор берёт, соединяет всё вместе, типа запускает тесты и уже там дописывает недостающее, но они, скорее всего, будут работать, ну, там по большей части, потому что план предусматривает в том числе сигнатуры AP, чтобы интеграция могла произойти. Вот в том виде, в котором Open Spec пишетки и даже спеки. Такое невозможно. То есть OpenC можно потом реализовывать исключительно последовательно и тесты писать только после того, как написан код, потому что до этого нигде нет знания про то, какая сигнатура у тех методов, которые мы хотим проверять. Вот.

И что я увидел, ну, из интересного такого, да, что OpenS, э-э, при формировании проподикумента просто выкинул процентов 60 деталей из плана, который сделал Myкод. Ну, то есть потому что у него жёстко задан вот этот вот формат, в котором, ну, видимо, явно я не проверял, за счёт чего он это конкретно сделал, но просто я увидел, что результат больше похож на тот, который был бы, если бы я ему просто промптом написал эту задачу. Вот. То есть он такой очень компактный, очень сжатый, очень всё там типа спецификации максимально подробные, типа он вывел сам. Дальше, возможно, подсматривая в дизайн документ, возможно, нет, я уже не помню, это там почти месяц назад было. >> А и и дальше, как я как я использовал эти два разных инструмента? Типа у меня были две несвязанные сессии. Я в одной сессии делал имплементацию и в ней же, используя инструменты MyClot кода, делал какую-то валидацию, которую он предлагает делать. там субагентами, там максимально параллельно вот это вот всё. А потом как финальную проверку делал через OpenS. Он OpenS уже использовал исключительно свои артефакты, которые он сам построил. Но он не трогал код. То есть я ему вначале явно сказал: "Ты типа валидатор исключительно и только пишешь какую-то обратную связь, изменения не вносишь". Практически на каждом шагеспек находил какие-то отличия. от спецификации. И, ну, я буквально брал его, этот результат валидации, копировал в ту сессию, как как будто бы это просто внешняя обратная связь от меня, да, и просил у моило кода до до закрыть вот эти вот пробелы.

Вот тут я увидел, что OpenS со своим подходом к формированию, в том числе, артефактов выигрывает с точки зрения количества итераций на выходе, а для получения какого-то качественного рабочего результата. Вот. Но при этом, э, я не как это не сделал какого-то вывода, что вот вот это точно лучше, вот это точно хуже. Оно скорее про разное, типа, и там, и там есть какие-то слабые, сильные стороны. И мне вот после опыта разработки такой и получение вот этого опыта валидации как бы через сторонний инструмент захотелось. А можно как это всё вместе и можно без хлеба. Все плюсы от того и от другого. И ни одного минуса желательно, чтобы не было. >> Ну просто хороший результат. вот побыстрее, максимально параллельно и так далее и тому подобное. Не смог я пока соединить их между собой. Может быть, это и не нужно. В какой-то момент я просто бросил эту мысль отлежаться ещё и для себя решил, что я просто буду в разных задачах пробовать разные подходы. Ну, то есть там, где в проекте уже внедрён Open Spec, мы уже какой-то путь прошли. Просто продолжаем в том же духе, потому что это рабочий инструмент.

В команду я внедряю Open Spec. А, и команде нравится, ну, в плане несколько полреквестов паревиированных, где вот можно смотреть дизайн, документы и не обязательно смотреть в код. В целом разработчикам заходит, особенно когда полуреквест объёмные. И вот там мы движемся в эту сторону. Типа спека развивается вместе с проектом. У проекта есть в том числе дополнительные инструменты валидации, чтобы агент мог там линтеры запустить там в случае с плюсовым кодом Silant, получив какую-то там дополнительную обратную связь про то, что плохо код написан. А тесты сейчас вот мы работаем над тем, чтобы добавить железо в цикл проверки. Ну, учим агентов собирать прошивку, заливать её на МЦУмодуль и смотреть логи по логам понимать, что всё действительно работает, не залипло, не зависло, не было ребутов, неожиданных там крышей по памяти и так далее. И вот пока я верю, что в случае сдет разработкой это будет работать. Ну, типа Open Spec плюс дополнительные инструменты для валидации. Ну, как у разработчика, по сути, да, агенту те же самые возможности, а для каких-то проектов, которые я там сам себе делаю и где на старте не всё понятно и нужно, ну, как-то чуть более детально проработать, возможно, даже типа попроектировать на уровне каких-то сущностей в коде. Вот то, что код делает, когда он пишет план, типа, он уже сразу же начинает оперировать сущностями, которые в кодет создавать какую-то структуру классов, там, взаимосвязи и описывает это всё. Вот там мне этот подход как будто бы заходит, я ещё его попробую аа с разных сторон по поиспользовать.

То есть у меня там остаётся не до конца провалидированная как раз-таки история с мультиагентностью. Я сделал подход. Ну, я уже говорил, что вот у клодкода вскоде в виде экстеншена плохо с представлением вот этой параллельностью. И надо всё-таки уходить в терминал. А, о мой мой о my clot код он ещё типа авторы рекомендуют его запускать не как команду clot, а как свою обёртку. Ну там ОМЦ называется, и она, я ещё не смотрел, что конкретно она добавляет. Возможно, просто там какие-то пути дополнительные, да, для каких-то директорий с конфигами прокидывает, может быть, что-то ещё. Точно, я знаю, что у этого ОМЦ своя система скилов есть. как как сказать, как у агентик фреймворка, они делают делают свой собственный skки discovery и свой собственный skill, как это skill creation, да? Ну, типа самообучение на основе опыта в сессиях. А когда ты просишь вот используешь скил MyCД кода, он создаёт его не в общей папке клода, а где-то у себя, в том числе на уровне проектов, папочке там и своими какими-то инструментами, в том числе эти скилы, находят в процессе работы. В общем, какая-то там более сложная такая система, которую хочется чуть больше осознать и пощупать собственными руками с разных сторон для того, чтобы уже принимать решение, она вообще годная. Если годная, то для каких задач? Стоит ли её там как-то дополнительно внедрять в рабочий процесс вот уже в команде или, может быть, и дополнительное место? Ну, короче, тут у меня пока ответов нет, >> но выглядит по-прежнему интересно. Как-то так.

>> То, что ты Мёльком упомянул, что очень важен скил для того, насколько будет эффективен вообще подход с агентной разработкой, и сказал, что вот так как у тебя достаточно был глубокий бэкграунд, то ты за 8 часов там сделал прямо целый продукт. А, во-первых, хочется понять какой-то масштаб. Вот если бы у тебя вообще не было нейронок, то сколько бы это заняло?

>> Я я вот ээ как это на такой вопрос обычно отвечаю так: если бы у меня не было нейронок, я бы вообще не взялся решать эту задачу, потому что у меня тупо столько времени нет, чтобы её решить. Э, скорее всего, до первого результата было бы не меньше недели с учётом, в том числе, ритма, в котором я мог бы эту задачу решать. Ну, то есть условно тут тут ээ вот с нейронками как бы, особенно как это на выходных, когда есть свободное время, какой аспект работает? Типа непрерывность. Я погрузился в задачу, я не переключая контекст, её сложную, объёмную, типа дорешиваю до какой-то промежуточной точки, вот которая меня удовлетворяет. И это занимает часы. Если делать эту работу медленнее, там, ну, достаточно много времени съестся просто тупо на переключение контекста. То есть каждый раз, когда я буду к этой задаче возвращаться, мне надо будет потратить, ну, там полчаса времени для того, чтобы вспомнить, разобраться, где мы там остановились. И есть ещё вот этот фактор, что, ну, много времени бы ушло непосредственно на проектирование, проработку, изучения чего-то. Это очень сложная система. сама вбор там десятки девайсов как-то описанных, как-то там работающих, это просто тупо невозможно удержать в голове. И там бы был бы какой-то такой, ну, пошаговый подход к решению. Я бы там выбирал какие-то классы устройств, детально разбирался бы, как как с ними надо работать, писал бы какую-то параллельную документацию, которая бы помогала мне вспоминать быстрее преследующих заходов. То есть там даже бы тот объём работы, который нужно было бы проделать, он был бы ещё больше. То есть не только код написать из пеки, а вот из-за сложности работы, из-за распределённости её во времени нужно было бы самому для себя делать вот эти вот хендоф документы, как мы сейчас придумываем для агентов, да, чтобы они между сессиями как-то передавать контекст, если сессия очищается. Вот по совокупности факторов я бы даже не взялся. Вот я точно себе отдаю отчёт. Ну, то есть сказать, что там тебя это минимум X5 ускоряет, это в целом справедливо.

>> Мне кажется, что да, в таких задачах. Да. >> Угу. А тогда ещё чуть хочется подробнее про скилы. Вот и ты когда-то рассказывал не в рамках этого разговора, но про то, что у тебя есть опыт ворваться в пускай и знакомую предметную область, но на незнакомом языке и вполне успешно с агентами там двигаться. И даже на примере вот этого кейса с плагином, если бы у какого-то энтузиаста просто были бы вот разные железки, они между собой никак не стыкуются, и он такой: "А я вот слышал, есть нейронки, и с ними можно что-то напрограммировать. Вот я хочу эти две мои домашние железки поженить". Ээ понятно, что у него бы всё это заняло гораздо больше времени. Но в целом, считаешь ли ты, что это было бы возможно человеку, который не погружён вот именно в инженерную движуху?

>> Ну вот если бы он условно решал ту же задачу, которую я решал, мне кажется, нет, потому что там даже вот по моему опыту, даже в процессе >> а-а проектирования плана, это у меня первый прототип занял там 8 тире9 часов. Я же потом ещё несколько вечеров сидел и дотюнивал эту систему. И там были моменты в духе зафак вообще, что такое. Ну, типа, не так надо было решать эту задачу. То есть я в процессе уже, когда начал в детально смотреть, как конкретно оно сделано, каких возможностей не хватает, сталкивался с тем, что задача местами решена некорректно. И я это видел просто потому, что я понимаю, как её надо правильно решать. А вот, ну, поставим сюда человека, который не знает, как её правильно решать. У него единственный шанс как бы осознать вот эту неправильность, да, это попробовать использовать, увидеть, что-то не работает, и дальше попросить ээ модель просто разобраться с этим. Ну, то есть вот вот что-то не работает. Что может человек сказать? Вот логи этого инструмента, там что-то не работает. И надеяться на то, что модель сможет разобраться, что именно не работает. Сколько это в итоге сожрёт токенов на понимание проблемы? Сможет ли она в итоге понять эту проблему, типа предложить адекватное решение и в итоге решить, типа неясно и времени, сколько это в итоге займёт, тоже не очень ясно. Ну, то есть, наверное, обладая бесконечными ресурсами, ну, типа, и токенов, и времени, типа, и желанием решить эту задачу, наверное, можно.

>> На том масштабе, про который ты говоришь, бесконечно это примерно подписка долларов за 100. Вот так интуитивно, наверное, да.

>> Про вот людей, которые в большой команде сталкиваются с приходом нейронок, какие вещи ты тут замечаешь? Ты сказал, что в целом команда смотрит на дифы в виде того, что генерит Open и это нормально заходит, но чуть раскрою вообще. Вот типа были люди много лет, фигачили код, тут приходят нейронки и вот и что

>> с чем я вообще столкнулся, да? Ну при при внедрении нейронок. То есть так получилось, что в команде своей основной я являюсь главным амбассадором использование ЛМК, потому что вот, собственно, я на стыке э нескольких моментов того, что у меня есть опыт инженерный богатый, типа многолетний, разносторонний, там в том числе инфраструктурный, который тоже очень здорово помогает, потому что по сути выстраивание как бы харнеса и каких-то вспомогательных инструментов ээ вокруг этого харнеса для того, чтобы таки сделать этот фидбклуб, это инженер о инфраструктурная задача в чистом виде. Я увидел вот для себя вот этот кратный профит, который, ну, 100% окупает ээ усилия, затраченные на изучение этого этого инструмента, на там пробование разных вариантов использования и так далее и тому подобное. Я точно знаю, короче, что это купится кратно в моём случае. Вот когда я приходил с этим в команду, особенно на ранних этапах, >> я сталкивался с сопротивлением в этом месте, потому что у людей такого опытого не было. И даже тот, который они получали на первых шагах, он был, ну, скорее негативный или такой типа странный. Ну, то есть, ну да, я вот тут что-то попробовал, >> да, мы там что-то подискутировали, да, даже какой-то код на выходе получился, но нет ощущения, что я бы ровно тот же самый код написал бы сильно медленнее. или там с меньшим уровнем качества, скорее даже наоборот. Может быть, даже просто за то же время справился с этой задачей, но зато токены бы не потратил там, ну и так далее. И как это пришлось приложить разные усилия. Ну, я выбрал такой подход, что у меня в команде девять человек-разработчиков помимо меня, и я с каждым индивидуально на личках пытался нащупать, ну, типа своё, свой подход, какие-то, а, увидеть, какой можно предложить маленький следующий шаг для человека, для того чтобы ему было типа не проблемно его попробовать, не жалко было времени, и он с какой-то высокой вероятностью получил бы позитивный результат. >> Вот у меня там прямо буквально с каждым свой индивидуальный трек был про это. Вот. И в итоге типа сейчас все в команде так или иначе используют лэмки и противников, прямо открытых противников использования не осталось.

Аа что касается инструментов более сложных, чем просто вот стандартный режим планирования в ЕАгентах, вот я уже сказал, что Open Spec - мы там используем в нескольких проектах, не во всех. То есть здесь ещё предстоит какой-то путь, потому что, ну, сам инструмент добавляет, как это, другой немножко сложности. Его нужно осознать, нужно осознать флоу, нужно его там попробовать обкатать на нескольких задачах, нужно там проникнуться, понять, где оно работает хорошо, где оно не работает. И ещё там периодически тратить усилия на то, чтобы всё-таки придумывать, как как оно типа лучше может работать вот в этом конкретном проекте. Вот. И, ну, там прямо сейчас у нас OpenSP используется в нескольких инфраструктурных проектах. Там как раз хороший профит для разработчиков вышел в том, что у людей, у которых нет опыта работы с инфраструктурой, ну там с разными какими-то инструментами, типа ансигла, например, для автоматической наливки железок. Вот. Ну там условно, кроме меня в команде никто никогда не работал и не хотел бы. Вот проект настроенный, засетапленный под то, чтобы можно было при помощи Лемок решать эту задачу, оно просто для этих людей разблокирует саму возможность эту задачу решить без необходимости, но сильно детального и глубокого покружения. То есть можно при помощи лнки получить, ну, такой достаточно сносный результат. Вот, в общем, инфраструктура в этом смысле не такая критичная, как продакшн код прошивок. Поэтому оно работает. И и вот тут вот как бы такая обвязка, которую я заранее подготовил, а потом только привлёк туда людей в работу. Этот этот сценарий оказался годным, рабочим, типа можно тиражировать.

А-а проект типа общая библиотека для eded прошивок. Ну, то есть мы там делаем клаудные устройства, умнодомовые, яндексовые, которые подключаются к нашемудомовому облако нативно. А это как бы кроссплатформенный фреймворк, библиотека, а, которая для для разных железок работает, типа общая библиотека, общая библиотека компонентов, короче, которая адаптирована под запуск на разных платформах. И так как это такой специфический проект в том смысле, что это общая библиотека, там можно написать какие-то юнит-тесты на отдельные компоненты, которые будут выполняться даже на Линуксе. Не обязательно их запускать на какой конкретной таргетной платформе. А там есть потребность в том, чтобы эти эти компоненты были как-то документированы. Аа код такой типа не очень специфичный и не работает напрямую с железом. 80% кода в этой библиотеке, как написано, то там в целом использовать лмки, внедрить туда Open Spec аа оказалось, ну, сильно проще, чем проекты конкретных прошивок, которые работают на железе, потому что сам проект может и агент, работая с этим проектом, а, может получать обратную связь, просто даже запуская юниттесты вот на той же машине, на которой работает сам агент. А вот с проектами прошивок эта задача пока не решена. Там не то что OpenСпек внедрить как бы непонятно как, а там даже с агентом бы научиться нормально работать. Вот, как я чуть раньше говорил, что мы сейчас в процессе разработки решения для вот так называемых, э, hill hardware in the loop, а, тестов, типа, и подхода, когда у агента будет возможность с железом взаимодействовать напрямую. Вот, кажется, после того, как мы решим вот эту задачку, и у каждого разработчика на столе появится аппаратный сетап. Ну, там, условно, с Raspberry P и через которую подключены нужный набор железок, который участвует в разработки конкретного устройства. И мы научимся хотя бы с аген вот этот цикл обратной связи выстраивать. Вот там уже можно будет какие-то чуть более сложные решения нанизывать, что пока мы до сих пор не там. То есть всё, что разработчики сейчас делают с прошивками конечных устройств, когда используют лмки, это просто пишут код, который компилируется. Всё. Вся остальная валидация по-прежнему остаётся на человеке. И, ну, лмка здесь действительно помогает по большей части с проработкой решения. Ну, потому что она может там даташит прочитать на 800 страниц. Ну, не весь, конечно, но там что-нибудь поискать по нему, там найти конкретные странички, где там регистры какие-нибудь описаны, и там, ээ, накидать какой-нибудь драйвер там и так далее. Но всё равно финальная валидация результата, того кода, который Лемка написала, остаётся на человеке. Это, конечно, не тот режим, к которому мы уже как-то, который мы пользуемся, когда делаем frontend, backндend на разных языках, infru на Питоне, на тепскрипте и там в других языках. Тут ещё, короче, п надо закрывать.

Ну я же правильно понимаю, что когда ты говоришь здесь валидирует, это в смысле проверяет, что оно именно работает, а не в смысле читает код. То есть то, что сгенерила нейронка, потенциально можно не читать, но важно, чтобы человек, так как пока что нету технической возможности агенту потыкать в железку, чтобы человек пошёл и пол.

>> Да, не читает код, тут это бесполезно. Типа мы и так используем возможности агентам ревьюить, ну там разными моделями или тем же той же моделью в другой с чистой сессии. Короче, вот такое. Делать кросс-ревь добивая качества до нужного. Нет смысла тут человеку смотреть. Фактически это о том, что для железок пока что нельзя автоматизировать часть QA, но именно чистая разработческая часть как будто бы чистая разрабоческая часть - это в том числе прошить прошивку, убедиться, что она работает. Ну там по логам, например, увидеть ээ глазами, что мы дошли до нужной ветки кода и там какие-то данные вывели, которые можно понять, что да, мы правильно здесь отработали. Вот эту часть мы сейчас делаем руками. Я не говорю про то, что сейчас нету инструментов в мире про это. Скорее, нету инструментов прямо сейчас нам доступных. То есть есть там парочка стартапов, которые уже пытаются эту задачу закрыть, но они делают что? Они делают своего агента, которого нужно купить по подписке. И это там американские стартапы или там европейские стартапы, которые никогда в жизни от нас денег не возьмут за лицензии. Ну, короче, э я тут больше вижу, что >> нам самим придётся ровно тот же самый путь пройти, возможно, сделать свой свой там плагин условно или там какой-то тулинг, который будет интегрироваться с агентами попроще. Ну, то есть не надо будет сильно много времени разработчику, разработчику потратить на того, чтобы воспроизвести этот сетап. То есть это будет больше похоже на какой-то тиражируемый продукт там с настройками. Вот. Но сделать нам его придётся самим.

Если попытаться подытоживать всё, что прозвучало, то ты достаточно быстро прошёл путь, вот начал что-то делать с агентами до ситуации, когда у тебя уже поспеке генерится всё настолько качественно, что можно и не читать, что там сгенерилось, ты принёс это в команду. И несмотря на то, что предметная область очень непростая и суперответственная, потому что после того, как прошивка ушла в магазин, её уже не починишь, вы тем не менее пользуетесь нейронками, чтобы разрабатываться, и команда довольна. Нигде ничего не переврал.

>> Ну как это, когда она ушла в магазин, у нас по-прежнему там, на самом деле, она ушла на завод. магазина ещё устройства должны быть произведены там соки прошиты ещё до старта производства устройств и так далее типа очень большой гэп между тем когда прошивка ну типа условно готовая от нас уезжает и до старта продаж там типа 3 месяца у нас ещё есть времени и мы конечно же это время используем для того чтобы доделать софт а потом накатить его апдейтом апдейты у нас остаются возможность такая Но всё остальное, да, да, >> супер. Спасибо большое.

>> Спасибо тебе за то, что пригласил. >> Пока-пока. >> А ещё подпишитесь на Telegram-канал Девсподин.