Spec-Driven Development на практике | SDD, BMAD, OpenSpec, вайб кодинг | Podlodka Podcast #486

Всем привет. С вами подкаст Подлодка и его ведущая Егор Толстой. Это я и Станислав Цыганов.

Привет, привет, друзья.

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

И люди смотрят такие нажалкие там час 06 и такие: "Чего это всё?"

А, Стас, и знаешь что ещё длинное помимо выпусков подлодки?

А, давай.

Спецификации в Spec Driven Development очень длинные. Люди жалуются на это. Будем сегодня разбираться, должны они быть длинными или нет, потому что выпуск как раз-таки проспект Driven Development.

Подожди, мы не с просня пишем?

Это это одно и то же, не обращай внимания.

О'кей. Ладно.

Поэтому поэтому поэтому пора представить нашего сегодняшнего гостя. Мы посли в гостя Алексея Верховского, автора одного из самых популярных SDD фреймворков или тулкитов, разберёмся, как правильно говорить, под названием BMOД. А, собственно, Алексей один из его Да, завтра Алексей один из его основных контейнеров. При этом он занимался спектрин девелопментом ещё до того, как вообще это название появилось.

Ну, это тоже неправда. Сейчас разберёмся.

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

О'кей. А, всем привет. Софтвером занимаюсь лет так 30. В основном в Северной Америке, ну, сначала там, где-то на ранних этапах лет пять занимался им по всему миру. Просто ездил по разным местам и прикручивал там телефонный биллинг в больших безликих телефонных корпорациях. Потом работал, э-э, в консалтинге, в общем, в этом качестве, где я только не писал за деньги код, включая там Microsoft, самый большой Gчфон в природе, Oracle, ну, в общем, энное количество всяких нефтегазовых заведений, а, и так, и тп. последние лет 15, э- в общем-то надоело мне заниматься консалтингом и занимаюсь я работаю на удалёнке, в основном на американские бизнесы, Силиконовую долину. Вот этим всем делам я пришёл, ну, собственно, Лмон-то я начал пользоваться при разработке ещё года три, наверное, назад. Ну, когда это всё было умным автокомплитом, по сути дела, да, там был такой период. Вот. А, значит, давать ей самой чего-то там писать. Ну, в принципе, где-то в апреле прошлого года, в марте, наверное, я понял, что уже, видимо, можно. По крайней мере, надо всерьёз пытаться, потому что я, в общем-то, не люблю э влезать в новые технологии на слишком ранних этапах. Это, как правило, убийство времени. Ну, ещё и очень трудно угадать, это на самом деле новая технология или просто как бы новая блестящая игрушка, которая через полгода умрёт, да? Вот поэтому я обычно жду и, в общем-то, стараюсь влезать вот где-то вот перед вот этим вот местом на кривой, наизвестной, как это называется-то, забыл уже. Ну, в общем, неважно. А, короче, так получилось, что где-то весной прошлого года я понял, что это место как раз настало в именно идеи давать Лэму самому писать там больше, чем четыре слова подряд, как в общем-то и все в тот момент. Поставил себе клод, значит, и как бы оказалось, что в принципе, да, можно, но это не сильно быстрее получается, [тяжело вздыхает] потому что, [вздыхает] ну, плывёт агент-то. То есть ему ещё тем более в те времена, это же полтора года назад, это в общем, ну или там год назад, это прошлый, это это средние века собачными годами. Дадада. Да. То есть когда на самом деле они ещё там сильно больше, ну, условно говоря, там двадцати строк кода подряд писать у них практически не получалось. И в общем вот этот режим, который [откашливается] я обычно описываю, как ругаться на эллэмку время от времени плакать. А это было, конечно, очень забавно и поучительно, и познавательно, но в смысле там какого-то резкого роста скорости по сравнению с тем, чтобы просто печатать, [тяжело вздыхает] по большому счёту, не давало. Единственное, что было, так сказать, так вот реально приятно, что вместо того, чтобы, значит, быстро печатать там многими пальцами на какой-то клавиатуре, я довольно быстро пришёл к тому, что из клавиатуры всей нужна, по сути дела одна кнопка по большей части включить запись. Отпустил, выключить запись. Вот. А, да, это было здорово. То есть как это по-русски будет? Carpal tunnel syndrome.

Да-дада.

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

Понятно. Хочешь решить проблему, сделай это сам.

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

Да. А, поэтому давай вообще начнём с того, что попробуем на пальцах объяснить, а что вообще такое Spec Driven Development? Вот как работает ванильный SDD подход, особенно для тех, кто никогда раньше так не работал. просто промл агента.

Давай даже начнём с того, откуда он вообще берётся в этой жизни.

Давай.

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

Угу.

Поэтому мы сейчас про SPCDriven Development в том плане, в котором это начало с там лёгкой руки Гитхаба называться в августе прошлого года. Идея очень простая. А у тебя есть LLM? У ЛМА есть такая штука под названием Context Window. Ещё у неё есть такая штука под названием usable Context Window, которая на самом деле чем дальше, тем сильнее отличается от просто Contex Windows, чем значит если, ну, как бы что такое контекст, рассказывать, я думаю, тут никому не надо, да? Не, это считаем, да, что это эта планка есть,

слишком базово. Значит, проблема в том, что когда это всё переваливает за, ну, в те времена 50.000, а сейчас где-то 120-150 тысяч токенов, лэмы начинают плыть. Они, значит, забывают, что было в середине, чуть позже начинают забывать, что было в начале. Аа они начинают чудить по-разному, так сказать. Ну, в общем, понятно. Lost midle syndrome, да? Вот, соответственно, у тебя есть фундаментальное ограничение этого метода. Причём, что интересно, вот сейчас нам продают как бы сервисы, там миллион токенов, вот обещают там 2 млн уже начать, да, но если почитать свежие статьи того же Антропика про конкро, то есть вот про эту проблему, значит, usable Context Windows не вырос там в 5-10 раз, он в лучшем случае вырос процентов на 20 по сравнению, там, скажем, с моделями, которые были в начале этого года. Так, а можно Егор как-то очень сорян, что перебиваю. Просто я хочу ворваться. Мы как-то очень, может быть, быстро пропустили. А я когда смотрю на модель, там написано размер окна. И вот сейчас вот, например, у каких-нибудь Санета там написано 1 млн означает. Ну и когда я смотрю на этот миллион, я это понимаю следующим образом. То, что вот когда мы до миллиона дойдём, вот тогда моделька начнёт плыть. И, ну, а точнее, она не плыть будет, она она, соответственно, начнёт соответственно сжимать контекст и так далее. Но если бы она этого не делала, она бы начала плыть. Ну и, собственно, там можно придумать способ, как запихнуть туда слишком много контекста. Я не знаю, там скормить, а, слишком большой файл какой-нибудь или ещё что-нибудь. Ну, короче, есть способы. Вот это вот 1 млн, это вот, ээ, ну, кажется то, что предыдущее предыдущее вот это значение было, ну, я не знаю, там в 10 раз меньше, 200.000. Ну то есть, но при этом, но при этом утверждается, что как бы эффективный контекст вырос всего на 20%. Что это значит? Сколько он тогда?

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

Что на самом деле нормально, когда ты занимаешься каким-нибудь брейнстормингом, да? Почему это нормально? Потому что, ну вот мы, когда вот разговариваем, мы же уже забыли, что было полчаса назад. А полчаса назад - это где-то там сколько? 50, по-моему, тысяч токенов. Так, по порядку величин, не больше. Вот мы забыли и всё нормально. Мы продолжаем разговаривать. Как бы у нас главное, что текущий контекст держится. Вот. А это там, ну, что-то отложилось где-то, что-то даже куда-то записалось, но в голове у нас этого сейчас нет. Правильно. Когда LLM пишет код - это крайне нежелательная вещь, потому что именно так в этом коде появляется куча всяких fail modes. То есть куча всяких вот вот именно вот она чудить начинает. А, поэтому, значит, да, тебе дали, так сказать, контекст Windows миллион, но это не значит, что надо продолжать кодировать до миллиона.

Угу.

На самом деле, в общем, как только ты видишь там, ну, во-первых, эту цифру надо мониторить со страшной силой, то есть просто всё время на неё смотреть на каждом ходе в своём. А, во-вторых, как только ты увидел, что там как-то сильно перевалило через 100.000, надо придумывать, как эту сессию остановить и начать новую. Значит, этот самый compressшн, вот этот, когда на контекст сжимает, это на самом деле что? Это тот же самый Lost in midle, то есть она из вот сессии выкидывает кучу токенов, да? А оставляет те, которые ей показались важными. Проблема в том, что лмы на самом деле плохо понимают, что такое важно. Поэтому, когда ты видишь, что она пошла вот этот вот компакт делать, это уже ай-ай-ай. когда тебе нужно именно вот точный рекол нужен, понимаешь?

Угу.

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

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

Ну, есть простой, на самом деле, способ - это просто понять на кончиках пальцев. Берёшь там какое-нибудь преобразование какого-нибудь там большого набора файлов, там, допустим, 300 штук. Надо что-то такое придумать, чтобы каждая из них требовало именно не скрипт написать, а подумать. То есть inference, да? И чтобы этого инференса было, ну, допустим, там 30, 40, 50.000 токенов на файл. А потом их запускаешь все в одной сессии один за другим, и смотришь на результат. И чтобы результат был как бы вот, ну, чтобы тебе было сразу понятно, что такое хорошо, что такое плохо. Там прямо чётко видно вот нынешний опус там с миллионом контекстов. Ну, я это делал не на нынешнем, а, по-моему, версию или две назад. Ну, оно сильно не изменилось с тех пор. А, судя по всему, вот там чётко видно, когда после 200.000 токенов, она начинает уже прямо заметно чудить, а после где-то 350-500 она уже просто как бы вместо того, что, значит, я ей сказал: "Сделай такое-то преобразование",

начинает делать что-то вроде makeт бера.

Вот так вот.

О'кей. Так,

это прямо хорошо видно.

Так, про это понятно, да? Про это про это понятно. Давай погнали дальше к Да, к тому, откуда вообще,

как это связано вообще с SДD. О'кей. Проблема ясна.

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

причём в самое начало сессии. То есть, да, как раз именно так и получается, что идеальный вариант вот этой сессии на 100.000 токенов выглядит именно так. Вот она запустилась, да? Что значит она запустилась? Примерно так. Ты проснулся, ты знаешь всё, что происходило до декабря прошлого года, и перед тобой такая белая стена, там написано: "Тебя зовут Вася. Вот твоя задача". И там дальше 1ты000 слов задача, да? Вот. А, значит, если после того, как ты прочитал эти там 1.000 слов, тебе всё ясно и как бы не надо никуда ходить, там чего-то как-то широко искать, читать какие-то, значит, эти search results большие там и всё такое, да, ты просто, ну, о'кей, я Вася, вот моя задача понеслась. Вот это идеальная как бы сессия для coding agent. Если вместо этого, так сказать, ты, значит, пришёл, тебе сказали, что ты Вася, написали там, какой ты Вася, а дальше, значит, какой-то Петя тебе там в час по чайной ложке начинает рассказывать, что ему надо от этой жизни, да, то, ну, как [откашливается] правило, если эта задача не совсем уж тривиальная, вы, в общем-то, этого полезного контекста 2/3 потратите просто, чтобы разобраться, что надо петь от этой жизни. А вам же ещё надо сгенерить из этого код, потом этот код проверить, закомитить и всё такое прочее, да? А вы уже на самом деле по сути дела 2/3 спалили на, в общем-то, вот этот диалог. Вот отсюда, собственно, берётся как бы эта простая идея, что, да, надо, значит, в какой-то другой сессии написать вот эти вот тыся слов, так сказать, которые мы Вася сообщим о том, что он должен сделать а за следующие 3 минуты грубо. А, и после этого, в общем, этот Вася отработает как молодой бог. Ну, настолько, насколько он может. Вот. Вот тебе и вся идея, так сказать, Spec Driven Development, как она есть.

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

mode - это самая примитивная имплементация SPDAM Development. Так точно.

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

Подожди, мне кажется, ты сейчас Подожди, ты какое-то новое свойство сейчас придумал. Мы его вообще не обсуждали пока что. Вот я бы на самом деле следующее свойство обсудил другое немножко,

что дальше на самом деле А, ну понятно, вот один такой Вася, то есть один coding session, вам решит одну простую маленькую проблему. То есть он, собственно, продакшн-кодом напишет, ну, 100 300 обычно, не больше, чаще всего меньше за эти 100.000 токенов, да. Ну, опять же, как бы зависит от задач. Естественно, он там может очень много написать, но

это тут мне стало стыдно за мои пулреквесты в одну сессию в 3.000 строк.

Ну нет, так тоже бывает, как бы мне совершенно не стыдно за мои такие же, но просто они не все такие далеко.

Я к тому, значит, а смысл тем не менее в том, что дальше у вас на самом деле возникает э задача, которая больше, чем одна сессия.

Угу.

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

Угу.

Да. Вот. И, соответственно, это, в принципе, в известном смысле такой же самый спектрин, но только уже пленинг. И когда мы говорим про спеки, это, к сожалению, такая путаница терминологическая есть, сложившейся терминологии нет. Но мы всегда должны держать в голове вот в каждый момент в таком разговоре. Мы про какие спеки сейчас? проспект одной истории на один коди се про спек, ну, допустим, если в терминах вот этого вот agile, в который там я, в общем-то, в этой жизни много и со вкусом. А спектр эпика, который, ну, 5-10 этих историй, да, или мы про спект прямо проекта, который, ну, 40 тире 100. Это немного разные люди, все трое, но особенно сильно отличаются спеки вот вот этого всего от спека одной истории, одной кодингсессии. Вот. Сейчас вопрос вопрос так занкаться, что, как я правильно понимаю, главное различие между спекой всего проекта и вот это вот, а, одного одного спринта заключается в том, что спека проекта она в некотором смысле она полностью описывает текущее состояние проекта. А спека спринта должна в первую очередь описать о том, что должно измениться, как, ну, то есть она описывает в первую очередь изменений и в нём фокус или в чём разница. Ты ты всё время пытаешься тащить сюда specs идею spec source, да? То есть когда у тебя типа там источником истины о том, что уже есть, является там какой-то marкdдауфайл. Значит, есть такая идеология, есть её имплементации. Ну, OpenSP, собственно, это оно. Например, моё сугубо частное мнение, основанное, в общем-то, ни на чём, кроме, ну, грубо говоря, это личного опыта и общение с людьми, которые так пробовали делать, сводится к тому, что эта идея, она впереди, на самом деле, развития технологии сейчас. То есть так ещё делать нельзя. Ну, можно, но плохо получается. Аа, поэтому с моей точки зрения, значит, э, если мы говорим про спеки, которые одной кодинг-сессии, да, то на входе у этого планирования есть, э, ну, короче говоря, там самый богатый контекст про твой проект - это код самого проекта. В этом коде, кстати, есть комментарии раньше. Это, ну, вот одна из вещей, которые сильно поменялись, так сказать, после того, как мы стали писать код с лмами. Значит, раньше, в принципе, правильно было комментариев не писать а-а как дефолт, да? То есть, если там у тебя возникло желание написать комментарий, сначала сскадь и хорошенько подумай, как бы в кодеть так, чтобы он был не нужен. И только если не получилось, тогда о'кей, садись, пиши комментарии, потому что комментарии расползались собственной имплементацией. Сейчас комментарии больше не гниют. То есть лмы современные, они отлично совершенно. Значит, комментарии про то, почему здесь именно так, а не по-другому поддерживают на ура. И потом как бы точно так же в коде, если код нормально организован, они их очень быстро и точно находят. Поэтому держать как бы старые спеки после того, как они утратили актуальность, я в принципе смысла не вижу. Ну, в смысле, вижу там в архиве я их держу, иногда заглядываю туда с точки зрения археологии.

Угу.

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

О'кей. А про какие тогда спеки мы говорим? Про какие виды уровней? Это тогда сессия и а спринт или что?

Вот. А проект, ну, в моей голове проект epic story, ак это не спринт, это эпик. От спринта он отличается тем, что - это там небольшое количество историй, которые вот все вместе связаны общей темой. Обычно, на самом деле, просто там из них получается какая-то цельная фича полная.

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

Угу. Так

скажем так.

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

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

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

Так вот, >> вот я как раз хотел сказать, не только модели, но и мы сами были ещё глухими. >> И это тоже. >> Это же человекомашинная система, >> да? Это кто мы как кто люди как некожаные харнесы для моделей? Ну, [смех] в каком-то смысле, да.

А вот так вот, умрёт ли Spec Driven Development, когда модели станут умнее? >> На мой непросвещённый взгляд, а-а, я это как бы часто рассказываю. А последняя версия Бимеда, это будет один промт, который будет звучать примерно так: спроси у человека, что ему надо, и так и сделай. Значит, если у тебя есть идеальный агент, то вот это идеальный Spect Driven Development Framework. Значит, у идеального агента есть, так сказать, ну, близкое к бесконечному, значит, Конtк Window, окно контекста, а у него, так сказать, какой-то такой абсолютно невероятный рекол, и он ещё каким-то образом научился понимать, что важно, что нет. Значит, на мой взгляд, вот этот идеальный агент, особенно в той части, которую Фред Буркс в своё время, это человек, который написал статью Silver Bullet, известную, да, там лет 40 назад, наверное. Вот он это называл, а, essential complexity, то есть, э, фундаментальной сложностью, как бы, в отличие от, э, случайной. Значит, я не вижу лмов, которые хотя бы примерно приближались вот к этому делу. То есть, что я вижу, что у них растёт как бы точность вот исполнения того, что им сказали в разных смыслах, да. У них, значит, растёт способность, э, ну, грубо говоря, там вспомнить токены из середины и сделать так, как надо. Ну, тоже, кстати, не то чтобы сильно, на самом-то деле, насколько я, так сказать, понимаю. Ну, так, наивно интуитивном уровне, в общем-то, как бы вот этот usable context window - это вещь, которая сильно коррелирует с размером модели. Похоже, что и поскольку мы в этом смысле довольно сильно упёрлись в ограничения по физике уже, по железу просто, вот, то оно перестало расти, на самом деле уже так. Ну, как бы оно растёт, но не там в 10 раз на каждом поколении, как это было в какой-то момент. Вот. А поэтому, если вот так вот взять, посмотреть на хрустальный шар, которого у меня нет, а неблагодарное абсолютно дело предсказывать развитие технологий, но я бы тем не менее предположил, что это что-то вроде управляемого термоядерного синтеза. То есть оно вон оно за углом, но термоядерный синтез за углом уже сколько? 80 лет. У меня есть сильное ни на чём не основанное подозрение, что вот с лммами вот этот вот идеальный вариант вообще Agi как таковой, да, а это та же история. То есть нам как бы следующий очень долго будет казаться, что вот он прямо вот протяни руку и он уже здесь, но он не здесь. >> [смех] >> Опять же, какая нам разница? Сейчас нам эта штука нужна. Нужна, польза от неё есть? Есть. Если завтра перестанет быть нужна, ну, я первый выброшу её на помойку и буду делать то, что надо в тот момент.

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

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

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

>> Ну, о'кей. Значит, э давайте так. Арч на эту тему есть. А-а, значит, разбиение на вот Plan Mode и Impменitation - это штука, которая ещё там 2 года назад, в принципе, в академической литературе, так сказать, поддерживалась на раз плюнуть. И с тех пор как бы мало что поменялось. Ну, в смысле, ЛМУ поменялись радикально, да? То есть с тех пор произошло там четыре примерно таких фундаментальных сдвига в их возможностях. Вот. Но, в общем, поскольку контекст Windows как был 100.000 токенов так по большому счёту и остался. А то вот это вот разделение, так сказать, напишем ему сначала план, а потом в другой сессии скормим этот план в начало контекста. Это никуда не делось. И как бы всякие попытки, значит, проверить это, они, в принципе, приходят к одним и тем же выводам всё это время, насколько я могу судить. Вот это значит пункт первый. Аа пункт второй, вообще говоря, эвалы, а тем более бенчмарки - это штука крайне сомнительная, на самом деле. А-а, во-первых, ну и, собственно, академическая литература в этом смысле тоже это такая вещь, которую надо воспринимать такой здоровым скепсисом. А значит, все эти люди, а как бы никто из них на самом деле не берёт там, грубо говоря, эту базу кода там на миллион строк на C++се или там на чём-нибудь ещё, да, такую настоящую, тяжёлую, а, в которой он сам типа знает всё, что там можно знать почти, но не всё. Ну всё, никто не знает. А и как бы не пытаются там, значит, вносить изменения двадцатью разными способами и так типа там каждую неделю. Такого нет. Никто этого не делает, правильно? Потому что это, ну, это не масштабируемо. А это, на самом деле, как бы своя задача. Она сильно отличается от того, что все эти агенты делают на бенчмарках. Куча, значит, валов и бенчмарков, они либо про какие-то абсолютно как бы микрозадачи, да, такие вот игрушечные, аа никто не строит именно взять полмиллиона строк и приписать к ним ещё 50.000 с целью ивалов. Это невозможно. Просто куча ивалов, на самом деле, у нас сейчас это о'кей. Вот у нас есть значит, допустим, тяжёлая, на самом деле, там какая-нибудь куча кода, написанная 10 лет назад или 20 людьми. А вот у нас есть изменения, которые эти люди должны были сделать 4 года назад, да? И вот у тебя есть ЛМ, который, конечно, тоже умеет кодировать, но он же умеет кодировать принципиально по-другому. То есть код, который пишет LM, он заметно отличается от кода, который пишет человек. Я прямо вот как бы могу на самом деле посмотреть на страницу кода вот с такого вот расстояния. Мне сразу видно, что написано человеком, что машиной.

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

>> А как тогда понять вообще, становится лучше или нет?

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

>> Штука в том, что тогда, да, нету никакой там статистической значимости, ничего такого, да? А и бог бы с ней. Статистическая значимость тоже сильно переоцененная вещь. Значит, если я на своих примерах, которые мне понятны, вижу, что вот этот сделал вот так, а вот этот сделал там на 10% лучше. И могу ещё, на самом деле, потом подтвердить, что и три других тоже там, по крайней мере, два из них сделали на 10% лучше. Всё, мне этого достаточно. А мне гораздо интереснее, на самом деле, сидеть и думать о том, как бы это палка или лопата. То есть структурно структурно эта штука, она подходит под ограничение метода и моей задачи или нет. Если подходит, то вероятность того, что она будет хорошо работать, опять же, вот как бы я никогда вообще не утверждаю, что она работает лучшим образом. Это >> Угу. >> Ну, понятно, это гордыня просто была бы, да. Никто не знает, что такое лучшим образом. >> Пройдёт 2 месяца, лучшим образом станет по-другому. Понимаю, понимаю, о чём ты говоришь. Про то, что в целом померить пользу такого инструмента, как SDD, объективно, реально очень сложно. Во-первых, а во-вторых, мы в подлодке видеть её очень легко при этом, >> да. Вот. А во-вторых, мы в подлодке много раз говорили про бенчмарки, и всегда мы упираемся в то, что бенчмарки - это очень это штука, которая обычно измеряет какой-то очень синтетический сценарий в вакууме. Вот легко читится и на самом деле вообще не коррелируется реальной пользой. А вот, а, но при этом, >> ну, реальная польза для синтетического сценария в вакууме на лицо. Хорошо. >> Вот. Но при этом и меня тоже типа не ложится в меня очень хорошо. История с тем, чтобы принимать решение только на основе чуйки, на паре тройке своих конкретных примеров, потому что аа так мы и заканчиваем людьми, которые себе поставили миллион скилов каких-то непонятных. А взяли >> последний опус, максимум эрт и вперёд. >> Да ну, короче, на на уровне чуйки кажется, особенно когда у тебя ты руку ещё не сильно с агентами набил, тебе кажется, что да, всё делает лучше. Оно же всё выглядит супергениально, супер классно, и люди себе натаскивают кучу всякого барахла. Вот. И как понять, что СДD - это не такое же барахло? У меня у меня есть идея, но она она очень такая, ну, то есть нужно быть достаточно большой, надо надо быть или достаточно большой корпорации, тогда ты можешь просто на уровне своей корпорации взять и провести АБЭшку. Половина у тебя >> снова Стас экспериментами на надле. >> Дадада. Половина половина как попуасой пользуются. Мне очень нравится, если что, этот подход просто используют какой-нибуд сонетик и пишут там на на стиле, а пишут там в три в три слова, что надо сделать для следующей задачи. А вторая, соответственно, берёт и пробует при помощи спек. Дальше потом открываем трейсы, смотрим фейр моды, смотрим токен консепtion и всё остальное сравниваем. В итоге получаем какую-то статистику, из которой можем сделать вывод. А второй вариант, можно быть, э, вендером, а, и предоставлять сво, ну, собственно, свою модель и просто знать про это, работает это или нет.

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

>> А я предлагаю, может быть, дальше поговорить про практику. А я до этого вот разгонял историю про то, что вот там, а, спека как источник правды, сейчас хочется поразбираться, а, по факту, а, как вообще выглядит эта спецификация? Вот если на неё посмотреть своими глазами, это первое, и, а, поговорить, может быть, про неё в контексте применимости к каким-то определённым типам задач. А можно начать вот, может быть, про применимость. Все ли задачи, которые решают разработчики, одинаково хорошо решаются при помощи SD? Тривиальные задачи решаются без помощи SD ничуть не хуже. Значит, то есть, если у тебя есть, ну, собственно, как бы в Бимаде есть такой скилл под названием Quick def. В этом скиле написано, что если там пришёл к тебе человек, принёс тебе интент, и этот интент он простой, и у него то, что там называется blradius равен нулю, зона поражения, типа того. Ну, то есть, короче, если тебя попросили там, грубо говоря, в одном файлике там поправить три строчки, да, вот, то из всей этой, значит, церемонии, то есть спека тебе не нужна, и так всё понятно. Аа из, значит, ревью там как бы, ну, короче, по простой программе. То есть мы сделали эти три строчки, мы её проревьюили там одним слоем только и нормально. Если он ничего не нашёл этот слой, ну, и хвала Аллаху. Вот. А значит, и это не СД, то есть это как раз такая штука, которая говорит, что, ну, если оно такое, то SD здесь не нужен. Антикрев всё равно нужен, да? То есть вещь, которая, так сказать, потом на всё это вот совершенно другом контексте, информационно-асимметричном посмотрит и скажет: "Не, ребята, так нельзя, она нужна". Вот. А значит, чтобы на всё это посмотрел человек, который понимает, что важно, в принципе, тоже было бы сильно невредно. [вздыхает] А, но спеку писать как бы для сессии, которая сама по себе заканчивается там за 20.000 токенов, ну, нет никакого смысла.

>> Угу. >> И это, кстати, тоже, да, это же, ну, это просто физика процесса. То есть, если у тебя А там три шага, там не два на самом деле, да, там первый шаг вообще там четыре даже. Значит, первый шаг - это понять, что хочет человек. Вот так, чтобы ему потом на следующих шагах в идеале уже никаких вопросов не задавать. То есть мы всё поняли, да? Это интент называется. О'кей? То есть как бы понимание, как это намерение. О'кей. Второй - это, зная вот это намерение, надо пойти и проследовать, значит, э код, всякий другой контекст, который там в проекте есть. Там, ну, понятно, вот этот вот верхнего уровня из спек верхнего уровня, то есть собрать в кучу всю необходимую информацию. Ну или как бы по крайней мере попытаться там именно определить, какая информация необходима, да, и её собрать. Это второй этап. Третий - это, собственно, спланировать изменения на основании, в общем, того, что ты понял, что человек хотел и что ты узнал про этот код, да? Потому что опять же вспоминаю, всё это началось с того, что ты, в общем, это проснулся, тебе сообщили, что ты Вася, и ты больше ничего Ну там System Prompt ещё написан. Понятно. На самом деле тебе очень много всего сообщили, но неважно. А, короче, а, и потом уже только ты пишешь код. Вот если вот эти четыре стадии все укладываются в одну сессию там в 50-70 максимум 100.000 токенов, то, в общем, там спектривен как бы особо тебе ничего не даст. А если не укладывается, то даст. Чем хуже укладывается, тем больше даст. Примерно так.

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

>> Этот вопрос, да? Он такой лукавый, на самом деле. Почему? Потому что ответ на него, он очень сильно зависит, а, от контекста. То есть в одном проекте одно, в другом другое. На одной задаче одно, на другой другое, да? И б от способности модели. То есть, допустим, вот если бы мне его задали год назад, да, даже полгода назад, на самом деле полгода, ну да, 7 месяцев назад у нас случился декабрь. Ну, правильно. Значит, а то я рассказывал, ну, про свою практику. Так вот, типа, на моей работе я делаю так, да, что внутри, на самом деле, каждого coding session даже я, в принципе, писал там типа, значит, вставь здесь human in the loop checkpoint. в начале, в конце и ещё там, ну, как бы до трёх мест, где это ещё имеет смысл, внутри одной сессии. Да, и, кстати, лмы с этим, в общем, более-менее прилично справляются, между прочим. А, как ни странно. Значит, ну, им там надо сообщить пару фактов, типа там, что вот если >> принимаешь там много решений, то это прямо вот то место, где надо их приняв, типа, встать и подумать с человеком. Вот. То есть я делал так полгода назад. [вздыхает][тяжело вздыхает] Прошло всего полгода, значит, мой подход опять же на работе кардинально изменился, потому что как бы я стал умнее, а главные лмы стали умнее. Вот. То есть теперь то, что я стал умнее, как бы это приводит к тому, что я лучше спеки пишу в итоге, потому что у меня как бы сильно развилась чуйка на failor ms. То есть я, когда читаю спеку, я вот как бы многие вещи, которые полгода назад ещё не видел невооружиным глазом, сейчас их просто вижу вот так вот. Вот. То есть самы выше система человекомашинная, да, умнеют не только машины, но и человеки, когда ею пользуются постоянно. Вот. То есть, соответственно, у меня как бы косяков от того, что я неправильно сообщил интент или мы там что-то там сделали на уровне планирования, не то, стало радикально меньше по обеим причинам. Соответственно, мой подход сейчас вот к Human in the Loop выглядит так. Значит, обычно я, значит, делаю, ну, by default называется, так сказать, вот есть у тебя история, значит, ты написал в рамках этой истории, ну, этот qu workflow называется вбима. Значит, он написал эту самую спеку, а я на неё смотрю довольно быстро. Дальше она пишет код, и этот код типа Hitl Review там, ну, перед этим review ещё, но в общем, вот это вот Human in the Loop. Я его, в принципе, делаю там на каждую историю. Это дефолт, да. Ну и, в принципе, как бы, если человек только начинает это всё делать, на мой непосвящённый взгляд, именно так и надо делать сейчас. То есть как-то пытаться ещё дальше улучшать, это как бы с самого начала, на самом деле, опасно, потому что, ну, уплывёт. Вот оно плыть пытается всё время, значит. Но тем не менее, что я делаю довольно часто, у меня есть эпик, ну как это, э, человек, который придумал BM, в общем, в какой-то момент сказал, что типа из не знаю, сам он эту фразу, так сказать, выдумал или где-то услышал, но я услышал от него. Идея в чём? Что значит, э-э, мы когда планируем этот эпик, разбиваем его на кодингсессии. Собственно, мы просто делаем так, чтобы вся неопределённость и все решения по внутреннему дизайну принимались слева. Желательно в первой истории, может, в первых двух, да? Значит, эти первые две истории мы исполняем именно в режиме, так сказать, Human and the Loop. >> [фыркает] >> А остальные там восемь, например, просто запускаем как бы цикл. А я даже, в общем, неделю назад написал скилл про это, который примерно такой же, как Вик, только там не предполагается участие человека в принципе. То есть он прямо заточен на оркестратора конкретно. Вот. А дальше, на самом деле, ты делаешь ревью уже всего целиком. У меня, на самом

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

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

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

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

О'кей. Я хотел, >> ну, это вопрос в том, где ошибка вылезла, да, на этапе дизайна именно спеки писания или на этапе, так сказать, превращения этого спеки в код. >> Угу. О'кей. Да, >> если как бы на втором этапе, то не надо переписывать спеку, нет смысла. А если на первом, то да, есть есть смысл.

>> Хочу немножко вот в эту сторону, э, наверное, последний заход сделать. Мы вот сейчас обсуждаем и, э, обсуждаем какие-то достаточно эфемерные задачи, которые на бумаге, ну, то есть мы обсуждаем чего-то, что-то такое достаточно сложное, на что там надо написать спецификацию. Вот. Но если прямо вот так вот задуматься даже вот в продакшн-коде, опять же, тут надо сразу дать контекст. Я, э, как-то большую часть кода, которую я в своей жизни там писал, там руководил и так далее - это мобильная разработка. Вот. И в мобильной разработке, особенно в её айёсной части, а люди по нездоровому повёрнуты. Ну, практически каждый айёсник у него. Ну, если он дошёл до синьора, дошёл до синьора и не придумал свою собственную архитектуру, короче, вон из профессии. Вот. А к чему? Это, на самом деле, черта, как бы >> не только >> далеко не уникальная для этой отрасли. К чему к чему я это веду? к тому, что, собственно, вот эта вот история про архитектуру и про достаточно жёсткую спецификацию, а, именно архитектурную кода, она как будто бы приводит к тому, что вот те самые вот трассирующие, вот тот самый дизайн, а, на самом деле, вот это вот, вот эти договорённости - это попытка снизить необходимость вот этого предварительного дизайна в начале. И условно попытка сделать так, чтобы 80% фичей могли быть реализованы. Ну, типа все знают, мы вот так вот делаем. Вот так у нас выглядят сервисы. Вот так у нас датас-слой. Вот так мы вёрстку делаем. И попытка это свести к тому, чтобы даже вот как вот по старинке, а мы могли дать какую-то спецификацию описания именно продуктовые требования там плюс дизайн дать midle разработчику и о и получить код неотличимый от кода, который написал бы сеньор в такой же самой ситуации. Вот из-за этого вопрос возникает: означает ли это то, что а для там 80% вот как раз для такого вида задач, где вот по сути вот эти вот все там требования, вот эти все решения уже были давно приняты на старте на уровне вообще архитектуры, вот во всех этих задачах SDD на самом деле не нужен.

>> Нет. >> А что мы тогда в спеке пишем? >> Ну как бы usable context window-то оттуда никуда не делся.

>> Ну то есть мы туда просто берём пидишку и кидаем. Значит, давай вернёмся обратно. Да. >> Так, >> значит, чтобы узнать у человека, что ему нужно, то есть Intн Discovery, >> Угу. >> никакой там спектectктриван не нужен. Это всё как бы выше по течению происходит, правильно? Это всё равно какой-то там диалог с ЛЛэмобом, там с другими человеками, там хрен его пойми с кем ещё. Значит, дальше. а-а, чтобы собрать, а-а, значит, контекст по коду или там по файлам, который ты написал уже контекста, да, но вот именно вот весь контекст, который кодингженту понадобится, чтобы это реализовать, это пока ещё тоже не спектрин, правильно? Но тем не менее кто-то должен это пойти и сделать. То есть в худшем случае у тебя coding agent пойдёт этим заниматься. Он спалит как бы характерно там 70.000 токенов на это дело на нормальной там кодобазе. А дальше, собственно, вопрос. То есть если у тебя всем этим занимается одна и та же сессия, то это накладывает, ну, как бы отпечаток, во-первых, на размер изменения, который ты можешь сделать в этой сессии, во-вторых, на качество, потому что, как ни крути, как бы она плыть начинает.

>> Понятно. Скорее всего, в этой сессии уже мы ничего делать не будем. Надо как-то этот весь все собранные знания аккумулировать и просунуть следующего. >> А это уже спектривен. >> О'кей. >> Прикинь, как здорово. >> Нормально. >> Ну да. [смех] То есть даже когда ты пишешь, так сказать, там вот в середине сессии, но до того, как ты начал кодировать с компаct, это что? >> Угу. >> Spec Driven Development, >> потому что этот, так сказать, compact session - это и есть спек в этот момент. Ну, это, конечно, плохой спек, но это спек.

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

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

>> То есть, если у тебя cдинing agд начинает смотреть какие-то скриншоты, не дай бог, это, в общем, плохо, потому что скриншоты смотреть - это очень дорого. >> Угу. >> И, соответственно, опять же, то есть у тебя есть бюджет 100.000 токенов, ну, условных, да, там, самовыше. Но тем не менее, значит, ты этот бюджет очень быстро спалишь, если, так сказать, тебя кодингогент, так сказать, будет смотреть именно на пиксели. Поэтому на пиксель должен смотреть кто-то другой, а кодингогенту уже должно быть сказано, что типа там, вот, чтобы получились какие надо пиксели, надо сделать вот такой-то контейнер. Вот так-то его там, >> ну конкретно МCпишка, она там передаёт структуру структуру там с вложенности с контейнерами, со всеми констрейтами и всем остальным, поэтому это, наверное, лучше информация с точки зрения кода. Ну, в общем, это, на самом деле, вот про Фигму конкретно я вообще про UX я мало чего знаю, потому что я им почти не занимаюсь. Вот. Поэтому, да, я не тот человек, у которого надо спрашивать, как именно вот пиксели делать красивые. Ну, в целом вообще >> я это в принципе умел когда-то, но это давно было >> в целом, да, [фыркает] Стас, отвечая ещё, дополняя этот вопрос, как будто бы я не видел пока ни одного Spec Dream and Development подхода, где прямо вопрос UI прямо хорошо был бы решён, потому что, ну, вообще агенты UI - это, по-моему, одна из самых больших головных болей, не очень хорошо решёт про печально, да, реально, >> не, есть решения, которые лучше, чем как бы ругаться и плакать. Там, если ты как бы год поругался и поплакал на эту тему, то когда тебе приносят это решение, то, в общем, это ты испытываешь релиз такой конкретный. Я много таких людей, в общем-то, видел. И, ну, в принципе, это, ну, так, чтобы прямо вот после этого вообще перестать плакать, такого нет.

>> Ну, там обычно типа все колеблятся между двумя полюсами из того, что я вижу. Полюс номер один - это сначала сделать так, чтобы у тебя была классная дизайн-система Pixel Perfect со всеми заведёнными компонентами в коде. И дальше в спеке ты оперируешь компонентами. Вот. Либо второй лагерь говорит такой: "Да насрать на этот UI, что-то похожее сделал и нормально". То, что выглядит не очень красиво, красиво в нашем век ничего не значит. Вот я два лагеря знаю таких.

>> Стоп, блин. Короче, я вот я с тобой вот с первым лагерем соглашусь. Красавчики, молодцы все, делаем дизайнсистему. А второй лагерь, мне кажется, он всё-таки другой. А нету проблемы в том, чтобы сделать дизайн, похожий на то, что у тебя в Фигме есть. И там есть плюс 100, 500 способов, начиная от того, что ты MCP подрубаешь и отдельным им ещё отдельный налог платишь за использование токенов. Это какая-то вообще новая новый уровень жадности. С другой стороны, ребятам надо выживать. Вот. Но там, а, агенты очень круто генерят, потому что там передаётся не пиксели, там передаётся именно структура. Ну, то есть вложенные контейнеры друг друга и вёрстка получается хорошей. В худшем случае вариант для бедных - это, соответственно, экспорт в формате HTML. А все, э, ну, собственно, что может быть прекраснее для агента, чем HTML? Сколько, на каком количестве HTML они вообще в своей жизни научились, правильно? Поэтому они тоже генеряат достаточно >> отдельный столкий вопрос, >> да, >> был ли это хороший HTML, >> да, по дай это был HTML, там неважно. Важно, какой результат получился. И результат получился хороший. То есть он в конечном счёте он смотрит на HTML и генерит код на Uном фреймворке соответствующую. Ну, то есть, по крайней мере, вот то, с чем я играл, со то, что он там Swift UIчик, он, например, хорошо генерит Compose неплохо и так далее. Вот. Но тут опять вопрос в том, что получается, что это немножко дальше, и оно как будто немножко конфликтует со спекой, потому что в этом случае дизайн, вот эти мокапы, в некотором смысле являются важной спекой, которая они должны как-то соотноситься. И чего уж там, а, брать и описывать в этой спеке расположение между собой объектов ну это не самая лучшая идея. Ну, то есть, если мы попытаемся взять >> Подожди, подожди, стоп. А это спека какого уровня, история, эпиic или проект?

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

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

>> Так, а я предлагаю двинуться дальше. А затронув вопрос про то вообще юайчик, является ли зона ответственности спецификацией или нет. Мне кажется, нам надо поговорить в целом про спецификацию. Вообще, а что в спеках стоит писать, а что не стоит? Это вообще если важна ли вообще структура спеки или пофиг можно сплошным текстом мысли и всё >> го о хороший вопрос [смех] давайте сначала про маленькую значит про маленькую спеку на самом деле вот именно про маленькую мы знаем довольно много по двум причинам во-первых там миллионы уже сейчас людей как бы их там пишут по 30 штук в день и во-вторых как бы именно на этом уровне в общем-то академический resarch так сказать он ну вот это вот статейкисиве они в принципе там попадают куда-то туда. То есть если вот про это где-то, в общем, там какие-то люди там в каком-нибудь университете чего-нибудь в коллаборации с антропиком написали статью, то это, в принципе, это самое потом, когда ты это берёшь и тянешь к себе в своё решение, оно, в общем, обычно стреляет на этом уровне. Значит, что мы знаем вот на этом уровне? про это, про всё. Во-первых, как ни странно, значит, самое главное во всей этой истории, что мы знаем, что она должна быть определённого размера. Конкретно, [вздыхает][тяжело вздыхает] значит, э если это statement of intent, то есть это как бы там описано, что хотел человек от этой сессии, то это 300 токенов максимум. Значит, это может звучать на самом деле как типа очень немного, но вообще-то это две-три страницы текста. Нет, подожди, >> нет, подожди. 300 токенов - это да, 300 слов. Две-три страницы текста - это 1.500, да? Это это полстраницы текста. Значит, если я не могу тебе в полстранице текста объяснить, что мне от тебя надо, то это уже это самое значит интен большего размера, чем одна история почти всегда. Ну, опять же, мы не говорим как бы на абсолюте, да, то есть нету там никаких заборов там, которые типа о 301 токен свободен, это типа уже сразу две истории. Ну нет, да. Но тем не менее вот где-то оптимальный размер именно намерений человеческих - это токенов 300. оптимальный размер всей спеки целиком, как бы вот того, что именно вставляется в начало сессии кодинговой. Это где-то и вот про это есть, на самом деле, довольно много исследований. И, ну, в принципе, как бы с моими, значит, чуйкой, личным опытом и как бы сказать вот я вот это прописал там в какой-то момент, а дальше там, ну, я не знаю, сколько миллионов раз это было в разных местах, на разных контекстах исполнено. Были люди, которые ко мне приходили и говорили, что это мало. Но, в общем, я их обычно переубеждал, что это у них что-нибудь в другом месте не так. Так, и что же тогда в эти пишется в этих полуторытысякенах?

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

>> Нет, подожди, значит, зачем там жить продуктом? Продукты живут в интенте, да? То есть вот продукт как бы тебе объяснил, что нужно. Угу. >> Угу. >> Это именно интен. >> Всё, я понял. Да. >> Да. Значит, то есть как бы в чём идея? Значит, вот в идеале, когда у тебя есть именно planing session, тот, который пишет спепупу, значит, после того, как именно предложение. У меня гениальное предложение. Я предлагаю разыграть разыграть вот это вот по шагам. Ну, то есть вот пришёл продакт, >> ну, это долго будет. >> Долго. А, [смех] а квик, >> прикинь, по токенов это три странию командук. Нету командыкспек, померла давно уже. Есть команда Quick Def, там всё происходит внутри. По шагам там всё просто. Первое, что там написано, это типа узнаю человека, что ему надо. То есть, ну как узнай, либо посмотри как бы вот в тот промт, который вызвал этот скилл, либо посмотри, так сказать, в предыдущий контекст, либо, собственно, если не там, не там, ничего такого нет, спроси у человека. Вот. И продолжай спрашивать у человека, пока, в общем, не станет всё понятно. Потом, значит, напиши это всё там в приблизительно 300 токенов, не сильно больше. Потом, значит, запускаем субагента, которому сказали субагент. Ну, там, на самом деле, там про вот про субагента про следующего. Там вообще одна строка, там просто написано, типа, пойди вот так вот вокруг, типа поводи жалом, так сказать, посмотри, что что на самом деле будет нужно, чтобы спланировать а имплементацию этого намерения, то есть исполнение этого желания. Вот иди, ищи. Значит, дальшем ищет сам. Как бы раньше про это там было прямо много параграфов, так сказать, но вот Опус 4.7 приблизительно он уже ничего этого не требует. Он как бы сам отлично справляется с этой задачей на, ну, хотя бы примерно нормально организованном коде, где как бы всё понятно, логично и по полочкам разложено.

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

>> Это не звучит как, э, intent размером в один coding session. >> В смысле, он слишком большой. >> Это, скорее всего, как минимум как минимум эпик в реальной жизни, а может быть и больше, потому что у тебя сразу как бы вылезает, что их надо репортить где-то, да, их надо на самом деле где-то правильным образом учитывать. Там должен быть какой-то немедленный секьюрити вокруг этого всего. Ну, короче, это это работа на месяц, вообще-то. [смех] Так пому-то ежели. Вот. Ну, соответственно, то есть это плохой пример для coding session, это хороший пример для проекта.

>> А, о'кей. Мы делаем, а, ладно, более простой. Мы нам нужно на мы показываем какие-то сущности, мы хотим сделать новый вид фильтров. Фильтры по, я не знаю, там по нерасловости предложения. Поиск поиск авиабилетов и хотим добавить фильтр количества пересадок.

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

>> А, ну вот смотри, то есть про coding session, да? Это значит intтент на один coding session и дальше там, ну, как бы вот у меня на самом деле в этом у нас в BMАде есть этот спект. Там, в принципе, как бы практически каждое слово в этом темплейте написано кровью, так или иначе. А, и в общем там получилось в итоге примерно так, что, значит, сначала там идёт интент, потом там идёт, ну, я сейчас из головы говорю, могу на самом деле пойти посмотреть. Ну, примерно так. Значит, что там идёт этот input output matrix, так называемый. На самом деле это просто как бы некоторый набор правил, что если на вход прилетело вот это, на выходе должно быть вон то. >> Угу. >> А покрывающий как бы все >> типа аля такой верхнеуровневый мы тесты как будто описываем, да? Ну, это ещё не тесты, но из этого, да, из этого нужно делать уже тесты, >> да, да. То есть мы описываем, по сути дела, как же это, блин, >> ну, трево системе, >> господи, по-русски это называется. [вздыхает][тяжело вздыхает] Ну, в общем, мы, конечно, и так наполовину по-английски говорим сейчас. Короче говоря, это значит у тебя есть какие-то

values. У них есть какие-то domain boundaries. Если вот, то есть у тебя есть общее множество всех возможных значений чего-то, да? Вот если оно как бы вот в эту категорию попало, то вот так должен выглядеть выход здесь. Если в это, вот так.

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

Есть одна маленькая проблема, что не все требования можно выписать в таком виде. Вот есть на самом деле обычно ещё какие-то acceptance критерия, которые не про вод и вывод. [фыркает] Соответственно, как бы за этим ты пишешь все остальные типы AIS, да, которые для этой сессии важны.

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

>> Это один input output matrix row, да?

Угу. А второй - это какой? Что мы делаем, когда их нашлось ноль?

>> О'кей, нормально.

>> А третий - это какой? Что мы делаем, когда их нашлось больше пяти? Ну или там двадцати, я не знаю, сколько у вас там на экран влезает.

>> Понятно. Понятно. Вот это всё вот оно.

>> А это получается общая спека будет для, ну, то есть это это требование, оно кажется общее, оно вообще не изменится у нас. То есть мы говорили сейчас про какие-то условно стадии. То есть у нас в начале там в первой старе мы, а, там она треacing, соответственно, потом а мы уже там делаем развесистая UI, потом развесистое, например, ээ. А, и правильно ли я? Ну и у нас и у нас вот эти требования, они вообще не изменятся. Это они универсальные для всей для всей вот этой вот фичи, для всей для всего этого эпика там,

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

>> Ага, о'кей, я понял. Скорее всего, вот, соответственно, у тебя как бы и получается на самом деле, что когда ты как бы берёшь какой-то интент больше, чем одна история, да, и ты выписал для него все требования, какие смог придумать, вот примерно по такой же схеме, ну или можно, в принципе, то есть вот на том верхнем уровне как бы и работает и вот эти все это самое энтропомощные штуки, типа when then, вот эта вся, в общем, тема старая.

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

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

>> Угу.

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

>> огонь стало понятно.

>> Возвращаемся к спеке про coding session или не возвращаемся, потому что мы ещё не закончили,

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

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

>> чтобы он за меня придумал, я вообще ничего не хочу.

>> Ну не, ну по не, ну почему? Тебе же без разницы, он forloop или цикл напишет для того, чтобы перечисление какое-ни, это он за себя уже придумал.

>> Во. Ну да, да, можно и так сказать. [смех] Вот. А а вторая шкала, про которую

>> это кардинальная разница, в том-то и дело.

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

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

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

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

>> Проблема в том, что есть бесконе в мире есть бесконечное количество вещей, которых не надо сделать в этой сессии.

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

>> Дадада. удержать его просто,

>> да, [смех] в том, чтобы как бы показать докуда докуда копать. чтобы как-то результат получился предсказуемый.

>> Потом там ещё есть такой тоже вопрос интересный. Я не знаю, если честно, на него ответа, но это сложный вопрос. Аа значит где надо писать примеры, а где абстрактные правила? Как бы обычно у меня там стоит инструкция типа, что напиши абстрактное правило, там предельно просто, а потом как бы, если оно хотя бы чуть-чуть сложное, подкрепи его парой примеров. Но, в общем, я понятия не имею, это правильно или неправильно, но вот где-то там, ну, и последнее, что там должно быть, собственно, ну, почти последнее, ладно, это, а, там ещё, понятное дело, должны быть functional requirements, если они играют какую-то роль в этой истории. часто не играет никакой роли, да, потому что мы там, допустим, Performance Optimization будем где-то ещё делать. Ну и понятно, что он всё равно там чуть-чуть про это думает, но именно там заряжать его на то, что надо его как-то там померить, в общем, и так далее, это очень большая работа. Это лучше не надо делать.

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

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

>> А стоит ли оставлять вот такие nice to have вещи, которые не прямо не лазерно фокусируют агента на проблему, которую надо решить, потому что выглядит это как, ну, мусор какой-то словесный?

>> Лучше нет. А на самом деле, смотри, вот я когда говорил, что 1.600 токенов, да, это механизм, которым ты как раз заставляешь лмку, которая пишет эту спеку, выкинуть всё неважное.

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

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

>> Сины пром нет. Смотри, системный промт - это вещь как бы, ну, во-первых, системный промт - это вообще абстрактно, да? Это это не про проект совсем. Значит, есть, понятное дело, у тебя контекст проекта. То есть это там какой-нибудь там ClДМ или ещё что-нибудь, так сказать, где, в общем-то, написано вот всё, что каждая сессия должна знать про этот проект. Скорее всего, там не написано про архитектуру как таковое. Там просто написано, что если тебе надо узнать про архитектуру, прочитай вот этот файлик. Ну, прогрессив Discoverover, потому что, в общем, далеко не каждой сессии вообще надо знать про архитектуру. Зачем? Значит, а знать про вообще архитектуру кодигагенту, как правило, тоже не надо. Вот тому, которые планирует, часто надо. Обычно надо. Вот тому, который кодирует, в принципе, достаточно сообщить, а-а, как бы сказать, ну, то, что ему, собственно, надо знать. То есть у тебя есть там, грубо говоря, допустим, у тебя в голове там 100 коробочек и 200 стрелочек, а этому агенту надо там три коробочки и две стрелочки. Вот остальные ему, в принципе, и не нужны. Если он начнёт их сам себе, так сказать, куда-то грузить, это, в принципе, печаль. Ну, опять же, самовыше у тебя бюджет не резиновый далеко токена на контекст. Вот. А значит, там вот какая штука. То есть, да, это такая секция там есть. Она короткая совсем, как правило. Ну, потому что Интент-то у тебя маленький и, соответственно, изменение тоже небольшое. Но а там ещё, значит, написана такая инструкция для планирующего агента. Ну, у меня написано, и это, в принципе, вроде как хорошо работает, что не надо принимать решения, которые должен и может из своего контекста принять coding agent. Потому что часто у тебя в спеках, когда они тоже генерятся лмами, ну, они сейчас, собственно, всегда генерятся лмами, вот эти уровня одной сессии.

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

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

>> О'кей.

>> Ему там, ну, скорее всего, надо сказать, что писать надо вот в этом файле и вот в этом файле. А что именно? Ему как раз лучше бы не говорить, потому что, собственно, тогда зачем нужен coding session-то, чтобы там каким-то не очень идеальным образом, в общем-то, это переписать код уже написанный в Маркдауне в там какой-нибудь DJ JS тоже плохо, да? То есть именно как раз это, ну, опять же, это такая идея Progressive Discoverovery есть, наверное, все уже знают, что это такое.

>> Ну, я думаю, да.

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

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

>> Так,

>> ну вот так.

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

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

>> Дадададада. [фыркает] Но с другой стороны, у меня у меня контекст Window, тем более, он вот окусенький. Ну, если это пять страниц текста, это прямо уже здорово. На самом деле, на пяти страницах текста я уже плыву в середине только в путь. Понятное дело. А вот, а значит, соответственно, а зато на самом деле, кстати, я очень хорошо умею видеть, ну, смотреть на это визуальные представления, а ЛЛМКА не умеет. Вот поэтому именно на этом, значит, уровне, как бы сказать, абстракции вот, ну, размера предметной области, да, когда мы уже говорим не про один cing session, а про несколько, а тем более про 100, там, на самом деле, сильно начинают рулить всякие графические представления. Вот те самые коробочки со стрелочками. Если я смотрю вот так вот на страницу, где нарисовано там 10 коробочек и 30 стрелочек, а-а, значит, я смотрю вот так вот на такую же страницу, где они там написаны словами, то, в общем-то, это на странице, где они нарисованы, я, в общем, проблему увижу сразу, скорее всего. А на странице, где они описаны словами, ну, как пойдёт. Мы тут в выпуске про про этот про э-э корреляции. Внезапно узнал для себя то, что Ну, у меня тоже вот. Но нам там гость сказал, что это на самом деле не так. И есть куча людей, которые в голове очень плохо себе представляют стрелочки и кружочки. И в общем в общем, есть разные люди,

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

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

>> Вот внутри эпика я никогда не параллелю, практически никогда, потому что, ну, нету смысла обычно. А между эпиками оно, на самом деле, довольно здорово получается часто. То есть ты там, грубо говоря, сказал там какому-нибудь этому оркестратору, типа вот на этом эпике номер четыре, так сказать, сторис там те по 10, иди и делай. [фыркает] У него это займёт полтора часа. эти полтора часа я могу на самом деле в этот момент заниматься там эпиком номер пять, потому что я когда планировал спек проекта, я прямо выписал там в последовательности эпиков. Это не просто как бы список эпиков, а это именно список с зависимостью. Вот. И это тоже такая важная роль спеки. Теперь, значит, про спеки, это моё личное мнение, оно как бы для меня работает. Я вообще делаю так, особенно на уровне проекта, то есть когда это там, ну, типа там 3 тире10 историй, я сильно не заморачиваюсь. В общем, в бимеде есть скилл под названием BM SPC. Значит, я просто запускаю этот скилл. Он, в общем, всё делает, как надо, и там всё прекрасно. А если это именно проект большой, да, там, как правило, в начале много неопределённости, а в конце, на самом деле, тебе нужно про этот проект объяснять как бы самым разным целевым аудиториям, часть из которых - это сессии и лмные другие, да, а часть из которых люди. Люди тоже разные, в том числе ты сам, на самом деле. Вот поэтому там я делаю, в принципе, так. Аа, ну, как бы с точки зрения парадигмы примерно, значит, сначала у тебя есть груды какой-то, точнее так, сначала у тебя есть инtт, вообще-то, а опять же, самывы выше - это, как правило, полстраницы, максимум страница текста, ну, которую ты там как-то родил, да, неважно как там пошёл, поговорил с каким-нибудь там умным опусом, ээ, или сам написал или тебе его как бы кто-то написал. Ну какая разница? В общем, ИТНТ итент. После этого, так сказать, я обычно, если это именно проект настоящий, значит, иду и тем или иным способом собираю такие груды порода. То есть либо это какой-нибудь depress search пром в какой-нибудь Джемини, который тебе там на 40 страниц диссертации напишет там, кто кому Рубинович, да, вот так в этом мире. И там, в общем, среди этих со0ка страниц, ну, может, там будет там пять здравых идей. Ну, и хорошо. Вот. Или там я сам пошёл там или с кем-нибудь, в общем, ну, что-нибудь такое там набройнстормил тоже. В общем, там 100 дурацких идей, среди них две гениальных. Нормально, в общем, хорошее соотношение, на самом деле. Дай бог, если так каждый раз. Вот. А потом, э, значит, я из всего этого выделяю как бы главные мысли, причём, ну, по отдельности из каждой этой кучи. И это всё, в принципе, опять проable context Windows, кстати, потому что на этом уровне там что получается? Обычно люди вот собирают так или иначе эти кучи, дальше, ну, это если наивно это делать, засовывают прямо их прямо вот так. А в там какой-нибудь этот генератор каких-нибудь там PRD, все знают, что такое PRD или нет?

>> Прок.

>> Вот. И у них на входе, так сказать, получается типа документ.

>> Угу. И они думают, что это и есть, по сути дела, типа спека этого проекта. Дальше выясняется на самом деле, что что там произошло, когда ты эти там кучи запихал, ты сразу раздул там, грубо говоря, контекст эток до 100-2.000 токенов уже. Когда он начал про всё это думать и пытаться из этого что-то сделать, он половину того, что он там увидел, забыл. При этом, как бы, поскольку он не знает, что важно, что нет, самовыше упоминали, да, он он плохо это знает на самом деле, то оказывается на самом деле, что из этой половины, в общем-то, частично он забыл там вот одну из тех двух гениальных мыслей, которые там были среди девяносто восьми идиотских, правильно? Так вот, значит, поэтому, как бы, я делаю так. Я на самом деле сначала пропускаю эти кучи через там дистиллятор некий автоматический, который просто вот он смотрит на кучу и такой: "Ну вот вот это ключевая мысль, вот это ключевая мысль, вот это ключевая мысль". Он как бы не знает, они на самом деле левые или нет, да? Ну, в смысле, идиотские или гениальные. Он просто знает, что они такие типа guiding thoughts, то, что называется. Вот обычно их там получается, ну, и со ссылкой, где на самом деле было написано про это вот в исходной куче. Получается где-то штук 40 обычно. Если их все как бы свести вот так вот и, ну, просто дедубликацию сделать, потому что там же они повторяются всё время, правильно? Там в разных видах. Вот у тебя есть там, грубо говоря, 20-30 этих самых гайдис про эту идею. И вот тут, значит, ну, это так делаю я. Значит, я начинаю эти guiding thoughts, ну, то, что называется, как бы сказать, укреплять. На самом

деле, в общем, у меня пром про это есть. У нас в Бимаде уже, кстати, возник. Мы его таки донесли дотуда. А значит, ну, короче, вот поэтому списку он уже там как бы как-то классифицирован более-менее в там в каком-то логичном порядке, да, ну, чтобы смотреть сначала на, в общем-то, что, потом как, потом это, почему так нельзя, скорее всего.

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

Смысл в том, что, в общем, в итоге на выходе получается такая странная штука. значит, худобедно организованных там более-менее в разумном порядке. Просто 20 очень коротких параграфов про то, что мы тут собрались строить. В этом месте оказывается, что вот из этого я могу сгенерить любое представление этого проекта, какое захочу. Практически автоматом. Если мне нужен PRD, я сгенерирую PRD. На самом деле мне никогда не нужен. вообще никогда, потому что как бы, ну, кому нужен PRD, значит, тому, кто будет планировать, не нужен PRD, ему можно просто на вход эти 20 отдать, да? Значит, тому, кто будет деньги на это давать, тем более не нужен D, ему вообще нужно совсем другое. А-а, ну и так далее, да? То есть там девелоперам, которые будут думать, как всё это строить, в принципе, PRD тоже не нужен. Ну, то есть, если надо там принять архитектурное решения, то этих двадцати идей вот так хватает, так сказать. Уже ничего не надо. Бу. Перти нужен продукту, чтобы оправдывать свою полезность. >> А, ну, господи, да пусть пишут PRD тогда, если им это нужно, как бы можно этот PRD просто рассматривать в качестве одной из куч на ходе этого процесса, понимаешь? >> О'кей. >> Ну, либо вообще как бы гениальный уровень - это заставить сам продукт им пользоваться чем-то таким. Вот это прямо здорово, когда так получается. Не всегда получается.

[тяжело вздыхает] Вот мы говорили о том, это, ну, не в этой сессии, но тем не менее, значит, как это всё продать тру трудовому коллективу, да? Вот девелоперам это всё продать просто, ну, по моему опыту сравнительно, а вот бизнесам - это мамочки мои, вот, вот где страшные тайны-то золотого ключика это само содержится. [фыркает] Им, да, тяжело. >> Угу. О'кей. Так, получается, ещё раз. спеки вот такого верхнего уровня - это, по сути, такой верхнеуровневые ключевые идеи и интент получается. >> Ну, в моём нынешнем мире, да, я сейчас делаю так, последние где-то полгода, наверное. >> Ой, о'кей, понял. Так, а надо ли нам ещё, >> ну, Интен, да, обязательно. То есть как бы вообще вот это тут надо понимать, что эти 20 значит ключевых идей там, ну, может, 50 там, не знаю, ну, как бы редко 10 и никогда не больше со0ка в моём опыте. Там, когда ты их строишь, у тебя как раз интент кристаллизуется со страшной силой в них. Вот просто в процессе представления.

>> Хотел хотел проговорить про как-то участие участие непосредственно человека. А я услышал такие моменты, что, во-первых, у нас а чем более верхнеуровневая, соответственно, спека, тем, а, большего вовлечения, а, человека мы ожидаем. Соответственно, идём от самого большого дальше, потом снижаемся всё ниже, ниже, ниже. На каждом из этапов, э, а спека она может там при помощи модели в том числе проливаться. И там мы, соответственно, приглашаем человека в том, чтобы он, соответственно, как-то взял, подправил, э, выкинул там что-то ненужное, как-то доуточнил требования. Но условно, если мы работаем вот с этим методом, мы много работаем для того, чтобы сделать вот первоначально как-то загрузить себе в голову в контекст весь эпик, а потом уже на вс всё более и более мелких шагах а тратим всё меньше и меньше времени. А хотел >> не не совсем так. Ну, в моей практике это не так. >> Так, а как? >> Смотри, значит, в моей практике, если я вообще делаю проект вот размера проекта, это происходит, ну, допустим, раз в месяц максимум. Ну, потому что у меня нету Гринфилда, да? У меня есть как бы >> на работе, значит, обычно, и я как бы имею дело со старыми проектами, >> Угу. >> в которые мы там всё время что-то добавляем или меняем. Значит, Greгenfield у меня бывает, но довольно редко. А так вот, когда, значит, я раз в месяц у меня возникает интент именно размером там не на один эпик, а больше, то, да, я трачу где-то день на вот этот процесс. Потом, значит, когда у меня из вот этой штуки генерация, собственно говоря, архитектура и список эпиков, ну, поскольку у нас, на самом деле, проекты старые, там всё уже и так понятно обычно, поэтому это на самом деле очень быстро всё происходит. Когда я потом гидиль успех эпика, это вообще практически автомат. То есть там вот тебе успех проекта, вот в нём типа описан уже там, ну, как-то кратко, там эпик номер четыре с генери не успех. Посмотрел это прямо ну полчаса - это самое большее, реально меньше. При этом у меня где-то полрабочего дня уходит на то, чтобы читать код свой чужой код ревью. >> Угу. >> То есть вот как бы вот такая практика на самом деле. Ну, если говорить про спеки, получается опять, ну, примерно то, о чём я говорил, то, что мы платим дорого, >> а >> чем более верхнеуровневая спека, тем больше нашего влечения, соответственно, >> на одну спеку, да. >> О'кей. >> Ну, просто понятно, что в одной типа спеке размера проекта там 40 спек размером с историю. >> Угу. >> Поэтому в общей сложности, скорее всего, времени на них уйдёт больше. Но, ну там у меня не было никогда, так сказать, в последнее время там именно спекмером с историю, на которые я потратил там 6 часов в своей жизни. Спек размером с проект - это, ну, вообще норма жизни. Это хорошо, ещё если только шесть.

>> Так, у меня есть ещё один вопрос по поводу спецификации. Мы его уже чуть-чуть затронули, и это прямо точно мечта вообще куче людей, которые думают про Spec Driven Development. Они такие думают, что мы вложили кучу времени в спике, а давайте не будем их выкидывать, а сделаем так, чтобы они всегда жили, были вечно зелёными, обновлялись вместе с Кодом и служили бы, а, замечательным контекстом для агента. Вот примерно, Лёш, как ты говорил, комментарии только. Зачем комментарии в коде, когда можно целый, подробный, классные, файликами? Аа ты сказал, что это всё ещё технически как будто не очень возможно. можешь вот тут давай, давай так представим, что технически становится возможно, имеет ли оно вообще смысл в процессе? Стоит ли нам ждать, когда такое появится, и надеяться и мечтать об этом? >> Мечтать об этом? Ну, смотреть, что хотеть от этой жизни, но, в принципе, можно. >> Угу. >> А я сильно сомневаюсь, что это появится как бы в ближайшие 10-20 лет. Ну, может быть. Кстати, штука в чём? Во-первых, комменты в коде - это вещь, на самом деле, ортогональная коду, потому что в коде написано обычно как, а в комментах как бы просто почему. А, ну это правильные комменты в коде выглядят вот именно так. Ну плюс, понятное дело, если тебе нужно документировать какой-нибудь там публичный PI- это другой вопрос, да. А, и в этом смысле как бы комменты они не являются абстрагированным представлением кода. Они являются просто пояснением, почему это так, которое тебе нужно, чтобы, ну, не потерять, собственно, суть. Вот. А значит, спека в этой истории, э- ну, кстати, опять же, я говорю, то есть есть люди, которые так делают, и у них это как-то работает. Поэтому всё, что я сейчас, так сказать, скажу, это ни на чём не основано. Я так не делаю. Я принял в какой-то момент решение так не делать, потому что мне показалось, знаешь, на основании там чуйки и разговоров с другими людьми, которых я почему-то уважаю, да, что так делать не надо, но может я и не прав. Вот. Но тем не менее, значит, спека в таком подходе - это абстрактное представление кода. То есть это источник истины. Печаль в том, что это как будет по-русски лосси, >> ну, с потерями. >> То есть там вообще без вариантов, на самом деле, теряется информация. То есть мысли изречённые есть ложь. Здесь это работает точно так же. При этом как бы поскольку механизм вот этой компрессии - это, по сути дела, ЛМ, который самый выше там плохо понимает, что важно, что нет, то и компрессия там получается тоже такая странная. Значит, чтобы её удерживать там в каком-то более-менее приличном виде, ну, то, что я вижу как бы время от времени, просто глядя под капот Опенспеку, это что там куча, на самом деле, дикой совершенно сложности именно про это в нём самом. Ну, то есть ты смотришь на эту сложность, такой: "Да, не может быть, чтобы это работало там на горизонте в полгода хотя бы". Ну просто не может быть. Но это опять же я говорю, может я ошибаюсь, но моё такое вот чуйка. И там, в общем, приходится просто много усилий, как бы, к этому прикладывать. А ну зачем? У тебя в коде уже всё написано, если там нормальные комментарии, там даже написано вот это. Почему, которого часто не хватает просто в коде? Да. Ллэмы они тренированы, собственно говоря, смотреть в код и всё про него понимать. >> Ага. >> То есть, ну, КЛОД отлично справляется с этой задачей, кодекс тоже хорошо. А, ну вот поэтому я как бы не вижу смысла, значит, то есть, ну, как, короче говоря, там спеку любого уровня, да, надо держать примерно до того места, ну, как бы вот рядом с агентами, то есть где-то там в доступности, в контексте там нужных сессий держать ровно до того места, а когда ты эту спеку исполнил и провёл по ней ретроспективу. После этого это мой подход, её надо куда-то архивировать. И, ну, может быть, когда-нибудь там из каких-то ностальгически обучательных соображений тебе захочется на неё ещё раз посмотреть и содоргнуться. >> Угу. >> Да. Потому что, ну, то есть если это была спека трёхмесячной давности, я на них иногда смотрю, я содрогаюсь. Это как бы хорошо и правильно так должно быть. А, ну, в общем, вот так. А если бы она была активная у меня в проекте до сих пор, ну, я бы каждый день по 20 раз содрогался. У меня в проектах обычно хватает с чего содрогаться и без этого, поверьте. [смех]

>> О'кей. О'кей, услышал. Так, теперь аа я хочу пройтись прямо тако в режиме блица скорее по вопросам и проблемам, которые люди чаще всего задают, когда слышат что-то проdд. Я там много это в нашем ей клубе вижу, в чатиках и так далее. И вот давай я буду прямо миф какой-то называть, а ты говори миф - это или нет. И так парой слов, почему. Собственно, первый - это про передачу смыслов. Это как раз, наверное, похоже на то, что ты сейчас разгонял. Собственно, э человеческий язык - это такая довольно несовершенная штука, чтобы дать машине полное описание того, что надо сделать. Мы либо описываем всё слишком лосси, и тогда агент сам слишком много вещей самостоятельно выводит, либо мы описываем всё слишком детально, и тогда уже практически доходим до уровня кода, потому что типа sufficiently detailed spec is a code. На самом деле, так, собственно, как быть с тем, что смыслы теряются и агент в итоге делает что-то не то, что ты на самом деле хотел? Ну, для этого у тебя существует система обратной связи в пять слоёв как минимум. То есть там автоматические тесты, entic review, human review, а там, ну, короче, не буду полный перечень, так сказать, приводить, но в конце концов у тебя есть продакшн. >> Угу. И, в общем-то, у меня есть надежда, что из этого продакшена как-то простроен канал, что, в общем, когда у кого-то что-то не так, во-первых, они могут понять, ну, точнее, не сами понять, но как бы они могут тебе что-то сообщить такое, что позволить тебе понять, что именно у них было не так. Вот. И как бы, ну, опять же, никакого другого критерия истины в принципе у нас нет. >> А с с какой истиной и тесты, и агентское ревью сравнивают? >> Как это? >> Ну, опять же, а что делают тесты? Тесты проверяют, что код работает правильно. Отку кто пишет эти тесты и откуда они знают, что такое правильно? И то же самое >> проверяют ли они, что кот работает правильно? >> Да, >> это отдельный тонкий вопрос. >> Угу. >> Вот, э, с тестами вообще всё сложно, на самом деле. Как бы зелёные тесты сильно переоценены, опять же, особенно когда их пишет тот желм, ну, как бы в другой сессии, пусть, но тот же, который кодировал. На самом деле есть тоже такая проблема, а значит, что, который кодировал, он тебе как бы напишет там [вздыхает][тяжело вздыхает] кучу тестов, а, исходя из примерно тех же соображений, ну, как по тем же весам, на самом деле, из которых он кодировал, да? А, и там всё будет такое зелёное, красивое. Там ещё даже у тебя будет там близких к 100% каридж, может быть. Вот. И при этом там будут содержаться, так сказать, косяки. Там есть целый класс косяков, на самом деле, а, которые выглядят именно так. Continuous integration зелёный, coverage 100%, а код неправильный. Вот. А, ну, соответственно, что что мы должны сейчас сделать? Перечислить там известные мне классы этих косяков. Ну, их там, не знаю, сейчас напридумываю штук шесть из головы. Но они есть, всем, как бы, это понятно. А, то есть как бы тесты, ну, в общем, в лучшем случае, если это хорошо правильно написанные тесты, покрывают, что этот код, а, сделал то, что до него как бы донесли в там/acceptance criteria. >> Это может быть. >> Потом, значит, это писать автоматические тесты для фронтэнда- это вообще неблагодарное дело. Даже сейчас он как бы слишком быстро меняется и там на уровне сильно выше самого теста у тебя просто получается, что ты создаёшь себе больше проблем, чем решаешь таким образом. >> О'кей. Я, наверное, услышал тебя. Так что эта проблема на самом деле не уникальная именно для SДD. Вот просто SD её не решает, >> как и подавляющее большинство других проблем. Да. >> О'кей. А давай следующее. А лмка, вот ты сел, написал какие-то умные слова в спецификации, а, а лэмка может их проигнорировать. Ну, это, наверное, подножится предыдущей проблемы. А, и без настоящей формальной верификации про это вообще не узнать. Есть, короче, такой клуб адептов формальной верификации, кто говорит, что давайте вообще в целом программу там на коке писать. >> Ну, есть, я, в общем, знаю таких людей даже. как бы это же очень дорого. Просто >> тебе такой уровень качества, так сказать, нужен, если ты рулишь там ядерным реактором, например, >> ну или даже на самом деле там каким-нибудь станком, в общем, в который вставлен какой-нибудь резец, потому что он может резануть куда-нибудь не туда, да? А, ну как бы 90 сколько-то там процентов всего софта, который пишется, оно, в общем-то, не такое. И как бы есть куча предметных областей, где, в принципе, вполне нормально там допустить как бы протечку каких-то дефектов в в продакшн. >> Как бы никто этого не любит. В общем, все задаются вопросом там, сколько человек надо слегка огорчить, чтобы это было хуже, чем повесить котёнка, да? А, ну это происходит тем не менее. То есть котёнков, в общем, время от времени вешают, а с верификацией, короче говоря, проблемы. Понятно, в чём? Что если у тебя простая предметная область, то она, в общем-то, возможна и даже как бы за разумные деньги это можно сделать. А как только у тебя, так сказать, сложность перевалила за какую-то довольно маленькую, на самом деле, в общем, объём, [фыркает] это всё разваливается. Ну, по большому счёту, на том, что как бы у тебя возникают вопросы к как бы это сказать, а-э, а вот то, что мы верифицируем, оно само-то, правильно? >> Угу. >> Ну, как-то так. >> А следующий миф про увеличение потребления токенов. И здесь, на самом деле, интересно, потому что я знаю ребят, которые, а, когда скорее проплан мод, но когда им нужно что-то запланировать, они врубают самую дорогую модель, самую умную, последний опус и врубают максимальный эфт. Вот. И здесь вот интересно с точки зрения, а, вообще моделей, наверное, в первую очередь, а, для того, чтобы обслуживать всю эту мушинерию, насколько умной должна быть модель и насколько много эфтать. Мы можем как бы долго рассуждать по этому поводу. Все наши рассуждения, они на самом деле станут неверными буквально через пару недель. И если мы через пару недель будем рассуждать, то то, что мы тогда нарассуждаем, оно опять станет неверным через пару недель. В связи с чем, как бы, я долго про это думал, так относительно довольно много, но как бы перестал заморачиваться, и я тоже гоняю опус в режимериниing. И в общем, у меня как бы две подписки по 100 руб. Одна на клод, другая на кодекс. Мне хватает, как правило. Если не хватает, я беру ещё одну. >> Ну и, наверное, закрыва. То есть жизнь коротка, как бы, и всё равно я стою гораздо дороже, чем эти две подписки. >> У меня буквально вчера, на самом деле, был разговор с человеком, который рассказывал, задавал вопросы про то, типа, как я вообще подхожу к оптимизации траты токенов, пытаюсь ли я использовать там какие-то для имплементации модели попроще или, может быть, вообще там китайские какие-то модели. А вот когда когда я спросил, съедает ли он вообще свои, проверял ли он вообще, насколько он свои лимиты у подписки съест, если он будет всё делать на хайрининге. Он такой: "Блин, не проверял". >> Ну я иногда съедаю, но это не каждый день далеко происходит, поэтому как бы мне хватает. >> Угу. >> Ну ждём, ждём, что произойдёт с индустрией, когда вендеры полностью перестанут субсидировать токены. >> Да, >> тогда и поговорим. >> Тогда будем платить китайцам. У них будет дешевле. >> Да, там на самом деле есть О'кей. Есть нюанс, правда, у этого нюанс в том, что не всем доступны подписки. На самом деле, если ты большая корпорация, то нет у тебя подписок. Вот ты платишь там по API ценам. Вот. И вот там уже >> и тебя там давят на уши на это всё. Дадада. Дада. Да. Поэтому, короче, уважение этим людям, им правда уже сейчас стоит это оптимизировать, >> безусловно. Ну либо как-то придумывать, как всё-таки сидеть на подписках, потому что экономия такая, что там чудовищная просто экономия, на самом деле. А так, Стас, ты хотел свою историю рассказать и задать? >> Да, я хочу рассказать историю. Тут постараюсь уложиться, короче, не потратить ваши 100.000 токенов. В общем, уже без шансов >> после всех. Да. Может следующее. Это что, короче, решил поучаствовать в Хогатоне и попробовать какой-то спектри developмент. В частности, я прямо решил попробовать то, что порекомендовал кто-то из кто-то на интервью пользовательском, а, собственно, BMAT. Аа, делал я это параллельно. А у меня, как это, я параллельно, условно, на одной половине экрана, я при помощи Google Стича, а, занимался очень приятным занятием. Я делал классные дизайны, того, что хотел за захокатонить. А на второй половине я, соответственно, а, собирался разработать спеку и по спеке, собственно, это всё запрогать. Ну и подумал то, что к моменту, как мне дизайны понадобятся, я как раз со спеками закончу. А, >> на самом деле ты там 2 часа отвечал на 300 вопросов, из которых два были по делу. >> Именно именно так. Именно так. И у меня, а, из-за этого возникло ощущение вообще вот от этого всего. Вот мы говорили о том, что для слишком простых задач, возможно, скрин developмен будет оверкилом, если это влезает всё в одну сессию. Вот у меня есть ощущение ещё обратное, что если мы берём слишком большую задачу, например, полностью разработка приложения, то она тоже не очень удачная, потому что тебя фактически заставляют на берегу достаточно детально во всех спецификациях, во всех важных деталях проработать весь сервис. И это очень большая такая постоянная, короче, это очень жатая, очень мощная когнитивная нагрузка. Аа при этом аа потенциально а ещё и не очень понятно, зачем это делать вот прямо настолько сконцентрированно всё вместе. И возможно я как-то неправильно применял, и мне действительно надо было как-то немножко выдохнуть и сказать о том, что вот мы бьём по проектам. Но я в тот момент работал с ним в некотором смысле как с опусом. Ну вот я ожидал, что он мне я ему дам какую-то, в общем, достаточно ограниченную там спеку, и он мне там всё я при помощи этого смогу реализовать от начала до конца. Там будет много непроработанных вещей, будет такой в некотором смысле tracй шат а готового готового приложения. Потом я уже там детали доработаю уже там, я не знаю, допилю как-то по-другому. Вот. И у меня и у меня вот такое ощущение возникло, то, что здесь есть слишком много какого-то энтерпрайза, который в конечном счёте он, э, заставляет у человека, который с этим работает, а, достаточно мощных когнитивных там усилий, трат, мысли топлива и всего одна в очень сжатое время. >> Ну, сразу вопрос, это когда было? >> Да, буквально когда, но вот это весной. >> А, о'кей. То есть, ну, всё-таки это 1812, а не 1712 год уже. [смех] Не забываеш, что мы всё в собачьих годах читаем. >> Давно, но не так давно. Дадада. Задача, которую можно решить на хакатоне - это задача не того размера. Там, на самом деле, вот если бы у тебя был под рукой BMC, он бы тебе сделал вот этот скилл, который возник чуть позже, на самом деле. >> Угу. >> Он бы сделал ровно то, что тебе и нужно было. Это раз. [фыркает] Два. Значит, BM. Дело в том, это штука, которая там первый комит, по-моему, был, если мне память не изменяет, в апреле двадцать пятого года. То есть это было ещё за несколько месяцев до спекта даже гитхабовского. Вот. И значит, в тот момент а не было вообще практически никакого понимания, в общем, о том, как всё это надо делать. И там человеку пришла просто в голову мысль, что надо взять и описать процесс. Это самое, ну, определённый, скажем так, класс процесса, как он себе представлял про человеческие организации. При этом, значит, это заменить там типа человеков на, ну, по сути дела, так сказать, описание ролей, энное количество персон, да? Значит, этим персонам раздать там каждому там свои workкфлоус и типа счастье настанет. Значит, [вздыхает][тяжело вздыхает] счастье настало до какой-то степени, а, но при этом, да, в общем, у него как бы получилось именно то, о чём ты говоришь. У него получился, особенно вот в левой части планирования, значит, очень тяжёлый процесс, в котором была куча Human in the loop. И там этот процесс, он такой типа там наглухо скриптованный. Он задаёт массу вопросов и как бы на выходе у него типа, который само выше нахрен никому не нужен. Ну, по большому счёту, [смех] вот, то есть, а, поэтому, как бы, по сути получилось, что, значит, ты как бы с задачей построить там скворешник, как бы полез там в штуку, которая не очень оптимальным образом умеет строить микрорайоны. Вот. И когда ты строишь микрорайон, то то, что тебе там задали как бы 300 вопросов, это не так страшно, потому что всё равно потом как бы от ответов на эти вопросы зависит твоя дальнейшая жизнь в течение там 2 лет. >> Угу. >> А когда у тебя хакатон, да, у тебя нету времени на 300 вопросов, поэтому как бы, ну, это просто не тот инструмент был. >> Ой, >> сам инструмент, а значит, он с тех пор, ну, короче, он всё время претерпевает какие-то изменения. Вот. И сейчас он как бы гораздо больше, если знать там, какими именно скилами пользоваться, какими нет, он гораздо больше подходит под хакатоны, чем там вот то, что ты описываешь. >> О'кей. А, >> ну, в принципе, это не это, короче, это не про SDD, это вот про там конкретно там BM, использованный именно вот так. >> О'кей. Я тогда, может быть, немножко упрощу вопрос, потому что, ну, вот просто даже на основе того, о чём мы сегодня говорили, что вот есть вот такая иерархия, а, спек, и это прямо, а,

Как будто бы вот сама по себе эта иерархия спек, она в том числе задаёт саму вообще структуру работы с этим. То, что она в явном виде диктует, что в некотором смысле разработка будет происходить по Waterfall.

Нет, не обязательно. Значит, опять же, а-а, у вот того Bimed как бы в том взводе, да, ещё была такая интересная проблема. Он тебя заставлял как бы выписать там 10 эпиков и в них там каждую историю по отдельности. Ну там не выписать её на уровне там coding session prompt, это вообще было бы уже, так сказать, совсем смешно, да. Но тем не менее, в общем, он тебя как бы с заставлял прописать именно с той историей, ну, разбивку на истории. При этом, понятное дело, значит, когда ты сделал первую из этих 100 историй, остальные 99 у тебя, скорее всего, в голове поменялись радикально. Ну, то есть обычно после первой истории ты понимаешь, что вот эти 40 мы делать вообще не будем, потому что закопаемся там начисто, да, а вот вместо этих 60ти мы сделаем вот вот эти 50 из них и ещё 15 вот таких. Ну, грубо говоря, да?

А, поэтому, значит, это тоже неправильный подход. А надо именно делать так. Значит, если у тебя есть вот интент размером в проект, ну, типа там характерно 50-100 эпиков этой истории, собственно, coding sessions, значит, это обычно вот в общей сложности работы где-то на неделю, как правило. Значит, ты делаешь разбивку на эпики. Ты, когда начинаешь работать над первым эпиком, делаешь разбивку первого эпика на истории. Собственно, истории выписываешь там ровно прямо перед тем, как начинать над ними работать. Каждую конкретно, ну, детализируешь, да. [вздыхает][тяжело вздыхает]

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

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

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

>> потому что это стало делать дешевле теперь. В том-то и дело.

>> Угу. То есть вот сама динамика, так сказать, откуда берутся эти вот tracer bullets, всё такое, да, они берутся от того, что пока ты думаешь о чём-то, просто думаешь, типа там, что и как я буду строить. Ты знаешь как бы одно, как только ты написал первые три слова там main и открыл эту самую круглую скобку, да, ну вот в этом в ручном процессе, [вздыхает] и прямо сел такой и начал думать, что же написать сразу после этого. Прямо буквально в этом месте у тебя как бы представление о том, что и как мы строим, изменилось обычно. А если ты написал ещё 10 слов, оно может радикально изменилось уже, потому что ты начал думать про как, а это самое как вот оно это возвращается обратно. Вот.

И когда на самом деле, то есть если мы писали большой ручной такой артефакт, типа документ, а потом у нас происходил этот момент, и нам надо было как бы там всё бросать, иди переписывать этот документ, потому что у нас представление изменилось руками. Это было дико дорого всё, да? То есть по той же причине, как бы в там девяностые годы прошлого века умер UML. Отличная, кстати, вещь, между прочим, рулит не по-детски сейчас, а тогда он умер. Почему он умер? Потому что, о'кей, я нарисовал вот эти вот как бы детальные там со всякими там разными рюшечками, квадратики со стрелочками, да. Я на них посмотрел, я что-то прямо понял, мне хорошо. Потом я написал эти первые 10 строк кода, и у меня там как бы это стрелочки стали не все смотреть туда, куда они раньше смотрели. Если я в этот момент должен остановиться и пойти, на самом деле всё это перерисовывать и каждый раз, когда у меня что-то меняется в коде рисовывать, то на это уходило бы там, ну, не знаю, половина моей жизни, наверное. А сейчас она не уходит, потому что сейчас ты можешь просто сказать агенту: "Слышишь, агент, вот у нас тут поменялось, иди там всё остальное подправь". И в общем-то это он как бы не совсем точно, но он достаточно точно делает эти правки. Этого хватает.

>> Ещё и скинули в контекст просто картинкой в Paint'е сделанной то, что старая UML-ка стрелочка такая и новая UML-ка с новыми стрелками. Вот отсюда, собственно, как бы и возникает вот эта вот возможность на самом деле, а, принимать там какие-то решения до того, как мы начали писать код, который раньше принимать было бы глупо, а сейчас наоборот глупо их не принимать, оказывается. Ну я же говорю, там это спектр, это там не вот это это не двоичная тема, там, либо мы делаем, либо Waterfall, да, она двоичной никогда вообще не было. Вот ты всегда на самом деле какие-то решения принимал до того, как. Просто сейчас ты можешь этих решений, не только можешь, но это и хорошо вообще, это правильно принимать как бы до того, как написать первые три строки кода больше. [вздыхает] Отсюда у людей возникает вот это вот ощущение, что ба, ребята, это же не чистый Scrum. Ну и хрен бы с ним, зато оно работает. [фыркает] Инструмент поменялся, офферс другие.

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

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

>> Угу.

>> Видимо, зависит от команды, может быть, наверное. То есть, ну, я знаю тоже, что у людей есть проблемы с этим, как бы там начинаются холивары, как всегда, и так далее. Вот. Ну, в общем, оно заводится. Это пункт первый. Пункт второй, значит, как работать. Ну, по большому счёту, как бы, у меня команда маленькая, поэтому я про это знаю. Ну, вот либо на масштабах там микроскопического, там продак стартапа, грубо говоря, либо со слов других участников забега. Значит, э в основном со слов других участников забега у меня сложилось впечатление следующего содержания. Что, значит, по сути дела, а что значит, как работать? Ну, самым выше у тебя есть, значит, спека размером с историю. Спеку [откашливается] с размером с историю, естественно, пишет, так сказать, отдельный индивидуальный девелопер. Ну, точнее, интент к ней он пишет, а всё остальное, в общем, правит, может быть, да? Значит, там как бы проблемы команды вообще не возникают. То есть я могу делать SD, даже если там все вокруг меня там, я не знаю, делают что-то ещё. Мне это абсолютно никак не мешает. То есть, если я могу сформулировать там на полстраницы интент, я могу этот интент исполнить через, значит, допустим, например, так сказать, этот Bimed'овский workflow под названием Quick Dev или Devoto, если это вот, значит, это пункт первый.

Пункт второй. Значит, если у нас есть, допустим, маленькая команда, там творческий коллектив из пяти человек, вот как мы раньше на самом деле между ними распределяли работу? Э, planning poker, блин, planning poker'ом оценивали, а потом вот так тыкали пальцем и такой: "Ты, короче, делаешь это, а ты вот".

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

>> Угу.

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

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

>> Угу.

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

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

>> Ну да, зато приятнее.

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

>> Это похоже, что перестало работать. Ну вот именно вот это вот там, что ты типа этот самый там абсолютно гениальный, типа там писатель UI на каком-нибудь, не знаю чём.

>> Дада. Значит, это где-то год назад это работало реально.

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

>> Угу.

>> Реально. Но людям нравится. То есть как бы есть люди, которые прямо это они любят такое.

>> Вот это как раз, да, возвращаясь к моему термину.

>> Сейчас с Машей, тут с Петей нормальная тема, если нравится. Хорошо. Да, это как раз к моему набросу в начале про то, что в AI разработке из-за того, что многие решения мы принимаем на уровне вайп-чеков, то даже те практики, которые уже есть, там прямо ресёрчи полноценные, которые говорят не работает, люди продолжают себе тянуть, говоря: "Ну, а мне нравится, у меня вроде норм".

>> Слушай, а до вообще всего этого агентского так и было всю жизнь.

>> Да, это правда.

>> Ничего не поменялось же. [смех] А как как человек, который спровоцировал очень многих людей на очень много разных карго-культов, я согласен.

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

>> Так, послушай Егора и сделай наоборот. Это это всегда хорошая идея подождать год.

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

>> Угу.

>> Да, там есть, ээ, карго.

>> Ну, собственно, как бы само понятие карго-культ произошло про авиационные перевозки.

>> Ну да.

>> Правильно. Ну так и здесь, на самом деле, если вы там, грубо говоря, товарищи, которые это живут на острове где-то там в Тихом океане и там ещё не вылезли из каменного века, то, в общем, да, ваш Spec Driven Development будет такой же, скорее всего. Но с другой стороны, вы как бы там в конце концов видимо это оденетесь в рубашки и джинсы, и там ваша жизнь немножко изменится после этого всё равно со временем. Не, ну я не знаю, я здесь не могу молчать. Здесь есть прямо момент, что, э, у нас, ну, собственно, research'а нету. Доказать мы не можем. Evaluation слишком искусственный.

>> Research.

>> Какой research? Есть.

>> Про planning mode research есть.

>> А, о'кей.

>> А это, собственно, примитивная как бы реализация этого принципа.

>> Угу.

>> Это работает точно. Это подтверждается массой примеров. Ну, не примера, именно исследованиями, да. Про этот самый context ещё больше есть.

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

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

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

>> А, смотри, давай я скажу, откуда берётся исчезающе малое. Да, чтобы быть неголословным. Я буквально недавно, 2 недели назад, открывал Google Trends и сравнивал Spec Driven Development с запросами типа Cloud Code, Codex, Agentic Development и прочее. И там, ну, разница типа на два порядка. Ты же понимаешь, что люди, которые на самом деле сейчас работают с Cloud Code, из них примерно половина занимается Spec Driven Development.

>> А если мы говорим про plan mode, то да,

>> то по факту того, что они пользуют plan mode, ну как бы они просто не знают, что это так называется, но тем не менее это оно. Это очень примитивная на самом деле реализация его, но это оно. А если они ещё там этот самый какой-нибудь slash-rev запускают, ну это же вообще прямо оно. Тоже, кстати, очень примитивная реализация, на самом деле. Там всё скучно. Ну,

>> на самом деле в в масс SD уже пошёл в тот момент, когда у нас plan modes везде появились. А дальше это вопрос того, какие ещё идеи провайдеры harness'ы себе забирают.

>> Да-да, да, это, в принципе, так и работает. То есть как бы всё, что там кто-нибудь вот в одном из этих проектов, в том числе в Bimed'е, там придумал, грубо говоря, там сегодня через там 2-3 месяца, если это реально окажется рабочим, а иногда под другим, иногда под тем же самым названием, так сказать, появится в Cloud Code. Это, ну, и ещё, на самом деле, это потом назовут Карпат из чего-нибудь там.

>> Хотя, как бы там сплошь рядом я там про то, что называют вот таким вот образом, как бы могу там ткнуть пальцем там в какой-нибудь div там где-нибудь, да, не обязательно в Bimed'е, но в Bimed'е тоже. И сказать: "Ребята, а вот вот здесь это было там за 3 месяца до того". Ну, было нормально.

>> А у меня есть две спекуляции на эту тему. Первая из них - это история про которую мы аккуратненько как-то пропустили. про то, что плохо быть бедным и плохо, в общем, платить за токены, а не, э, на субсидированных токенах сидеть. Собственно, ну, стоимость она объективно будет больше. И здесь возникает вопрос, если можно условно попробовать залить для там многих задач вот эту когнитивную сложность ээ дополнительным напряжением головы конкретного человека, наверное, кто-то склонен это делать, особенно, ну, там, в зависимости от размера проекта, если он не очень большой. Собственно, вопрос в том, а-а, даже если бы за эти токены, которые я жгу, а-а, я бы платил именно как бы полную цену, то, значит, так или иначе, хоть чучелом, хоть тушкой, это было бы примерно процентов 20, может быть, 30 моей зарплаты. Если бы я работал не в Северной Америке, я бы просто как бы пропорционально платил бы китайцам за какой-нибуд 52 вместо Opus. Да, оно как бы хуже, но не сильно. А значит, в этот момент, соответственно, если меня эта штука на длительной перспективе ускоряет хотя бы в полтора раза, она уже имеет смысл. А она ускоряет, ну, по моим, так сказать, назовём это субъективными ощущениями. Хотя, в принципе, есть и какие-то квази-статистики на эту тему, опять же, мои, они как бы сходятся. Ну я говорю, это может быть про профессиональная деформация сознания, но я вот так вижу.

Вторая спекуляция - это мы как-то слона в комнате не замечаем, но вот это вот весь подход, он на самом деле базируется на довольно мощном допущении, что мы 100% задач а мы можем хорошо реализовать при помощи LLMки. Тут, возможно, мы можем, но всё упирается в, в том числе, в веру, веру, веру конечного разработчика. Потому что я вот на, а, интервью с конечными разработчиками, когда я у неё спрашиваю: "Как вы вообще ячик используете, сколько процентов вы пишете коды, то там оно очень сильно разбегается. Кто-то вообще говорит: "Я типа только 30% делаю, я не хочу типа отупеть". Ну, то есть есть вот просто когнитивный барьер вот такого уровня. И, соответственно, для человека закрыт путь в Spec Driven Development просто на этом уровне, то, что он не готов 100% как бы, ну, он не готов делегировать, а когда ты делаешь все как бы всю разработку, всё написание кода и, соответственно, тебе путь заказан. Есть люди, которые говорят о том, что, ну, у меня получается хорошо, эффективно делать там 70%, 30% мне приходится делать руками, и я не знаю, как это автоматизировать. Сейчас у человека не получается это при помощи агентов вот какого-то типа задачи делать. И это тоже в конечном счёте приводит к тому, что здесь вот этот флоу ломается и непонятно как, ну, типа, что делать с таким. То есть ну как бы ты там всё классно запланировал уже, всё там у тебя эпики, э, и тут в середине вы внутри сессии обламываетесь на том, что тебе надо как-то, я не знаю, или руками прийти. Ну, короче, как-то написать контроль на себя и пишешь руками в этот момент.

>> Не, ну да, но ты же ты же только что

>> Ну, смотри, одна история - это 300 строк кода примерно. Ну,

>> 300 строк кода ты пишешь за день характерно. Это ещё так. Ну, может, даже за полдня, если ты увидел, что она написала 304 кода, который вообще не туда, например, да, ну что тебе мешает как бы в этот момент выкинуть нафиг эти 30 строк кода, пойти их написать руками?

>> Да так про всё можно сказать. Зачем мне модель? Я пойду просто эти 300 строк кода просто руками напишу. Я красавчик.

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

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

>> потому что, ну, собственно, вся, потому что раньше пальцы были это узким место, а сейчас нет. Сейчас пальцы не узкое место. Пока где-то там кто-то печатает какой-то код, я могу, так сказать, переключившие контекст. Что, кстати, вот это неприятно, да, что тебе всё время приходится это перескакивать с одного на другое, потому что иначе ты будешь сидеть на попе ровно и ждать там 15 минут, пока там что-нибудь не закончится. Вот. Но тем не менее ты переключаешь контекст, начинаешь, в общем, чесать репу там про вот именно про внутренний дизайн и как бы зачем вообще всё это надо, в какой-то другой истории. Поэтому, ну, тупеть там вот мне точно не грозит, как бы с моим workflow. А-а, и вот на этой замечательной ноте, когда мы выяснили, что Spec Development хорош ещё тем, что он ещё и умнее вас делает, помимо всего остального.

>> Не, вот это вряд ли, кстати, но думать заставляет, по крайней мере. [тяжело вздыхает] Вот,

>> соответственно, не даёт тупеть. Это разные люди.

>> О'кей. Вот что Spec Driven Development не даст вам стать тупым. А как бы Дарио, Модей не пытались это сделать. Надо сделать на нам надо это сделать каким-то слоганом нашего подкаста. то, что подкаст что не даст вам отупеть в эру AI. [смех]

>> А единственный, единственный последний последний заслон между нами и тотальным отупением. Вот, давайте подводить черту. А мы сегодня говорили про Spec Driven Development. И напомню, что было. А было то, что в самом начале мы вы, если вы думали, что вы ещё не используете SD, но вы используете plan mode, плохие новости, а может быть, хорошие, вы уже используете SD. Вот. И дальше от этого замечательного тезиса мы оттолкнулись и поговорили про то, а зачем вообще SDD нужен и какие проблемы решает, на каких уровнях он работает и как он мапится на процесс разработки, в каких задачах подходит хорошо, в каких задачах подходит не очень, что вообще такое за сущность спецификация, какие слова в неё надо писать и откуда взять эти слова, откуда взять эти горы руды, которые потом станут хорошей спекой? Аа поговорили про то, могут ли спеки быть вечно зелёными или не могут. Обсудили кучу разных проблем, мифов и лучших практик работы с SD. В лучших традициях написания спецификаций мы не поговорили, например, о том, какие конкретно фреймворки есть, чем они друг от друга отличаются, как они подходят к разным задачам, но у нас ни у кого не хватит, а не только контекстного окна всё это вместить, а лимитов подписки, а чтобы поговорить ещё и про эти темы. Поэтому я приду,

>> как мы узнали и как мы узнали, буквально за пару месяцев всё может поменяться даже для конкретного в общем подхода.

>> За 2 дня всё может поменяться, да? За пару месяцев точно поменяется. Там уже не может, а именно обязательно.

>> Вот. А поэтому, Лёша, спасибо тебе большое, что к нам пришёл и поделился своим гипергигантским опытом работы с SD. Очень клёво, очень интересно. А вот ждём, что количество Markdown файлов закоммиченных резко повысится

>> или наоборот понизится. Мы же говорили, что не надо этого делать. [смех]

>> Это правда. Это правда. Боремся с Markdown'ом по одному файлу за раз. Вот. Поэтому ещё раз спасибо тебе. А если будут ссылки на какие-то исследования, что ты упоминал, на какие-то вещи, которые стоит почитать, прикладывай, мы всё к выпуску тоже приложим. И Стас,

>> да. Можно ли задать тебе вопрос?

>> Конечно. А

>> вот мы только что

>> Ладно, подожди, лучше напиши в спеке. [смех]

>> Блин, это лучше было. А, да, я хотел сказать, что мы только что выяснили, что сам процесс написания спек делает тебя менее ту, возможно, менее тупым, а возможно, даже умнее. Что тебе нравится больше, чем понимать, что ты как продакт этим занимаешься уже давно, и значит ты вообще ультраразум.

>> Вообще я я, видимо,

>> я поплыл уже к третьему часу записи. Извини. Наконец, наконец мы смогли смогли потратить Егор слушал в полухо и наконец мы смогли потратить 100.000 токенов его контекста. Да. А больше этого, дорогие друзья, мне нравится, когда вы ставите пять звёзд в Apple Podcasts, Twitter, рассказывайте нас друзьям, а самое главное, слушайте подкаст Подлодка. И отдельное спасибо, если вы дослушали до этого выпуска. Я хочу, в общем, поблагодарить всех, кто послушал наш замечательный, гигантский, прекрасный выпуск, и отдельный лайк всем тем, кто, а, нам на комментарии про deep dive, которые такие вот обрезанные версии, то есть записали 3 часа вот такие вот прямо вот такой вот на крутой добротный выпуск, вот прямо вот как вот этот. А а мы потом в deep dive берём и выпускаем всего час из этого, выкидывая, короче, куча всяких баек, историй. Просто дистиллированная какая-то вот, в общем, скукота. Лайк всем тем, кто просит выкладывать, в общем, большие, полноценные, классные выпуски. One Love. Ребята,

>> всем спасибо, всем пока.

>> Пока-пока.

>> Счастливо.