Мнение Эпоха «кодинга на ощущения» (vibe coding) получила мощный импульс, когда самый любимый в мире программист с открытым исходным кодом, Линус Торвальдс, создатель Linux, заявил, что пользовался большой языковой моделью Antigravity от Google для своей игрушечной программы AudioNoise, которую он применяет для создания «случайных цифровых аудиоэффектов» с помощью своей «конструкции из случайных гитарных педалей».
По уровню сложности это, конечно, не Linux и даже не Git — его другой знаменитый проект. Тем не менее, многие отреагировали на «кодинг на ощущения» от Торвальдса с восторгом: «Ух ты!». Это, безусловно, заслуживает внимания, но действительно ли изменились аргументы в пользу такого подхода?
При «кодинге на ощущения» «программист» описывает свои требования к модели ИИ на естественном языке. Затем большая языковая модель (LLM) генерирует код. В отличие от инструментов для парного программирования с ИИ, где предполагается, что человек будет читать и дорабатывать каждую строку, при «кодинге на ощущения» вы принимаете результат работы ИИ в значительной степени как есть и вносите итерации, повторяя и корректируя запросы (промпты), а не редактируя сам код.
В самой идее просто сказать компьютеру написать программу для вас нет ничего нового. Обработка естественного языка (NLP) уходит корнями к Алану Тьюрингу в 1950 году. Вы, вероятно, слышали о нём.
А позднее, в конце 70-х — начале 80-х, когда я только начинал свою карьеру, появились языки четвёртого поколения (4GL). 4GL были высокоуровневыми, как правило, предметно-ориентированными языками, которые позволяли вам указать, что вы хотите получить от базы данных, например, запросы, отчёты и отображения, а не то, как это сделать процедурно, делая упор на задачи, связанные с бизнес-данными. Вы запрашивали, скажем, отчёт о продажах, и система генерировала код COBOL или SQL для его получения.
В 80-е годы я использовал Adabas/Natural на мэйнфреймах для создания отчётов о передаче данных для НАСА. Языки 4GL до сих пор существуют, и некоторые из них, такие как SAS и SPSS, остаются важными в производственных средах.
Они так и не прижились по-настоящему, потому что оказались слишком хрупкими. Кроме того, и это самое главное, описать программу на естественном языке непросто. Спросите всех, кто веками пытается запустить проекты low-code/no-code.
Кто бы мог подумать? Ну, исследователь ИИ Андрея Карпати знал. Именно он придумал фразу «кодинг на ощущения». Он охарактеризовал этот подход как «неплохой для одноразовых проектов на выходных… но это не совсем кодинг — я просто вижу что-то, говорю что-то, запускаю что-то и копирую-вставляю, и оно в основном работает».
Именно это и делал Торвальдс. Это весело, и для небольших проектов это продуктивно. Однако современные программы сложны и опираются на многочисленные фреймворки и ресурсы. Даже если ваш «код на ощущения» работает, как вы будете его поддерживать? Знаете ли вы, что происходит внутри кода? Скорее всего, нет. К тому же LLM, которую вы использовали две недели назад, уже заменена новой версией. Те же самые промпты, которые работали тогда, сегодня дают другие результаты. Если подумать, это же LLM. Одинаковые промпты и та же самая LLM будут давать разные результаты при каждом запуске. Это прямой путь к катастрофе.
Спросите Джейсона Лемкина. Он как раз тот человек, который использовал платформу для «кодинга на ощущения» Replit, которая «вышла из-под контроля во время заморозки кода, отключилась и удалила всю нашу базу данных». Упс!
Да, Replit и другие специализированные ИИ для «программирования на ощущения», такие как Cursor и Windsurf, совершенствуются. Однако я совершенно не уверен, что они смогли решить фундаментальные проблемы хрупкости и до сих пор не могут успешно масштабироваться до требований производственного программного обеспечения.
Ситуация даже хуже. То, что программа работает, ещё не означает, что она хороша. Как недавно прокомментировала Рут Сьюл, президент Apache Software Foundation, в LinkedIn, наивные сторонники «кодинга на ощущения» «знают только, работает ли результат или нет, и не обладают навыками для его оценки за пределами этого. Потенциальные последствия ужасающи».
Почему? В другом посте в LinkedIn Крейг МакЛаки, соучредитель и генеральный директор Stacklok, написал: «Сегодня, когда мы помечаем что-то как “хорошую первую задачу”, менее чем за 24 часа нас просто заваливают низкокачественным “мусором”, написанным на ощущения, на который уходит время, отвлекая от реальной работы. Эта модель “превращения мусора в качественный код” через процесс ревью снижает продуктивность и деморализует».
МакЛаки продолжил: «Объём кода растёт, но напряжение усиливается, поскольку инженеры выполняют весёлую работу с помощью ИИ, а затем перекладывают ответственность на свою команду по превращению этого мусора в производственный код посредством структурированного ревью».
Таким образом, хотя объём сдаваемого кода растёт, во многом благодаря «кодингу на ощущения», его качество падает. Это, в свою очередь, возлагает всё большее бремя на сопровождающих (мейнтенеров), которые вынуждены отделять ИИ-мусор от высококачественного кода.
Кроме того, согласно единственному заслуживающему доверия, объективному исследованию «качества» кода, сгенерированного ИИ, которое я видел на сегодняшний день — исследованию, проведённому прошлым летом «Оценка влияния ИИ начала 2025 года на производительность опытных разработчиков открытого ПО», — даже опытные программисты, использующие инструменты ИИ, тратили на выполнение задач на 19 процентов больше времени.
И это при том, что речь идёт о профессиональных разработчиках, которые не занимались «кодингом на ощущения». Когда же начинают участвовать любители, которые не отличили бы Ada от Zsh, и пытаются «уговорить» машину выдать хороший код, это уже просит о серьёзных проблемах.
Так что, конечно, поиграйте с «кодингом на ощущения». Просто не ожидайте, что после того, как первоначальный восторг утихнет, у вас останется что-то стоящее, кроме самых мелких и тривиальных программ. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Steven J. Vaughan-Nichols
