«Вайбкодинг» ‑ это просто ролевая игра для парней, которые хотят чувствовать себя хакерами, не делая сложной работы, или это мощный инструмент, меняющий процессы даже ML-инженера? Я думал, что это просто игрушка, пока не попробовал.
Привет, меня зовут Марк, я ML-инженер уже более 4-х лет и за несколько дней я навайбкодил приложение не зная ни языка ни технологий. А еще я навайбкодил кучу техдолга и получил неочевидные трансформации личности.
Я не буду учить тебя пользоваться нейросетями, но я разобрался, где вайб уместен, где запрещен и какие скрытые минусы тебя ожидают при длительной работе с AI-агентами.
Как я решил начать
Для начала давайте договоримся, что мы различаем вайбкодинг и программирование с AI-ассистентом. В этой статье речь про оригинальную концепцию вайбкодинга.
Наверняка вы видели сотни видосов на ютубе “я создал стартап с нуля за неделю при помощи Claude Code” или “я настроил 20 MCP в Codex и теперь он сам закрывает все таски”, и у меня они постоянно вызывали FOMO. Мол, я что, зря стараюсь? Вот я пишу код, а через 5 лет все поголовно будут вайбкодить, зачем кому-то мои навыки?
Да, я использовал LLM в качестве ассистентов и до этого, но только через UI интерфейс или автодополнение Cursor. Доверить машине самостоятельное решение задачи я всегда опасался, т. к. не верил в ее способности.
Но человек я достаточно азартный, интерес и потенциальный выигрыш перевесили опасения и я решился.
Первый опыт
RAG с нуля на Swift за неделю
Это был пет-проект, RAG до этого я никогда не встречал, как и разработку под MacOS. Выбрал связку Swift (front) + Python (back) + Pinecone (DB, retrieval) + GPT (generation). Я использовал:
Claude Desktop с подключенными MCP для формирования PRD
Claude Code для основной разработки, планирования спринтов и ведения документации модулей; использовал по максимуму mcp, commands, hooks, subagents
Cursor вместо VSCode, иногда для точечных фиксов и автодополнения
Web Claude, Web GPT для “взгляда со стороны”
В общем, все по лучшим традициям на момент августа 2025. Было невероятно приятно заниматься верхнеуровневым планированием, постоянное ощущение себя “создателем”, а не просто рабочим разрабом. В процессе я даже что-то узнал про Swift. Проект дошел до MVP, имел простую функциональность: добавление/удаление файлов из индекса, автообновление индексов и чанкования в фоне, получение ответа на запрос, исходя из контента чанков.
Я впервые почувствовал, что управляю процессом, а не процесс управляет мной! Любая гипотеза проверялась за минуты, а не за целый вечер. И мне не страшно было ошибиться! Наконец-то я начал мыслить продуктом, а не кодом.
Порог входа в новую технологию стал, казалось, почти нулевым. Я не чувствовал себя джуном в незнакомом стеке. Скорее архитектором, который делегировал всю механическую часть системе. В какой-то момент начало казаться, что годы изучения языков и фреймворков были необязательным этапом.
UI Aналитическая платформа
Это был уже кейс с работы, за несколько дней создал MVP платформу для удобного показа результатов исследований. Заказчики могли по кнопке получать предсказания нескольких моделей и кучу аналитики. Чистый Python, а для UI — всеми нелюбимый streamlit. Деплой был в кластере по сути локально, даже без отдельного пода и сервиса.
Мозг я не напряг вообще ни разу, чувствовал себя дизайнером и волшебником — из ниоткуда появляются работающие кнопки. Баги обнаруживаются и фиксятся быстро агентами-ревьюерами. Мечта.
Что интересно — заказчикам и менеджерам понравилось больше всех. Это был хороший такой “плюсик” в карму, мол, заботишься об удобстве → ускоряешь проверки → экономишь деньги → молодец!
Заказчики видят результат, а не твои внутренние struggles. Демки готовятся раньше, обсуждаются амбициозные планы: докрутить так, добавить это. Все начинают мыслить не задачами, а желаниями.
И в этот момент я решил, что готов делать так всё.
Опыт в работе
Задача была следующая: обучить модель генерации для RAG. Сильно углубляться не буду, но надо было:
собрать, разметить данные и обучить несколько QLoRA-адаптеров моделей-ассессоров
создать методом nucleus sampling много генераций и разметить их моделями-асессорами
отобрать пары и обучить модель генерации через DPO
повторить пункты 2–3 несколько раз
Метод называется RAG-DDR. Сначала все было замечательно, но чем больше разрастался проект…
стоп, он не может написать рабочую параллелизацию? зачем мне
ThreadPoolExecutorесли достаточноasync?эм, а че у меня лосс не падает, “claude find issues” и так уже 5 часов
tensor_parallel=8в vllm не ускорит в 8 раз, клод, не надо меня обманыватьсам пожалуйста оптимизируй параметры, ты же умная модель
почему у меня метод
predictуже в третьем файле? очень надеюсь в этот раз он все правильно нагенерирует, а я пока тикток гляну
Каким-то я раздражительным стал… Мои агенты-ревьюеры и дебаггеры уже 5 часов подряд не помогают, лезть в код? Не хочется. Наверное плохие промпты, пойду их улучшу. И субагентов побольше дам. И токенов еще куплю.
Но ладно, такие проблемы бывают и у простого кодинга. Фух, задача закрыта. Хоть сейчас и 11 часов вечера. Что-то я вымотался, пойду поиграю в доту. Уже нет сил что-то продуктивное делать, всё-таки рабочий день был, я заслужил.
Бухгалтерия вайбкодера
Итак, что мы получаем, если поддаемся вайбу в долгосрочной перспективе.
Дебет
Быстрые гипотезы
Многие гипотезы решаются Claude во временных файлах, что очень удобно и позволяет концентрироваться только на их придумывании. При грамотно спроектированной кодовой базе это действительно сильно ускоряет работу.
Рост насмотренности
Видишь корректное использование незнакомых библиотек, языков, паттернов. В свое время я так познакомился со Swift и научился правильно использовать Pydantic.
Снижение когнитивной нагрузки
Скучная рутина делегируется агентам, освобождая мозг для принятия самых важных решений. Правда есть нюансы, которые обсудим ниже.
Усиление исследовательского мышления
Код перестает быть барьером, ты начинаешь мыслить не “как сделать?”, а “что сделать?”. Это в целом хорошее мышление по жизни, единственный нюанс — иногда оно сопровождается отсутствием сопротивления и дешевому получению желаемого. Но для full-time работы это, кажется, только плюс)
Рост креативности
Возможно мгновенно воплощать гипотезы, UI, тестировать то, до чего раньше руки бы не дошли.
Эйфория от работающего кода
Ты получаешь огромное количество дофамина, когда закрываешь двухдневную задачу двумя промптами.
Кредит
Уменьшение когнитивной выносливости
Пока ты пишешь код сам, ты входишь в режим “потока”. Когда за тебя код пишет Claude — ты в бесконечном ревью. А проверять LLM психологически затратнее, после 4х часов такого ревью ты чувствуешь себя как выжатый лимон. Мозг вынужден переплачивать ресурсами за постоянный контекст-свитчинг между твоей задумкой и генерацией агента. Ты становишься более раздражительным. Ты не чувствуешь, что хорошо поработал и получил ценный опыт сегодня. Ты чувствуешь, что позанимался какой-то херней и тебе повезло, что она сработала правильно. У меня такое ощущение было постоянно на поздних стадиях любого проекта, когда надо было очень аккуратно использовать агентов.
Атрофия problem solving
“Claude, why loss is not converging? fix pls” в какой-то момент настигает любого вайбкодера. Инстинкты инженера понимают, что сейчас надо лезть в формирование сэмплов, искать ошибки в расчете лосса и т. д. Но Claude так много раз тебя выручал, пусть и сейчас сам просмотрит все и найдет. В какой-то момент ты заметишь, что уже месяц не пытался решать сам проблемы в коде. Ты как будто становишься мягче, проблемы самому решать уже труднее и хочется их избегать. Это проявляется и в реальной жизни: решения принимаются быстрее, но поверхностнее. Ты предпочитаешь не сильно себя напрягать, постоянно хочется мгновенную подсказку. Комфорт начинает преобладать над ростом.
Аутсорсинг критического мышления
Пункт тесно связан с предыдущим. Даже в задачах ML возникает соблазн скормить агенту графики обучения и попросить подтюнить гиперпараметры, чтобы метрики были выше. Ты начинаешь просить LLM придумывать гипотезы, а потом просишь их проверять. При этом агент практически всегда бесполезен. Когда нужно локализовать улучшение или проблему — он выдает только похожую на правду гипотезу. Мне это напоминает оправдания, мол, я проверил это и это, ниче не сработало, но я старался. И если ты не садишься самостоятельно выявлять проблемы или улучшать пайплайны — ценность тебя как инженера теряется.
Усиление СДВГ
Пока Claude генерирует тебе очередной шедевр, ты просто вынужден ждать. Но ты ведь эффективная личность, поэтому хочешь максимально продуктивно провести рабочий день, чтобы в следующий раз работы было меньше. Ты переключаешься на другую задачу. А потом обратно, когда Claude закончил. И снова. И снова. Ты делаешь так 5 раз, а потом мозг перегревается. Ты говоришь себе: “ладно, я не Цезарь, мозг у меня однопоточный, поэтому буду выполнять задачки последовательно”. Вкидываешь промпт и сидишь ждешь. Ждать просто так скучно, но и снова перегреться ты не хочешь. Тогда “на помощь” приходят соцсети, рилсы, тиктоки, ютуб. И работа превращается в промпт-скроллинг. Думаю, не надо объяснять, что контекст проекта теряется, раздражительность от багов усиливается, как и усталость от работы. Полноценный Lock In возможен только у вайбкодеров с ютуба, продающих тебе свой же SaaS.
Токсичная креативность
Креативность была плюсом, но она же и минус. LLM — это бесконечный раб, беспрекословно выполняющий любые твои указания. Так почему бы мне не разойтись как следует? Сделаем удобно: по кнопке загрузка данных, по кнопке запуск обучения. Самому было бы тупо лень, но тут такая возможность, нельзя упускать. И ты начинаешь городить абстракции там, где нужен простой скрипт, зато чувствуешь себя создателем. Через день вайб пропадает, а куча переусложненного кода остается. Этот оверинжиниринг мало того, что добавляет тебе сложностей в проекте в будущем, так еще ты тратишь весь свой креативный потенциал на “всем нужные фичи”. А мог бы создать свой блог или написать проект за рамками работы, если уж так хочется повайбить.
Непрогнозируемость
Все твои time estimates превращаются в казино. Когда ты ориентируешься в проекте ты знаешь, что эта задача на 20 минут. В вайбкодинге время становится квантовым. Ты можешь решить задачу одним промптом за 20 секунд, а можешь потратить 5 часов, перезапуская пол проекта, потому что умная LLM не сохранила очевидно нужное поле в одной из начальных таблиц. Иногда это выливается в переработки. Кто бы мог подумать?
Бонус: гемблинг-зависимость
Аналогия тут очень к месту. Результат каждого промпта непредсказуем, мозг каждый раз предвкушает положительный исход. Будто дергаешь за рычаг “однорукого бандита”. И мозг вырабатывает чудовищное количество дофамина. В детали вдаваться не буду, есть отличные лекции Владимира Алипова на ютубе. Но факт остается фактом: вайбкодинг превращает инжиниринг в лудоманию. Ты проигрываешь 5 часов времени, надеясь “отыграться” следующим промптом. И когда получается — ты чувствуешь невероятный кайф, который обычным кодингом уже получить не способен. Ты подсел.
Вайбкодинг — убийство
Итак. Самое опасное в вайбкодинге — не ошибки и не галлюцинации модели. Самое опасное — исчезновение сопротивления.
В обычном кодинге или с AI ассистентом ты сталкиваешься с трением: непонимание, тупики, долгий дебаг, необходимость держать систему в голове. Это неприятно, но именно тогда формируется навык. Когда трение снимается “по умолчанию”, ты начинаешь закрывать задачи быстрее — и расти медленнее. И эту аналогию можно провести и в спорте, и в личной жизни и вообще везде.
Через год такого режима ты внезапно обнаружишь, что стал быстрее принимать решения, но медленнее думать. Парадокс. Твой мозг, который эволюционно был создан для решения сложнейших задач, начинает лениться и требовать мгновенного дофамина от кнопки Enter. Ты становишься “мягким”. Ты останавливаешься в развитии. Хорошо еще, если у тебя был хороший бэкграунд и несколько лет опыта — есть на чем строить.
Рано или поздно ты решаешь вернуться на грешную “невайбовую” землю. Но обнаруживаешь, что все это время ты будто бежал на беговой дорожке: пота много, а дистанция до реальных экспертных знаний сильно не сократилась. Это довольно страшное чувство — понять, что ты не улучшился как инженер. И новую такую же задачку тебе снова придется дотошно объяснять LLM, контролируя каждый шаг, потому что у тебя не появилась нужная экспертиза для ее самостоятельного решения. А была бы — решил бы в 5 раз быстрее, чем ИИ. И без гемблинга.
Я понял, что по кайфу кодинг только MVP, а все за пределами — по прежнему тяжелая работа. Да, легкие вещи сейчас стали доступны всем. Но тяжелые всплывают как сливки. И постепенно это понимают все. Иначе бы 80% стартапов не платили сотни тысяч долларов на чистку вайбкода.
Где неуместно
Везде, где цена ошибки большая.
Это главный принцип. Пожалуйста, не доверяйте агентам написание кода без проверки и кучи тестов в этих сценариях:
будет нагрузка и нужно масштабирование — сразу мимо, LLM с этими задачами справляется хуже всего, проверено лично на практике
продакшен системы — использовать AI в качестве ассистента — да, но не вайбкод; каждое решение надо перепроверять и лучше не делегировать LLM большие куски проекта
длительный проект — лучше потратить в 5 раз больше времени на старте, чем в 15 раз больше через полгода
Кстати, RAG из примера выше не воспроизводился с репозитория. А UI интерфейс выдерживал одновременно только одного пользователя. Но об этом, разумеется, на этапе MVP можно умолчать.
Где уместно
Везде, где цена ошибки маленькая.
Есть места, где повайбкодить можно и часто это упрощает работу:
небольшие пет проекты — особенно круто настраивать сети агентов именно в них, чистая воля воображения; в больших не стоит полностью делегировать свой мозг ИИ
хакатоны / стартапы / кейс MVP на работе — идеальный кейс, отлично подходит под концепцию looks finished; но только если вы будете готовы переписывать все полностью для продолжения
визуал / UI / фронтенд, сайты (с точки зрения MLщика) — ТОЛЬКО для внутреннего пользования
тест гипотез / sql — одноразовые микро скрипты, которые не требуют включения в кодовую базу проекта
работа с данными — единоразово построить графики, посчитать статистики, смерджить, сгруппировать, почистить
тулзы для работы — одна несложная задача, результат предсказуем
Что в итоге? Все-таки писать код?
Нет. В статье шла речь про ВАЙБкодинг, а не про кодинг с ассистентом. AI можно и нужно использовать в работе и ML-инженеру тоже. Надо дробить задачу самому на маленькие атомарные таски и писать их с помощью LLM, но всю картину проекта так или иначе хранить в своей голове, а не в файлах PLAN.md и директории docs/. И все решения принимать самому, даже если не хочется и даже если есть уверенность в том, что агент решит все правильно. Поддашься соблазну — и, как я говорил выше, налог придется заплатить большой.
Вайбкодинг. Нет короткого пути к тяжелой работе.
Комментарии (58)
alexanderniki
07.03.2026 18:10Все начинают мыслить не задачами, а желаниями.
По моему опыту, это начало конца даже самого лучшего и продуманного проекта - превращение его условный в Nero Burning Rom
Dhwtj
07.03.2026 18:10В bloatware скатиться можно если не ставить приоритеты и не ценить минимализм и простоту
iushakov
07.03.2026 18:10Через год такого режима ты внезапно обнаружишь, что стал быстрее принимать решения, но медленнее думать. Парадокс.
Это буквально центральная идея одной широко известной книги: Думай медленно, решай быстро.
Собственно книга про то что думать быстро плохо, потому что это ведет к ошибкам
morowenka Автор
07.03.2026 18:10концепция в книге верная, но кажется у меня она немного в другом ключе)
думать медленно, чтобы проанализировать возможные исходы / обдумать сценарии / потратить много когнитивного ресурса, чтобы сформировать верный путь к решению проблемы - правильно; ты потратил много компьюта на обдумывание и мало на решение
думать медленно, потому что ты привык к мгновенному решению проблем и мозгу просто лень думать, мысли стали более стохастическими и с постоянным желанием какую-то часть решения делегировать LLM - я считаю неправильно; ты тратишь мало копьюта на решение, но и на обдумывание тоже мало, хотя времени потратил много
diffnotes-tech
07.03.2026 18:10бесконечный ревью AI-кода выматывает потому что нет критерия "готово". Если написать тест до промпта - результат бинарный, прошёл или нет. Гемблинг из статьи ровно от этого - неопределённость результата. Убираешь неопределённость тестами и это обычная делегация, не слот-машина
morowenka Автор
07.03.2026 18:10хорошее замечание, я согласен, что парадигма сначала писать тесты, а потом накладывать на них код в вайбкодинге верная
но тут опять подводные
во-первых - тесты писать самому что ли? нет, пусть их ллмка тоже пишет; если их вручную отсматривать и проверять - ок, но это уже выходит за рамки вайбкодинга
во-вторых - не во всех сценариях тесты будто бы уместны; если речь про разработку, то да, написал тест - добавил функцию - проверил; если речь, например, про ML - часто вообще сложно сказать какие тесты писать и на что; я не гуру написания тестов и прибегаю к ним только когда разрабатываю библиотечку/повторяемый код каких-то сложных пайплайнов, и я понимаю, что тесты можно написать на все что угодно; на моей практике в трех командах, что я успел поработать, культуры написания тестов для экспериментов не было ни в одной; и я согласен с этим, разработка станет кратно дольше и запутаннее, потому что много ресерча и ты написал тест -> написал код -> проверил результат -> он тебя не устроил, ты хочешь поменять пайплайн -> меняешь все зависимые тесты, проверяешь чтобы старые тесты не поломались/переписываешь их -> добавляешь новый код
короче не всегда просто убрать неопределенность тестами, но если такая возможность есть в проекте - надо пользоваться
Frisian
07.03.2026 18:10Я не чувствовал себя джуном в незнакомом стеке. Скорее архитектором, который делегировал всю механическую часть системе
Я тоже когда смотрю стримы киберспортсменов, чувствую себя киберстпортсменом...
Простите но что то в вашей логике не сходится, вы с помощью вайбкодинга даже не понимаете что в проекте, вы даже джуном себя не можете ощущать ибо не понимаете как все работает даже на минимальном уровне, вот такие же ощущения что они великие программисты очевидно испытывают те кто на какой нить тильде сделал сайт в два клика, что там под капотом вы не знаете и не понимаете, но вы уже архитектор...
Intelllectual
07.03.2026 18:10Зачем проектировщику-архитектору условной резидентской многоэтажки знать тонкости и детали того как джамшуты будут ложить кирпич и возводить стены? Что то скорее в вашей логике не так.
Задача проектировщика — создать план, чертежи, и делегировать все процессы на исполнительные звенья.
Проектировшик это управленец, менеджер, стратег. Ему не обязательно знать ньюансы. Он ставит задачу и оценивает конечный результат. Процесс не важен.
Frisian
07.03.2026 18:10Да вы все правильно говорите, вот только в случае с вайбкодом, нет ни чертежей, ни планов, ни деталей, у вас именно такие Равшаны и Джамшуты все эти планы и чертежи рисуют, они же тысячи раз по схожим планам дома строили, и никто не проверяет что там внутри и возводят здание, которое рухнет в любой момент!
Intelllectual
07.03.2026 18:10Вы не учитывается стремительно меняющиеся условия.
То что вчера было вайбкодингом, уже сегодня обрастает выверенными методологиями, одна из которых — предварительное формирования проектного чертежа перед реализацией или правкой. Это уже БАЗА к которой интуитивно подкрались вайбкодеры.
Мне хватило меньше года вайбкодинга, чтобы смекнуть, что кодить без плана — значит обрастать огромным техдолгом и стремительно лететь лбом в стену из неожиданного рефакторинга)) Предварительного опыта в разработке не было. Эдакий обречённый вайбдебаг получается в противном случае.
Frisian
07.03.2026 18:10Так у Вас есть план и есть понимание потому что вы программист и знаете как что должно работать? А пару дней назад тут человек писал что у него курсор навайбкодил проект на 200 тысяч строк и 2 крупных комита сделал, хотя в его комментах еще пол месяца назад фраза: "Я вот вообще плохо шарю в самом програмировании" , по факту Равшан с Джамшутом сделал все от проекта до постройки. А он как "архитектор", проверил или внешне совпадает это все с его представлением, а что там внутри? Не забили ли на несущие конструкции? Не построили ли дом в болоте и он уже начал уходить под землю? Вы не можете определить, потому что не понимаете что внутри, у вас от архитектора остается только способность оценить содержимое по обертке!
Что самое поразительное никто не может показать нормальных корректных результатов своего вайбкодинга, которые не очередной пет проект, бессмысленный и беспощадный! Куча рассказов как им агенты накодили приложение которое им уже как два года нужно и на которых у них небыло совершенно времени, но я сильно подозреваю что такие "нужные" были приложения!
morowenka Автор
07.03.2026 18:10Я не беру в расчет тех, кто вообще не разбирается хоть минимально в программировании. Если какой-нибудь менеджер или школьник возьмется вайбкодить что-то сложное, то он практически точно прогорит после MVP. Исключений я не знаю.
У меня есть план, у меня есть смежный опыт и опыт в программировании, у меня есть понимание какая должна быть архитектура. Грубо говоря я сам был Джамшутом на другой стройке много лет, я знаю как строят дома и мне выпала возможность построить свой дом. Чем не архитектор?
> нормальных корректных результатов своего вайбкодинга, которые не очередной пет проектПосыл статьи в частности в том, что таких результатов добиться большим количеством усилий и не получается :). В больших проектах нужно грамотно использовать AI, а не бездумно вайбкодить.
Dhwtj
07.03.2026 18:10предварительное формирования проектного чертежа перед реализацией или правкой
Первоначальный план можно сразу выбрасывать. План это только повод для серьезного разговора. Это дерево проб и решений, откатов назад и переделок
Dhwtj
07.03.2026 18:10Проектировшик это управленец, менеджер, стратег. Ему не обязательно знать ньюансы. Он ставит задачу и оценивает конечный результат. Процесс не важен
Вопрос качества процессов, доверия к ним. Не только локальных, но и сквозных. Архитектор должен знать эти сквозные процессы, а иногда вникать в локальные.
Intelllectual
07.03.2026 18:10По "кредиту" онли факты!
За два года ощутил все перечисленные пункты. Нужна воля, дисциплина и последовательность, чтобы не скатиться в эти пункты. Статья классная, новичкам обязательна к прочтению.
vitalist84
07.03.2026 18:10Я уже долгое время работаю тимлидом и сам редко пишу код. Прочитал статью и вижу, что у меня такие же ощущения от управления командой и проектами как тут у автора от вайбкодинга. Я тоже просматриваю каждый день по много ревью, мне сложно вникать в детали, так как их очень много. Я стараюсь обращать внимание на архитектурные решения, но с каждым годом по мере удаления от программирования это становится труднее. Я больше концентрируюсь продукте и фичах, а не на коде. В этом смысле мои подчиненые выступают в роли таких же агентов как тут описаны. И те же самые плюсы и минусы в моей работе как указаны в статье. В этом смысле ничего нового.
И вот мы снова видим, что агенты претендуют на роли джунов и мидлов.
FixicusMaximus
07.03.2026 18:10Видали таких лидов на проектах. Если при лиде нет техлида, который за порядком следит и по рукам бьет, а иногда и по жопе, то обычно в коде большой кусок грязи и внутри команды разрабы друг в друга какашками кидаются, текучка в таких командах большая, что только усугубляет ситиацию.
vitalist84
07.03.2026 18:10Конечно, этим тоже приходится заниматься. Но так и в этой статье про это пишут тоже самое. Что без надзора все может рухнуть. Я тут вижу полные параллели. А значит люди = агенты. Постепенно математические знаки >, = заменяться на <. Агенты потеснят людей.
OlegZH
07.03.2026 18:10Я стараюсь обращать внимание на архитектурные решения, но с каждым годом по мере удаления от программирования это становится труднее. Я больше концентрируюсь продукте и фичах, а не на коде.
Для преодоления такого явления и существует ротация. Ротация — это когда один и тот же человек в разное время оказывается на различных позициях в одной и той же компании. Иногда следует возвращаться и к написанию программного кода. Да и вчерашний "джун" мог бы побывать в шкуре архитектора, понял бы, насколько это сложно, но и несколько свежих идей подкинул бы. Да и и "эйчару" тоже иногда не помещает окунуться в технический долг, чтобы не спрашивать всякую всячину на собеседованиях.
vitalist84
07.03.2026 18:10Я лишь хотел показать, то что автор считает как огромную проблему при работе с агентами - уже давно существует в мире людей, надо лишь подняться на ступеньку выше обычного разработчика. Тогда выяснится, что приходится заниматься не одной задачей, а все время переключать контекст, в день принимать десятки не связанных мержей. Обсуждать несколько архитектурных решений в разных участках кода каждый день. И это не что-то сверхъестественное и невозможное - а повседневная реальность.
morowenka Автор
07.03.2026 18:10Ключевую вещь вы сказали - что все равно приходится и лиду валидировать выхлоп своих агентов (разрабов). Это уже не вайбкодинг, это грамотное использование инструментов, которое хоть и упрощает жизнь (избавляет от необходимости самому кодить), но все также требует траты большого количества когнитивного ресурса. И от него сложнее убежать, вы же не скажете команде на синке что-нибудь типа "сами спроектируйте", потому что команда воспримет вас как некомпетентного лида, типа какого фига он перекладывает свою работу на нас.
А в контексте взаимодействия с AI возникает возможность и соблазн не тратить этот ресурс, из-за чего возникают проблемы (аутсорсинг проблем ЛЛМ, усиление сдвг, токсичная креативность, получение гемблинг-зависимости итд). Никто же не увидит, как вы говорите своим агентам "сами спроектируйте". А было бы, кстати, интересно провести эксперимент, в котором все запросы к LLM по части кода были бы на таком же уровне открытости, как запросы лида к его команде.vitalist84
07.03.2026 18:10Могу сказать - «сами спроектируйте». Это тоже часть делегирования. Ну или из-за нехватки времени или лени могу упустить важную архитектурную деталь. Через месяц или два эта деталь вылезет, и будет уже восприниматься как техдолг, придется переделывать. Опять таки - люди не гарантия отличного результата.
Frisian
07.03.2026 18:10А потом скажите: я не так задумывал переделайте?)
vitalist84
07.03.2026 18:10Не совсем - «в вашем решении есть такие, такие недостатки, переделывайте». И в моих решениях бывают недостатки тоже, и тоже приходится переделывать. Это только у авторов статей ИИ ошибается, а люди никогда)
Frisian
07.03.2026 18:10Есть небольшое но, ИИ агенты которые претендуют на эту роль генерируют огромные объемы кода, проверить его будет намного сложнее и дольше!
vitalist84
07.03.2026 18:10Это ставит вопрос о автоматизации ревью и проверок работоспособности продукта.
MVMmaksM
07.03.2026 18:10И вот мы снова видим, что агенты претендуют на роли джунов и мидлов.
Заменили уже? Как успехи? Не забудьте только агентов распределить по грейдам, чтобы они учились, росли и т.д. а то спустя какое-то время у вас синьоров не будет. Еще научите агентов брать на себя ответственность за код
DmitryOlkhovoi
07.03.2026 18:10Это все индивидуально. Есть вещи которые за годы надоедают. Типо за 15+ лет уже порешал, понаписывал многое, и делать очередную кнопку уже чисто физическая активность. Я как бы вижу решение и знаю результат, пропадает интерес и отсюда некая лень, не желание нажимать на кнопки. А бывает когда прям хочется и понажимать.
Dhwtj
07.03.2026 18:10всю картину проекта так или иначе хранить в своей голове
Да, это ключевое.
В результате быстрее разработка то стала? Какие-то метрики улучшились?
morowenka Автор
07.03.2026 18:10Я постепенно ухожу от концепции вайбкодинга в работе к использованию AI как ассистента, проверяя за ним основные шаги. Описанные минусы при этом все еще проявляются, процесс избавления от плохих паттернов делегации небыстрый.
В таком подходе быстрее стала однозначно, думаю в разы, метрик нет, а какие тут нужны?Dhwtj
07.03.2026 18:10У меня повышение производительности максимум +50%, причём достиг этого полгода назад и все новое уже не помогает.
Легаси-с.
Вернее, долгоживущие системы. 15 лет системе.
appet1te
07.03.2026 18:10Иван Петрович Павлов в своем труде «рефлекс свободы» описывал также инстинкт цели(он все подряд называл инстинктами). И также говорил что инстинкт цели лучше всего развит у англичан. И что для его наличия, усиления и развития необходима трудность.
Возможно от этого такие длиннопосты в англоязычном интернете мол, дарк соулс вернул меня к жизни и т.д.
Daddy_Cool
07.03.2026 18:10А вот и деформация меня как хабрачитателя. После первого абзаца сразу иду в конец статьи и в комменты - а то вдруг я читаю нейрослоп.
О, дивный новый мир!morowenka Автор
07.03.2026 18:10я просто вырезал из статьи "хочешь я сгенерирую еще 5 более убедительных аргументов?")))
Sanitir
07.03.2026 18:10Статью плюсанул, но выводы что LLM и хайлоад несовместимы в корне неверные.
Мне LLM и ускоряло запросы в разы (да, из 2-3 рекомендаций часть как будто спорных, но некоторые прям в точку) и с эксплуатацией сильно помогает, ну там "эластиксёрч тормозит, где смотреть, что крутить" - советы часто синтаксически устаревшие, но практически всегда сильные и соответствовали выжимке из "сидеть и несколько дней доки шерстить"
А код за меня писать я как раз практически не прошу, не нравится почти всё.
morowenka Автор
07.03.2026 18:10Совместимы, но надо контролировать и хорошо самому понимать как должно произойти улучшение скорости/памяти - а это уже не вайб)
Было много ситуаций разных из последнего - (пишу на python) была написана параллелизация, в которой создавались сразу все задачи иmax_workersбыл большой, в результате чего в event loop оказывалось с течением времени огромное количество pending корутин. Это увеличило потребление памяти из-за чего через два часа работы скрипта выполнение стало просто медленнее, чем без такой параллелизации.Писал бы я сам и сразу бы нашел узкое место, поэтому сейчас я заранее знаю какое масштабирование и как мне надо провести и целенаправленно прошу LLM сделать конкретные операции.
zeuver
07.03.2026 18:10Вот пишу этот коммент и думаю: "А может мне закинуть статью в промт и спросить у ллм, какой коммент сюда написать?"
Как же это жизненно..morowenka Автор
07.03.2026 18:10прочитал коммент и подумал: "что мне на него ответить? может закинуть его со статьей в промпт и спросить у ллм?"
LeVoN_CCCP
07.03.2026 18:10тест гипотез / sql — одноразовые микро скрипты, которые не требуют включения в кодовую базу проекта
Привет от скл буквально двухдневной давности, коллеге дал умное слово для поиска и анализа решения проблемы. Он загнал его в ИИ, получил ответ, сделал, ребутнули сервер и ... он не поднялся, благо админ не спал вечером в выходной. А потому повторюсь скл это то, что работает с данными, не надо туда ИИ. Вообще никак даже если очень хочется и думаешь оно быстро. Быстро - написать самому, даже если будет выполняться долго, результат будет предсказуем.
цена ошибки маленькая.
работа с даннымиА потому я с этим не соглашусь вообще никак. Код можно восстановить/написать заново (с нуля без бекапов), данные заново сделать шансы намного меньше (с нуля без бекапов).
morowenka Автор
07.03.2026 18:10Ключевое, что цена ошибки маленькая. Поэтому данные я имел в виду какие-то промежуточные/локальные. Но если ты их собирал месяц, то даже у локальных цена ошибки будет большой - значит надо осторожно, создавать вайтлист операций. В контексте взаимодействия с продовыми БД - никакого CRUD, только R (чтение), у меня стоит whitelist команд, поэтому на теории ничего не может сломаться.
При этом это все еще останется вайбкодингом, просто связанным по рукам и ногам.LeVoN_CCCP
07.03.2026 18:10Read в прод для девелоперов нуууу ... нет. Хотя может я испорчен всякими банками и конфедициальными данными. Whitelist команд, ну наверное можно, только кто будет в энциклопедии Юнлэ искать можно ли сделать что хочешь или нет, особенно когда дев не у каждого на машине или например стейдж тестовые проглядеть почему ошибка возникает ... более двух комманд (разработчиков) на связанных таблицах.
Если человек продолжает настаивать, то я ... соглашусь - конечно же вайбкодите скл. благодаря этому у меня будет работа и цена её если и изменится, то не в меньшую сторону. Я смогу разобрать Авгиевы конюшни и объяснить, что было не так. Хотя объяснение не понадобится, потому что какая разница что не понимал до не будешь понимать и после.
jaqjaq
07.03.2026 18:10Интересно уже были практики токенизировать затраченные усилия сотрудника-человека на решение задачи с приведением к общей шкале с тем же Claude Sonnet 4.6 и последующим переводом в твердую валюту?
ThisMan
Ловлю себя на мысли и действительно пытаюсь этому сопротивляться, что теперь уже даже не хочется тратить время на промты. Хочется просто все и сразу, чтобы модель сделала как надо с одной фразы
Задачи, попытки, ошибки переместились в другую плоскость, но все равно остались и это не дает стать настоящим "волшебником"
morowenka Автор
полностью понимаю
я тоже сопротивляюсь и стараюсь всегда потратить время на объяснения, но каждый раз в какой-то момент я сажусь за код уже уставший и раздраженный и меньше всего мне хочется распинаться в промптах; и это всегда отправная точка, причем она особенно страшна, если модель корректно решила задачу - планка допустимого уровня раздраженности и усталости, при котором ты еще готов распинаться, опускается, и в следующий раз будет еще больше хотеться просто написать "implement this. make no mistakes"
кажется, в такой момент лучшее решение это отложить код и пойти прогуляться (если, конечно, не каждый день это такие моменты..)