Что если создать мобильное приложение, не зная ни строчки кода на Swift? Добро пожаловать в мир вайбкодинга — нового стиля программирования «по настроению», где естественный язык и LLM заменяют синтаксис и компиляторы.

Во второй части выступления Андрея Карпатого мы также поговорим о новом типе «пользователей» — LLM‑агентах («духах людей») и о том, как адаптировать нашу инфраструктуру (документацию, API, сайты) для их удобства с помощью... llms.txt. Готовы ли вы кодить «в потоке» и строить для нечеловеческих интеллектов?

Часть 1
Часть 2

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

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

Запрос vs результат: как избежать разочарований

Совсем недавно я наткнулся на несколько блогов, где описывались лучшие практики работы с LLM, и один из них особенно мне запомнился. В нём говорилось о подходах и уловках, которые помогают «удерживать ИИ на поводке». К примеру, если ваш запрос слишком расплывчат, система может и не выдать то, что вы хотите, — в таком случае придётся переделывать проверку и формулировать задачу заново. Это создаёт ненужные циклы работы. Именно поэтому стоит потратить немного больше времени на первоначальную формулировку деталей запроса. Чем яснее запрос, тем выше вероятность, что проверка пройдёт успешно и можно будет сразу двигаться дальше.

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

Расскажу историю, которая хорошо передаёт мои мысли. Впервые я сел за руль беспилотного автомобиля в 2013 году: у меня был друг, работавший в Waymo, и он предложил прокатиться вокруг Пало‑Альто. Я тогда сделал фото с помощью Google Glass, в то время это была настоящая новинка, про которую говорили все. Мы сели в машину и проехали около 30 минут по улицам, шоссе... Всё прошло идеально: за всю поездку не понадобилось ни одного вмешательства в процесс вождения.

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

Пример отлично иллюстрирует то, что разработка программного обеспечения действительно сложна. И когда я слышу заявления вроде «2025 год станет годом агентов», мне становится тревожно: мне кажется, что это не год, а десятилетие агентов и работа над этим займёт гораздо больше времени. Нужно вовлекать людей в процессы, действовать осторожно и вдумчиво, ведь это программное обеспечение, а не волшебство. Давайте относиться к этому серьёзно.

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

Вайбкодинг

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

Слышали ли вы когда‑нибудь про вайбкодинг? Да, название стало мемом благодаря твиту, который породил целое движение.

Забавная история связана с тем, что за свои, кажется, пятнадцать лет в соцсети я так и не научился предсказывать, какой твит станет вирусным, а какой утонет в шуме, никем не замеченный. Я думал, что тот конкретный твит как раз окажется чем‑то малозаметным — таким себе потоковым размышлением, которому суждено затеряться, — но, внезапно, он стал мемом. Похоже, он нашёл отклик, сумел выразить то, что многие чувствовали, но не знали, как сформулировать. Сейчас уже даже есть страница на «Википедии» — выглядит как мой серьёзный вклад.

Естественно, я не мог не попробовать вайбкодинг сам, ведь он безумно весёлый. Вайбкодинг идеален, если вы хотите создать что‑то абсолютно уникальное, чего ещё не существует, — и вам просто хочется «пофантазировать», особенно в какой‑нибудь субботний день.

Я создал небольшое iOS‑приложение. Забавно, что я даже не умею программировать на Swift, но меня поразило, как быстро я смог создать что‑то на уровне простейшего приложения. Прошу вас, не ждите глубокой сути, это довольно глупая вещь, но важно то, что спустя всего день я уже смог запустить его на своём телефоне. И я подумал: ух ты, это невероятно... Мне не пришлось неделями изучать основы Swift или копаться в документации.

Позже я вайбкодил ещё одно приложение, которое называется MenuGen, и оно доступно по адресу https://menugen.app.

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

В MenuGen вы просто фотографируете меню, а приложение генерирует изображения блюд. Каждый, кто подписывается, получает 5 $ бонуса на счёт.

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

Честно говоря, было поразительно, что MenuGen в виде прототипа работал столь быстро, а превращение в реальный продукт заняло столько сил лишь из‑за невероятной муторности процесса.

Например, если вы пробуете добавить вход через Google на свой сайт, инструкция от библиотеки вроде Clerk покажется огромной стеной текста. Вот вам пример: бесконечный список шагов — «Перейдите по этой ссылке», «Выберите этот выпадающий список», «Нажмите там». Машина буквально диктует мне, что нужно делать. И я думаю: «Ну почему ты, компьютер, не можешь сделать это сам? Зачем я трачу время?!» Просто безумие!

Строим для агентов

Итак, финальная часть моего выступления сосредоточена на вопросе: а можем ли мы создавать непосредственно для агентов?

Если говорить в общих чертах, то перед нами возникла совершенно новая категория потребителей и манипуляторов цифровой информации. Раньше это были только люди — через GUI‑интерфейсы или компьютеры — через API, а сейчас у нас появился совершенно новый субъект. Агенты — конечно, компьютеры, но в то же время… они почти как люди, не так ли? Эти эдакие «духи людей», обитающие в сети. Им необходимо взаимодействовать с нашей программной инфраструктурой. И нам стоит спросить себя: что мы можем для них соорудить?

У вас на сайте может быть файл robots.txt, в котором веб‑краулеры получают указания о том, как вести себя на ресурсе. Аналогично вы можете создать файл llms.txt — простой текст в формате Markdown, объясняющий большим языковым моделям, о чём ваш домен. Чрезвычайно удобно для восприятия со стороны LLM.

Если вместо этого модель попытается анализировать HTML вашего сайта, всё превратилось бы в более сложный процесс, а вот прямое взаимодействие с LLM в виде удобного для неё формата информации — уже принесёт гораздо больше пользы. Это стоит того.

Однако некоторые сервисы начали адаптировать свои документы специально для LLM. Например, компании Vercel и Stripe уже стали первопроходцами в этом направлении, кроме того я видел ещё кое‑какие примеры. Компании представляют свою документацию в формате Markdown, который великолепно интерпретируется LLM.

Приведу понятный лично мне случай. Может быть, вы знаете 3Blue1Brown — он создаёт анимационные видеоролики на YouTube. Да, я обожаю эту библиотеку, Manim, которую он написал. Так вот, однажды я захотел создать свою собственную анимацию — к счастью, для Manim есть подробная документация о том, как её использовать, но мне вовсе не хотелось тратить время на изучение всех подробностей. Вместо того я скопировал весь текст документации, вставил его в LLM, описал, что хочу получить… и оно сработало! LLM просто создала на лету анимацию, которую я задумал! И я был просто в восхищении, это было невероятно.

Вот почему, если мы сделаем нашу документацию более доступной для LLM, то сможем открыть невероятное количество новых возможностей. Я считаю, что подход нужно внедрять повсеместно.

Ещё один нюанс, который стоит подчеркнуть, — проблема состоит не только в преобразовании документации в Markdown (это довольно простая задача); нужно модернизировать её, ведь всякий раз, когда в документации появляется «Кликните здесь», возникает препятствие. LLM пока просто не может выполнить такое действие.

К слову, Vercel заменяет любую инструкцию со словом «click» на эквивалентную для агентов curl‑команду, которую LLM может выполнить от вашего имени. Кроме того, существует так называемый Model Context Protocol от Anthropic, позволяющий общаться с агентами напрямую. Я искренне верю в такие идеи и их потенциал.

Также меня радует появление множества полезных инструментов, упрощающих работу с данными в форматах, удобных для LLM. Например, когда я захожу в репозиторий на GitHub, скажем в свой NanoGPT, накормить LLM этим репозиторием и запустить вопросы там напрямую не получается — GitHub всё‑таки предназначен для людей. Но если просто изменить ссылку с GitHub на Gitingest, инструмент конкатенирует все файлы в единый текст, создаёт структуру директорий и делает их готовыми для вставки в вашу любимую LLM. Согласитесь, удобно?

Возможно, ещё более впечатляющий пример — это DeepWiki. Здесь дело не ограничивается простым предоставлением сырых данных из файлов. DeepWiki анализирует содержимое репозитория GitHub, а затем создаёт полноценные страницы документации, предназначенные именно для LLM. Представьте, насколько это может помочь в работе: копируете текст, вставляете его в LLM и получаете готовое решение. Впечатляет, не правда ли?

Мне очень нравятся подобные инструменты, которые предполагают всего одно изменение в URL, а делают данные доступными для LLM. Это чудесно, и, я уверен, таких решений должно быть больше.

Говоря о работе с LLM в удобном интерфейсе, стоит упомянуть BotHub. Это платформа, где можно запустить различных чат‑ботов (ChatGPT, DeepSeek, Gemini и др.), а также генераторы изображений (Midjourney, Flux) и видео (Google Veo, Runway) — всё собрано в одной системе. Попробуйте BotHub по специальной ссылке — она даёт 100 000 стартовых токенов!

Подводя итог…

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

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

Мне самому безумно интересно, во что всё выльется. Не могу дождаться момента, когда мы будем создавать это вместе с вами.

Вайбкодинг демонстрирует невероятную мощь программирования естественным языком с помощью LLM, позволяя за считанные часы воплощать идеи в рабочие прототипы вроде MenuGen. Развитие LLM‑агентов требует фундаментальной перестройки того, как мы представляем информацию и функционал — через LLM‑ориентированную документацию и специализированные инструменты. Мы находимся в начале пути, где лёгкость вайбкодинга сочетается с вызовами интеграции, а привычные интерфейсы адаптируются под новых пользователей‑агентов. Это время экспериментов, переосмысления и огромных возможностей для тех, кто готов строить не только с помощью ИИ, но и для ИИ.