Transcription
Всем привет. Сегодня мы погружаемся в такую, знаете, нашумевшую тему вайбкодинг. Угу. Много споров вокруг, много ожиданий. Что это вообще такое? Демократизация разработки, когда любой может, ну, типа код написать, да? Или это что-то рискованное, что угрожает качеству безопасности, может, даже самой профессии? Вот-вот. Где тут грань? Попробуем разобраться.
А чтобы разобраться, мы как раз взяли за основу очень интересное интервью с Заком Лойидом. Он ведь основатель и CEO компании Warp. Той самый Warp, чей инструмент как раз и используют для вот этого самого кодинг. Верно. Именно так. Мы опираемся на его публичное интервью. Оно было на YouTube канале Тины Хуанг. Отлично. И наша цель сегодня не просто его пересказать. Конечно, нет. Ну что вы, мы хотим понять суть. Что это за вайб-кодинг? Что он может реально, а где его пределы? Ну вот прямо сейчас. И как вообще инструменты типа WordP меняют игру и для новичков, и для, так сказать, матёрых профи. Да. И вот что мне показалось особенно интригующим. Сам Лойд, хотя и создал платформу для этого, он высказывает довольно э ну он сам их назвал острыми взгляды, да. Там не всё так однозначно. Вот давайте с этого и начнём, с самых основ. Coding. Что это вообще за зверь?
Ну, термин стал популярным не так давно. Его подхватили известные люди. Тот же Андрей Карпать упоминал. Угу. Идея в том, что ты как бы не пишешь код сам строка за строкой, как обычно. Ты больше, ну, задаёшь направление, описываешь идею, что ли, высокоуровнево, так интуитивно, типа, хочу вот такую штуку. Примерно задаёшь вайб, настроение, общую концепцию, а искусственный интеллект, ну, то есть и он уже пытается это воплотить в коде. Звучит, ну, почти как магия. Сделай мне красиво. Ну да, есть такое ощущение поначалу.
И как к этому Лойд относится? Вот его же продукт, он же ровно это и позволяет делать. Казалось бы, ему это только в плюс. А вот тут как раз и начинается интересное его позиция. Она такая двойственная. То есть, с одной стороны, он говорит: "Да, вайп-кодинг - это фантастика, но с оговоркой. Для чего? Для личных проектов супер, для каких-то экспериментов, для людей, которые вообще не программисты, но хотят что-то для себя автоматизировать, сделать какую-то утилиту. Вот для них это, ну, просто невероятные возможности открывает". То есть это та самая демократизация, снижение порога входа. Абсолютно. Он даже цифру приводит. Примерно 20% их платящих клиентов в WORB - это как раз вот такие пользователи, не профессиональные разработчики, а люди, решающие свои задачи с помощью и по сути они и занимаются вайп-кодингом. 20% - это немало. Согласна.
Но тут же Лоид добавляет ложку дёгтя. Он говорит об острой стороне, о рисках. И где они проявляются? когда речь заходит о профессиональной разработке, о работе в команде, о больших, сложных ответственных системах. Вот тут вайп-кодинг в чистом виде, как он говорит, становится проблемой. Почему? В чём проблема-то? А проблема в том, что по своей сутийкодинг очень часто означает, что ты получаешь код, но не до конца понимаешь, как он на самом деле работает под капотом. Логично. сгенерировал что-то, оно вроде работает, а что там внутри, неясно именно. А если ты не понимаешь механику, то что? Легко пропустить ошибки, баги, проблемы с производительностью или, что ещё опаснее, дыры в безопасности. Да уж, безопасность - это серьёзно.
И ещё один момент, который Лойдт подчёркивает, особенно для командной работы. Представь, ты потратил время, сгенерировал с помощью и кучу кода, приносишь его команде. А они говорят: "Нет, это нам не подходит". Вот именно. Другие инженеры смотрят на это и просто не пропускают твой код в основной проект. И они, скорее всего, будут правы, потому что этот код может не соответствовать стандартам качества, принятым в команде, архитектуре, политикам безопасности. И получается, время потрачено зря. Да, усилия впустую. Вот оно ключевое напряжение. С одной стороны, вау, какие возможности для новичков и для себя. С другой, потенциальные проблемы и риски в профессиональной среде. Это очень важное разделение. Контекст решает всё, получается.
Хорошо, если вайп-кодинг в чистом виде рискован для профи, но полезен в других ситуациях, как быть? Можно ли его как-то, ну, приручить, сделать более ответственным, особенно для тех, кто только учится или вообще без технического бэкграунда? Алойд как раз много говорит об обучении, но с интересным акцентом. Он считает, что главное - это не зубрить синтаксис конкретного языка, будь то Python или JavaScript. А что тогда? А понимать концепции, фундаментальные вещи. Что такое база данных, зачем она нужна, какие бывают, что такое API, как устроен веб, ну хотя бы азы HTML, CSS, JavaScript, что такое переменная, цикл, условия, вот это всё, но на уровне идеи, а не конкретных команд. То есть важнее понимать, из каких кубиков строится программа и как они друг с другом связаны, чем помнить, как пишется for или if. Именно, грубо говоря, да.
И как это помогает при работе с и, если и всё равно сам код пишет? А помогает это сразу в нескольких вещах. Во-первых, если ты понимаешь эти концепции, ты можешь гораздо точнее и осмысленнее поставить задачу и агенту. Ты не просто скажешь: "Сделай мне сайт", а сможешь уточнить: "Мне нужен эээнд с такой-то базой данных, вот такой-то API для фронтенда". То есть формулировка запроса становится лучше, да? А во-вторых, и это может быть даже важнее, такое понимание просто необходимо, когда что-то идёт не так, а что-то обязательно пойдёт не так. Ну да, и же не идеален, конечно. Он может нагенерить код с ошибками или сделать не совсем то, что ты хотел, или выдать работающий прототип на 80%, а тебе нужно довести его до 100%. И вот тут, чтобы исправить, докрутить, отладить, нужно поймать основы, иначе ты просто застрянешь без шансов. Хм, интересно.
И что ещё любопытно, Лойд ведь предлагает сами и инструменты использовать для обучения, не просто как генератор кода, да? Вот это очень важный момент. В том же WB, например, можно попросить и: "А объясни-ка мне вот этот кушок кода, который ты сгенерировал. Почему ты сделал именно так? А какие были альтернативы?" То есть инструмент превращается из чёрного ящика в такого интерактивного наставника. Совершенно верно. Лойд проводит аналогию с чат GPT. Можно же просто копировать ответы на вопросы по учёбе, а можно вступить с ним диалог, задавать уточняющие вопросы, спорить и в итоге реально разобраться в теме. Вот также и с кодом. Понятно. Он считает, что вот это базовое понимание, как работают компьютеры, как устроен код, это уже не просто навык программиста, а а фундаментальный навык для любого человека в современном мире. Да, именно так.
Ну вот интервьюер Тина Хуанг, она предложила чуть другую точку зрения, немного более, скажем так, лояльную к чистому вайбкодинг. Да, у неё был интересный тейк. Она предположила, что может и не обязательно глубоко копать в сам код, если ты хорошо понимаешь ограничение инструмента. Ага. Умеешь очень чётко ставить задачу. Она там упоминала, но это requirements document, требования к продукту. или даже PRP, product requirements prompt, то есть супердетальный промпт для как техническое задание для машины. Да, и если ты знаешь, когда надо остановиться и позвать на помощь уже живого инженера, вот при таких условиях может и не нужно лезть в дебри кода. Это тоже интересная мысль. Получается, чтобкодинг сам по себе может стать отдельным навыком не программирования в классическом смысле, а умение эффективно рулить и для генерации кода, типа новая профессия и кодер, ну или что-то вроде того. Возможно, мы видим формирование нового разделения труда. Кто-то ставит задачи и рулит процессом на высоком уровне, кто-то разбирается в деталях, если нужно.
И вот тут самый главный практический вопрос. А можно ли сегодня вот прямо сейчас взять и с помощью этого вайбкодинга создать полноценное приложение такое, чтобы не стыдно было пользователям показать, запустить в продакшн? Или это всё-таки пока игрушки, личные проекты, какие-то внутренние утилиты для компании, прототипы? Да, вот это ключевой момент. Заклой тут приводит очень показательный пример. Из своей же компании WordB у них рекрутер работал, который вообще не программист. Совсем, совсем. Но он с помощью WordP взял и сделал себе инструменты для автоматизации. Довольно сложный. Кстати, что он делал? Он интегрировался с их ATS, ну, системой отслеживания кандидатов, парсил резюме, как-то их анализировал, отправлял уведомления в слаг. В общем, реально полезная штука для его личной работы. Звучит круто. Настоящий успех вайб-кодинга? Да, для него лично, безусловно. Но подвох вылез потом. Какой? Рекрутер пришёл к инженерам и спросил: "Слушайте, классная штука получилась. Давайте её как-то развернём, чтобы и другие могли пользоваться". Логично. Инженеры посмотрели на код, который сгенерировал и под руководством рекрутера, и схватились за голову. Почему? Там оказалось около 50.000 строк кода. Ого. для утилиты. Да. И этот код был, по словам Лойда, абсолютно непригоден для продакшена. Его не возможно было поддерживать, тестировать. Он не следовал никаким стандартам, принятым в компании. Просто неремонтопригодный монолит. Понятно. То есть для себя супер, для других никак. Вот именно.
Илойд говорит, что этот пример отлично иллюстрирует рождение целого нового класса программного обеспечения. Он называет его персональный софт. Персональный софт, да, это инструменты, которые люди создают для себя для решения своих уникальных специфических задач. Они очень полезны для конкретного человека, но они никогда не станут публичными продуктами. Их невозможно масштабировать или поддерживать командой. Значит, ответ на мой вопрос про продакшн приложение пока скорее нет, если говорить о чистом вайбкодинг без глубокого понимания. На данный момент, по словам Лойда, он не знает ни одного примера широко используемого коммерчески успешного приложения, которое было бы создано вот так исключительно в вайп-кодинг. Но он же наверняка верит, что это изменится. О, да. Его прогноз очень оптимистичен. Он считает, что технологии развиваются стремительно и модели становятся умнее, буквально на глазах. И он полагает, что уже через год-два, может быть, модели станут достаточно мощными, чтобы генерировать код, который будет действительно пригоден для продакшена. Надёжный, масштабируемый, безопасный. Год-два - это очень быстро по меркам индустрии. Очень. Но такова скорость прогресса выи сейчас.
А что сегодня? Какова реальность для профессиональных разработчиков, которые используют и инструменты? Сегодня реальность такова, и это мощнейший ускоритель. Он помогает писать код быстрее, генерировать рутинные куски, ну, boйлерпateт, находить ошибки, писать тесты, рефакторить. То есть ассистент, да, отличный ассистент, второй пилот, как говорят, но он не заменяет инженера. Нужен постоянный контроль, нужно понимать, что он там генерирует, нужно тщательно проверять, ревьюить. Это не волшебная кнопка сделать всё за меня. И плюс та проблема, о которой ты уже говорила. Да, Лойд её тоже подчёркивает. Фундаментальное ограничение. Даже самый умнений ИИ и Ии не сможет сделать то, что тебе нужно, если ты сам не можешь чётко и однозначно сформулировать, что именно ты хочешь. Компьютер не читает мысли. Именно, особенно, если человек и сам не до конца понимает, чего он хочет. Классика жанра в разработке ПО. Да уж, проблема постановки задачи вечна.
Хорошо, чтобы стало понятнее, как это работает на практике, давай немного про демовар, которое было в интервью. Что там показывали, как это иллюстрирует то, что мы обсуждаем? Демо было довольно наглядным, да? Во-первых, Лойд показал, как можно создать простенькое веб-приложение с нуля. Какое? Таймер Помадора. Знаешь технику управления временем, но в стиле мема Бонга Cat. Аха, Bнга Cat Помодоora. Забавно, да, и он использовал фреймвор NextGS. И самое интересное, он начал буквально с голосовой команды. Прямо голосом сказал, что хочет. Да, что-то вроде создай мне помадора таймер с Бонга Cat на nexts. Это, конечно, подчёркивает вот эту лёгкость старта, скорость прототипирования, о которой он говорил. Вайп-кодинг в действии, так сказать. Голосовое управление кодом - это сильно впечатляет. Выглядело эффектно, не спорю. Потом он показал итерацию, говорит: "И а давай улучшим визуал, добавь 3D модель кота". И агент вносит изменения тоже голосом, кажется, да? Или короткими текстовыми промптами. И вот тут важный момент. Интерфейс WordB позволял легко видеть, что именно изменил и прямо div показывал вот старый код, вот новый. То есть контроль всё-таки есть, да? И можно было ткнуть в любой кусок нового кода и попросить и: "А объясни, что ты тут сделал". Это как раз иллюстрирует то, что даже при вайп-кодинг нужен контроль и возможность разобраться, что происходит. Не просто слепая магия. Понятно. Управляемый процесс, а не чёрный ящик. Стараются сделать его управляемым.
Да, был и второй пример в демо, более такой утилитарный. Что там было? создание утилиты для командной стройки Cool на Python. Она должна была визуализировать структуру базы данных SQL. Ну, то есть просчитать схему базы и вывести её в виде аски графики прямо в терминале. Полезная штука для разработчика вполне. И тут Лойд обратил внимание вот на что. ВARP сгенерировал не только сам Python scриpt. А что ещё? Он сгенерировал юнит-тесты для этого скрипта и файл Redmi с описанием, как утилитой пользоваться. О, вот это уже серьёзнее. Тесты, документация, да, это уже гораздо ближе к такому нормальному инженерному подходу. Даже если код генерируется автоматически, он должен быть тестируемым и документированным. Это показывает, что инструменты движутся в сторону поддержки более зрелых практик разработки. Интересно.
Ну и про лошадь надо упомянуть, раз уж зашла речь. А, да, это было забавно. Лойд для запуска каких-то новых функций записал проморолик, и он там реально верхом на лошади скачет в ковбойской шляпе. Обыгрывал название Cenw. Хах. Ну и с чувством юмора у команды порядок. Это видно, запоминается, это точно. Но давай вернёмся от ковбоев к серьёзной разработке. Вот мы поговорили про вайб-кодинг для новичков и личных проектов. А как подход меняется, когда за WРP садится опытный инженер, который работает не над игрушкой с нуля, а, скажем, над самим WordB? Там же он говорил миллион строк кода на раст. Огромная кодовая база, да? Как он использует Ии в этом случае? Вот тут Лойд показал совершенно другой паттерн взаимодействия. Никакого задай мне Vibeб. А что вместо этого? Вместо общего описания, что я хочу получить в итоге, он даёт и агенту очень чёткие пошаговые инструкции, как именно нужно внести изменения. Можешь привести пример? Да, он показывал, как добавлял всплывающую подсказку, ну, лтип к какому-то элементу интерфейса в warp. И он не просто сказал: "Добавьтип", он указал вот этот конкретный UI-компонент. В нашей кодовой базе уже есть вот такие паттерны для тултипов. Используй их. тебе нужно будет задействовать вот такой-то обработчик событий. То есть он фактически диктует и алгоритм действий. Почти как стажёру бы объяснял. Очень похоже. Он использует и не как самостоятельного творца, а как очень продвинутого, но исполнительного ассистента, которому нужно точно сказать, что и как делать, опираясь на существующий контекст. Понятно. Роль инженера смещается в сторону архитектора, постановщика задач и ревьювера. для ИИИ. Абсолютно верно. И он активно помогает ИИ, даёт ему максимум контекста, говорит: "Смотри вот в эти файлы". Может прикрепить скриншот с проблемой, которую нужно исправить. И контроль. Контроль - это ключевое. Инженер постоянно следит за тем, что предлагает AI. Wordb показывает изменения div, и инженер их внимательно просматривает. Если что-то не так, он не просто откатывает, а даёт и корректирующее указание. Нет, вот здесь ты сделал неправильно, потому что переделай вот так. Это реально похоже на кодрев, только ревьюируемый это AI. Именно так это и выглядит. Это кардинально отличается от того наивного вайпкодинг, где ты просто ждёшь магического результата. Да, разница огромная.
Интересно, а как Лойд вообще позиционирует WB на рынке? Сейчас же много и инструментов для кодинга появляется. Он проводит такое различие. Есть инструменты вроде RLТ или Bolt. Они больше про создание веб-приложений с нуля, часто прямо в облаке в браузере. Ага. А Wordb также, как, например, CERS или AI помощники в ID типа Copilot или Cloud Code. Это скорее локальное приложение. Ты ставишь его себе на компьютер и работаешь со своими проектами, со своими репозиториями, которые лежат у тебя на диске. Понятно? То есть для работы с существующим кодом, да. Но уникальность WordP, по мнению Лойда, в том, что он построен вокруг терминала, вокруг командной строки. Почему? Он верит, что будущее разработки - это не столько ручное редактирование кода в текстовом редакторе или IDE, сколько управление AIгентами. Ты будешь говорить агенту, что делать через команды, через промпты. А терминал - это естественная среда для такого взаимодействия. Но терминал же обычно чисто текстовой, не очень удобный. Вот. А WordP пытается это исправить. Они делают удобный графический интерфейс UI поверх терминала, специально заточенный под взаимодействие с II, чтобы было и мощно, как в терминале, и удобно, как в ГУИ. Интересный гибрид.
А как они сами-то разрабатывают? С помощью ВARP есть какие-то внутренние правила? Да, он упоминал, что у них есть внутренний документ типа гайдлайна. Называется что-то вроде как WORP использует свой P для создания Вар. Забавно. И какие там ключевые принципы? Ну, он выделил несколько. Инженер всегда несёт финальную ответственность за код. И - это инструмент, а неответственный. Важно говорить агенту не только что делать, но и как делать, особенно в сложном коде. Задачи нужно дробить. Не просить ей сделать что-то огромное сразу, а разбивать на мелкие управляемые шаги. Нужно понимать код, который генерирует, и нельзя принимать его на веру слепо. Нужно постоянно учиться и совершенствовать свои навыки промтинга, то есть умение правильно ставить задачи. Ии логично, всё сводится к осознанности и контролю.
Кстати, ты упомянула, что ВАРP начинался не с ИИ. Да, это тоже интересный момент. Компания ВАРP уже около 5 лет. Изначально их идея была просто сделать терминал лучше, удобнее, быстрее, современнее. То есть и пришёл позже, да? Когда появились мощные языковые модели в RGPT, команда Вар поняла, что ИИ идеально ложится на их концепцию улучшенного терминала, что И может кардинально изменить само взаимодействие человека с компьютером через командную строку и не только. И продукт начал эволюционировать от просто лучшего терминала к терминалу с е помощником, а теперь уже к тому, что они называют агентивной средой разработки. То есть миссия осталась помогать разработчикам работать быстрее и лучше, но путь к ней сильно изменился под влиянием ИИ. Именно так.
Хорошо, давай теперь затронем ещё один острый вопрос. Безопасность. Да, важная тема. звучат опасения, даже исследования какие-то были, что и е ассистенты, они, конечно, помогают писать больше кода и быстрее. Угу. Но при этом и уязвимости в этом коде может оказаться больше, потому что генерируется быстро, может не всегда продуманно. Как с этим быть? Как Лойд и Вар на это смотрят. Позиция Лойда тут такая многослойная. Во-первых, он опять возвращается к инженерной культуре. и личной ответственности. Разработчик должен проверять код, сгенерированный и так же тщательно, как если бы он писал его сам. Никаких поблажек. То есть человеческий фактор ключевой, да? Во-вторых, сами инструменты должны помогать в этом контроле. Тот же варп, который показывает все изменения и, позволяет их детально изучить, это шаг в нужную сторону. О'кей? Что ещё? Вретих, резко возрастает роль автоматических средств проверки. статические анализаторы, кода, линтеры, сканеры безопасности. Все эти инструменты становятся ещё важнее. Их нужно встраивать в рабочий процесс, чтобы они ловили проблемы как можно раньше. Автоматизация контроля, да? И в четвёрток, что интересно, сам ИИ может стать частью решения проблемы, которую он же и помогает создавать. То есть и будет проверять код, написанный другим и человеком с помощью и именной упоминает, что в есть функция, когда ты можешь попросить и агента, а проверка вот этот код на потенциальную уязвимости. И может быть натренирован находить типичные паттерны небезопасного кода. И ловит ошибки и любопытно получается такой замкнутый круг немного, ну или спираль развития, где инструменты становятся умнее и помогают на разных этапах.
Хорошо. И вот мы подходим к концу нашего разговора. Какой главный совет Заклойд даёт тем, кто сейчас смотрит на все эти и возможности и думает: "А может мне свой стартап запустить или просто какой-то проект сделать?" Даже если опыта в кодинге особо нет? Он настроен очень позитивно и ободряюще. Он считает, что да, сейчас действительно можно очень быстро создать работающий прототип MVP minimum viable product, используя EИe. И потолок сложности задач, которые можно решить таким образом, будет только расти. То есть дерзайте, да, но с важным уточнением. Его главный совет не просто делать что-то прикольное с и, а браться за решение реальных значимых проблем. То есть фокус на проблеме, а не на технологии. Именно найти то, что тебя лично волнует, к чему есть страсть, интерес, какую-то боль, которую ты хочешь убрать. По его мнению, в мире полно больших важных задач, которые ждут своего решения. А ИИ - это инструмент, который сейчас значительно снижает барьер входа. Он позволяет большему числу людей, даже без глубоких технических знаний, попробовать свои силы в создании чего-то по-настоящему ценного. искать проблему, в которую веришь, и использовать и и как рычаг для её решения. Да, вот это его основной посыл для начинающих предпринимателей и создателей. Отлично.
Ну что ж, давай тогда подводить итоги нашего погружения. Давай. Вайкодинг - это явно не просто модное словечко, не просто хайп. Нет, это отражение реальных изменений и становится активным участником процесса создания софта. нравится нам это или нет. И это открывает, ну, действительно, огромные возможности, особенно для тех, кто не был программистом раньше, для создания вот этого персонального софта, для быстрого прототипирования, для решения каких-то узких нишевых задач. Безусловно, но как мы услышали от Закалойда, эта новая сила, она требует, ну, ответственности, осознанности, да, для создания чего-то серьёзного, надёжного. масштабируемого просто вайба недостаточно. Нужен инженерный подход, понимание основ, готовность контролировать, проверять, брать на себя ответственность за результат работы Ии. И инструменты вроде WB, они как раз и пытаются нащупать этот баланс, дать среду, где можно продуктивно и что важно управляемо взаимодействовать человеку и машине. Да, чтобы это был не хаос, а сотрудничество. И вот эта граница между чистым iglub кодинг для себя и профессиональной разработкой с использованием и она становится всё более м такой размытой, гибкой. Согласен.
И вот финальная мысль, которую хочется как-то подбросить на подумать. Угу. А что, если и действительно научится генерировать код очень высокого качества, прямо вот продакшн уровня? По детальному запросу, конечно, не сместится ли тогда фокус в работе самого разработчика? В какую сторону? Может быть, главным навыком будущего станет не столько виртуозное владение синтаксисом Java или Python. А что тогда? А умение глубоко, досконально понимать предметную область, для которой пишется софт. способность предельно точно, формально, непротиворечиво сформулировать задачу для и, конечно, критически оценить результат его работы, соответствует ли он бизнес-целям, требованиям безопасности, этическим нормам. То есть разработчик как переводчик с языка бизнеса и предметной области на язык формальных спецификаций для ИИ и как главный контролёр качества. Ну, как вариант, что станет ядром инженерной компетенции в эту новую эпоху? Вот вопрос. Да, вопрос отличный. Есть над чем подумать. Спасибо тебе за этот интересный разбор. И тебе спасибо. И спасибо всем, кто был с нами. Да, до новых встреч.