Comments 58
Пожалуй, соглашусь, но с оговоркой.
Из LLM-моделей - Claude Sonnet 4.6, немного Claude Opus 4.6, и Qwen 3.5-397B.
По моему субъективному опыту, выбор модели сильно влияет на результат. Использование последних выпусков Opus сократило бы необходимое количество дебагов по сравнению с Sonnet.
Но полностью не исключило бы ошибки 100%.
Claude Code действительно пишет Next как-то через жопу. На Opus 4.8 с high effort вроде нормально, а 4.7 обе модели - стабильно как минимум 1 ошибка из-за которой стейджинг\прод упадет. GPT5.5 на high в этом плане лучше - ни разу за месяц не было регрессий. Мог что-то не так понять или не доделать, но все работало.
В итоге для себя решил Opus для планирования и реально тяжелых задач, типа reverse engineering, Codex для работы по планам Opus-а и прочей мелочи типа отцентровать div.
Одна из причин почему LLM многословен:
Он не знает, какие данные придут (хотя вы знаете), в месте обработки поставит много защитного кода (хотя это вы должны были создать типы чтобы невалидные данные были невозможны). Тогда в любом случае код не упадет.
Проблема ещё в том, что он не знает куда кидать ошибку (а это вы должны были позаботиться чтобы создать типы исключений или кодов возврата ошибок), поэтому молча её поглотит и не предупредит (а это вы должны были решить допустимо это мои надо падать и надо ли логировать)
LLM склонен к catch-and-swallow, потому что его цель "чтобы прошло/скомпилировалось", а не "чтобы упало громко при нарушении инварианта". Ну так вы должны были его предупредить что сверху кто-то ловит и исключения кидать можно. Ещё сильнее: дать ему как именно кидать тип ошибки (Result<T,Error> или конкретные exception-типы), тогда у него появляется куда кидать и он перестаёт импровизировать
хотя это вы должны были создать типы чтобы невалидные данные были невозможны
вы должны были позаботиться чтобы создать типы исключений или кодов возврата ошибок
Выходит, что на плечи агента можно возложить в основном только написание конкретной бизнес-логики, когда всё "окружение" для новой фичи в виде DTO, исключений, REST-клиентов, JMS-слушателей и проч. уже написано?
А может, он просто обучен на худших решениях с stackoverflow?
в месте обработки поставит много защитного кода
а вы лично хоть раз агента пользовали или только по телевизору смотрели?
гарантированная проблема всего сгенерированного кода это ужасная обработка ошибок и граничных условий.
а многословен он потому, что генерит все "как есть" даже не пытаясь "вспомнить", что секунду назад он генерировать метод, который почти полностью совпадает с текущим, и поэтому общее тело надо выделить в отдельный метод и переиспользовать.
Стандартная выработка программиста - две тысячи строк в неделю. Стандартная выработка вайбкодера - шестьдесят тысяч строк в неделю. При таких масштабах сама идея прочитать код написанный сеткой попахивает безумием. Не вы первый, кто заметил, что стратегия эта не работает.
Вайбкодинг это вообще отдельная история. Мне кажется, там пытаться что-то понять вообще не имеет смысла, если проект хоть сколько-нибудь большой, так как все изменения делались человеком, который в принципе не имеет каких-либо знаний и экспертизы, вследствие чего и способности определить правильность написанного кода. При попытке ревьюить такое количество нейрокода, который не подвергся хотя бы первичной валидации тем, кто его генерировал, есть риск получить психическую травму :)
Думаю, в данном случае уместнее сравнивать выработку обладающего квалификацией инженера с использованием агента и без него.
Vibe code, ai assistant programming, ai agentic enginering... Какая разница, как это называть. Вы не сможете нормально пользоваться нейросетями при разработке, пока не научитесь проверять код не читая его.
Научите надёжно проверять код не читая его.
Вот как раз статью готовлю. Думаю, сегодня уже будет ближе к вечеру
Тегни меня в ответ, я прочитаю
Не понял, где тегать. В любом случае, вот: https://habr.com/ru/articles/1043842/
Вот так @netricks
А технически вообще возможно "проверять код не читая его"? Понятно, что есть всякие линтеры, анализаторы и прочие инструменты.
Но есть же ещё "насмотренность", когда опытный глаз видит в коде что-то не то. И иногда можно долго копать, прежде чем сознание поймёт, что именно "не то" угляделось и к каким конкретным ошибкам может приводить.
А если вместо органических нейросетей применять электронные, то не получится ли так, что описание логики работы и контрактов, достаточное для адекватной работы LLM, будет практически не отличимо по потраченному времени и ресурсам от написанного вручную кода?
Стандартная выработка вайбкодера - шестьдесят тысяч строк в неделю
6 дней в неделю по 10 kloc?
Мсье явно уже встречал такую дичь в реале
Стандартная выработка вайбкодера - шестьдесят тысяч строк в неделю
"Стандартная" как бы намекает, что есть какая-то статистика по вайбкодингу. Или судите больше по себе? Кто имеется в виду под вайбкодером - опытный программист, начинающий или не-программист? И что можно сказать о "стандартном" качестве такого кода?
Да. Статистика есть. Она, конечна, взята по полутора калекам, но вряд ли мы с коллегами сильно отличаемся от общечеловеческой массы. Число в 60 тысяч плюс минус трамвайная остановка упорно повторяется. Я бы сказал, что моя рабочая оценка.
Нет, не новички. Вообще ни разу не новички. Качество разное. Тут надо понимать, что большая часть этих шестидесяти тысяч уходит не на написание нового кода, а на переписывание старого. По мере переписывания качество подтягивается.
Ну, а в целом, моя статья по вайбкодерским практикам уже почти вот-вот.
Если у вас вайбкодер генерит по 60к строк, значит у вас нет нормального код-ревью и CI/CD пайплайнов с жесткими лимитами на покрытие тестами и цикломатическую сложность
У меня две $20-подписки Codex, у которых использую все лимиты под ноль для двух backend+frontend проектов на TypeScript. Получается до 15к строк в неделю кода, включая тесты и доки. Все доки читаю, код читаю по диагонали и интересные части. Обычно трачу всю недельную квоту за 2 дня, а в остальное время изучаю, тестирую более внимательно и делаю огромный коммит, где всё понамешано. Пока это не прод и проекты полностью мои.
Код наверное в 2 раза более многословный, но при этом есть возможность оптимизировать горячие места типа размера собранного бандла, кеширования в браузере и т.п., где руками пришлось бы долго экспериментировать и анализировать, а тут агент всё за меня сделал.
Также могу легко вылизывать UX, делая всяких плюшки, до которых руки бы вообще не дошли: индикация прогресса, кастомные компоненты и т.п..
А на работе C++, там пока до активного ИИ не созрел кроме как сгенерировать класс и потом детально его изучить и отредактировать руками. Ну и баги агенты помогают искать. В текущих задачах слишком много нюансов качества кода, производительности и управления памяти, которые я не готов доверить агентам. Но после этих задач может и буду использовать ИИ-код активнее в задачах попроще.
Я вот активнее всего использую ИИ для анализа кода, анализа текстов, анализа логов, и ещё для саммаризации изменений во время ревью пул реквестов. И ещё для поиска и разборов информации.
И вот это жизнь куда больше упрощает, чем вайбкодинг. В плане написания кода я ИИ доверяю лишь рефакторинг и то очень понятный и дописание тестов по примеру.
Ну и документацию, потому что лучше такая дока чем вообще никакая.
Сейчас они реально полезны только как инструмент для ускорения рутинных задач. Но в задачах со строгими архитектурными ограничениями они часто увеличивают общий объём работы, генерируют избыточный, нестандартный или потенциально некорректный код, который потом нужно тщательно вычищать и перепроверять. По факту происходит не снижение когнитивной нагрузки, а её перераспределение, с написания кода на его ревью и контроль качества, причём часто с ростом затрат. Поэтому твой вывод корректный, сегодня ИИ это не замена разработчика, а инструмент с высоким риском и неоднородной выгодой, эффективность которого сильно зависит от типа задачи и зрелости процесса разработки.
Странное заявление про детерминированный результат от человека. Неужели вот прям действительно каждый раз реализацию делаете одними и теми же методами? Никакого развития и повых методов, копипаста одного и того же? У меня часто бывает пока какой-то незначительный баг копаю находится повод поразмыслить а не переписать ли ещё половину системы чтобы лучше работало.
Статистика говорит, что розгами и плетью от джунов можно добиться больше дисциплины, чем от LLM
Возможно, я не до конца раскрыл мысль про более детерминированный результат от человека.
Когда я пишу/изучаю код, пытаюсь поймать и пофиксить баг, делаю рефакторинг и проч., я произвожу действия частично или полностью с осмыслением того, что я делаю, т.е. с учётом архитектуры проекта, технических и бизнесовых ограничений и ньюансов, здравого смысла, последствий от одного, казалось бы, маленького изменения, и так далее. В случае генерации кода агентом, у меня сложилось впечатление, что ЛЛМ ничем подобным не руководствуется или руководствуется частично, упуская те или иные ньюансы, из-за чего даже валидное на первый взгляд решение на самом деле может таковым не являться.
Детерминированность тут означает, что человек понимает, что и зачем он пишет. Он может обосновать каждое архитектурное решение. А сетка просто подставляет статистически наиболее вероятный токен
Интересно, что да - вот я хоть и занимаюсь сетками профессионально, а на практике скорее склонен кинуть конкретную задачу в чат по конкретному куску кода, нежели использовать агентов (агенты как-то пока не прижились).
По конкретному куску кода отвечает и переписывает хорошо.
Но непредсказуемость сама по себе создаёт дополнительную когнитивную нагрузку,
А кому щас легко?
Попробуйте нормальный Claude Code и нормальный стек технологий и ЯП.
Автор прав в главном - когнитивная нагрузка при чтении чужого кода всегда выше, чем при написании своего. И неважно кто его писал, ИИ или коллега из соседнего отдела
Проблема в том, что доведение сгенерированного кода до качества, соответствующего уровню продуктивного контура, занимает ничуть не меньше, а иногда и намного больше времени, чем если бы код писался руками.
Есть выход - отделить архитектуру от реализации. Чел. отвечает за контракты, за архитектуру - и даже не заглядывает что там за страх оно нагенерило. Начнешь заглядывать и делать правильно - весь буст так называемый сойдет на нет.
При таком подходе использование ИИ допустимо только в MVP-решениях и относительно простых проектах, не претендующих на что-то значимое. В "серьёзных" продуктах, такой код просто не пройдёт по критериям безопасности, производительности, uptime, стабильности, поддерживаемости и расширяемости и т.д.
допустимо только в MVP-решениях и относительно простых проектах, не претендующих на что-то значимое
Ваша правда. Для внутренних утилит или скриптов, с легко проверяемым поведением, для MVP-проектов (проверка идеи). Т.е. когда есть четкий API (задан человеком) и критерии приемки, полное прокрытие поведения тестами (тесты дергают API и происходит то что задумано).
Когда нужно качество (быть лучше других, а не просто работать), поддерживаемый код - то надежнее и быстрее руками.
Но! Многие пока об этом не знают, LLM-ки начали активно использовать сравнительно недавно, а некоторые даже не начинали. Пока есть вера в чудо...
К сожалению, LLM - это именно что “T9 на стероидах”. Они обучаются буквально в виде “продолжи текст”. Это практически чудо, что они просто в состоянии поддерживать беседу. Причем неплохо поддерживать.
То, что LLM “знает” как правильно писать код, может объяснить код - ни разу не значит, что она эти знания применяет при написании кода. Это просто разные навыки у LLM. Размышления помогают, но размышления, зачастую, это просто “набросать в контекст по теме”. Да, это дает значительный буст. Но мыслить модель от этого не стала.
Но LLM пришли, показали неплохие результаты, в том числе и в кодинге. Причем даже локальные модели. И они с нами надолго - если не на всегда, то точно до момента, когда изобретут что-нибудь более продвинутое.
меня бесит их фундаментальное качество - недетерменированность результата.
В смысле, Вы ожидали от недетерменированного механизма детерминированного поведения?
Spec-Driven-Development + Skills = ok
Архитектура теперь критически важна, и ее нужно знать, а часы написания кода можно свалить на LLM.
LLM и не может пока с полуслова понимать, что Вы хотите, иначе Вас бы давно уволили. Было бы это лучше или нет?
Думается, что все претензии из-за неумения ставить задачу нейронкам. Не нравятся полотна кода? Просите сети делать максимально компактный код. Получается неоптимально по скорости? Просите делать оптимально. Это не 'высосано из пальца'. Это реальные рекомендации по сотням чат-сессий.
Ну и да, актуальные LLM'ки фундаментально недетерминированные. Ожидать от них противного не стоит.
В любом случае буквально всегда есть вариант: не нравится - не используйте.
Есть один знакомый. На волне хайпа IT пытался вайтивайти, донимал разными вопросами с чего начать и как получать 400К денег в секунду, желательно ничего не изучая. ЯП с их дурацким синтаксисом у него вызывали головную боль и депрессию. Не вкатился, естественно.. Недавно звонил и спрашивал что делать если ИИ как-то не так прикрутило оплату к сайту заказчика, он ему уже и так и эдак давал задание, но тот что-то криво прикручивает.. Чувак вайбкодит вообще не отдупляя что там под капотом. Я знатно охренел.. но видимо это и есть оно, наше будущее, неизвестно что нагенерированное по требованию макаки вайбкодера, как-то там вроде работающее..
Мне наоборот кажется, что ИИ разгрузил мне мозг и помог искоренить прокрастинацию. Раньше было сложно сесть за работу и решение задач, а теперь легко, можно начать с вопроса или дачи задачи агенту. Разгребать то, что он написал, тоже проще, чем своё придумывать, если не пытаться понять всё досконально и сразу как он сгенерировал, а только после тестирований и исправлений проверять важные моменты. Их тоже можно у агента спрашивать.
В итоге я за компом 10 часов в сутки 7 дней в неделю что-то разрабатываю, потому что процесс затягивает. Руками я в 5 раз медленнее бы двигался и не мог бы проводить столько времени за разработкой.
надо просто понимать ограничения технологии и просчитывать, что можно делегировать и выиграть в итоге по времени, а что будет пустой тратой сил и токенов. всегда есть куча рутины, с которой агенты вполне себе справляются.
Недавно иначе взглянул на тезис "Достаточно подробная спецификация — это код". Не как повод похоливарить, а представить код работающего проекта, в качестве этой спецификации. Вместо ее описания на естественном языке. Куда уж подробнее.
Сетка должна уметь написать код на целевом языке, с учетом его практик и концепций. Показать свой действительный уровень. И это не просто показатель уровня, а полезность в рефакторинге и переносе прототипов в другую среду.
Вот только что бы написать такую спецификацию нужно быть самому в контексте.
Приведу цитату:
Отдельно Хайтауэр предупреждает об опасности бездумной генерации. Он вспоминает старую формулу "писать — значит думать": когда инженер пишет код сам и медленно, он спотыкается о собственные ошибки, понимает, что выбрал не ту структуру данных или что архитектура трещит по швам. ИИ выдает тонны готового кода за секунды, разработчик радостно отправляет его в прод, пропуская этап мысленной валидации, — и так плодится высокоскоростной технический долг".
Как правило разработка ведётся в контексте какой то предметной области. Причем ТЗ/ФТ пишут обычные люди. Я 25 лет занимаюсь разработкой и ещё не встречал "идеальной спецификации".
Как правило в процессе разработки все документы корректируются, уточняются. Часто приходит понимание что лучше сейчас изменить архитектуру чем спустя 3 релиза.
У всех по разному но я например активно участвую в встречах аналитиками где обсуждается спецификация. Но если я перестану писать код то я быстро потеряю контекст.
Проблема даже хороших инструментов (моделей) в том что они дают то что ты просишь а не то что тебе нужно.
Банально, потому что до разработки ты знаешь чего ты хочешь, но ещё не знаешь что тебе нужно.
Даже казалось бы элементарные задачи опасно делегировать. Недавно была задача загрузить файл в систему, идеальный кандидат на работу ИИ, но закончились лимиты и делал сам, в итоге обратил внимание что в задаче описан поиск договора, но при этом пропущена часть о доп. соглашении и в тестовых данных нет так как этот функционал только что вошёл в релиз.
На вайбкоде я бы это пропустил и потом бы пришлось править ошибки. Так как я делал сам то я обратил внимание на это, сообщил аналитику и они доработали требование.
Хотя конечно я часто использую ИИ но как правило для review когда уже MVP написан, задачу я понял, и дальше просто скучная рутина (потому и месячная подписка улетает за неделю).
Ещё классно писать модульные тесты, это как новый фреймворк который может изучить код и предложить варианты тестовых данных.
Но именно режим вайбкодинга это 100% смерть продукта и проекта. Это как обосраться в мороз, первое время тепло.
Абсолютно соглашусь с тем, что нервная нагрузка и усталость от вайбкодинга - сильно повышенная.
Я провел эксперимент над собой - смогу ли я полностью бесплатными нейросетями навайбкодить себе замену Asana, а точнее - по сути свой чат, замену Телеграму (но мессенджер с привязкой в неким задачам).
При том, что знаний в этих web-технологиях всех, наверное не больше 10%.
Столкнулся с тем, что плохо спал все эти три недели эксперимента - гонка за получением правильного результата от нейросетки и бесит и приносит удовлетворение от победы одновременно.
Но устаешь неимоверно, и матерится стал впятеро чаще. Больше такой опыт повторять не хочется.
Хотя результата я достиг, за три недели наваял в одного полностью бесплатно систему, в которой уже 37+ тысяч (!) строк (PHP + MariaDB + Javascript (который я уже возненавидел)).
Если кому-то интересен такой личный таск-мессенджер - обращайтесь.
https://pmaker.ru/задачат_функционал/
старался описывать задачи подробно, добавлял контекст, объяснял не только что нужно сделать, но и как.
Замечу, что на формулирование и написание детализированного промпта для получения мало-мальски приемлемого результата уходило немало времени - иногда сопоставимо с тем, чтобы написать код самому.
Да, есть такое..
Меня бесит использование ИИ в разработке. И я наконец понял почему