Ключевое, что цена ошибки маленькая. Поэтому данные я имел в виду какие-то промежуточные/локальные. Но если ты их собирал месяц, то даже у локальных цена ошибки будет большой - значит надо осторожно, создавать вайтлист операций. В контексте взаимодействия с продовыми БД - никакого CRUD, только R (чтение), у меня стоит whitelist команд, поэтому на теории ничего не может сломаться.
При этом это все еще останется вайбкодингом, просто связанным по рукам и ногам.
Совместимы, но надо контролировать и хорошо самому понимать как должно произойти улучшение скорости/памяти - а это уже не вайб)
Было много ситуаций разных из последнего - (пишу на python) была написана параллелизация, в которой создавались сразу все задачи и max_workers был большой, в результате чего в event loop оказывалось с течением времени огромное количество pending корутин. Это увеличило потребление памяти из-за чего через два часа работы скрипта выполнение стало просто медленнее, чем без такой параллелизации.
Писал бы я сам и сразу бы нашел узкое место, поэтому сейчас я заранее знаю какое масштабирование и как мне надо провести и целенаправленно прошу LLM сделать конкретные операции.
Я постепенно ухожу от концепции вайбкодинга в работе к использованию AI как ассистента, проверяя за ним основные шаги. Описанные минусы при этом все еще проявляются, процесс избавления от плохих паттернов делегации небыстрый.
В таком подходе быстрее стала однозначно, думаю в разы, метрик нет, а какие тут нужны?
Ключевую вещь вы сказали - что все равно приходится и лиду валидировать выхлоп своих агентов (разрабов). Это уже не вайбкодинг, это грамотное использование инструментов, которое хоть и упрощает жизнь (избавляет от необходимости самому кодить), но все также требует траты большого количества когнитивного ресурса. И от него сложнее убежать, вы же не скажете команде на синке что-нибудь типа "сами спроектируйте", потому что команда воспримет вас как некомпетентного лида, типа какого фига он перекладывает свою работу на нас.
А в контексте взаимодействия с AI возникает возможность и соблазн не тратить этот ресурс, из-за чего возникают проблемы (аутсорсинг проблем ЛЛМ, усиление сдвг, токсичная креативность, получение гемблинг-зависимости итд). Никто же не увидит, как вы говорите своим агентам "сами спроектируйте". А было бы, кстати, интересно провести эксперимент, в котором все запросы к LLM по части кода были бы на таком же уровне открытости, как запросы лида к его команде.
Я не беру в расчет тех, кто вообще не разбирается хоть минимально в программировании. Если какой-нибудь менеджер или школьник возьмется вайбкодить что-то сложное, то он практически точно прогорит после MVP. Исключений я не знаю.
У меня есть план, у меня есть смежный опыт и опыт в программировании, у меня есть понимание какая должна быть архитектура. Грубо говоря я сам был Джамшутом на другой стройке много лет, я знаю как строят дома и мне выпала возможность построить свой дом. Чем не архитектор?
> нормальных корректных результатов своего вайбкодинга, которые не очередной пет проект
Посыл статьи в частности в том, что таких результатов добиться большим количеством усилий и не получается :). В больших проектах нужно грамотно использовать AI, а не бездумно вайбкодить.
хорошее замечание, я согласен, что парадигма сначала писать тесты, а потом накладывать на них код в вайбкодинге верная но тут опять подводные
во-первых - тесты писать самому что ли? нет, пусть их ллмка тоже пишет; если их вручную отсматривать и проверять - ок, но это уже выходит за рамки вайбкодинга
во-вторых - не во всех сценариях тесты будто бы уместны; если речь про разработку, то да, написал тест - добавил функцию - проверил; если речь, например, про ML - часто вообще сложно сказать какие тесты писать и на что; я не гуру написания тестов и прибегаю к ним только когда разрабатываю библиотечку/повторяемый код каких-то сложных пайплайнов, и я понимаю, что тесты можно написать на все что угодно; на моей практике в трех командах, что я успел поработать, культуры написания тестов для экспериментов не было ни в одной; и я согласен с этим, разработка станет кратно дольше и запутаннее, потому что много ресерча и ты написал тест -> написал код -> проверил результат -> он тебя не устроил, ты хочешь поменять пайплайн -> меняешь все зависимые тесты, проверяешь чтобы старые тесты не поломались/переписываешь их -> добавляешь новый код
короче не всегда просто убрать неопределенность тестами, но если такая возможность есть в проекте - надо пользоваться
концепция в книге верная, но кажется у меня она немного в другом ключе)
думать медленно, чтобы проанализировать возможные исходы / обдумать сценарии / потратить много когнитивного ресурса, чтобы сформировать верный путь к решению проблемы - правильно; ты потратил много компьюта на обдумывание и мало на решение
думать медленно, потому что ты привык к мгновенному решению проблем и мозгу просто лень думать, мысли стали более стохастическими и с постоянным желанием какую-то часть решения делегировать LLM - я считаю неправильно; ты тратишь мало копьюта на решение, но и на обдумывание тоже мало, хотя времени потратил много
полностью понимаю я тоже сопротивляюсь и стараюсь всегда потратить время на объяснения, но каждый раз в какой-то момент я сажусь за код уже уставший и раздраженный и меньше всего мне хочется распинаться в промптах; и это всегда отправная точка, причем она особенно страшна, если модель корректно решила задачу - планка допустимого уровня раздраженности и усталости, при котором ты еще готов распинаться, опускается, и в следующий раз будет еще больше хотеться просто написать "implement this. make no mistakes"
кажется, в такой момент лучшее решение это отложить код и пойти прогуляться (если, конечно, не каждый день это такие моменты..)
Ключевое, что цена ошибки маленькая. Поэтому данные я имел в виду какие-то промежуточные/локальные. Но если ты их собирал месяц, то даже у локальных цена ошибки будет большой - значит надо осторожно, создавать вайтлист операций. В контексте взаимодействия с продовыми БД - никакого CRUD, только R (чтение), у меня стоит whitelist команд, поэтому на теории ничего не может сломаться.
При этом это все еще останется вайбкодингом, просто связанным по рукам и ногам.
прочитал коммент и подумал: "что мне на него ответить? может закинуть его со статьей в промпт и спросить у ллм?"
Совместимы, но надо контролировать и хорошо самому понимать как должно произойти улучшение скорости/памяти - а это уже не вайб)
Было много ситуаций разных из последнего - (пишу на python) была написана параллелизация, в которой создавались сразу все задачи и
max_workersбыл большой, в результате чего в event loop оказывалось с течением времени огромное количество pending корутин. Это увеличило потребление памяти из-за чего через два часа работы скрипта выполнение стало просто медленнее, чем без такой параллелизации.Писал бы я сам и сразу бы нашел узкое место, поэтому сейчас я заранее знаю какое масштабирование и как мне надо провести и целенаправленно прошу LLM сделать конкретные операции.
у меня у самого уже деформация от большого общения с ии...
я просто вырезал из статьи "хочешь я сгенерирую еще 5 более убедительных аргументов?")))
Интересно)
Я постепенно ухожу от концепции вайбкодинга в работе к использованию AI как ассистента, проверяя за ним основные шаги. Описанные минусы при этом все еще проявляются, процесс избавления от плохих паттернов делегации небыстрый.
В таком подходе быстрее стала однозначно, думаю в разы, метрик нет, а какие тут нужны?
Ключевую вещь вы сказали - что все равно приходится и лиду валидировать выхлоп своих агентов (разрабов). Это уже не вайбкодинг, это грамотное использование инструментов, которое хоть и упрощает жизнь (избавляет от необходимости самому кодить), но все также требует траты большого количества когнитивного ресурса. И от него сложнее убежать, вы же не скажете команде на синке что-нибудь типа "сами спроектируйте", потому что команда воспримет вас как некомпетентного лида, типа какого фига он перекладывает свою работу на нас.
А в контексте взаимодействия с AI возникает возможность и соблазн не тратить этот ресурс, из-за чего возникают проблемы (аутсорсинг проблем ЛЛМ, усиление сдвг, токсичная креативность, получение гемблинг-зависимости итд). Никто же не увидит, как вы говорите своим агентам "сами спроектируйте". А было бы, кстати, интересно провести эксперимент, в котором все запросы к LLM по части кода были бы на таком же уровне открытости, как запросы лида к его команде.
Рад, что откликнулось!
Я не беру в расчет тех, кто вообще не разбирается хоть минимально в программировании. Если какой-нибудь менеджер или школьник возьмется вайбкодить что-то сложное, то он практически точно прогорит после MVP. Исключений я не знаю.
У меня есть план, у меня есть смежный опыт и опыт в программировании, у меня есть понимание какая должна быть архитектура. Грубо говоря я сам был Джамшутом на другой стройке много лет, я знаю как строят дома и мне выпала возможность построить свой дом. Чем не архитектор?
> нормальных корректных результатов своего вайбкодинга, которые не очередной пет проект
Посыл статьи в частности в том, что таких результатов добиться большим количеством усилий и не получается :). В больших проектах нужно грамотно использовать AI, а не бездумно вайбкодить.
хорошее замечание, я согласен, что парадигма сначала писать тесты, а потом накладывать на них код в вайбкодинге верная
но тут опять подводные
во-первых - тесты писать самому что ли? нет, пусть их ллмка тоже пишет; если их вручную отсматривать и проверять - ок, но это уже выходит за рамки вайбкодинга
во-вторых - не во всех сценариях тесты будто бы уместны; если речь про разработку, то да, написал тест - добавил функцию - проверил; если речь, например, про ML - часто вообще сложно сказать какие тесты писать и на что; я не гуру написания тестов и прибегаю к ним только когда разрабатываю библиотечку/повторяемый код каких-то сложных пайплайнов, и я понимаю, что тесты можно написать на все что угодно; на моей практике в трех командах, что я успел поработать, культуры написания тестов для экспериментов не было ни в одной; и я согласен с этим, разработка станет кратно дольше и запутаннее, потому что много ресерча и ты написал тест -> написал код -> проверил результат -> он тебя не устроил, ты хочешь поменять пайплайн -> меняешь все зависимые тесты, проверяешь чтобы старые тесты не поломались/переписываешь их -> добавляешь новый код
короче не всегда просто убрать неопределенность тестами, но если такая возможность есть в проекте - надо пользоваться
концепция в книге верная, но кажется у меня она немного в другом ключе)
думать медленно, чтобы проанализировать возможные исходы / обдумать сценарии / потратить много когнитивного ресурса, чтобы сформировать верный путь к решению проблемы - правильно; ты потратил много компьюта на обдумывание и мало на решение
думать медленно, потому что ты привык к мгновенному решению проблем и мозгу просто лень думать, мысли стали более стохастическими и с постоянным желанием какую-то часть решения делегировать LLM - я считаю неправильно; ты тратишь мало копьюта на решение, но и на обдумывание тоже мало, хотя времени потратил много
это правда, пусть лучше роль фантазера будет только у продакта)
полностью понимаю
я тоже сопротивляюсь и стараюсь всегда потратить время на объяснения, но каждый раз в какой-то момент я сажусь за код уже уставший и раздраженный и меньше всего мне хочется распинаться в промптах; и это всегда отправная точка, причем она особенно страшна, если модель корректно решила задачу - планка допустимого уровня раздраженности и усталости, при котором ты еще готов распинаться, опускается, и в следующий раз будет еще больше хотеться просто написать "implement this. make no mistakes"
кажется, в такой момент лучшее решение это отложить код и пойти прогуляться (если, конечно, не каждый день это такие моменты..)