Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Первый оставляет вас медленнее конкурентов
Бегите бегите, как леминги в пропасть
А куда деваться то? Это шоу сдохни или умри.
Происходящее вокруг вайб-кодинга у меня помимо рефлексии, описанной в статье, вызывает конечно и другие мысли. С позиций скорее разработчика, нежели менеджера. Далеко не все из этих мыслей положительные. Меняется суть профессии разработчика. Что важно - меняется степень того, насколько результативность разработчика определяется его уникальными когнитивными способностями. При этом уверен, что условное спортивное программирование останется как явление и соревновательная дисциплина.
Но, как бы не было порой грустно от происходящей трансформации профессии - адаптироваться под происходящие изменения становится вопросом выживания для бизнеса, не имеющего огромного запаса прочности.
Экономика меняется, скоро люди перестанут платить за ширпотреб оверпрайс, они захотят покупать хорошие и надежные продукты за адекватную цену. Выживет не тот, кто сделает быстрее, а тот, кто предоставить качественный и надежный продукт, за приемлемую цену. А для производства такого продукта нужна хорошая инженерия. Вайбкодинг это не про инженерию, это про "тяп-ляп и в продакшен".
На сегодняшний день уже собраны развитые экосистемы агентских скиллов. На мой взгляд особого внимания заслуживают следующие проекты...
Поделитесь опытом. Пишу относительно сложный бэкенд код. Очередная фитча с тестами вайбкодитсч опусом по общей постановке задачи в среднем за 1-6 часов. Но затем до недели уходит на ревью. Это раза в два быстрее чем руками, но все ещё спорный профит.
Для начала, модель делает много шаблонных глупостей, вроде ненужных фоллбэков на старые версии логики, проверок того что не может случиться, смешении задач и уровней абстракции, классов не в тех папках, новыми функциями под старыми именами, повторных решений одних и тех же задач и так далее. Но это я частично решаю один раз заготовленными промптами на ревью. Прогон промптов занимает ещё от часа до пол дня.
Потом мне надо погонять это с дебагером чтобы изучить всю логику, которой я ещё по сути не знаю. Здесь я вижу пробелы, которые ни я ни агент не осознавали когда вайбкодили и правлю логику с агентом. Так постепенно уходит неделя.
Вопрос - удается ли этого реально избежать за счёт скиллов брейшторминга и разработки? Или при достаточно сложной логике эта моя неделя пока неизбежна?
Спасибо за комментарий!
На мой взгляд примерно так, в порядке убывания соотношения результативности к затратам времени:
Использование режима планирования при начале работы над фичей-задачей.
При начале работы над новой задачей сосредоточиться на описании условной loss function относительно результата работы. Т.е. сформировать и включить в промпт для агента описание критериев достижения успеха по данной задаче. В идеале - количественно выраженный критерий. Это позволяет агенту на этапе верификации своей работы получить понимание о том, насколько сделанное близко к поставленной цели.
Команда А (агентов :)) - (подробно описано в теле статьи)
Поместить в mdку для агента ваше понимание того, что из (обычно) лучших практик является избыточным в случае вашего проекта. Как например "ненужные фоллбэки на старые версии логики". Иными словами - выразить то, от каких хрестоматийных паттернов вы готовы отказаться в угоду скорости разработки с полным осознанием их избыточности / неприменимости в контексте именно вашего проекта..
Ввести агента "аудитора". Его задача - проведение review вновь реализованной фичи агентом-аудитором. Парадоксально, но даже если правила игры для аудитора будут на 99% совпадать с правилами, определяющим действия агента-разработчика - то контрольный взгляд обычно выявляет достаточно много отклонений. Это более простой и понятный путь относительно целой команды агентов.
TDD-подход с агентами. В данном случае речь не только о модульных тестах. Чаще об интеграционных или даже e2e. Хотя конечно модульные при условно-бесплатном коде на мой взгляд тоже must. Это также очень комплементарно пункту 2.
Чаще об интеграционных или даже e2e. Хотя конечно модульные при условно-бесплатном коде на мой взгляд тоже must.
Интересно что вы об этом упомянули. Я пока полностью отказался от модульных тестов и оставил только интеграционные. Потому что модульные тесты это еще дополнительный код который мне надо ревьювать с пониманием логики его работы. А ревью и понимание как раз и есть узкое место не позволяющее ускориться в разы. Напротив, интеграционные тесты понимать проще - вход и выход.
Вы правы. Но идея применения модульных ровно в том, чтобы значительно уменьшить объём ревью. Т.е. качество кода вокруг boilerplate оставлять на таком уровне, который отвечает требованиям:
успешного выполнения модульных тестов
целевым значениям метрик при нагрузочном и интеграционном тестировании
Если же речь о каких-то core вещах на базе совсем нетривиальных алгоритмов - в этом случае отдам предпочтение потратить время на ревью, нежели довериться модели работающего чёрного ящика.
В общем - везде решение относительно review нужно принимать осознанно на мой взгляд.
Но сам факт того, что может существовать код из-под пера агента, который миновал ревью разработчика - я на сегодня уже считаю допустимым. НО - это конечно вопрос баланса в соотношении рисков-скорости.
Спасибо за статью! Как на счёт коммерческой тайны? Полностью доверяете облачным решениям? В статьях, комментариях часто пишут, как используют ии в разработке, но вот это место либо умалчивается, либо у нас опенсурс/пет проект.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вайб-кодинг как серфинг между хайпом и нейрослопом