Комментарии 125
Ага, я бы еще добавил в рекомендации: если планируешь написать большую часть кода целиком с помощью нейронки, сначала обсуди с ней архитектурные решения, попроси ее описать алгоритм (желательно, конечно, описать самому и потом убедиться, что она правильно поняла), и только после этого пробуй компилировать / запускать.
сначала обсуди с ней архитектурные решения, попроси ее описать алгоритм
Не помогает особо.
Документировать каждое решение, которое ты держал бы в голове утомительно.
А вот осознанные приёмы из структурного программирования и итерационного уточнения задач помогают. Top down with stubs, например. Или/и TDD. Любого программиста на собеседовании за такое похвалят.
Именно! Top-down, заглушки — по своей сути являются формами декомпозиции, и работают гораздо лучше. Они создают каркас, в который можно вставлять и проверять небольшие, сгенерированные LLM, части.
Форм декомпозиции много
Есть ещё прототипирование, итеративная и инкрементная разработка.
Они все придуманы для борьбы со сложностью, чтобы в контекстное окно человека или LLM влезал нужный кусок задачи и контекст.
Но из них для top down with stubs нужны самые минимальные усилия по документированию и восстановлению контекста
Помогает умение разбивать большие или сложные задачи на более мелкие, управляемые и однозначно формулируемые подзадачи, подходящие для генерации с помощью LLM. Это отличается от классической декомпозиции: при разбиении задачи ты не только думаешь о логических границах, но и о том, как "упаковать" каждую подзадачу так, чтобы она была самодостаточной для модели.
Вайб-кодинг опасен при отсутствии системности и методологий.
Человек должен описать бизнес-требования и создать ВСЕ тестовые сценарии, чтобы AI генерировал код, соответствующий ожиданиям.
Важен и нисходящий подход и качественная декомпозиция, начиная с высокого уровня проектирования.
Фреймворки для организации такого подхода уже есть.
Нам остается менять подход от Программист к Проектировщик.
Пытаться заставить LLM "написать большую часть кода целиком" — это часто попытка использовать инструмент не по назначению. Гораздо эффективнее использовать LLM для ускорения реализации хорошо декомпозированных подзадач, где человек отвечает за общую структуру и интеграцию, а LLM помогает с написанием конкретных блоков в четко заданных рамках и контексте.
Маленькую, четко очерченную задачу гораздо проще сформулировать в промпте так, чтобы минимизировать неоднозначность. Для большой и сложной задачи даже детальное ТЗ или обсуждение архитектуры оставляет много пространства для неверного толкования LLM.
И еще один момент: проверять маленький кусок кода проще, чем разбирать монолит. Когда ты видишь 500-1000 строк сгенерированного кода, велик соблазн сказать "ну, вроде норм" (привет, вайб-кодинг).
На моем опыте в арихтектуру нейронки не умеют. Сгенерить идей каких-то разрозненных пойдет. Но выстроить арихтектуру, даже не очень большого приложения, пока не могут.
Писать код, отчасти используя ИИ - это как сшивать несколько кусочков ткани.
Вроде и держится, но рано или поздно оно всё равно пойдёт по швам
Если мне надо совместить несколько быстро меняющихся нестандартизованных api, то там и без ИИ все быстро пойдёт по швам. Но сказать кому-то "не меняйте не хочу" не выйдет.
Не весь код с ИИ "рвётся". Дело не в ИИ, а в навыке. Выбираешь правильную модель, осознанно формулируешь задачу, даёшь качественный контекст, проверяешь каждую строку — и ничего не трещит по швам. Шей с умом — и будет держаться.
Ну да, конечно в любом "косяке" ИИ можно обвинить кривой промпт и катнуть бочку на разработчика, потому что такой аргумент довольно железный и довольно сложно доказать обратное)
Да, LLM сама по себе не идеальна (вероятностный инструмент) и может ошибаться даже при хорошем запросе. Доказать обратное в каждом конкретном случае сложно, вы правы.
Но практический опыт показывает прямую и сильную корреляцию между качеством входных данных (промпт, контекст, декомпозиция) и качеством результата LLM.
Независимо от того, чей "косяк" в конкретном случае, единственный способ для разработчика повлиять на результат — это улучшать свои входные данные (промпт, контекст) и процесс взаимодействия (декомпозиция, итерации, проверка).
А чем это принципиально отличается от ситуации, когда над проектом работают несколько разработчиков? Конечно, рано или поздно будут баги. И в какой-то момент кодовая база может превратиться в месиво, которое проще выкинуть и переписать. Это все и до LLM было
LLM-долг не лучше и не хуже человеческого — он другой. LLM пишет очень правдоподобный, но вероятностный, часто "почти правильный" код. LLM-долг менее очевидный на первый взгляд. Не хуже, не страшнее. Просто требует новой оптики, чутья на LLM-кривизну.
У LLM-долга есть особая форма — контекстный инцест:
LLM генерирует код с незамеченным, коварным дефектом (LLM-долг).
Этот код проходит ревью (из-за своей правдоподобности) и попадает в основную кодовую базу.
При работе над связанной функциональностью разработчик (или другой разработчик, или даже сам ИИ в будущем) использует этот уже дефектный код как контекст для нового промпта к LLM.
LLM, видя дефектный код в качестве "примера" или "окружения", с высокой вероятностью воспроизведет ту же ошибочную логику или паттерн или построит новую логику поверх ошибочного фундамента, считая его правильным. LLM не просто копирует ошибку — она творчески её развивает. Новые варианты старого бага сложнее отследить.
Каждый новый заражённый фрагмент становится донором контекста для будущих генераций. Один дефект порождает десять, те — сотню.
LLM генерируют код гораздо быстрее человека. Если этот механизм "контекстного инцеста" запущен, он может распространять дефекты по кодовой базе со скоростью, недоступной при чисто ручном копировании или наследовании ошибок человеком.
Это почему у вас старый код превратился в требования к новому коду?
А можно пример подобного? Сталкивался с обратной ситуацией, когда ИИ в качестве контекста давался сгенеоенный код, и ИИ писал, что в этом коде заметил ошибку.
Замечу, что это были эксперименты и прототипирование. Для прода надо стопроцентно понимать, как и что работает.
Разница в назначении контекста:
Контекст для оценки: "вот что есть, что с этим не так?" → LLM ищет проблему.
Контекст как пример: "вот как мы делаем X, сделай Y" → LLM воспринимает код как правильный образец и тиражирует проблемы.
В вашем случае LLM работала в режиме критика — вы, вероятно, не просили "сделай как здесь", а скорее писали "что с этим не так?".
Человек тоже может посадить какой-то неочевидный баг. А потом этот код может скопипастить другой человек. Проблема не нова.
Интересно, что значит "незамеченный коварный дефект"? "правдоподобный код"? Вокруг нас какая то невидимая магия или точная инженерия? Если вы упускайте "коварные дефекты" или "правдоподобный код" (я до сих не понял смысл этих слов), значит вы сами не до конца понимаете контекста? Каждая строка кода должна быть проверена, до того как она попадет в основную кодовую базу. Если в каком то месте происходит какая то непонятная хрень, то нужно ее переписывать на очевидную и тестируемую хрень или забить болт и кликать на Аппрув?
Никакой "магии" тут нет, и конечная ответственность за код, попадающий в main, всегда лежит на человеке.
Идеальный процесс ("каждая строка проверена") сталкивается с реальностью: объем и скорость генерации LLM могут создавать повышенную нагрузку на ревьюера, увеличивая риск пропуска именно неочевидных ошибок в правдоподобном коде.
LLM могут генерировать код, который выглядит структурно и синтаксически безупречно, но содержит тонкие логические ошибки, связанные с неполным "пониманием" контекста или статистической природой генерации. Это отличается от типичных человеческих ошибок, которые часто более очевидны.
"Правдоподобный код" (в контексте LLM) — имеется в виду код, который выглядит логично и чисто, НО при этом может содержать неочевидные логические ошибки, упускать важные краевые случаи, не полностью соответствовать специфическим требованиям проекта (если они не были идеально переданы в контексте) или иметь скрытые проблемы с производительностью/безопасностью. Он хорошо мимикрирует под качественный код.
"Незамеченный коварный дефект" — это ошибка, которая не видна при поверхностном ревью из-за "правдоподобности" окружающего кода. Часто связана не с синтаксисом, а с логикой, обработкой состояний, краевыми случаями или неверной интерпретацией контекста моделью. Может проявиться только при определенных условиях в runtime. Ее "коварство" в том, что она прячется за фасадом формально качественного кода.
LLM строят код на статистике, а не на семантическом понимании. Это повышает вероятность именно таких "почти правильных", но логически неверных в нюансах конструкций.
Если в каком то месте происходит какая то непонятная хрень, то нужно ее переписывать на очевидную и тестируемую хрень или забить болт и кликать на Аппрув?
Есть промежуточные состояния и разные уровни уверенности/риска.
Не дай Бог, Боинг начнет рано или поздно код на ИИ писать))
А вы думаете там какие-то уникальные программисты работают? Если говорить про российские реалии, то з/п разработчиков в банках в разы превышают з/п тех кто работает с реальными железками. Контракты на проекты составляются так, что если не укладываешься в сроки (зачастую заниженные), то платишь штрафы. Это все не способствует более качественному коду на производстве.
А надо еще учесть, что ближе к железкам используется языки более низкого уровня, где выстрелить себе в ногу проще простого. Железки сложнее тестировать чем обычное ПО, зачастую там нет тех отделов QA, к которым привыкли в enterprise разработке. Но зато там в целом отрасль и люди более консервативные, до них вайб кодинг дойдет с запозданием лет на 5, за это время он станет получше.
Рано точно не начнёт, не переживайте.
Так у них и без ИИ было всё плохо.
Помните примерно в 2017-2019 737MAX8 по всму миру падали? Это делала MCAS — их новая система очередного "улучшения", которая даже в железе была спроектирована без учета контекста — типичный ИИ-подход...
Судя по результатам опроса вопрос копирайта уже решен или стандартом кодинга стало заливание на прод всего подряд не взирая на юридические риски.
ИИ стал частью нашей работы
Офф: Хабр такой Хабр.... 90% комментаторов истошно кричат, что никакой ИИ не заменит программистов, но 90% новостей на этом сайте - про ИИ.
Ты работаешь в компании, которая разрабатывает медицинское ПО
99.999% программистов не пишут ПО для Боинга или для критической части медицины. Они пишут ПО для продажи китайских товаров и кредитов. Так что рассуждения про безопасность - натягивание совы на глобус.
ИИ - не понимает контекста. Он не знает, что за API ты вызвал. Он не знает бизнес-логику. Он предсказывает (!), а не проектирует
И "предсказывает" хорошо. Просто охрененно "предсказывает", если не лениться и писать промпт с наличием всех необходимых для задачи классов и структуры СУБД.
Я просто орнул когда Дипсик мне за несколько минут выдал реализацию класса, которую я бы писал минимум полдня, разбираясь в абстракциях нескольких сторонних пакетах вендоров, где для того, что бы понять как работает код нужно прочитать два независимых мануала, а хождение по коду в IDE - как лабиринт из абстракций.
И да. Код работает. В проде работает. Как нужно. Уже давно. Никто бы из коллег лучше не написал, включая меня.
Но иногда - страшно
Конечно страшно. Пару-тройку лет назад про ИИ и слышно не было, а сегодня оно за тебя код пишет, который в прод уходит. Страшно осознавать, что тенденция идёт к тому, что между человеком и компьютером скоро исчезнет прокладка, называемая программист.
Вот именно, то же ощущение.
99.999% программистов не пишут ПО для Боинга или для критической части медицины. Они пишут ПО для продажи китайских товаров и кредитов. Так что рассуждения про безопасность - натягивание совы на глобус.
Просто автор привел пример с требованиями к безопасности слишком очевидными даже тому кто не хочет задумываться. Но это не значит, что 99.999% программистам не нужно задумываться о безопасности кода.
Я просто орнул когда Дипсик мне за несколько минут выдал реализацию класса, которую я бы писал минимум полдня, разбираясь в абстракциях нескольких сторонних пакетах вендоров, где для того, что бы понять как работает код нужно прочитать два независимых мануала, а хождение по коду в IDE - как лабиринт из абстракций.
Если бы вы все же потратили "минимум полдня", то, возможно, стали бы чуточку умнее, повысили бы свои навыки и развили бы нейронные связи в мозге. Если вы использовали DeepSeek, то умнее в процессе не стали ни вы, ни DeepSeek. Вдобавок теперь в компании есть код, который работает с использованием абстракций нескольких сторонних пакетов вендоров, и ни одного человека, который знает, как эти абстракции использовать.
Собственно против такого подхода и написана статья.
Если бы вы все же потратили "минимум полдня", то, возможно, стали бы чуточку умнее, повысили бы свои навыки и развили бы нейронные связи в мозге.
А почему к "вдумчивому написанию кода руками" часто идёт противопоставление "написал промпт и тупо скопипастил не глядя"?
Я к LLM отношусь как к джуну что очень хочет стать мидлом. А к её коду как к коммиту.
Прежде чем принять коммит в код, его нужно посмотреть.
Потому что посмотреть готовый код это не написать самому, процент того, что останется в мозге совершенно разный - тот же самый подход и в обычном обучении
А ещё через пол год-год вы обнаружите, что забыли как написать простой цикл с банальным алгоритмом, потому что за вас это делала LLM, а вы только визуально аппрувили - я, например, сознательно отказался от всяких copilot, кроме совсем уж противных вещей вроде частей тестов или моков, не смотря на (мнимый) ущерб в скорости работы
Это пассивное и активное использование. Это примерно как чтение и говорение при изучение ин.языка
Если бы вы все же потратили "минимум полдня", то, возможно, стали бы чуточку умнее
Опять эти инфантильные рассуждения об уме, когда речь идёт о программном коде. Мальчики, зарубите себе на носу: к уму и кругозору кодовая база не имеет никакого отношения. Я "минимум полдня" тратил половину своей жизни на это (программирование), на изучение мануалов и фреймворков - где мои честно заработанные миллионы?
Вдобавок теперь в компании есть код, который работает с использованием абстракций нескольких сторонних пакетов вендоров, и ни одного человека, который знает, как эти абстракции использовать
Это не моя вина, т.к. эти абстракции поставляют ваши любимые фреймворки, написанные по правилам ваших любимых теоретиков. Дипсик просто аккумулировал это всё и поскольку знает больше, просто выплюнул РАБОЧИЙ результат.
Помимо этого несчастного класса на 150 строк в проекте много мест, где черт ноги поломает. И это далеко не вина разрабов проекта, скорее претензии к тем, кто создавал фреймворк, вендоров и закладывал всю эту сложность.
Когда 4,5 года назад я написал, что через 10 лет 90% программистов будут не нужны, мне в комментариях только ленивый не отписал, что я идиот и не лечусь (я делал перевод этой статьи на Хабр но сейчас не могу его найти, почему-то).
Два года назад, на волне первого "шока" от ChatGPT, Хабр был полон фырканий про галлюцинации, про то что "окей, квиксорт он может написать с грехом пополам или дополнить строчку моего кода, но в интеграцию кровавых ынтерпрайзных систем со сложной логикой он на моем веку не сможет. Еще мои внуки будут поддерживать это легаси." И что? Через два года, "вы находитесь здесь".
Собака лает, караван идет. Через два-три года ваш комментарий будет выглядеть такой же архаикой, как те фыркания выглядят сейчас. Например, потому что ИИ будет настолько круче 99.9% программистов в вопросах безопасности систем, что будет считаться моветоном не прогонять через ИИ-ревью все то, что пишут другие ИИ или остатки горе-программистов.
Зачем писать вручную, навыки, если дальше нейронки только умнее будут и это всё не пригодится? Этот как, например, пройти нарубить дров, наловить зверей и готовить на костре, когда есть магазин и нормальная духовка, или вообще столовая. Да, будет навыки выживания. Но зачем, если ты всю жизнь будешь жить в квартире, и люди живут в квартирах, а не выживают в лесу. Все уже не вернуть, нейронки есть и только начали развиваться. Прогресс надо поощрять. Вы же хотели чтобы роботы работали за вас? Пожалуйста - уже код пишут.
Я просто орнул когда Дипсик мне за несколько минут выдал реализацию класса, которую я бы писал минимум полдня, разбираясь в абстракциях нескольких сторонних пакетах вендоров, где для того, что бы понять как работает код нужно прочитать два независимых мануала, а хождение по коду в IDE - как лабиринт из абстракций.
Можно конкретно что за вендоры, что за абстракции, что за мануалы, и что за взаимодействие такое архисложное в общих словах?
Вам правда это интересно, что нужно прям КОНКРЕТНО?
Проект на Laravel, самописные вендоры связанные с авторизацией (на основе абстракции фреймворка, как я понял) и внутренней кухней фреймворка по отправке http запросов. Мне даже трудно описать задачу, ибо там черт ноги поломает. Суть в том была, что реализация самописного вендора препятствовала тонкой настройки приложения. ИИ дал мне подсказку. Без ИИ я бы черт знает сколько времени лазил бы по всей этой подкапотной магии фреймворка.
Если "оно" действительно "за тебя код пишет", тогда — да, ты прокладка, и тебе должно быть страшно.
Ощущение что пока 90% программистов застряли в фазе отрицания и дружно обсуждают свою незаменимость, где то средний Вася Пупкин без определенного рода занятий уже начал осваивать программирование с ИИ без всей этой рефлексии.
о, в карму полезли, зацепило за живое)
"Неконструктивное общение")
Попробуйте копнуть глубже и "90%" тутошних умников - не программисты вовсе. И ни разу ИИ не использовали для реальной кодовой базы.
После выхода Дипсика я использую его постоянно. Просто ржу над мнениями, в которых каждый раз рассказывают, что он ничего не умеет. Очевидно, что люди забивают туда запросы уровня "эээ...Фейсбук мне запили", а потом удивляются, что ИИ чушь выдает.
Вы не можете знать, кто здесь программист, а кто нет, и тем более, как они используют ИИ.
А насчёт подхода — согласен: дело в нём, а не в самом ИИ.
Очень сильно зависит от языка программирования. Все кроме Python и TypeScript/JavaScript, и Golang уверенно посасывает лапу.
Кроме того, Gemini 2.5 Pro это первая модель, которую я видел, которая старается дописывать код в класс/файл с учетом стиля и отдельных customs, принятых в этом файле, например, способе логгирования (а прописывать все это в промпте или в cursor rules, естественно, лень). Все предыдущие модели всегда, насколько я видел, писали код в своем "любимом" стиле для того или иного ЯП, утрамбованным в них через пост-обучение. Впрочем, даже Gemini 2.5 Pro в этом плане очень далека от идеала.
Согласен, разные модели, разные стеки, разные результаты. Нет «лучшей» LLM, есть подходящая для твоей задачи.
Claude всегда пишет код в моём стиле, если дать достаточно контекста (существующий код «вокруг» новой функциональности).
Все кроме Python и TypeScript/JavaScript, и Golang уверенно посасывает лапу.
Пока только тестирую на простых задачках, но по первому впечатлению Claude (через Cursor) пишет на Rust не хуже, чем на Go (Python/JS/TS мне не особо интересны, так что с ними не сравнивал).
И это в контексте поднятого в статье вопроса очень неплохо, потому как Rust из всех более или менее мейнстримных языков наибольшее количество ошибок выловит на этапе компиляции. Так что для LLM тоже не так просто написать компилирующийся, проходящий clippy, но при этом всё равно содержащий баги код :)
Дорогой дневник, этот комментарий почему то вызвал маленькую бурю в стакане моей кармы. Хуже было только когда я спроси скан исходного документа у историков.
Когда уже есть опыт и понимание - то да, помогает. Я бы сказал, что ИИ это такой быстрый интерфейс мозг-компьютер. Да, он требует сначала письменного рассужденияя, потом быстро генерирует код, которы понимается сразу на скорости чтения. И его достаточно безопасно с или без изменений можно влить. Понимаешь, что делаеть - да, отличный и быстрый результат.
Но вот беда, если не понимаешь, или понимаешь не до конца. Всякое может быть.
Например, "реши уравнение 4х = 8". Овет: "-2 * i^2".
хм.. странно что ответ какой-то сложнее, чем я ожидал, но математика была так давно... не помню, но вроде бы похоже... что-то такое проходили.. ну ка, wolfram alpha, надо проверить. О и правда 8. "git push origin solution".
Вот просто гипотетика. Ты работаешь в компании, которая разрабатывает медицинское ПО. Или ПО для дронов. Или для спутников. Ты внедряешь кусок ИИ-кода, который обрабатывает какие-то критичные сигналы. Всё работает. На тестах - норм. В проде - норм. Но через два месяца происходит сбой. Из-за того, что один параметр оказался
nullв неподходящий момент. А проверка на него была... ну, слишком не "вайбовая".
Какой-то бред. Открой коммиты в любом популярном репозитории или ченджлог у проги и что там будет? Правильно - Fix Fix Fix Fix Fix. Как же так, неужели люди не пишут код без багов с первого раза?
ИИ с каждым днем пишут код лучше - меньше путаются в большом контексте, делают меньше ошибок, реже галлюцинируют, так что это вопрос времени, когда они начнут выплевывать по 100к+ строк рабочего кода за промпт и ошибаться реже людей.
Ну джуны в предметной области, которые не умеют в математику, думают, что вся правда страшная жизни в том, что где-то null не обработали. А вот я медицинским ПО занимался, и нет, эта проблема вообще никак не стоит по сравнению со всем остальным.
100к значащих строк кода это очень много бизнес логики. С разными внутренними связями. Вы ее промптом не опишите. Ее даже в десятке тикетов однозначно не описать. Уже нужны огромные Миро схемы и десятки протоколов встреч.
Для обычного кода есть о большое. Мы умеем оценивать сложность. Для бизнес логики такой оценки нет. Но мне кажется что там точно степень. И каждый шаг вперед будет будет на порядки дороже.
Ну кто дальше других в будущее идёт, тот больше платит. Если проблема не затрагивает все возможные варианты развития потенциального будущего, то, думаю, экспоненты там не будет, достаточно чёткого тз на определённый срез обозримого будущего. И да 10к знаков тз может легко стать 100к знаков рабочего кода.
Но бизнес все ещё играет в be∀ting dead horses.
Я последний раз видел ТЗ на 10к знаков лет 10 назад. Написать десяток страниц однозначного ТЗ это огромная работа. Нынче везде эджайл и юзер стори на пару абзацев. И таких юзер стори много. Соединяются они через Миро схемы или что-то подобное.
Не спорю. Те же десять лет назад я начал чувствовать, что IT умирает. Теперь это мало чем отличимо от того же трейдинга. Ну в рамках правового поля без зарплаты не останешься, но без настроения или без развития, - да запросто.
Так ИИ может написать ТЗ на 10к знаков, просто добавив воды типовой на основе лаконичного промта.
Поигрался с перплексити и копилотом тоже. На самом деле, как справочник типовых или редких библиотечных функций очень даже приемлемо. Последнее, что было - сборка и оптимизация запроса гео-данных из таблиц, близких к ОСМ. Ну и?
Первый промт, конечно же "есть это .. напиши запрос для ..". Ух-ты, а он применил postgis, hstore функции и даже cte.. копируем, запускаем .. падаем с ошибкой. Так, не всё умеет копилот. Ок, посмотрел подправил запрос - ок, обнаружил не использованный индекс, скорректировал - скорость выросла вдвое. Не густо, но все же.. Отдал тоже самое перплексити.. видимо одна обучающая база, запрос практически такой же, но с иной ошибкой.
Улучшение: "какие ещё функции postgis могут упростить и ускорить запрос?" (там 25строк в нем) куча бла-бла, но выдал пару вариантов интересных (забыл).. применил, скорость выросла ещё раза в 4. Потраченное время? Если бы писал сам с нуля, шарился по документации, то пришел наверное к тому же самому, и .. за то же самое время. Экономия? Вряд ли и сильно. С ИИ, перезапросами, проверками, корректировками и размышлениями над эксплейн суммарно ушло 1.5 дня. Что в лоб, что по лбу.
Но соглашусь с автором. Страшно то, что ревью стали делать силами копилота, и это уже наблюдаю повально.
Страшно то, что ревью стали делать силами копилота, и это уже наблюдаю повально.
Запускаем appscreener и офигеваем от количества уязвимостей. Пытаемся исправить, а он не пропускает и не говорит точно почему. Ищем описание функций и в упор не видим ничего страшного.
Потом оказалось что appscreener плохо работает с трассировкой и не доверяет параметрам по умолчанию.
Перекидываем задачу на LLM. Не сразу но задача решается. Время экономит.
Вот тебе и ревью. Аж двумя роботами
🤖⚡⚡🤖
Типичные ошибки лучше запомнить, конечно. Но много ложно положительных от этого appscreener. А без его аппрува на прод не пустят.
Да, нейросети неплохо имитируют написание кода, так неплохо, что даже опытный программист поначалу не видит разницы. Но начинаешь проверять написанное - о, ужас!..))) Ни один первокурсник не напишет такого бреда.
В этом вся опасность копилотов для джунов. А когда подобный джун начинает постить комменты к ревью из копилота .. часто становится не только смешно, но и грустно одновременно.. "для решения .. надо было распараллелить процессы, например вот так .." А ничего, что все стадии этих якобы "процессов" строго линейны и горутины зависая на ожиданиях данных в каналах исполняются строго последовательно? )
Я чатбота использую так же, как раньше использовал гугл. Правильно сформулированный вопрос дает нужную информацию и/или пример кода. Далее, если это код, то он, разумеется, не вставляется напрямую, а используется для понимания как это сделано и работает.
В собственном коде используется идея, которую предложил бот, а не его код. Так и только так можно сохранить контроль над кодом и понимание чего происходит.
Неистово плюсую. То же относится и к Stackoverflow: никто не заставляет копипастить оттуда код — достаточно оценить идею, и, если она норм, (пере)использовать её самому.
Иногда нейронки выдают просто феноменальный код, который команда сеньоров не выдала бы, просто удачно сгаллюционировав. Уменее работать с нейронками это уже отдельный скилл. Примерно как получение шелка из паука-шелкопряда.
Вы путаете — не всё использование LLM равно "вайбу". Нужно отделять осознанное программирование с LLM от слепой копипасты. Проблема не в Claude или Copilot, а в тех, кто пулит их код в main не вникая, потому что "выглядит нормально". "Вайб" на проде — это преступление. За такое — леща, жёстко и без разговоров.
Вайб это называется потому, что иногда (в процентном соотношении не очень часто, но физически всё равно получается очень часто) нейронки выдают очень удачные нестандартные решения, которые не пришли бы в голову опытным спецам, потому что "так не принято", "так никто не делает" и прочее... Т.е., путём эксперимента из нейронок можно выдавать просто шикарнейшие, и не побоюсь этого слова - инноваторские технические решения. Если долго "вайбить" над нейронкой, даже не умея кодить, рано или поздно можно выдать большой и качественный проект. Отсюда и слово вайб - которое в английском в одном из значений означает "предчувствие". "Чувствуя" что может нейронка, а что нет, можно из неё получать отменный результат, имея даже малые познания в используемом языке программирования.
"There was a bad vibe about that place" - "Было плохое предчувствие насчет этого места"
Оригинальное значение термина (принятие кода без проверки) никуда не девается и остается реальной проблемой.
Приписывание LLM способности генерировать "инноваторские" решения, превосходящие опытных спецов — это сильное преувеличение. LLM — это рекомбинаторы существующих знаний. Они могут выдать неожиданную комбинацию, которая покажется новой, но крайне маловероятно, что это будет настоящая, глубокая инновация. Скорее, это будет применение известного паттерна в непривычном контексте.
Идея, что можно создать "большой и качественный проект", не умея хорошо кодить, но "чувствуя" LLM — это крайне опасное заблуждение.
Вы пытаетесь представить "вайб" как некий эзотерический путь к инновациям, доступный посвященным, которые "чувствуют" LLM. Но если убрать эту романтическую обертку, то остается то, что можно описать как: "программирование на ощупь" (отказ от формальной логики в пользу интуиции) или "кодинг наугад" (перебор вариантов в надежде, что звезды сойдутся, и что-то "шикарное" случайно выпадет из LLM).
Вайб — это когда ты плывёшь по течению с подпиской на ИИ за 20$ в месяц, а трезвый взгляд и логика тонут где-то за бортом, и тебе пох, лишь бы волна качала.
"Все уже написано до нас". Боты имеющее в своей базе весь гитхаб, стековерфлоу, и прочее, плюс весь код тех кто посылал им его на обработку, легко найдут там подходящие под запрос куски. Удобство людям в том, что не надо все вышеупомянутое шерстить в поисках.
Честно говоря, пугает вот это: "ИИ написал за меня всё что нужно и это было сделано отлично, даже ничего исправлять не пришлось". Постоянно пытаюсь делегировать ИИ сколько-то серьезные участки работы и каждый раз требуется, как минимум, достаточно существенная переделка сгенерированного кода. Причем время вдумчивой проверки этого кода вполне себе сравнимо с тем временем, что потребуется на его самостоятельную реализацию.
Какой у вас стек? Какими моделями пользуетесь? На каких типах задач? Используете ли контекст?
Наблюдал схожее поведение на разных стеках и моделях LLM. Наиболее сильная модель из тех, что пробовал, на мой взгляд, была Claude 3.7. Но даже её вывод надо контролировать, на миддл+ задачах уже спотыкается и без проверки высок риск запушить багов на прод.
В реальной работе генерация — только начало процесса, а не его завершение:
Генерация → Критический анализ → Правка/доработка → Интеграция → Тестирование.
Соотношение "время на генерацию и проверку" vs "время на написание руками" зависит от многих переменных: стека, сложности и типа задач, умения работать с моделью и получать нужные результаты.
Как любой инструмент, LLM подходит не для всех задач.
Смысл вайб кодинга в том что ты и не проверяешь код, Карпатый говорил что вайб кодинг это про быстрые прототипы, его нельзя делать частью процесса разработки софта. Это не значит что ИИ нельзя применять при разработке софта, но это уже не будет вайб кодингом.
Согласен, в продакшене "вайб" — это не просто ошибка, а провал профессионализма. За "вайб" на проде надо не леща давать, а сразу выгонять.
Осознанное использование LLM в разработке с чёткими промптами, качественным контекстом, проверкой и интеграцией, не имеет ничего общего с "вайбом".
У нейронок своя атмосфера. Если ты ей пытаешься скормить код из большого проекта с уже сформировавшейся методологией, то получишь эффект "джуна на проде". Если же ты с нуля следуешь методологии, которая заложена в LLM, и развиваешь её, четко понимая, какие возможности есть у модели, то можно сделать большой проект без серьёзных правок. Конечно, для такого требуется хорошая база изначально, и неплохое, как минимум, понимание языка/языков на которых генерируется код. Нейронка не пишет код и за тебя работу не делает, она просто генерирует максимально логичный, согласно её базе знаний, код.
Языки программирования это костыли для человека,
ибо слаб он и немощен - не может писать сразу в машинных командах.
Скоро вместо кучи программ везде будет одна LLM, которая в runtime создаст
UI наиболее приятный конкретному пользователю и будет выполнять все его
желания, не пиша никаких программ.
Не так скоро. В 2025-м модели всё ещё ограничены контекстным окном, галлюцинируют без чётких промптов и выдают баги, если не держать их за руку.
Уже наблюдал как галлюционирует перплексити и даже с четко заданным промтоп и даже на английском. Если нет в обучающей базе точно такого же куска - галлюцинация становится практически не избежной. А если кусок найден, то это значит только одно: эту задачу до тебя уже решали и решение уже попало в обучающую базу, т.е. как минимум "пару лет назад".. Если ИИ, как перплексити, выдает ссылки на источник, то надо ходить и перепроверять что он там наковырял.. часто источник или пара является галлюциногенными: открываешь исходник на гитхабе, а там в ишью .. как раз ошибка из его бреда не поправлена по сию.. :)
"Галлюциногенные" источники и круговорот херни в природе :)
LLM — как фабрики по переработке существующего кода.
А человек? Примерно так же, некие шаблоны в памяти и на основе их пишется код. Принципиально новые решения исключительно редко появляются, например собственнописная библиотека быстрого преобразования Фурье или что-то подобное. Вроде и от языка программирования не зависит, вряд ли кто-то на Cobol или SAP ABAP писал быстрое преобразование Фурье, а чат выдал код с подробными комментариями, то есть где-то алгоритм был взят и переложен в код на нужном специфическом языке, с подробными комментариями, советами и рекомендациями по применению.
Человек, столкнувшись с ситуацией, где шаблон не подходит или приводит к ошибке, способен (в идеале) отступить, проанализировать и найти другое решение или исправить ошибку, опираясь на понимание. LLM, столкнувшись с отсутствием подходящего паттерна в данных, склонна к "галлюцинации" — генерации правдоподобного бреда.
Вот выдал ИИ код.
Там могут быть ошибки.
Но люди тоже делают ошибки.
Нужно всё проверять, но и тут можно использовать помощь от ИИ.
Что если открыть новую сессию и сказать, что код должен делать то-то и вот тебе код и его нужно тщательно проверить? Другой нейронке задать тот же вопрос? Взять не весь, а сложный кусок сгенерированного кода и попросить тщательно проверить и пересказать, как он работает? Или попросить сделать какие-то более конкретные особенные проверки, например на то, что везде есть в коде проверка на правильные входные и выходные значения?
На тестах — норм. В проде — норм. Но через два месяца происходит сбой
Если на тестах было норм, то, наверное, что-то не так с тестами?
ИИ хорош на конкретные "почему" в разработке. спросить у него гораздо эффективнее поисковика. код с ним писать тяжело, всегда нужно проверять. да и не всегда сразу нужный результат. в целом дешевле писать самому. не представляю способа, который мог бы мне дать уверенности столько, что можно не проверять.
а так, - по мелочи что-то. с типизацией разобраться
Думаю, вайб-кодинга бояться не нужно, но важно чувство меры.
Так же, как чувство меры, когда позволяем детям тупить в телефонах, так же, как чувство меры, когда подсаживаемся на игрушки, или когда даем волю своему перфекционизму, допиливая и полируя какой-то функционал.
Лично для меня ИИ это свобода - нагружая ИИ для разных задач, я больше фокусируюсь на творчестве без снижения производительности.
К сожалению, с задачами джунов и мидлов вполне справляется ИИ, и мне пришлось уволить ребят.
В разработке последние 30 лет и мне нравится именно разработка.
К сожалению, с задачами джунов и мидлов вполне справляется ИИ, и мне пришлось уволить ребят.
Какой именно инструмент оказался достаточно хорош, чтобы заменить людей?
К сожалению, с задачами джунов и мидлов вполне справляется ИИ, и мне пришлось уволить ребят.
А кто в итоге пишет промты - разработчик, или аналитик/менеджер?
Да не парьтесь вы! По статистике, 98% современных программистов работают над задачами, которые нафиг никому не нужны, и использоваться по делу никогда не будут.
И всем было бы лучше, если бы и не использовались никогда.
ИИ идеально закрывает потребность в написании такого кода.
Ненужные задачи это невозможно, иначе бы программистам не платили. Но замечаю что задачи эти были решены ранее конкурентами и часто пишется похожий код. Хоть 3D движки, хоть расчет биллинга у сотовых операторов, задачи у всех операторов примерно одинаковые, но многие пишут свои системы учета финансов, тут и код на Cobol работает и новые версии переписываются на Rust и на всех промежуточных актуальных в свое время. Тут база для обучения колоссальна и код может быть очень хорошим сразу, даже если какой-то контекст упущен в промте.
Оплата подтверждает необходимость задачи для кого-то.
Я пытаюсь разобраться в коде, который выглядит как код супер‑сеньора с 25-ти летним стажем. Первое, что напрягает — его запулил джуниор.
Мне нравится вот такая фраза: "сеньор обычно пишет такой код, в котором при желании сможет разобраться и джун; а джун иногда может написать такой код, что и сеньор не разберется"
На мой взгляд, в коде не в последнюю очередь важна именно его поддерживаемость, и если какой-нибудь копилот пишет код, в котором потом сложно разобраться, то это скорее плохой код
Подождите-ка. А что, если просто продолжать делать код-ревью, как если бы это были коммиты от живых людей? (а они от них и есть)
Коммит в 300 новых строк? Пожалуй что отказать. Ну либо побеседовать о смысле этих строк.
Если строк немного - ну так значит можно и посмотреть, как же изменилась логика
Не тот код-стайл? Ну вы поняли...
Это не работает. Психология против.
Вот поревьюили, код фигня 42 замечания. Вам через 15 минут приносят 100500 других сгенеренных строк решающих (нет) ту же самую задачу. Будете еще раз два часа ревьюить?
Тот кто генерит ровно так же относится к этому коду. Этот код не стоит ничего, смысл время тратить? Вроде с виду похоже, какие-то тесты проходят, катим в прод.
Вот так проект и попадет в ситуацию где отделу из пары десяток человек надо переписывать нормально все что навайбкодило пара человек.
не пользуюсь вообще, если речь идёт о генерации с нуля. но при отладке с удовольствием прибегаю к помощи клавдии и deepseek. потому, что бесплатные и встроены в курсор :)
Как я начал бояться вайб-кодинга, или почему мы доверяем ИИ больше, чем коллегам