Transcription
к следующему вопросу.
Следующий вопрос. Давайте возьмём следующий вопрос про использование SPEC driven девелопмента. И ты, говорил, расскажешь про свой флоу. Я тут немножечко, ну, может, добавь ты комментариев своих, потом я ещё немножко додам добавлю комментариев и послушаем твой опыт.
Этот топик родился как обсуждение в чате, что как это вообще использовать и посмотреть на разные подходы, которые разные участники чата используют, потому что есть гипотеза, что он сильно улучшает качество агентского кодинга, особенно на средних или больших задачах.
>> Будто бы он улучшает стабильность ответов, насколько я понимаю. Повторяемость ответов даже. Качество, повторяемость качества ответов.
Ну давай быстренько вводную дам. Spect Driven Development подход в Е разработки, где спецификация становятся по факту главенствующим артефактом. И устраняется таким образом вайпкодинг эффект, когда у тебя контекст постоянно разный, в каждой задаче его мало. Ты таким образом, как бы оперируя контекстом, чётко контролируешь, что подаётся на вход, и, в принципе, можешь ожидать какого-то гарантированного качества результата.
Ээ я проделил тут на две части. Есть лагерь людей, которые считают, что Spect Driven Development основывается на инструментах типашек. Ээ, вот есть в Kra Spect Driven Development функционал, э, и есть в QPC Driven functional, когда тебе сами Дешки составляют план разработки, дизайн твоих фич, ты это всё опровишь, и потом идёт разработка.
Есть другие ребята, которые придерживаются того, что Spect Driven Development - это, собственно, подход. Они просто инструменты. Там, насколько я понимаю, сейчас два лидера, даже, наверное, три уже. Этохабовский спеккит, который реализует Spec Driven Development через стандартные сценарий, примерно как это в Кайре сделано, спека, план, задачи, выполнения и BM метод, который делает разные роли. вот то, про что мы сейчас разговаривали, делает агенту с разными ролями, и они пытаются разными ролями обрабатывать с каждой свою задачу и выдавать в итоге финальный результат.
Ещё я нашёл интересную реализацию, аэ, похожую больше на Spec Kit - это Open Spec. Вот такая вот библиотечка. Скинуть в чатик вам. Она, в принципе, делает то же самое, что спект. Но в итоге, как по мне, все эти библиотеки и все эти подходы про управление контекстом, про написание по факту MD файлов, которые кладутся в контекст. MD-файлов с тем, как работать с контекстом.
Вот, Денис, теперь тебе слово.
>> Ну да. А-а, тут у меня эволюция, я в чате тоже писал, эволюция была от того, что я пробовал этот подход в курсоре, потому что обещали, что он классные результаты даёт, но в итоге курсо курсоре ты через контекст 7, наверное, использовал, да, или
>> не, я чисто курсор использовал, но это давно было, ещё весной. Э-э, смысл был в том, что он готовил голимый план, а потом он по этому плану и не мог выполнить то, что там написано. То есть это было бессмысленно его использовать. По крайней мере, у меня вообще ничего не получилось.
А сейчас у меня получается на работе есть там ребята, они агенты делают, они там вообще код руками не пишут, и у них есть такой типа темплейт. или, скажем так, я сделал темплейт на основе тех спеков, которые они пишут. У них типа один файл, в котором есть, а, небольшой resarch, а, небольшая спека, небольшие таски, а-а, и ещё какой-то мусор, который там все говорят, нужно добавлять. То есть это невозможно читать, что оно там добавляет. То есть там типа литигейты какие-то, там какие-то этимейты оно пишет там как бы, ну, клодкод пишет.
С этой штукой качество кодинга сильно улучшилось, потому что можно работать с этим файликом и, в принципе, такие небольшие фичи пилить. А, но меня результат не устраивал, потому что файлик здоровый и там много мусора, его невозможно ревьювать.
А следующая моя эволюция была в том, что я заюзал гетхабовский спеккит. А у гетхабовского спеккита проблема, что он генерирует громадные эти файлы.
>> А как выглядит эта работа со спеккитом? Это просто рекомендации или это прямо библиотека, которая сама следит там за файлами, сама их заполняет?
>> Ну, короче, вот этот BM и Spec Kit - это как бы там несколько элементов, то есть там есть темплейты э промтов, которые используются для написания вот этих артефактов типа ресерча, а, спецификации и так далее. Вокруг этих темплейтов выстроена обвязка для агентов типа клодкода, там, кодекса и так далее.
>> То есть типа готовые настройки для агентов конкретно, да?
>> Ну там типа команды, он генерирует команды >> и потом есть обвязка в виде там каких-то скриптов. Это на Питоне, на баше, на джаваскрипте, в БМДЕ. А оно на основе этих а скриптов прогоняет flow вот этот спек д den driven девелоopмента. Но смысл в том, что они все вот и Спек Kit и BM, они хотят какой-то мегауниверсальный flow, который любой проект можно сделать. Это супер непонятно. Ну то есть я вот эту диаграмму читаю, я ни хера не понимаю.
Ну, это описание того, как типичная команда софтверная работает в аутсорсе. Типа,
>> ну, типа, да, но это сложно. Мне, э, ну, нужен был какой-то более простой инструмент. То есть я в итоге взял то, что сгенерировал мне спекткит как конечные темплейты и конечные типа артефакты и на их основе сделал себе похожий флоу, а похожие темплейты, но под мой стек, под мои проекты и, может быть, какие-то мои требования немножко по ним поитерировался, чтобы зарефайнить эти цемплейты.
И у меня осталось четыре команды типа resarch. Resarch делает что-то типасёрча, который делает perplexity или ты сам делаешь, когда исследуешь задачу. То есть у тебя там стоит задача вот там типа зарефакторить ээ проект, там заиспользовать новую библиотеку, то есть там какую-нибудь кэш-библиотеку. Ты говоришь, типа, вот у меня есть такая-то библиотека, её нужно заиспользовать в таких-то модулях, в таком-то проекте. Сделай мне depressch, задай ему там какие-нибудь вопросы, что делает библиотека, как это можно внедрить в мой проект наиболее наименее а таким Verbals методом, всякую такую вот херню.
>> А ты же при этом кодкодом пользуешься, да?
Да, он генерирует resarch файл, и это как канвас, ну, похож там начат GPT какой-то канвас, с которым ты общаешься и говоришь, типа, вот мне нужно ещё вот этот модуль, мне нужно там ТТL, ещё какую-нибудь херату, просто как брейншторм такой, как уточка.
>> У меня тут вопрос сразу. Вот, кстати, Умпутун в последнем выпуске радиоти очень расхваливал скилы антропиковские и говорит, что в клодкоде прямо тоже скилы можно использовать и что хороший подбор скилов под проект чуть ли не заменяет вообще всеect Driven Developмен подходы. У тебя просто агент знает, что делать. Ты ему просто в скилы подгружаешь нужные скриптики, нужное описание. Ты не пробовал скилы?
>> Я пробовал, но у меня возникла проблема, что мне клодкод не написал. довольно простой скилл. Вот я его там день промучил. Ээ мне нужно было написать аналог трейса. То есть у меня есть энроменты, у меня есть ти, а там в динамо DB лежит entтити, на S3 лежит какая-то производный артефакт от этой Enти, там картинка, условно говоря. И у меня это есть информация на стейджинге, есть на продакшене. Я попросил клодкода сделать скилл. То есть у меня уже было всё описание для такого скила. У меня был скрипт, но у меня там коллеги сказали, что нахер такой скрипт в основную кодовую базу добавлять, типа овенжиниринг. Я думал скилл сделать. Ну и он мне его мучил этот скилл. А в итоге он просто его не родил. То есть у них там было обещание, что можно ему дать возможность код типа самому писать. Вот, э, он, короче, не может, эээ, это сам обернуть, а сидеть разбираться там, короче, по сути скил, э- как я понял, это какой-то промпт, и ты должен ему дать какой-то суперпростой скрипт, ну, либо что-то супер понятное. А если что-то не очень понятное, то ничего не работает.
Вот в итоге эти скилы, э, ну, наверное, полезные. Э, и скилы, ну, короче, если про спекткит говорить, то есть вот у меня была тема, что есть темплейты, темплейты подгоняются под проект, есть команды, которые можно в самом проекте добавить, и они будут помогать тебе прогонять через этот флоу. В итоге ты работаешь с MD-файлами. А, в принципе, самая большая теперь стадия у меня - это resarch, а, а всё остальное, в принципе, генерится из него. Спека у меня супер маленькая на 100 строк, которая выделяет какой-то usерстории, рассматривает какие-то рейс-кондишены. В темплейтах у спеккита гитхабовского у него там так промпт настроен, что он тебя ещё спрашивает чкейсы, то есть он тебе задаёт вопросы, когда ему что-то непонятно по каким-то вопросам, и ты на них отвечаешь во время работы над спецификацией. То есть там полезные вопросы. Плюс при работе на спецификации видно, где агент какую-то херню начинает делать. То есть он делает не то, что ты хочешь. То есть ты там это правишь. Потом он делает implementation plan. Implementation plan - это именно код. Ты там в темплейте пишешь: "Пиши мне псевдокод, не пиши мне много, тесты там такие-то, то-то там такое-то". Он тебе по этому темплейту делает этот implementation план. И по implementation плану он потом таски делает. В тасках он делает граф мини-задач. То есть на большую таску там будет где-то около 100 сабтасков. И там вот что он может и субагентов там вызывать уже как бы то есть он определяет, что можно выполнять параллельно. То есть, условно говоря, в итоге у тебя задача фича вписывается в то, что ты пишешь resarch, контролируешь, что по этому resarch он сделал спеку, а и implementation план, который можно прочитать, то есть там в районе 100 строк.
>> Всё ещё непонятно, почему это всё выделилось прямо в
>> отдельное серьёзное название Specflow. Ну, у нас до этого существовал бан, который тоже пытался претендовать на единый термин. Теперь у нас есть спекфлоow, хотя по факту это просто итеративное улучшение твоего промпта, который объясняет, как с контекстом работать. Это же по факту промт инженерия, только промт инженерия с мозгами.
>> Ну, не совсем там, короче, получается, что вот этот вот resarch - это промт engниринг, контекст engниринг, который ты описываешь. То есть здоровый документ, который делает структуру твоего проекта для твоей конкретной задачи с конкретными ссылками на файл, с са,
>> ну, то есть делает работу агент, поясняет агенту за места, нужные для работы, показывает агенту самую основную информацию, необходимую для работы над этим проектом.
Ну да, ну совсем же не новый.
>> Ну о скорее контекст собирает. А спека она скорее для человека понять задачу. То есть он, э, тебе
>> не Что такое спека из стандартного процесса разработки, это понятно.
>> Ну, в агентах в агентах это выглядит так, будто бы ничего нового, просто дополнительный контекст по проекту, автоматически обновляемый. Вот я вот этой разницы не Я просто пытаюсь понять, это какое-то новое направление, типа, я не знаю, новый способ разработки век и яя, который с нами будет ещё жить 10 лет, или это просто новое название для обычного человеческого промтинга, когда ты нормально руками контекст под подсовываешь и нормально тебе енты пишут задачу.
Ну тут тяже тут обычный
>> тут тут
>> сейчас деньги закончит потом те
>> Да тут просто проблема в том, что тебя у тебя когда сложная задача сложная да есть ту, которую ты как программист бы делал там неделю-две написал бы там, не знаю, пару тысяч строк в сложном проекте, ну в сложном, среднем. А у тебя проблема, что эти эта фича не решается вайпкодингом. То есть ты не можешь за вайпкодинг сессию вообще её решить.
То есть она подожди, а что ты что ты имеешь в виду под словом вайпкодинг сессия? Вот 12 часов я потратил на написание промпта, который мне с одного запуска сделал среднесложную фичу. Это ещё веб-кодинг или это уже?
>> Ну это это скорее спека. Вот, то, что ты написал какой-то промпт,
>> по которому у тебя сгенерился код,
>> а это я бы назвал суть вот этого скдривен девелопмента, потому что в конце ты получаешь здоровенный артефакт на 1.000 1.500 2.000 строк.
>> Вот. Ну, ну не соглашусь, Денис. Буквально только что с одного промта, с трёх строк, вот полчаса назад я на ваших глазах получил 500 строк.
Это это не подожди, мы тут про разные вещи говорим. Я говорю, что а спектрин вот этот flow, он тебе позволяет в конце получить артефакт. Артефакт - это marкдау файл
>> с промтом, который потом ты отдаёшь плоткоду.
Понятно. Внутри этого промта написано, какие сабагенты должны делать, какие таски в каком.
>> Ну так и для этого уже название есть года два, как это называется метапромтинг, когда ты просишь модель на основании контекста сделать тебе промт, который лучше подойдёт под задачу.
>> Ну вот это и есть метапромтинг, да? То есть мне кажется, что Но он положен в методологию
>> Ага. О'кей.
>> Определённую, что у тебя есть любая задача. Ты любую задачу укладываешь в четыре этапа, там resarch, implementation,
>> дизайн,
>> не не там, а resarch спека, implementation и tasки. И ты можешь,
>> ну, небольшой среднего уровня задачу
>> решить. При этом, если понимать, ну, если тебе задача самому понятна, то этот флоу супербыстрый, и в конце ты получаешь тот результат, который описан,
>> на который рассчитывал, типа контролируем результат.
>> Да. И вот это главная ценность.
>> Давай.
>> Наши другие другие методы не давали мне вот этого предсказуемого результата.
>> Угу. Спасибо. Давай ещё Виталию дадим слово. Виталь, Виталик, привет. Ты как раз задавал вопрос мне в личку про Икфлоу, и про BM. Можешь, можешь рассказать?
>> Не прок не про спект, прокиit. Сори. Да,
>> спект - это GitHub. Вот как бы тима разрабатывают. Ну тут я бы, наверное, сказал так, что Spect Development - это один из подходов к контекст инженеринга. А контекст инженеринг как бы это, скажем так, практика того, что управлять и ограничивать контекст для лмок для того, чтобы получать более предсказуемые и адекватные респонсы. Вот. А, ну и, соответственно, контекст инженеринг - это под множество промнжиниринга. То есть всё это промт инженеринг, но это как как бы отдельное выбранное направление, отдельные практики.
>> Но ведь промтнженерия тоже включает в себя ужимание контекста.
>> Проженя - это очень большой, это очень большая область. То есть это нерик такой. Ну то есть это примерно как лмки - это часть и и является там частью, ну более
>> это как посмотреть, Карпаты вообще отказался от термина промнженерии и сказал, что всё это контекст инженерия
>> тут.
>> А потому что нам нужно управлять контекстом. У нас неограниченное как бы окно, даже сами люди, а м ну просто посмотреть на то, как инженеры работают, да, мы разбиваем ээ глобальную задачу приложения на маленькие подзадачи и фокусируемся на на небольшом э объёме, ну, то есть на небольшой задаче. Мы не можем сразу одновременно держать в голове всё приложение и вс и всё всегда его программировать.
>> Слушай, так с этой точки зрения у тебя случайно не будет наоборот у тебя промнженерия - это под вид контекст инженерии. Контекст инженерия включают в себя в том числе инженерию и промта и выстраивание контекста вокруг проекта, в том числе и для оператора, который пишет эти промты, и для агентов, которые их используют.
Нет,
>> нет, смотри, прот engриering достаточно ээ широкая как бы эрия, потому что она содержит как и ваншот, так и итеративные подходы. Контекст инженерия она больше ориентирована на интерактивный подход. То есть, а мы за одну итерацию создаём как некий артефакт для того, чтобы сделать следующую итерацию. То есть мы не даём глобально лмке задачу: "Разработай мне эту фичу". Да. И давай её мы обсудим и сразу разработаем. Мы сначала обсуждаем, что это за фича.
>> О'кей. То есть мы это контекст инженерии синглпромптов быть в принципе не может, которые неинтерактивные синглпромты.
Ну, тут такой подход, что мы как бы постепенно, общаясь с моделькой, создаём промежуточные артефакты, на основании которых мы создаём потом код.
>> А
>> то же самое, как и
>> как как до этого мы это делали командой людей, да? То есть там бизнес-аналитики подготавливали спецификацию. На основании спецификации там архитектор или тех подготавил солюшн. Из этого солюшена потом команда планировала, разбирвала на таски. Э разработчики делали, тестировщики тестировали.
>> Хорошо. Допустим, с теории с теорией более-менее уложились. Я тут закину сразу вопросик. Если у кого-то есть по нему добавить, то залетайте. Вопрос в том, насколько это насколько такой жирный по токенам подход. Э acceptable, блин, забываю слова. Короче, насколько он ээ подходишь он не жирный, он наоборот гораздо более экономный.
>> Почему он экономный? У тебя же у тебя же запускается куча всего, чтобы сделать более-менее средние
>> величина задачу.
>> А, Лёша, а скажи, пожалуйста, а сколько ты попыток сделаешь для того, чтобы сделать один промт, который тебе сделает за один раз?
>> Ну вот одну. Одну.
>> Одну,
>> да.
>> Чтобы вот фичу как бы а в нормальном как бы ну серьёзном проекте,
>> да? Да. Не, мы тут просто забываем про то, что мы, вообще-то, не вайпкодеры. Мы делаем один промт, а потом справляем за ием. Не отломается ничего от меня. Я сделал промт и я доисправил.
>> А,
>> ну смотри, зависит от того, а какого объёма фичу ты делаешь. Если там поправить, а, скажем, название кнопочки там или цвет на кнопке, то, ну, тебе действительно спецификацию не нужно писать. Не, ну не процвет на кнопки речь, конечно, написать какую-нибудь фичу на 30 файлов, которые ты будешь писать там полтора дня, тебе это всё сделает.
>> И ты хочешь сказать, что ты можешь написать про, который за раз тебе выполнит, и потом ты ещё будешь сколько дней это разгребать?
>> Нет, я буду 2 часа это разгребать. Вот буквально вот смотри, вот у меня на Генерина сейчас в курсоре тут файлов 15. Мне, чтобы их проверить, часу идёт. Руками бы я их писал, ну, часов 700. Промт там был буквально в три строчки. Так, если у тебя с первого раза всё получилось. 100% не получилось. Там 100% будут баги. Но я свой код знаю.
>> А что ты будешь делать? Вычитаю делать с этими багами вычитаю и исправлю.
>> Может быть руками, может быть дополнительными промтами. Да, конечно. Ну не знаю, как бы у меня, ну, как бы даже в буду прошлом, а как бы даже простые какие-то баги, но они требовали времени на то, чтобы их пофиксить, их отдебалить. Ещё нужно потом посмотреть, как бы, а как это исправить. То есть, ну, если, конечно, простая логика, то да, легко. А если логика непростая, если ты делаешь какой-нибудь там комбайн, который у тебя данные процессит, ну и где логика, ну то есть там у тебя уравнения какие-то, ну какие пару часов.
>> Мм давай послушаем ещё мнение ребят вот с руками у нас поднятыми. Давай сначала Денис, потом Валера.
>> Ну, короче, ты тут, Алексей ну проблему не видишь, поэтому тяжело. Но это обычная штука, когда это обсуждаешь. Короче, я писал вот, как ты рассказываешь, то естьдел какой-то промпт, мне код меняло. А, и в принципе этот подход работает на маленьких задачах, которые понятные, и ты знаешь, где надо пофиксить. То есть ты вместо того, чтобы идти там вшке код самому пофиксить, просишь этот код э сделать очень конкретно, подробно в определённых местах иешку. Как только появляется какая-то неопределённость, ишка она делает куча куча куча кода, который не нужен.
>> А,
>> ну у меня была такая проблема.
>> Встречный сразу вопрос просто, может, сразу ответишь, чтобы было более понятно. А откуда у тебя неопределённость в проекте, которым ты владеешь, который ты дорабатываешь? Ты не знаешь свой проект?
>> Ну там получается, что у меня, условно говоря, там стоит задача вот, ээ,
>> у меня там пять проектов на работе, да? Есть там проекты, которые я там я писал, есть проекты, которые я не писал, суперужасно написанные. И, например, там есть задача там что-то проэкспериментировать. То есть у меня был какой-то флоу, я его сам написал, а потом мне нужно написать валидацию. Валидация состоит из одиннадцати этапов. И мне нужно а этих 11 этапов заскриптовать. И, условно говоря, ты простым промтом говоришь: "Вот у меня один этапов, лежат логика там и там-то, сделай мне скрипт". Ну и как бы агент пошёл делать, делать тебе какую-то хероту просто. он генерит невообразимое количество, э, как бы кода ненужного. То есть ты потом пытаешься руками это править, но вот этот процесс исправления он очень ээ времязатратный. То есть это от задачи зависит, ээ сколько он там перестарался. То есть, если у тебя большая задача и она новая относительно, то для того, чтобы сгенери нормальный код, а нет код, который тебе придётся перелопачивать долго, долго, долго, тебе нужно подать хороший контекст на вход. Про это речь.
>> Ну, у меня есть ещё команда с разных людей. То есть там у менеджера есть свой набор требований, там у одного коллеги свой набор требований, там ещё у кого-нибудь будет ещё свой набор требований. И когда ты генеришь какими-то простыми промтами, а оно тебе делает тот код, который в их код не попадает. То есть я знаю, какой должен быть код для того, чтобы э прошло кодрев. Но чтобы этого кода добиться от лэмки, мне нужно тратить очень много времени и токенов для того, чтобы достигнуть этой цели. А в спектривен у меня вот эта стадия прототипирования, которая раньше была в коде и генерировалась там, я не знаю, тысячами, этот код, он у меня сжимается в resarch MD файла, а потом в спеке я немножко обсуждаю с лмкой, какой а код дополнительно ей надо писать, потому что она там прописывает течкейсы, которые она собирается обрабатывать. То есть она там собирается какие-то ошибки ловить и в кондишены вставляет, там какие-то кейсы там она выдумывает. Я ей говорю: "Вообще ничего не выдумывай". Ну не то, что вообще не выдумывай, типа вот этих два кейса тебе нужно обработать, все остальные попробуй где-нибудь с рута достать.
>> Принято.
>> А пото потом получается у меня есть там коллеги, которые требуют определённой какой-то архитектурной структуры. А я могу на стадии вот этого вот implementation details этот вопрос проконтролировать. Но артефакты, которые я создаю, то есть ты делаешь по кодовой базе, то есть он тебе туда напихал нужного контекста, ты потом сделал э спеку, где он тебе позадавал вопросы, что ты конкретно хочешь на уровне функциональных требований. То есть это суперкороткие какие-то вещи. И это вообще мало токенов требует. А следующая стадия - это уже конкретная реализация, где ты можешь и код пописать.
>> Не, ну как это работает, понятно. Мы это уже не раз обсуждали и пробовали. Так что
>> Да,
>> да, но смысл в том, что расход токенов супер маленький. То есть коллеги, которые у меня рядом сидят, пробуют, э-э, клод-кодом пользоваться, у них, э-э, они вайп-код, то есть они просто пишут промты, потом ревьют этот код, а потом им что-то не нравится, но у них этап там типа не то, что им не нравится, а в том, что скорее ты это отправляешь на ревью и там по 10.000 строк изменения и, ну, типа проекты на выброс можно и принять, да? А по сути в существующие проекты такое уже не засунешь. То есть там поэтому и много времени тратится, и люди не используют этот AI
>> так сильно, как они бы могли. А на больших проектах у тебя просто агент может там часами работать. Ну там рядом сидит там у меня коллега, он работает над большим C++ проектом, которые это просто там какие-то миллионы строк кода.
>> О'кей, давай, давай подытоживая, потому что там ещё у Валера рука.
>> А, да, да, подытоживая, что у тебя очень мало токенов тратится. Задачи у тебя не очень определённые. Даже если ты, мм, знаешь код, тебе нужно, а, указать, как реализовать, э, что именно реализовать, какие кейсы обработать, какие нет. Ты можешь сильно упростить решение на этих стадиях. А-а, и то есть это как ментальная модель для человека, которая ещё и для иллэмок очень сильно повышает качество результата. уменьшает расход токенов. А как бы что ещё там будет? Ну, точность результат, ну, скорость ещё тоже, потому что по вот этому финальному артефакту тасков очень быстро генерировать код. То есть это прям
>> там, я не знаю, полчаса, час и у тебя целый проект готов.
>> Спасибо, Валер.
>> Ух, я дождался. Ну, в общем, я уже не раз говорил, что это такие такси костры, но по сути вот описано сейчас Денисом и с другими ребятами, ээ, и то, что я хочу сказать далее, это всё просто разные подходы вот к этому контексту инженерингу. И что я хочу сказать, я уже писал об этом в чате
На днях, не помню в каком, в агентском, кажется. А, но я предлагаю вам, ребятам, кто практикует вот этот спекткит и другие логи контекст инженеринга, попробуйте э подойти к этому, как к этому подхожу я. Я вот буквально сегодня написал статью по этому поводу и >> спинешь ссылочку >> там есть в во внешнем контенте ссылочка на ликиды там статья. >> Угу. А-э, и там есть два главных пункта, которые я пропагандирую всем, и я сейчас объясню поподробнее.
Первый пункт - это set boundaries. Укажите ограничения. И второй пункт пункт - это, аэ, создайте контекст. Ну, короче, первое, раскрываю правила. Всё, что ты, Денис, рассказал про условия, про какие-то ограничения от команд, архитектуру и так далее, всё это можно прописать в правила. И любой запрос в агент будет знать этот контекст.
>> Ты когда говоришь правила, ты имеешь в виду рулы, например, в курсоре или это просто какие-то любой из механизмов там приходит System пром неважно.
>> Суть в том, чтобы задать именно бокс, в котором работает модель. Не, чтобы она не писала вот этот вот шумный код, про который ты рассказываешь, что она по всему проекту начинает что-то рисовать. Ограничий максимально, задай ей рамки, как она должна писать, где и что. Э-э, и второй момент, когда я ей задаю задание, ну, я со своего опыта рассказываю, я ей его даю, о, если на абстрактном примере, таким образом, как будто я передаю задачу Джуниору, который остался вместо меня, когда я в отпуск ухожу. Я передаю весь контекст задачи вообще. То есть вот для этого я использую голосовой ввод, freemtext, абсолютно всё, что я знаю про задачу, все какие-то констрейнты, какие-то, всё описываешь и всё. один промпт, задача готова к выкадке на пром на прот, как правило, это так происходит. Вот эти два пункта очень важны и прям не знаю, могут заменить даже ваш подход. Попробуйте просто именно так сделать.
>> Ээ так давайте, Виталик, потом Алексей,
>> да? А, ну на самом деле прав, а с другой стороны, ну, то есть как раз-таки Спектки Kit и подобные как бы они как раз-таки и нацелены на то, чтобы формировать вот эти правила, а вот эти баoundaries. То есть с помощью э промтов, с помощью э взаимодействия с лмкой мы эти баундери и подготавливаем. То есть не вручную сами там пишем, как бы, а, и формулируем как по по правилам промтинга, да? А нам другие промты помогают это сделать. То есть, в принципе, ну, здесь нету противоречия и нету как бы, скажем так, противоставления. Просто это удобный способ создания вот этих правил, этих баoundaries.
>> Угу. А вот, а ещё я хотел сказать, как бы вот есть другой ещё подход тому, что вот делать спектfow или spectit, а это bт метод. А у них подход немножко другой. У них не через то, что спецификации, ну
>> у них команда агентов, да?
>> Да. у них, ну, то есть естькит - это последовательность активности. То есть у нас есть промты, которые, а, описывают активность для того, чтобы сформировать спецификацию или вот эти правила Boundaries. А в BM там ранты, ну, то есть там агенты, которые играют конкретной роли, то есть там вот этот фреймворк протов, он построен немножко по-другому принципу. И если в спеed kit больше подходит для fullst девелоперов, которые от проработки требований, от постановки задачи и до delivery как бы разрабатывать, то BM он больше подходит, как мне кажется. И у меня пока нету как бы и конкретного примера, да, но мне кажется, то есть с отдельной ролью может работать как бы отдельный специалист в этой роли. И, соответственно, уже как бы там командную работу можно организовать с помощью вот этой команды агент.
>> Кажется, будто бы BM для более сложных и громозских задач хорошо использовать. Нет,
>> трудно сказать. Там, ну, есть своя специфика, да? То есть ты как будто общаешься с конкретным, ээ, ну, то есть либо ты играешь роль менеджера, да, который, э, взаимодействует с каждым членом команды, да, и проговаривает ему, что нужно сделать. Либо каждый отдельный специалист разговаривает со своим напарником и который помогает ему подготавливать артефакты для следующего этапа.
>> Угу. Да, спасибо.
>> Ну, как-то так. А,
>> Алексей,
>> так, ну, я, наверное, не буду там сильно что-то противопоставлять, скорее альтернативный вариант расскажу. А, то есть в моём примере это какой-то Greгenfield проект, в котором я всё ещё полностью владею кодовой базой. А у меня подход такой, что я строю кодовую базу таким образом, чтобы у ЛМКИ всегда была хороший пример, на который опереться. Вот у меня практически нет никаких заготовленных промтов. Я зачастую смотрю, понимаю, что можно реструктуризировать, чтобы какую-то новую фичу добавить, нужен лёгкий рефакторинг. Я такой делаю сначала маршенерию какую-то умную руками. Потом натравливаю, говорю: "Сделай мне вот такой же второй рядышком, вторую папочку с таким же подходом". Смотрю, что он накодил. Опять же выделяю какую-то общие, может быть, части, которые могут масштабироваться и говорю: "Всё, дальше вот следуй вот такому паттерну".
>> Ну, это хорошо работает, когда ты владеешь кодом и когда у тебя есть примеры, которые можно показать, чтобы он сделал по образю.
>> Да. Да, это хорошо работает. У нас ещё
>> в этом подходе наоборот готовить какие-то заранее проумты, спеки, потому что очень часто меняется структура, выйдет наоборот дольше.
>> Ну, есть ещё третий подход тут справедливости ради упомяну про него. Про него, кстати, Валик рассказывал. Валик ещё с нами, наверное, уже ушёл в воркшопе. Он показывал, когда он 5 или 6 часов делал сингle промт для того, чтобы запилить целый сервис по работе с тором и пловским. Это подход микроменеджмента, когда ты практически полностью без реализации кодовой описываешь от и до, как должен должна быть заимплементирована задача, и тебе просто я ий спокойно пишут по этому код. А, ну это когда ты хорошо очень знаешь то, что тебе нужно, хорошо знаешь кодовую базу свою и не хочешь писать код руками. Ну, есть и такой вариант, Денис. А, ну у меня, в принципе, подход похожий вот с предыдущим оратором, а что у меня уже есть кодовая база, уже есть паттерны, просто их много, то есть их в clд MD там Wagens просто не вложишь. Это слишком многословно. Э, и получается, что метод довольно гибкий, э-э, и позволяет тоже референсить эти примеры. Лэмка извлекает эти паттерны и вскладывает там себе в resarch или implementation план. Аэ, но я согласен с Валерием, что это можно делать проще. То есть я читанул, что он там как бы описал с баoundy, с контекстом. В принципе, я с этим методом так и работаю. То есть у меня есть какой-то freм промт, а, в который я всё накидываю, и потом я просто флоу прогоняю. Наверное, вот эта тема, что мне нужен этот флоу, может быть, мне, как человеку нужен этот флоу, чтобы понять, что я сам хочу сделать, чтобы уменьшить скоуп, а, на ревью, э, как бы потом, потому что я буду знать, что от меня будут требовать люди другие, и чтобы это как бы подогнать и проконтролировать, а, но положить это в какие-то внешние места. один раз у меня не получилось. Вот. То есть это либо слишком много надо писать, то есть полпроекта нужно там за как бы сделать, потому что у нас есть фичи но они тоже там разной степени зрелости. Вот то есть есть какие-то паттерны, но а их много, потому что задачи разные. То есть они не то, что ты просто по подобию добавляешь фичи. А я я ещё хотел тут обратить внимание, спасибо всем высказавшимся, хотел ещё обратить внимание, у нас есть же ребята, которые занимаются веб-кодингом, которые являются там инженерами либо не инженерами, но с кодом не сталкиваются. Нет у вас ощущения в принципе у всех у вас, что и SDD, и вообще весь промт инженеринг двигается в сторону, что мы отходим от написания кода руками? Все эти методы нужны, чтобы мы перешли от написания кода к объяснению задачи. С этой точки зрения тогда и для вайп-кодеров, и для инженеров без образования в программировании как бы разработка софта становится более открытая. Возможно будет, в принципе, и одно из одним из направлений их работы в будущем.
>> Когда этот момент настанет, тогда мы станем не нужны. Бойся его. Ну, по факту, когда ты описываешь всю структуру через архитектуры, спеки, что там, ээ, ну, вс всёвсёвсё ты описываешь словами, ты же там код не пишешь, ты только архитектурное видение описываешь, и ты зачастую на более-менее несложных задачах ты даже код можешь не ревьювать. Он либо написан хорошо, либо несколько итераций, он написан хорошо, не хорошо, работающи.
>> Очень важно иметь короткие итерации. Фидбек-клуб у тебя должен быть понятный через, когда ты заходишь через архитектуру и так далее, ты превращаешь кодирование в терфол.
>> Ну интересно, интересно, насколько долго нам ещё нужно будет уметь вычитывать код. Уже даже не писать, а вычитывать.
>> Можно я добавлю?
>> По поводу того, что Валера сказал, мы будем ненужными. Мне кажется, это, э, точно не так. И мне кажется, во-первых, рынок становится шире, во-вторых, да, меньше кодить, больше инженерить и и делать. То есть вот сейчас как бы раньше я смотрел на кодинг, обливался слюной, такой хотел заняться, а, но приходилось другими делами заниматься, чтобы денежку зарабатывать и всё, не было времени этим заняться. Да, я такой начал этим заниматься. Но сейчас я понимаю, что, ну, я не могу фултай это сделать. У меня есть другие обязанности там, а, в компании. И сейчас вот я пока эту тему изучаю, я всё жду, когда на хединят вакансии. Я вайпкодер, могу за день сраз проекты выкатывать. И я такого с удовольствием возьму в штат. И более того, я уже а одного человека отсобеседовал с клуба, и, ну, как бы мы сейчас переговоры ведём. огонь.
>> Поэтому и, ну, то есть ещё раз мысль такая, что это добралось до меня как представителя малого бизнеса и а таких как бы много. И и вакансий только станет больше, и заниматься мо, ну да, там не нтерпрайз проекты придётся писать, но а какую-нибудь ERP-систему локальную для конкретного проекта. Ну почему нет? Вот сейчас это возможно.
>> Мне ещё нравится, что смотри, ты же себе по факту можешь спекфлоу этот сам настроить. Это не какая-то супертехничная штука. Там буквально из техничного зайти на GitHub и почитать глазами, как это реализовать там в курсоре или в чём-то работал, не помню. Ты говорил сегодня, и ты это реализовываешь. У тебя уже задачи на более высоком уровне и более качественно выполняются. Как раз то, про что ты вначале спрашивал. Можно ли команды агентов самому настроить как-то без инженерии? Ну вот BMТ можно попробовать настроить по факту. Ну, это ты имеешь в виду к тому, что не нужен всё-таки разработчик, а типа самому всё это настроить и делать? Да. Дадада.
>> Не, ну всё равно это и сопровождать надо, и потестить всё надо. Это сколько времени уходит на всё это. Мне проще ээ делегировать и заплатить за это деньги, чем э я свой фокус направлю на всё это и тем самым убудет в другом месте.
>> Угу.
>> Да, я сейчас могу. Я уже делаю какие-то проекты. Вот, условно, я сделал платёжный календарь, а, с ерпэшкой нашей совместил, сделал выгрузки. А, всё, я теперь могу финансы считать. Из-под капота в моём складе такой штуки нету. Аа, но просто нет человека пока. Надо искать, надо нанимать. Э, это ещё не так популярно. У многих спрашиваешь, никто вообще не знает, что такое курсор, что такое код-код. Вот. Но а а как бы стандартного специалиста нанять с рынка, это дорого, как мне кажется. То есть охота вот такой баланс
>> там у нас в чатике уже это предлагают вайпкодерские услуги на мвпишку. Обрати внимание, ада Олег,
>> я я это сейчас всё прочитаю. Я этот я я не сдвгэшник ещё. Я не умею это одновременно три чата читать пока. Но но я это в себе развиваю. Я чувствую, вот эти вот новости ежедневные, они туда ведут.
>> Да. Хорошо. Э, так, Денис, давай ещё тебе дадим слово по этой теме и будем двигать дальше.
>> Да, повторюсь, я не пишу код теперь -э там потому что, ну, я пишу вот эти промты и вычитываю.
>> Ну, ты его читаешь, читаешь, как бы писать. Ладно, ты его всё равно вычитываешь, ты его понимаешь. Я я много читаю, да. Я как бы у меня скилл со школы скорочтения, курсы проходил, очень пригодились. Сейчас а-а хотел сказать, что невай, ну, не кодеры тоже делают довольно много. А эффекты, которые я наблюдаю - это то, что люди, которые знают, что надо сделать, теперь могут сделать это за вечер. А staff-инженеры, princiнл инженеры фигачат очень полезные тулы, которые потом команды делают. Раньше для них бы нанимали джуниоров, midлle разработчиков, сейчас фактически вайп-кодингом аэ они это закрывают. Вот менеджер у меня тоже в перерывах вайп-кодит. То есть если он видит понятную задачу, а, и там надо джейсоны подвигать, посравнивать, а силай сделать, то есть у него это получается прямо хорошо. То есть он как дизайнер такой с бизнес-фокусом, аа, очень хорошо понимает, как э там другие дизайнеры работают и так далее. может сделать хороший, понятный инструмент без вот этой всей коммуникации, что ему нужно требования писать, что ему нужно с кем-то пройтерироваться. То есть он сидит сам просто с курсором,
>> а вайпкодит
>> и плюс, закрывает задачи, которые раньше он бы делегировал, а пока бы у нас внутри команды освободилось место для низкоприоритетных задач, сейчас он может это делать сам. То есть там секюрити фиксы какие-то накатить, какие-то мелкие баги фиксить. То есть, ну, если это хорошо, если менеджер у тебя из технического из технической ветки.
>> М
>> дизайнер.
>> Ну, это техническая ветка. В смысле, это не человек, который не вырос из бизнес-аналитиков, например, либо из техракеров?
>> Нет, он делал в фотошопе карты.
>> А, а, о'кей. Ладно, беру слово назад. Хорошо.
>> Ну, он технически, то есть Джейсоны он умеет делать и править, редактировать. Понятно.
>> Вот и сила и запускать в терминале. Но как бы то есть спецификация - это ему в фотошопе рисовать карты.
>> Спасибо, Виталий. Я далеш я хотел добавить, что, ну, скажем, скорее всего для не понадобится инженера для простых каких-то приложений, типа календариков или там, а, сборщиков какой-нибудь статистики или ещё че-нибудь, а, или, ну, скажем, какие-то повседневные там м таск-трекеры или ещё что-нибудь достаточно простое, но всё равно Но остаётся место для, а, больших систем, а, сложных систем, которые должны учитывать множество нюансов. И такие системы, ну, невозможно навайп-кодить. Для них нужно, э-э, спецификацию, документацию как бы вести. И, ну, в любом случае инженеры нужны будут. такие системы не строятся как бы за один вечер или и в них вкладывается много человек и часов. И плюс, как я уже написал в чатике, ну, и не и нафиг ничего не нужно. Как бы у неё нету шила в заднице для того, чтобы ээ что-то делать, что-то придумывать.
>> Пока,
>> да не будет, Лёш. Е, ес если как бы ей что-то ну мм для этого яишки нужно разработать, не на сегодняшний день, да, это не таламус и можичок, да, то есть должна быть э- система разгона и система торможения. И и эта система должна совершать ошибки. Люди, у людей шыла в заднице, потому что мы способны совершать ошибки. Мы же отишки не хотим, чтобы она совершала ошибки. Мы хотим, чтобы она работала предсказуемо, изобретать что-то новое и делать что-то по-другому. Э для этого нужно совершать ошибки.
>> Ну, ты немножко подменил сейчас понятие. Э, как мне кажется, мы как разработчики, да, мы хотим, ээ, предиктивности ответов и того, чтобы нам лэмка делала то, что мы говорим. Но разработчики Лэмок хотят, чтобы они просто решали более сложные задачи. У них нет цели делать так, чтобы лэмки отвечали интерпретируемо. Да, они хотят, чтобы делать сложные задачи, но их пользователи, ээ, ну, то есть те, кому они продают свои системы, они хотят, чтобы эти системы стопроцентно гарантированный результат давали.
>> Ну, я как
>> который всегда хороший, они не будут приемле того, чтобы он плохой результат генерировал. А человечество продвинулось в своём развитии именно благодаря, что, ну, то есть мы совершили миллион удачных опытов, потому что мы 10 млн неудачных опытов. Ещё больше миллио модель в процессе обучения триллион раз неудачно сделала опыты. Я к тому, что интерпретируемость вообще не главная вещь. Главная вещь - давать новые знания и качественные решения. И в этой системе, у этих штук вполне себе может возникнуть всё, что угодно. Мы не знаем, как работают модели сегодня. Над интерпретируемостью докторские работы пишут. Ну, не докторские, там научные работы.
>> Нет, так тут дело не в интерпретации, а в том, качество некой
>> качество,
>> да, нет, в в свободе, ну, э э в свободе выбора, да? То есть, а у человек, ээ, хочет чего-то, потому что он, мм, как бы свободен выбирать, он свободен как бы делать то, что он хочет. Невозможно дать человеку задачу, да, ну, то есть как бы сказать: "Вот мне нужно это". Он у него уже рамка появляется. Точно так же, как у Иишки, да, тоже рамка появляется. И тогда уже как бы тот, который поставил задачу, он ожидает ну результат в этой рамке.
>> Да, понятно.
>> Не буду дальше тут входить, а то мы сейчас вообще в философию уйдём.
>> Ну, возможно, конечно, модельки когда-то захотят что-то сделать, но сейчас они реагируют на пока что мы операторы, мы являемся этим триггером, которые модели,
>> да, они реагируют на нашряют. Есть вопрос к Валере поводу его метода. Есть ли у него какие-то темплейты или там тупо темплейт выдумываешь каждый раз на задачу а boundariies и потом каждый раз накидываешь э рандомный контекст и или надиктовываешь его. А в том-то и дело, что я каждый раз баундес не выдумываю. Вот эти вот правила, они проектные, то есть они общепроектные. Сколько бы их там не было, это всё равно будет меньше, чем исходный там вот этот суперпромптат агента. Поэтому я максимально конкретно описываю правила, как писать код, что писать, какие есть структурные и архитектурные, э, такие важные вещи, которые условно, если бы пришёл новый человек на проект и мне нужно было бы ему его полностью загрузить, чтобы он знал, как как писать этот проект. Вот это я описываю в рулах.
>> Блин, не отпускают васки.
>> Ну, я каждой задаче отношусь, как я уже рассказывал, как к отдельному такому полному воркайте, который я передаю тоже кому-то. И вот он, оперируя вот этими двумя сущностями, практически каждый раз, если сама модель где-то не запуталась и накосячила, выполняет результат с ваншот.
>> Ну у меня к вам тогда ещё вопрос. Там Денис в чате много про это писал. Давайте поднимем голосом, в конце пообсуждаем ещё немножко. Не кажется, что спекфлоунерит много ситуативных файлов, которые только под конкретную большую фичу подходят. И значит, спеки надо хранить не в коде, как это сейчас делается в MD-файлах, а, например, где-нибудь в жире, там, где хранятся бизнес-требования, каким-нибудь MCP их подтягивать при желании. Плюс к тому же в жире сильно проще будет работать с теми спеками не техническому персоналу, который вдвежке вообще знать не знает и не лазит.
>> Ну, я для себя вообще их не храню в коде, потому что это слишком большие артефакты. То есть там ресёрчи какие-нибудь и вот эти вот tasks md их, э, очень тяжело читать.
>> Так, как ты их вкладываешь в контекст, если не в коде хранишь?
>> Гитогнор.
>> А, гитогнор.
>> Не, не, у меня есть отдельная папка, отдельной репозитории, где я храню эти спеки и туда их комичу. То есть я их не с кодом храню, с кодом у меня типа пиар по правилам команды оформленный. А в коде должно быть понятно, что он там делает, разложен, как бы комментарии, если что-то непонятное, спорное. А сама спека она, ну, типа команде неинтересна. То есть они не хотят читать именно промежуточные артефакты. Ну и непонятно, как их использовать на данный момент. Вот это, ну, в других командах я читал, эти артефакты, они бессмысленные. То есть, если там особенно темплейты не Human oriented, там просто бесконечно мусора насыпано, э, который написано в гайдах нужно лэмки, чтобы она успешно выполняла задачи. Ну, я со своих промтов это вычищаю, но типа никто их читать и не собирается. Просто есть же этот желание в некоторых компаниях и у некоторых команд-разработчиков сделать типа общую инфраструктуру MD файлов и сделать якобы общий такой спектрин подход, который будет подходить и фронтендеру, и девелоперу, и тестеру. Вот один репозиторий, из которого ты берёшь нужный тебе файлик с контекстом.
>> Я слабо верю в такой подход. меня принципиально я не пытаюсь шарить никакие мои рулы или ещё что-либо, потому что они реально устаревают, меняются от модели к модели. Надо адаптировать. У каждого разработчика свой подход, как работать с моделями. Разные ступылы все используют.
>> Просто это будет такая мусорка хуже устаревшей документации.
>> Короче, Gitnore либо отдельной репозитории.
>> Вот у меня, да, идея. Всё, хочу тоже себе навайп-кодить такую штуку, которая будет в отдельном репозитории комитить, а по, то есть у меня, например, папка под репозиторий рабочий проект. И вот эти файлы, чтобы комитились не в основной проект, а вот в сторонний где-то, который лежит чисто у меня, чисто под меня.
>> Ясненько. Хорошо. Тогда, если ни у кого больше топиков нет, стабильно 2 12 часа. Всем большое спасибо за то, что дошли сегодня. Спасибо отдельное всем, кто участвовал в дебатах и текстовы, и голосом. Сегодня прямо продуктивно было, мне кажется. И до встречи через 2 недельки, я думаю, там уже Ладно, не думаю. Всё нормально там будет. Через 2 недели встретимся. Давайте, пока-пока. Мишал.
>> Спасибо всем. Пока.
>> Пока-пока.
>> Всем пока. Всем пока.