Comments 58
Ловлю себя на мысли и действительно пытаюсь этому сопротивляться, что теперь уже даже не хочется тратить время на промты. Хочется просто все и сразу, чтобы модель сделала как надо с одной фразы
Задачи, попытки, ошибки переместились в другую плоскость, но все равно остались и это не дает стать настоящим "волшебником"
полностью понимаю
я тоже сопротивляюсь и стараюсь всегда потратить время на объяснения, но каждый раз в какой-то момент я сажусь за код уже уставший и раздраженный и меньше всего мне хочется распинаться в промптах; и это всегда отправная точка, причем она особенно страшна, если модель корректно решила задачу - планка допустимого уровня раздраженности и усталости, при котором ты еще готов распинаться, опускается, и в следующий раз будет еще больше хотеться просто написать "implement this. make no mistakes"
кажется, в такой момент лучшее решение это отложить код и пойти прогуляться (если, конечно, не каждый день это такие моменты..)
Все начинают мыслить не задачами, а желаниями.
По моему опыту, это начало конца даже самого лучшего и продуманного проекта - превращение его условный в Nero Burning Rom
Через год такого режима ты внезапно обнаружишь, что стал быстрее принимать решения, но медленнее думать. Парадокс.
Это буквально центральная идея одной широко известной книги: Думай медленно, решай быстро.
Собственно книга про то что думать быстро плохо, потому что это ведет к ошибкам
концепция в книге верная, но кажется у меня она немного в другом ключе)
думать медленно, чтобы проанализировать возможные исходы / обдумать сценарии / потратить много когнитивного ресурса, чтобы сформировать верный путь к решению проблемы - правильно; ты потратил много компьюта на обдумывание и мало на решение
думать медленно, потому что ты привык к мгновенному решению проблем и мозгу просто лень думать, мысли стали более стохастическими и с постоянным желанием какую-то часть решения делегировать LLM - я считаю неправильно; ты тратишь мало копьюта на решение, но и на обдумывание тоже мало, хотя времени потратил много
"Думай медленно, решай быстро" — это просто корявый перевод.
бесконечный ревью AI-кода выматывает потому что нет критерия "готово". Если написать тест до промпта - результат бинарный, прошёл или нет. Гемблинг из статьи ровно от этого - неопределённость результата. Убираешь неопределённость тестами и это обычная делегация, не слот-машина
Ну так и в гемблинге результат бинарный: или выиграл, или проиграл.
хорошее замечание, я согласен, что парадигма сначала писать тесты, а потом накладывать на них код в вайбкодинге верная
но тут опять подводные
во-первых - тесты писать самому что ли? нет, пусть их ллмка тоже пишет; если их вручную отсматривать и проверять - ок, но это уже выходит за рамки вайбкодинга
во-вторых - не во всех сценариях тесты будто бы уместны; если речь про разработку, то да, написал тест - добавил функцию - проверил; если речь, например, про ML - часто вообще сложно сказать какие тесты писать и на что; я не гуру написания тестов и прибегаю к ним только когда разрабатываю библиотечку/повторяемый код каких-то сложных пайплайнов, и я понимаю, что тесты можно написать на все что угодно; на моей практике в трех командах, что я успел поработать, культуры написания тестов для экспериментов не было ни в одной; и я согласен с этим, разработка станет кратно дольше и запутаннее, потому что много ресерча и ты написал тест -> написал код -> проверил результат -> он тебя не устроил, ты хочешь поменять пайплайн -> меняешь все зависимые тесты, проверяешь чтобы старые тесты не поломались/переписываешь их -> добавляешь новый код
короче не всегда просто убрать неопределенность тестами, но если такая возможность есть в проекте - надо пользоваться
Прохождение тестов <> корректная работа. Особенно когда тесты тоже LLM пишет.
Я не чувствовал себя джуном в незнакомом стеке. Скорее архитектором, который делегировал всю механическую часть системе
Я тоже когда смотрю стримы киберспортсменов, чувствую себя киберстпортсменом...
Простите но что то в вашей логике не сходится, вы с помощью вайбкодинга даже не понимаете что в проекте, вы даже джуном себя не можете ощущать ибо не понимаете как все работает даже на минимальном уровне, вот такие же ощущения что они великие программисты очевидно испытывают те кто на какой нить тильде сделал сайт в два клика, что там под капотом вы не знаете и не понимаете, но вы уже архитектор...
Зачем проектировщику-архитектору условной резидентской многоэтажки знать тонкости и детали того как джамшуты будут ложить кирпич и возводить стены? Что то скорее в вашей логике не так.
Задача проектировщика — создать план, чертежи, и делегировать все процессы на исполнительные звенья.
Проектировшик это управленец, менеджер, стратег. Ему не обязательно знать ньюансы. Он ставит задачу и оценивает конечный результат. Процесс не важен.
Да вы все правильно говорите, вот только в случае с вайбкодом, нет ни чертежей, ни планов, ни деталей, у вас именно такие Равшаны и Джамшуты все эти планы и чертежи рисуют, они же тысячи раз по схожим планам дома строили, и никто не проверяет что там внутри и возводят здание, которое рухнет в любой момент!
ни планов
Почему? Вы планирование не делаете что ли? Очень зря.
Вы не учитывается стремительно меняющиеся условия.
То что вчера было вайбкодингом, уже сегодня обрастает выверенными методологиями, одна из которых — предварительное формирования проектного чертежа перед реализацией или правкой. Это уже БАЗА к которой интуитивно подкрались вайбкодеры.
Мне хватило меньше года вайбкодинга, чтобы смекнуть, что кодить без плана — значит обрастать огромным техдолгом и стремительно лететь лбом в стену из неожиданного рефакторинга)) Предварительного опыта в разработке не было. Эдакий обречённый вайбдебаг получается в противном случае.
Так у Вас есть план и есть понимание потому что вы программист и знаете как что должно работать? А пару дней назад тут человек писал что у него курсор навайбкодил проект на 200 тысяч строк и 2 крупных комита сделал, хотя в его комментах еще пол месяца назад фраза: "Я вот вообще плохо шарю в самом програмировании" , по факту Равшан с Джамшутом сделал все от проекта до постройки. А он как "архитектор", проверил или внешне совпадает это все с его представлением, а что там внутри? Не забили ли на несущие конструкции? Не построили ли дом в болоте и он уже начал уходить под землю? Вы не можете определить, потому что не понимаете что внутри, у вас от архитектора остается только способность оценить содержимое по обертке!
Что самое поразительное никто не может показать нормальных корректных результатов своего вайбкодинга, которые не очередной пет проект, бессмысленный и беспощадный! Куча рассказов как им агенты накодили приложение которое им уже как два года нужно и на которых у них небыло совершенно времени, но я сильно подозреваю что такие "нужные" были приложения!
Я не беру в расчет тех, кто вообще не разбирается хоть минимально в программировании. Если какой-нибудь менеджер или школьник возьмется вайбкодить что-то сложное, то он практически точно прогорит после MVP. Исключений я не знаю.
У меня есть план, у меня есть смежный опыт и опыт в программировании, у меня есть понимание какая должна быть архитектура. Грубо говоря я сам был Джамшутом на другой стройке много лет, я знаю как строят дома и мне выпала возможность построить свой дом. Чем не архитектор?
> нормальных корректных результатов своего вайбкодинга, которые не очередной пет проект
Посыл статьи в частности в том, что таких результатов добиться большим количеством усилий и не получается :). В больших проектах нужно грамотно использовать AI, а не бездумно вайбкодить.
предварительное формирования проектного чертежа перед реализацией или правкой
Первоначальный план можно сразу выбрасывать. План это только повод для серьезного разговора. Это дерево проб и решений, откатов назад и переделок
Проектировшик это управленец, менеджер, стратег. Ему не обязательно знать ньюансы. Он ставит задачу и оценивает конечный результат. Процесс не важен
Вопрос качества процессов, доверия к ним. Не только локальных, но и сквозных. Архитектор должен знать эти сквозные процессы, а иногда вникать в локальные.
Зачем вы проецируете свой киберспортивный опыт на других?
По "кредиту" онли факты!
За два года ощутил все перечисленные пункты. Нужна воля, дисциплина и последовательность, чтобы не скатиться в эти пункты. Статья классная, новичкам обязательна к прочтению.
Я уже долгое время работаю тимлидом и сам редко пишу код. Прочитал статью и вижу, что у меня такие же ощущения от управления командой и проектами как тут у автора от вайбкодинга. Я тоже просматриваю каждый день по много ревью, мне сложно вникать в детали, так как их очень много. Я стараюсь обращать внимание на архитектурные решения, но с каждым годом по мере удаления от программирования это становится труднее. Я больше концентрируюсь продукте и фичах, а не на коде. В этом смысле мои подчиненые выступают в роли таких же агентов как тут описаны. И те же самые плюсы и минусы в моей работе как указаны в статье. В этом смысле ничего нового.
И вот мы снова видим, что агенты претендуют на роли джунов и мидлов.
Видали таких лидов на проектах. Если при лиде нет техлида, который за порядком следит и по рукам бьет, а иногда и по жопе, то обычно в коде большой кусок грязи и внутри команды разрабы друг в друга какашками кидаются, текучка в таких командах большая, что только усугубляет ситиацию.
Я стараюсь обращать внимание на архитектурные решения, но с каждым годом по мере удаления от программирования это становится труднее. Я больше концентрируюсь продукте и фичах, а не на коде.
Для преодоления такого явления и существует ротация. Ротация — это когда один и тот же человек в разное время оказывается на различных позициях в одной и той же компании. Иногда следует возвращаться и к написанию программного кода. Да и вчерашний "джун" мог бы побывать в шкуре архитектора, понял бы, насколько это сложно, но и несколько свежих идей подкинул бы. Да и и "эйчару" тоже иногда не помещает окунуться в технический долг, чтобы не спрашивать всякую всячину на собеседованиях.
Я лишь хотел показать, то что автор считает как огромную проблему при работе с агентами - уже давно существует в мире людей, надо лишь подняться на ступеньку выше обычного разработчика. Тогда выяснится, что приходится заниматься не одной задачей, а все время переключать контекст, в день принимать десятки не связанных мержей. Обсуждать несколько архитектурных решений в разных участках кода каждый день. И это не что-то сверхъестественное и невозможное - а повседневная реальность.
Ключевую вещь вы сказали - что все равно приходится и лиду валидировать выхлоп своих агентов (разрабов). Это уже не вайбкодинг, это грамотное использование инструментов, которое хоть и упрощает жизнь (избавляет от необходимости самому кодить), но все также требует траты большого количества когнитивного ресурса. И от него сложнее убежать, вы же не скажете команде на синке что-нибудь типа "сами спроектируйте", потому что команда воспримет вас как некомпетентного лида, типа какого фига он перекладывает свою работу на нас.
А в контексте взаимодействия с AI возникает возможность и соблазн не тратить этот ресурс, из-за чего возникают проблемы (аутсорсинг проблем ЛЛМ, усиление сдвг, токсичная креативность, получение гемблинг-зависимости итд). Никто же не увидит, как вы говорите своим агентам "сами спроектируйте". А было бы, кстати, интересно провести эксперимент, в котором все запросы к LLM по части кода были бы на таком же уровне открытости, как запросы лида к его команде.
Могу сказать - «сами спроектируйте». Это тоже часть делегирования. Ну или из-за нехватки времени или лени могу упустить важную архитектурную деталь. Через месяц или два эта деталь вылезет, и будет уже восприниматься как техдолг, придется переделывать. Опять таки - люди не гарантия отличного результата.
Есть небольшое но, ИИ агенты которые претендуют на эту роль генерируют огромные объемы кода, проверить его будет намного сложнее и дольше!
И вот мы снова видим, что агенты претендуют на роли джунов и мидлов.
Заменили уже? Как успехи? Не забудьте только агентов распределить по грейдам, чтобы они учились, росли и т.д. а то спустя какое-то время у вас синьоров не будет. Еще научите агентов брать на себя ответственность за код
Это все индивидуально. Есть вещи которые за годы надоедают. Типо за 15+ лет уже порешал, понаписывал многое, и делать очередную кнопку уже чисто физическая активность. Я как бы вижу решение и знаю результат, пропадает интерес и отсюда некая лень, не желание нажимать на кнопки. А бывает когда прям хочется и понажимать.
всю картину проекта так или иначе хранить в своей голове
Да, это ключевое.
В результате быстрее разработка то стала? Какие-то метрики улучшились?
Я постепенно ухожу от концепции вайбкодинга в работе к использованию AI как ассистента, проверяя за ним основные шаги. Описанные минусы при этом все еще проявляются, процесс избавления от плохих паттернов делегации небыстрый.
В таком подходе быстрее стала однозначно, думаю в разы, метрик нет, а какие тут нужны?
А как связано решение проблем и набор символов на клавиатуре руками?
Иван Петрович Павлов в своем труде «рефлекс свободы» описывал также инстинкт цели(он все подряд называл инстинктами). И также говорил что инстинкт цели лучше всего развит у англичан. И что для его наличия, усиления и развития необходима трудность.
Возможно от этого такие длиннопосты в англоязычном интернете мол, дарк соулс вернул меня к жизни и т.д.
А вот и деформация меня как хабрачитателя. После первого абзаца сразу иду в конец статьи и в комменты - а то вдруг я читаю нейрослоп.
О, дивный новый мир!
Статью плюсанул, но выводы что LLM и хайлоад несовместимы в корне неверные.
Мне LLM и ускоряло запросы в разы (да, из 2-3 рекомендаций часть как будто спорных, но некоторые прям в точку) и с эксплуатацией сильно помогает, ну там "эластиксёрч тормозит, где смотреть, что крутить" - советы часто синтаксически устаревшие, но практически всегда сильные и соответствовали выжимке из "сидеть и несколько дней доки шерстить"
А код за меня писать я как раз практически не прошу, не нравится почти всё.
Совместимы, но надо контролировать и хорошо самому понимать как должно произойти улучшение скорости/памяти - а это уже не вайб)
Было много ситуаций разных из последнего - (пишу на python) была написана параллелизация, в которой создавались сразу все задачи и max_workers был большой, в результате чего в event loop оказывалось с течением времени огромное количество pending корутин. Это увеличило потребление памяти из-за чего через два часа работы скрипта выполнение стало просто медленнее, чем без такой параллелизации.
Писал бы я сам и сразу бы нашел узкое место, поэтому сейчас я заранее знаю какое масштабирование и как мне надо провести и целенаправленно прошу LLM сделать конкретные операции.
Вот пишу этот коммент и думаю: "А может мне закинуть статью в промт и спросить у ллм, какой коммент сюда написать?"
Как же это жизненно..
тест гипотез / sql — одноразовые микро скрипты, которые не требуют включения в кодовую базу проекта
Привет от скл буквально двухдневной давности, коллеге дал умное слово для поиска и анализа решения проблемы. Он загнал его в ИИ, получил ответ, сделал, ребутнули сервер и ... он не поднялся, благо админ не спал вечером в выходной. А потому повторюсь скл это то, что работает с данными, не надо туда ИИ. Вообще никак даже если очень хочется и думаешь оно быстро. Быстро - написать самому, даже если будет выполняться долго, результат будет предсказуем.
цена ошибки маленькая.
работа с данными
А потому я с этим не соглашусь вообще никак. Код можно восстановить/написать заново (с нуля без бекапов), данные заново сделать шансы намного меньше (с нуля без бекапов).
Ключевое, что цена ошибки маленькая. Поэтому данные я имел в виду какие-то промежуточные/локальные. Но если ты их собирал месяц, то даже у локальных цена ошибки будет большой - значит надо осторожно, создавать вайтлист операций. В контексте взаимодействия с продовыми БД - никакого CRUD, только R (чтение), у меня стоит whitelist команд, поэтому на теории ничего не может сломаться.
При этом это все еще останется вайбкодингом, просто связанным по рукам и ногам.
Read в прод для девелоперов нуууу ... нет. Хотя может я испорчен всякими банками и конфедициальными данными. Whitelist команд, ну наверное можно, только кто будет в энциклопедии Юнлэ искать можно ли сделать что хочешь или нет, особенно когда дев не у каждого на машине или например стейдж тестовые проглядеть почему ошибка возникает ... более двух комманд (разработчиков) на связанных таблицах.
Если человек продолжает настаивать, то я ... соглашусь - конечно же вайбкодите скл. благодаря этому у меня будет работа и цена её если и изменится, то не в меньшую сторону. Я смогу разобрать Авгиевы конюшни и объяснить, что было не так. Хотя объяснение не понадобится, потому что какая разница что не понимал до не будешь понимать и после.
Интересно уже были практики токенизировать затраченные усилия сотрудника-человека на решение задачи с приведением к общей шкале с тем же Claude Sonnet 4.6 и последующим переводом в твердую валюту?
Проклятие легких побед: как вайбкодинг убивает волю к решению проблем