Чем хорош ИИ (и почему мы в это верим)

Искусственный интеллект — это естественный этап развития технологий. Мы всегда стремились создавать более умные системы и автоматизировать всё, что можно. В идеале — чтобы ничего не делать, а всё работало: красиво, быстро и само по себе. Чем легче мы можем создавать и управлять сложными системами, тем лучше — и в этом абсолютно нет ничего плохого.

Большие языковые модели (LLMs) стали основой этого прогресса. Сегодня почти каждый разработчик программного обеспечения так или иначе использует их (ну или, по крайней мере, подавляющее большинство). Многие из нас начинали путь в разработке ещё в начале нулевых, а кто-то и в прошлом тысячелетии. Тогда всё было совсем иначе. Да даже в 2017 году — не так уж и давно — поиск решения мог занять целый день. Копались в форумах, читали баг-трекеры, переходили по архивным ссылкам, и всё это — чтобы найти хоть что-то похожее на ответ. Если бы тогда уже был доступ к ChatGPT, мы бы могли сгенерировать решение за 10 минут, разобрать его и адаптировать под свою задачу.

Одиночество разработчика и глухой StackOverflow

StackOverflow тогда был, по сути, единственным местом, где ещё можно было попытаться найти ответ. Но по ощущениям — это была смесь элитарного клуба и бюро отказов. Новичков там не ждали, вопросы не терпели, а за малейшую неточность можно было сразу словить минус и ехидный коммент, мол, «гугли лучше».

Публиковали ещё несколько вопросов — настолько часто, что даже получили автоматический бейдж от системы. Ирония в том, что ответов от людей это всё равно не принесло.

А потом кто-то взял и заминусовал один из вопросов — просто так, без объяснений. После этого аккаунт заблокировали. И не за спам, не за троллинг — а за вполне уместные вопросы, на которые просто никто не знал ответов. Отличное начало карьеры, не правда ли?

Если бы тогда у нас были такие инструменты ИИ, как сейчас, этот период был бы гораздо менее болезненным. Мы бы находили ответы без лишнего стресса и без необходимости переосмысливать выбор профессии по дороге домой в десять вечера, сидя в холодном, пустом автобусе.

Мы всё это рассказываем, чтобы прояснить одну вещь: мы — ярые сторонники ИИ, машинного обучения, глубокого обучения — всей этой области целиком. Даже академические исследования некоторых участников нашей команды были сосредоточены на интеллектуальном анализе данных и искусственном интеллекте.

Бывали профессиональные споры с людьми, которые скептически относятся к этим технологиям, и, если честно, мы не понимаем этой враждебности. Почему вообще кто-то должен отвергать инструмент, который помогает работать умнее, учиться быстрее и быть продуктивнее?

А вот и то самое «однако»

Однако, инструменты, включая ИИ, созданы для того, чтобы помогать нам, а не заменять нас. И это — принципиально важно!

И вот мы подходим к нашей основной тревоге: vibe coding.

С этим трендом у нас серьёзные проблемы. Он просто не откликается внутренне. Честно говоря, вызывает отторжение на стольких уровнях, что даже сложно сказать, сможем ли разобрать их все в рамках одной статьи.

Но давайте начнём с основ — с фундаментальных проблем — и постепенно перейдём к более сложным.

Причем тут «вайб»!?

Даже если сама концепция vibe coding и хороша, то название у неё — худшее из возможных. По ощущениям, его просто недостаточно продумали. Давайте разберёмся, начав с определения обеих частей этого термина:

Vibe — настроение места, ситуации, человека и т.п., а также то, какие чувства они у вас вызывают (dictionary.cambridge.org)

Coding — составление последовательностей инструкций, называемых программами, которые компьютер может выполнять для решения задач. Это включает в себя проектирование и реализацию алгоритмов — пошаговых процедур — путём написания кода на одном или нескольких языках программирования. (dictionary.cambridge.org)

Теперь, когда мы определили оба термина, у нас остались два довольно глупых — но честных — вопроса:

• Где здесь вообще “vibe”?
• Где здесь вообще “coding”?

По-нашему, всё как раз наоборот.

Настоящий «vibe»

Для нас настоящие хорошие «вайбы» в программировании рождаются из обучения — из настоящего, глубокого обучения. Они появляются, когда ты погружаешься в новый язык, пробуешь незнакомую библиотеку, изучаешь новый шаблон проектирования или архитектурный стиль. Пытаешься понять, экспериментируешь, пробуешь внедрить в проект — а может, даже запускаешь что-то новое просто ради того, чтобы разобраться, как оно работает.

А потом, неизбежно, терпишь неудачу. Упираешься в стену. Потому что если этого не происходит — значит, не старался по-настоящему. Проводишь часы в поисках того, что пошло не так. И в этом процессе учишься ещё больше. В какой-то момент всё встаёт на свои места. Получается. И, возможно, делишься своими открытиями с другими — и вот так просто растёшь. Становишься лучшим инженером, чем был в начале.

Вот это и есть настоящий «vibe». Весь путь — любопытство, ошибки, настойчивость, прорывы, эмоции. Именно это придаёт программированию энергию и смысл.

Мы провели бессчётное количество часов, борясь с упрямыми багами — и нет, это далеко не всегда весело в моменте. Иногда это раздражает, выматывает, даже почти морально уничтожает. Но стоит найти решение — и всё сразу оживает. Вдруг мир снова становится ярким. Мы даже помним, какую музыку слушали в тот момент, сколько было времени, какая стояла погода, какой кофе пили — каждую мелкую деталь.

А потом, услышав ту же музыку, всё возвращается. Мы снова там, переживаем те эмоции заново. Именно это эмоциональное путешествие, это чувство награды делают для нас настоящее программирование по-настоящему значимым. Это и есть тот самый настоящий vibe. Дело не только в результате. А в пути, который помогает тебе расти.

Путь важнее, чем результат

Когда мы только начинали карьеру, фокус был полностью на конечной цели — на результате, на финальном продукте. Но, чёрт побери, как же мы ошибались. Со временем стало понятно: действительно важно — это путь.
Финальной точки нет — есть только этапы на бесконечном маршруте. И этот путь полон вызовов, уроков и, что важнее всего, вайба.

Именно это когда-то и подтолкнуло нас к тому, чтобы стать инженерами-программистами. Кто-то ещё в старшей школе представлял себе будущее: стать человеком, который глубоко понимает сложные системы, умеет решать проблемы с помощью точных, выстраданных навыков. Этот образ вдохновлял. Именно это делает нашу профессию по-настоящему крутой.

И для нас именно это и есть настоящий vibe — эмоциональные американские горки, через которые проходишь во время написания кода. Взлёты и падения. Фрустрация и озарения. То, как меняется настроение, когда погружаешься в проблему и медленно, шаг за шагом, находишь решение сам. Не думаем, что существует вайб лучше этого.

Мы просто не понимаем, как можно называть «вайбом» процесс, когда ты просто даёшь команду  LLM, и она сама генерирует за тебя код. Не то чтобы в этом есть что-то категорически плохое — об этом мы ещё поговорим позже — но лично для нас такой подход в ближайшее время не вариант.

Абстракция поверх абстракции?

Языки программирования становятся всё доступнее с каждым днём. Современные языки, как правило, заимствуют лучшие идеи друг у друга, стремясь к более чистому, интуитивному и лёгкому для изучения синтаксису. Конечно, всегда есть исключения, но в целом, если создаётся язык, который должен быть надёжным в будущем и массово используемым, внедрение этих улучшений уже не опция — это необходимость.

Кто-то может возразить, что языки вроде PHP всё ещё широко используются, или что практически вся банковская система США до сих пор работает на COBOL. И это будет правдой — но речь сейчас совсем не об этом. Не о языках, на которых построены огромные легаси-системы, переписывать которые практически невозможно (или крайне рискованно).

Возьмём, к примеру, авиацию. Если программное обеспечение самолёта написано на C, никто не захочет переписать его на что-то «поудобнее» — и на то есть веские причины. Никому не нужны неожиданные баги на высоте 10 000 метров. Точно так же, если банковское ядро работает на COBOL десятилетиями, часто лучше просто не трогать его. Эти системы настолько масштабны и критичны, что даже малейшее изменение может привести к серьёзным сбоям. В таких случаях стабильность важнее элегантности.

Но в новых проектах — тех, которые только создаются или пытаются набрать популярность — всё иначе. Если язык сложно читать, писать и анализировать, и при этом он не предлагает каких-то радикально новых преимуществ, ему будет сложно завоевать широкое признание. Опыт разработчика важен как никогда.

Суть в том, что современные высокоуровневые языки стали невероятно интуитивными. Возьмём Python — его можно практически читать как обычный английский текст, и это хорошо. Любой человек может создать простое калькуляторное приложение на Python уже через несколько минут после изучения основ. Вот в чём сила доступного синтаксиса — он даёт людям возможность создавать, а не просто писать подсказки.

Нет никакой необходимости просить ИИ сгенерировать весь код за вас. Всё можно написать самостоятельно, своими словами — и при этом сохранить полный контроль над процессом. Вы — пилот, сидящий слева, с руками на штурвале. Когда сталкиваетесь с тупиком или забыли какую-то конструкцию — обращаетесь к своему второму пилоту (ИИ). Получаете нужную информацию, адаптируете её под свои задачи и интегрируете в свой проект. Вы не копируете вслепую — вы управляете.

А вот vibe coding добавляет ещё один слой абстракции — поверх уже абстрактной концепции. Но теперь эта абстракция становится гораздо менее предсказуемой. Языки вроде C# уже являются высокоуровневыми и абстрагированы от машинного кода, но при этом они точны и надёжны. Если написать что-то, что нарушает синтаксис C#, код просто не скомпилируется. Всё просто. И если вы умеете программировать на C#, вы в полном контроле. Можно логировать ошибки, отлаживать критичные участки, анализировать производительность, писать чистый и поддерживаемый код — другими словами, вы пилот. Вы понимаете, что происходит под капотом. Да, система абстрагирована, но она последовательна и детерминирована.

А вот vibe coding всё это меняет. Он добавляет такую абстракцию, которая совсем не похожа на ту, что даёт, скажем, управляемый код. Она гораздо более расплывчатая. Например, компилятор C# всегда сгенерирует одинаковый промежуточный язык и байт-код для одного и того же исходного кода. А вот ИИ-инструменты могут выдать совершенно разные результаты на один и тот же запрос — в зависимости от контекста, случайных факторов или формулировки подсказки. И это делает новый слой абстракции гораздо менее надёжным — по крайней мере, на данном этапе.

А что будет, если слишком доверять ИИ?

Никто не берётся предсказать, каким будет будущее ИИ — но прямо сейчас, если слишком сильно полагаться на него в процессе разработки, всё может очень быстро пойти не так.

Чтобы не было недопонимания: речь не о тех сценариях, где ИИ используется как помощник, результат просматривается, правится и осознанно внедряется в проект. Это нормально. Это продуктивно. Именно так и должен работать хороший «второй пилот».

Речь — о настоящем vibe coding. Когда пишется расплывчатый запрос, результат даже не проверяется, и сгенерированный код сразу летит в продакшн. Примеров, к чему это может привести, уже более чем достаточно.

Возьмём, к примеру, печально известный проект SaaS, созданный с помощью Cursor. Его автор с гордостью написал в Twitter, что в проекте «ни строчки вручную написанного кода». А уже через два дня — новый твит: API-ключи достигли лимитов, пользователи обходят подписку, в базу данных сыпется какой-то мусор.

Собственными словами разработчика: «происходили случайные вещи».

Это не инженерия. Это бросание кубика, замаскированное под разработку

Честно говоря, нам по-человечески было жаль того разработчика — это невероятно обидно: ты веришь, что создал что-то крутое, а потом видишь, как пользователи начинают это ломать, обходить все ограничения и буквально высасывать из проекта всю ценность.

Но с этим мы все должны смириться: не существует короткого пути к устойчивому успеху.

Даже если повезло, и получилось быстро добиться результата без особых усилий, такие обходные пути почти всегда приводят к трещинам. А трещины очень легко эксплуатировать.

Люди заметят, что был выбран лёгкий путь — и некоторые из них намеренно расставят ловушки на этих же дорожках, просто выжидая, когда кто-нибудь оступится.

Говорят, пользоваться чужими ошибками — неправильно. Но на деле это самый разумный подход. Учись на чужом опыте, пока не приходится платить за свой. Особенно в мире, где интернет сам по себе — спидран по уязвимостям.

Именно поэтому, будь то разработка, запуск продукта или просто изучение чего-то нового, лучший подход — простой:

«Надейся на лучшее, готовься к худшему».

Это не пессимизм — это подготовка.

Риски безопасности

Теперь, когда мы разобрали пример SaaS-проекта, созданного с помощью vibe coding, давайте кратко поговорим о рисках безопасности, которые сопровождают этот подход.

Когда разрабатывается программное обеспечение для компании, безопасность — это не дополнительная опция. Это приоритет №1. Никто не хочет, чтобы секретные API-ключи случайно оказались в репозитории на GitHub, а то и вовсе — в открытом доступе. Учётные данные, токены и конфигурации с чувствительной информацией должны храниться надёжно, зашифрованно и с правильно настроенными правами доступа.

Но инструменты ИИ по умолчанию не понимают, что в приложении является чувствительным. Они не знают, какие переменные — это секреты, какие данные никогда не должны попадать в логи, и какие практики безопасности применимы в конкретной ситуации.

Да, возможно, кто-то знает об этом и может предупредить ИИ — особенно если за плечами есть опыт и уже была работа с подобными проблемами. Но что насчёт тех, кто этого ещё не знает? Кто использует ИИ как вспомогательный инструмент, никогда не строив систему с нуля с учётом всех аспектов безопасности?

Можно по незнанию закоммитить секреты в систему контроля версий, логировать пароли пользователей в открытом виде, оставить открытыми внутренние эндпоинты или создать огромные уязвимости — всё потому, что код выглядел «нормально».

Вот в чём настоящая опасность vibe coding: он может пропустить те вещи, о которых вы даже не знали, что должны о них беспокоиться.

Если вы не создаёте совсем простое приложение, вам всё равно придётся обратиться к настоящему инженеру

Программное обеспечение может очень быстро стать невероятно сложным — особенно в корпоративной среде. Если приложение полностью создаётся с помощью ИИ, и в какой-то момент возникает необходимость изменить что-то специфическое, есть большая вероятность, что ИИ просто не сможет помочь.

Был случай, когда нужно было внести очень конкретные изменения в файл template.json внутри шаблона .NET-проекта. ИИ, несмотря на множество попыток, не смог выдать работающий вариант. В итоге решение оказалось спрятано глубоко в обсуждении на GitHub.

Вот тогда и нужен настоящий инженер — человек, который умеет читать, понимать и точечно менять код. Или хотя бы тот, кто знает, где искать решение, которое ИИ просто не найдёт.

Но есть нюанс: такому специалисту вряд ли понравится работать с кодом, созданным ИИ. На самом деле, может потребоваться огромное количество усилий, чтобы просто добавить новую функцию, исправить баг или хотя бы понять, как устроена текущая структура проекта.

А если встаёт задача рефакторинга такого кода с нуля — это может превратиться в настоящий кошмар.

Vibe coding позволяет строить быстро, но при этом может накапливать огромный технический долг — незаметно, молча и очень быстро.

И последнее, но не менее важное — устойчивость

Когда Сэма Альтмана спросили, сколько OpenAI теряет из-за того, что пользователи пишут ChatGPT что-то вроде «пожалуйста» и «спасибо», он прославился своим ответом на X (бывший Twitter):

«Десятки миллионов долларов — хорошо потраченные. Никогда не знаешь, зачем это может понадобиться».

И это — просто за вежливые ответы вроде «не за что» или «пожалуйста».

Если даже такие мелочи стоят десятки миллионов долларов, это даёт примерное представление о том, какой объём энергии потребляется за кулисами.

Теперь представим масштаб одного только ChatGPT:

• ~122 миллиона активных пользователей ежедневно.
• ~400 миллионов активных пользователей еженедельно.
• ~1 миллиард сообщений обрабатывается каждый день.
• ~1 ГВт⋅ч электричества потребляется в сутки — это примерно как обеспечение энергией 33 000 американских домов в день.

Это колоссальное энергопотребление — и это всего лишь один продукт.

Одним из ключевых принципов инженерии всегда была эффективность — не только с точки зрения производительности и архитектуры, но и в вопросе рационального использования ресурсов. Но с vibe coding происходит обратное: мы резко увеличиваем потребление энергии до беспрецедентного уровня.

Одно дело — иногда искать что-то на статичном сайте. Совсем другое — целыми днями просить ИИ сгенерировать, перегенерировать и переформулировать целые блоки кода.

Сегодня в мире десятки миллионов инженеров-программистов. А vibe coding — по своей природе — проще, чем настоящая инженерия. Так что легко представить будущее, где вайбкодеры численно перевесят традиционных разработчиков. Если это произойдёт, энергетический след всей индустрии разработки может взлететь до небес — вместе с ним возрастут углеродные выбросы, и нас может ждать кризис устойчивости, к которому мы просто не готовы.

Заключение

Переходя к завершению, давайте на позитивной ноте: где же vibe coding действительно имеет смысл?

Разберём каждую сферу по отдельности — чтобы чётко понять, в чём его реальная польза.

Шаблонные проекты и повторяющийся код

Для начала: генерация шаблонных проектов — это отличнейший сценарий использования. ИИ-инструменты могут значительно упростить этот процесс, особенно если пока нет собственной системы шаблонов. Конечно, если уже было вложено время в создание собственных решений, то генерация нового проекта может сводиться к одной команде в CLI. Но если нет — ИИ вполне может закрыть этот пробел.

Демо-проекты

Ещё одна сфера, где vibe coding действительно сияет — создание демо-проектов для клиентов. Иногда не нужен полноценный продукт — достаточно чего-то, что можно показать. Рабочий концепт. Грубый прототип идеи. Вместо того чтобы тратить часы на сборку одноразового демо, можно поручить это ИИ. Быстро создать, презентовать своё видение — а потом либо выкинуть, либо использовать как основу для доработки.

Связующее звено между инженерами и менеджерами

Такой подход может быть особенно полезен для нетехнических участников процесса — продакт-менеджеров, проектных руководителей и владельцев продуктов. С помощью ИИ можно быстро собрать простой прототип, чтобы визуально и функционально донести своё видение до команды разработчиков. Вместо длинных ТЗ — грубая, но наглядная версия того, что нужно. Это сокращает недопонимания и помогает разработчикам быстрее и точнее реализовать ожидаемый результат.

Первые шаги в создании продуктов

Vibe coding может сыграть важную роль и в адаптации новых разработчиков или в обучении тех, кто только начинает осваивать эту сферу. Экспериментируя с кодом, сгенерированным ИИ, новички могут познакомиться с разными направлениями в разработке: веб-приложения, десктопные утилиты, мобильные приложения, игры — и понять, что действительно вдохновляет. Это, конечно, не заменит глубокого обучения и настоящего опыта, но может стать входной точкой в мир инженерии.

На этом всё — надеемся, статья заставила вас задуматься о будущем профессии. Следите за релизами, новостями и кейсами внедрения — присоединяйтесь к сообществу Appliner в Telegram.

Этот материал — перевод оригинальной статьи:

Giorgi Kobaidze 

Автор перевода: Мацак Максим | APPLINER