Vibe coding MenuGen

Vibe coding MenuGen

Вайб-кодинг MenuGen

27 Apr, 2025

27 апреля 2025

Very often, I sit down at a restaurant, look through their menu, and feel... kind of stuck. What is Pâté again? What is a Tagine? Cavatappi... that's a pasta right? Sweetbread sounds delicious (I have a huge sweet tooth). It can get really out of hand sometimes. "Confit tubers folded with matured curd and finished with a beurre noisette infusion." okay so... what is this exactly? I've spent so much of my life googling pictures of foods that when the time came to attend a recent vibe coding hackathon, I knew it was the perfect opportunity to finally build the app I always wanted, but could nowhere find. And here it is in flesh, I call it... 🥁🥁🥁 ... MenuGen:

Очень часто я сажусь в ресторане, листаю меню и чувствую себя... в тупике. Что такое паштет? Что такое тажин? Каватаппи... это же паста, верно? Sweetbread звучит восхитительно (я ужасный сладкоежка). Иногда всё это заходит совсем далеко. «Конфи из клубней, смешанное с выдержанным творожным сыром и заправленное инфузией из beurre noisette.» Ладно, и... что это вообще такое? Я столько времени в жизни провёл, гугля фотографии блюд, что когда подвернулась возможность поучаствовать в хакатоне по вайб-кодингу, я понял: это идеальный шанс наконец создать приложение, которое я всегда хотел, но нигде не мог найти. И вот оно, во плоти. Я называю его... 🥁🥁🥁 ... MenuGen:

MenuGen is super simple. You take a picture of a menu and it generates images for all the menu items. It visualizes the menu. Obviously it's not exactly what you will be served in that specific restaurant, but it gives you the basic idea: Some of these dishes are salads, this is a fish, this is a soup, etc. I found it so helpful in my personal use that after the hackathon (where I got the first version to work on localhost) I continued vibe coding a bit to deploy it, add authentication, payments, and generally make it real. So here it is, give it a shot the next time you go out :): menugen.app!

MenuGen устроен предельно просто. Вы фотографируете меню, и приложение генерирует изображения для всех позиций. Оно визуализирует меню. Разумеется, это не в точности то, что вам подадут именно в этом ресторане, но даёт общее представление: вот это — салаты, это — рыба, это — суп и так далее. Мне это оказалось настолько полезным, что после хакатона (где я заставил первую версию работать на localhost) я продолжил вайб-кодить — задеплоил приложение, добавил аутентификацию, платежи и в целом довёл его до ума. Так что вот, попробуйте в следующий раз, когда пойдёте куда-нибудь поужинать :): menugen.app!

MenuGen is my first end-to-end vibe coded app, where I (someone who tinkers but has little to no actual web development experience) went from scratch all the way to a real product that people can sign up for, pay for, get utility out of, and where I pocket some good and honest 10% markup. It's pretty cool. But in addition to the utility of the app, MenuGen was interesting to me as an exploration of vibe coding apps and how feasible it is today. As such, I did not write any code directly; 100% of the code was written by Cursor+Claude and I basically don't really know how MenuGen works in the conventional sense that I am used to. So now that the project is "done" (as in the first version seems to work), I wanted to write up this quick post on my experience - what it looks like today for a non-webdev to vibe code a web app.

MenuGen — моё первое от и до вайб-закоженное приложение: я (человек, который поковыривается в коде, но практически не имеет реального опыта веб-разработки) прошёл путь с нуля до настоящего продукта, на который люди могут зарегистрироваться, заплатить, получить пользу, а я — положить в карман честные 10% наценки. Это впечатляет. Но помимо практической ценности приложения, MenuGen был для меня интересен как исследование вайб-кодинга и его реальной осуществимости сегодня. Поэтому я не писал код напрямую; 100% кода написано Cursor+Claude, и я, по сути, не знаю, как MenuGen работает в том привычном смысле, к которому привык. Теперь, когда проект «готов» (то есть первая версия вроде бы работает), я хотел написать этот короткий пост о своём опыте — как сегодня выглядит вайб-кодинг веб-приложения для человека без опыта в веб-разработке.

First, local version. In what is a relatively common experience in vibe coding, the very first prototype of the app running on my local machine took very little time. I took Cursor + Claude 3.7, I gave it the description of the app, and it wrote all the React frontend components very quickly, laying out a beautiful web page with smooth, multicolored fonts, little CSS animations, responsive design and all that, except for the actual backend functionality. Seeing a new website materialize so quickly is a strong hook. I felt like I was 80% done but (foreshadowing...) it was a bit closer to 20%.

Сначала — локальная версия. Как это часто бывает при вайб-кодинге, самый первый прототип приложения на локальной машине занял совсем немного времени. Я взял Cursor + Claude 3.7, дал описание приложения, и он очень быстро написал все React-компоненты фронтенда, собрав красивую веб-страницу с плавными разноцветными шрифтами, маленькими CSS-анимациями, адаптивной вёрсткой и всем прочим — за исключением собственно бэкенд-функциональности. Видеть, как новый сайт материализуется так быстро — мощный крючок. Мне казалось, что я сделал 80%, но (спойлер...) на самом деле это было ближе к 20%.

OpenAI API. Around here is where some of the troubles started. I needed to call OpenAI APIs to OCR the menu items from the image. I had to get the OpenAI API keys. I had to navigate slightly convoluted menus asking me about "projects" and detailed permissions. Claude kept hallucinating deprecated APIs, model names, and input/output conventions that have all changed recently, which was confusing, but it resolved them after I copy pasted the docs back and forth for a while. Once the individual API calls were working, I immediately ran into some heavy rate limiting of the API calls, allowing me to only issue a few queries every 10 minutes.

OpenAI API. Примерно здесь начались первые проблемы. Мне нужно было вызывать OpenAI API для OCR-распознавания позиций меню из изображения. Пришлось получить ключи OpenAI API. Пришлось разбираться в слегка запутанных меню с «проектами» и детальными правами доступа. Claude постоянно галлюцинировал устаревшие API, названия моделей и форматы ввода/вывода, которые недавно изменились, — это сбивало с толку, но в итоге всё разрешилось после того, как я какое-то время перекидывал туда-сюда куски документации. Когда отдельные вызовы API наконец заработали, я тут же упёрся в жёсткий рейт-лимитинг — мне разрешалось отправлять лишь несколько запросов раз в 10 минут.

Replicate API. Next, I needed to generate images given the descriptions. I signed up for a new Replicate API key and ran into similar issues relatively quickly. My queries didn't work because LLM knowledge was deprecated, but in addition, this time even the official docs were a little bit out of date due to recent changes in the API, which now don't return the JSON directly but instead some kind of a Streaming object that neither I or Claude understood. I then faced rate limiting on the API so it was difficult to debug the app. I was told later that these are common protection measures by these services to mitigate fraud, but they also make it harder to get started with new, legitimate accounts. I'm told Replicate is moving to a different approach where you pre-purchase credits, which might help going forward.

Replicate API. Далее мне нужно было генерировать изображения по описаниям. Я зарегистрировался, получил новый ключ Replicate API и довольно быстро столкнулся с похожими проблемами. Мои запросы не работали, потому что знания LLM были устаревшими, но вдобавок на этот раз даже официальная документация немного отставала из-за недавних изменений в API, который теперь возвращал не JSON напрямую, а некий Streaming-объект, который ни я, ни Claude не понимали. Затем я упёрся в рейт-лимитинг API, из-за чего отладка приложения стала крайне затруднительной. Мне потом объяснили, что это стандартные меры защиты от мошенничества, но они же усложняют старт для новых легитимных аккаунтов. Мне говорят, что Replicate переходит на другую модель с предоплатой кредитов, что может помочь в будущем.

Vercel deploy. At this point at least, the app was working locally so I was quite happy. It was time to deploy the basic first version. Sign up for Vercel, add project, configure it, point it at my GitHub repo, push to master, watch a new Deployment build and... ERROR. The logs showed some linting errors due to unused variables and other basic things like that, but it was hard to understand or debug because everything worked fine on local and only broke on Vercel build, so I debugged the issues by pushing fake debugging commits to master to force redeploys. Once I fixed these issues, the site still refused to work. I asked Claude. I asked ChatGPT. I consulted docs. I googled around. 1 hour later I finally realized my silly mistake - My .env.local file stored the API keys to OpenAI and Replicate, but this file is (correctly!) part of .gitignore and doesn't get pushed to git, so you have to manually navigate to Vercel project settings, find the right place, and add your environment keys manually. I kind of understood the issue relatively quickly, but I could see an aspiring vibe coder get stuck on this for a while. Once the deployment finally succeeded, Vercel happily offered a URL. This surprised me again because my project was a private git repo that was not ready to see the light of day. I didn't realize that Vercel will take your !private! repo of an unfinished project and auto-deploy it on a totally public and easy to guess url just like that, hah.

Деплой на Vercel. К этому моменту приложение хотя бы работало локально, и я был доволен. Пришло время задеплоить базовую первую версию. Регистрация на Vercel, добавление проекта, настройка, привязка к моему GitHub-репозиторию, пуш в master, наблюдение за новым деплоем и... ОШИБКА. В логах были какие-то ошибки линтера из-за неиспользуемых переменных и тому подобных мелочей, но разобраться было сложно, потому что локально всё работало, а ломалось только при сборке на Vercel. Так что я дебажил, пуша фейковые отладочные коммиты в master, чтобы вызвать передеплой. Когда я исправил эти проблемы, сайт всё равно отказывался работать. Я спрашивал Claude. Спрашивал ChatGPT. Читал документацию. Гуглил. Через час я наконец осознал свою глупую ошибку — мой файл .env.local хранил API-ключи OpenAI и Replicate, но этот файл (и правильно!) включён в .gitignore и не попадает в git, поэтому нужно вручную зайти в настройки проекта на Vercel, найти нужное место и добавить переменные окружения руками. Я-то понял проблему относительно быстро, но могу представить, как начинающий вайб-кодер застрял бы на этом надолго. Когда деплой наконец удался, Vercel радостно предложил URL. Это меня снова удивило, потому что мой проект был приватным git-репозиторием, который не был готов увидеть свет. Я не ожидал, что Vercel возьмёт ваш приватный! репозиторий с незаконченным проектом и автоматически задеплоит его на совершенно публичный и легко угадываемый URL — вот так просто, ха.

Clerk authentication. Claude suggested that we use Clerk for authentication, so I went along with it. Signed up for Clerk, configured the project, got my API keys. At this point Claude hallucinated about 1000 lines of code that appeared to be deprecated Clerk APIs. I had to copy paste a lot of the docs back and forth to get things gradually unstuck. Next, so far, Clerk was running in a "Development" deployment. To move to a "Production" deployment, there were more hoops to jump through. Clerk demands that you host your app on a custom domain that you own. menugen.vercel.com will not work. So I had to purchase the domain name menugen.app. Then I had to wire the domain to my Vercel project. Then I had to change the DNS records. Then I had to pick an OAuth provider, e.g. I went with Google. But to do that was its own configuration adventure . I had to enable an "SSO connection". I had to go over to Google Cloud Console and create a new project, and add a new OAuth Credential. I had to wait some time for an approval process around here. I then had to go back and forth between the nested settings of all of Vercel, Clerk and Google for a while to wire it up properly. I thought of quitting the project around here, but I felt better when I woke up the next morning.

Аутентификация через Clerk. Claude предложил использовать Clerk для аутентификации, и я согласился. Зарегистрировался в Clerk, настроил проект, получил API-ключи. На этом этапе Claude нагаллюцинировал около 1000 строк кода, которые, по всей видимости, использовали устаревшие API Clerk. Мне пришлось долго перекидывать туда-сюда куски документации, чтобы постепенно сдвинуться с мёртвой точки. Далее — до сих пор Clerk работал в режиме «Development». Чтобы перейти на «Production», нужно было пройти ещё ряд квестов. Clerk требует, чтобы приложение было размещено на собственном домене. menugen.vercel.com не подходит. Так что пришлось купить доменное имя menugen.app. Потом привязать домен к моему проекту на Vercel. Потом изменить DNS-записи. Потом выбрать OAuth-провайдера — я выбрал Google. Но это само по себе оказалось отдельным конфигурационным приключением. Нужно было включить «SSO connection». Зайти в Google Cloud Console и создать новый проект, добавить новый OAuth Credential. Подождать какое-то время, пока пройдёт процесс одобрения. Потом долго переключаться между вложенными настройками Vercel, Clerk и Google, чтобы всё правильно связать. Примерно здесь я подумал бросить проект, но на следующее утро мне стало легче.

Stripe payments. Next I wanted to add payments so that people can purchase credits. This means another website, another account, more docs, more keys. I select "Next.js" as the backend, copy paste the very first snippet of code from the "getting started" docs into my app and... ERROR. I realized later that Stripe gives you JavaScript code when you select Next.js, but my app is built in TypeScript, so every time I pasted a snippet of code it made Cursor unhappy with linter errors, but Claude patched things up ok over time after I told it to "fix errors" a few times and after I threatened to switch to ChatGPT. Then back in the Stripe dashboard we create a Product, we create a Price, we find the price key (not the product key!), copy paste all the keys around. Around here, I caught Claude using a really bad idea approach to match up a successful Stripe payment to user credits (it tried to match up the email addresses, but the email the user might give in the Stripe checkout may not be the email of the Google account they signed up with, so the user might not actually get the credits that they purchased). I point this out to Claude and it immediately apologizes and rewrites it correctly by passing around unique user ids in the request metadata. It thanks me for pointing out the issue and tells me that it will do it correctly in the future, which I know is just gaslighting. But since our quick test works, only a few more clicks to upgrade the deployment from Development to Production, now re-do a new Product, redo a new Price, re-copy paste all the keys and ids, locally and in the Vercel settings... and then it worked :)

Платежи через Stripe. Затем я хотел добавить платежи, чтобы люди могли покупать кредиты. А значит — ещё один сайт, ещё один аккаунт, ещё документация, ещё ключи. Выбираю «Next.js» в качестве бэкенда, копирую самый первый фрагмент кода из документации «getting started» в своё приложение и... ОШИБКА. Позже я понял, что Stripe выдаёт JavaScript-код, когда вы выбираете Next.js, а моё приложение написано на TypeScript, поэтому каждый раз, когда я вставлял фрагмент кода, Cursor ругался ошибками линтера. Но Claude со временем всё подлатал после того, как я пару раз сказал ему «исправь ошибки» и пригрозил перейти на ChatGPT. Потом обратно в панель Stripe — создаём Product, создаём Price, находим ключ цены (не ключ продукта!), копируем все ключи туда-сюда. Примерно здесь я поймал Claude на использовании очень плохого подхода к сопоставлению успешного платежа Stripe с кредитами пользователя (он пытался сопоставить по email-адресам, но email, который пользователь указывает при оплате через Stripe, может не совпадать с email Google-аккаунта, через который он зарегистрировался, — и тогда пользователь просто не получит купленные кредиты). Я указал на это Claude, и он немедленно извинился и переписал всё правильно, передавая уникальные идентификаторы пользователей в метаданных запроса. Он поблагодарил меня за замечание и пообещал, что в будущем будет делать правильно, — что, я знаю, просто газлайтинг. Но поскольку наш быстрый тест сработал, оставалось лишь несколько кликов, чтобы перевести деплой из Development в Production, заново создать Product, заново создать Price, заново скопировать все ключи и идентификаторы — локально и в настройках Vercel... и тогда всё заработало :)

Database? Work queues? So far, all of the processing is done "in the moment" - it's just requests and results right there and then, nothing is cached, saved, or etc. So the results are ephemeral and if the response takes too long (e.g. because the menu is too long and has too many items, or because the APIs show too much latency), the request can time out and break. If you refresh the page, everything is gone too. The correct way to do this is to have a database where we register and keep track of work, and the client just displays the latest state as it's ready. I realized I'd have to connect a database from the Marketplace, something like Supabase PostgreSQL (even when Claude pitched me on using Vercel KV, which I know is actually deprecated). And then we'd also need some queue service like Upstash or so to run the actual processing. It would mean more services. More logins. More API keys. More configurations. More docs. More suffering. It was too much bear. Leave as future work.

База данных? Очереди задач? До сих пор вся обработка происходила «на лету» — просто запросы и результаты здесь и сейчас, ничего не кешируется, не сохраняется и т. д. Результаты эфемерны: если ответ занимает слишком много времени (например, потому что меню слишком длинное с кучей позиций, или API слишком тормозят), запрос может упасть по таймауту. Если обновить страницу — всё пропадает. Правильный подход — иметь базу данных, где регистрируются и отслеживаются задачи, а клиент просто отображает последнее состояние по мере готовности. Я понял, что мне придётся подключить базу данных из маркетплейса — что-нибудь вроде Supabase PostgreSQL (притом что Claude предлагал мне Vercel KV, который, я знаю, на самом деле deprecated). А ещё нужен какой-то сервис очередей типа Upstash для собственно обработки. Это означало бы ещё больше сервисов. Ещё больше логинов. Ещё больше API-ключей. Ещё больше конфигураций. Ещё больше документации. Ещё больше страданий. Слишком много для одного медведя. Оставлено на будущее.

TLDR. Vibe coding menugen was exhilarating and fun escapade as a local demo, but a bit of a painful slog as a deployed, real app. Building a modern app is a bit like assembling IKEA future. There are all these services, docs, API keys, configurations, dev/prod deployments, team and security features, rate limits, pricing tiers... Meanwhile the LLMs have slightly outdated knowledge of everything, they make subtle but critical design mistakes when you watch them closely, and sometimes they hallucinate or gaslight you about solutions. But the most interesting part to me was that I didn't even spend all that much work in the code editor itself. I spent most of it in the browser, moving between tabs and settings and configuring and gluing a monster. All of this work and state is not even accessible or manipulatable by an LLM - how are we supposed to be automating society by 2027 like this?

Итого. Вайб-кодинг MenuGen был захватывающим и весёлым приключением в качестве локальной демки, но довольно мучительной рутиной в качестве задеплоенного, настоящего приложения. Создание современного приложения — это что-то вроде сборки мебели из IKEA из будущего. Куча сервисов, документации, API-ключей, конфигураций, dev/prod-деплоев, командных и security-фич, рейт-лимитов, тарифных планов... При этом у LLM слегка устаревшие знания обо всём, они допускают тонкие, но критичные ошибки проектирования, если внимательно за ними следить, а иногда галлюцинируют или газлайтят вас по поводу решений. Но самое интересное для меня — я потратил не так уж много времени в самом редакторе кода. Большую часть времени я провёл в браузере, переключаясь между вкладками, настройками и склеивая монстра. Вся эта работа и состояние даже не доступны и не манипулируемы для LLM — как мы собираемся автоматизировать общество к 2027 году при таком раскладе?

Going forward. As an exploration of what it's like to vibe code an app today if you have little to no web dev background, I'm left with an equal mix of amazement (it's actually possible and much easier/faster than what was possible before!) and a bit of frustration of what could be. Part of the pain of course is that none of this infrastructure was really designed to be used like this. The intended target audience are teams of professional web developers living in a pre-LLM world. Not vibe coding solo devs prototyping apps. Some thoughts on solutions that could make super simple apps like MenuGen a lot easier to create:

Что дальше. Как исследование того, каково сегодня вайб-кодить приложение, если у тебя мало или совсем нет опыта веб-разработки, я остался с одинаковой смесью восхищения (это действительно возможно и намного проще/быстрее, чем раньше!) и доли разочарования от того, что могло бы быть. Часть боли, конечно, в том, что вся эта инфраструктура не была рассчитана на такое использование. Целевая аудитория — команды профессиональных веб-разработчиков, живущие в мире до LLM. А не вайб-кодеры-одиночки, прототипирующие приложения. Несколько мыслей о решениях, которые могли бы сделать создание сверхпростых приложений вроде MenuGen намного проще:

Какая-нибудь платформа для разработки приложений могла бы поставляться со всем необходимым «из коробки». Что-то, что выглядит как противоположность Vercel Marketplace. Что-то предвзятое, конкретное, предварительно настроенное со всеми базовыми вещами, которые нужны каждому: домен, хостинг, аутентификация, платежи, база данных, серверные функции. Если бы какой-то сервис сделал всё это легко и «просто работающим» из коробки — это было бы потрясающе. Все эти сервисы могли бы стать дружелюбнее к LLM. Всё, что вы говорите пользователю, по сути, сразу же будет скопировано и вставлено в LLM, так что можно сразу обращаться напрямую к LLM. У вашего сервиса мог бы быть CLI-инструмент. Бэкенд можно было бы настраивать curl-командами. Документация могла бы быть в Markdown. Всё это эргономически намного более удобные поверхности и абстракции для LLM. Не разговаривайте с разработчиком. Не просите разработчика зайти, посмотреть или кликнуть. Инструктируйте и наделяйте возможностями его LLM. Для своего следующего приложения я подумываю использовать простой HTML/CSS/JS + Python-бэкенд (FastAPI + Fly.io или что-то подобное?), нечто гораздо более простое, чем серверлесс-мультивселенная «современной веб-разработки». Возможно, простое приложение вроде MenuGen (или подобные ему) было бы значительно проще в такой парадигме. Наконец, вполне вероятно, что MenuGen вообще не должен быть полноценным приложением. «Приложение» — это просто один вызов GPT для OCR меню, а затем цикл for по результатам для генерации изображений каждого блюда и красивого отображения пользователю. Это почти звучит как простой custom GPT (в терминологии оригинального «магазина приложений» GPT, который OpenAI выпустил ранее). Мог бы MenuGen быть просто промптом? Мог бы LLM отвечать не текстом, а простой веб-страницей для представления результатов — по аналогии с Artifacts? Могли бы и другие приложения выглядеть так же? Мог бы я опубликовать это как приложение в магазине и зарабатывать наценку точно так же?

For now, I'm pretty happy to have vibe coded my first super custom app through the finish line of something that is real, solves a need I've had for a long time, and is shareable with friends. Thank you to all the services above that I've used to build it. In principle, it could earn some $ if others like it too, in a completely passive way - the @levelsio dream. Ultimately, vibe coding full web apps today is kind of messy and not a good idea for anything of actual importance. But there are clear hints of greatness and I think the industry just needs a bit of time to adapt to the new world of LLMs. I'm personally quite excited to see the barrier to app drop to ~zero, where anyone could build and publish an app just as easily as they can make a TikTok. These kinds of hyper-custom automations could become a beautiful new canvas for human creativity.

А пока я вполне доволен тем, что довёл до финиша свой первый суперкастомный вайб-закоженный проект — реальный продукт, который решает проблему, мучившую меня давно, и которым можно поделиться с друзьями. Спасибо всем вышеперечисленным сервисам, которые я использовал для его создания. В принципе, он может приносить какие-то $, если понравится и другим, — полностью пассивно, мечта @levelsio. В конечном счёте вайб-кодинг полноценных веб-приложений сегодня — штука довольно хаотичная и не лучшая идея для чего-то по-настоящему важного. Но есть явные проблески величия, и я думаю, индустрии просто нужно немного времени, чтобы адаптироваться к новому миру LLM. Лично я с нетерпением жду, когда барьер для создания приложений упадёт практически до нуля, когда любой сможет создать и опубликовать приложение так же легко, как снять TikTok. Такие гиперкастомные автоматизации могут стать прекрасным новым холстом для человеческого творчества.

The companion tweet (and the "comments section") is on my X @karpathy.

Сопутствующий твит (и «раздел комментариев») — в моём X @karpathy.