You Don't Need to Code to Follow These Words — A Tech Glossary for Vibe Coders

A while back, Hu Yanbin’s app got picked on by senior technical people. Their line was that anything people who don’t understand code vibe-code into existence is just a toy, riddled with holes.

I posted a video about it a couple of days ago, roughly arguing that even without knowing code you can use AI to run security checks and ship something production-grade. Plenty of people commented under that video, programmers and non-programmers alike. And one point in particular struck me — about blind spots.

The real blind spot: not the coding, the questions

For people who don’t code, the core problem isn’t “you need to understand code,” it’s that during development you need to be able to ask the right questions. If you don’t even know the basic concepts, and don’t know what you should be asking, then AI can’t fill in the gaps for you either.

So this episode I compiled about 122 entries — all basic concepts we need to understand when doing vibe coding and trying to build a good product. Not so you can study them to a professional depth, but so you at least grasp roughly what each thing is, enough to raise the question: “how should we be optimizing this?” That’s what lets AI do the job properly.

Let me pick a few and run through them.

Starting with servers, a run through the words

The first problem a lot of non-coders hit is that their product and service run locally, at localhost plus a port, and the moment they shut the computer down nobody can reach it.

• Server: whether you buy from Tencent Cloud, Alibaba Cloud, or ByteDance’s Volcengine, what you get is a computer in a distant data center, powered on 24 hours a day, running your service or site — you turn your own machine off and other people can still reach it.
• Domain / IP / DNS: the server gives you an IP address; bind the IP to a domain and people can reach it by domain name — and the piece in between that makes it work is DNS resolution.
• HTTP vs. HTTPS: a lot of beginners overlook the prefix their browser adds automatically. The difference between the two is encryption, and HTTPS also requires applying for a certificate. Knowing that, you can ask Claude Code directly: “my site is live, get me a certificate and switch it to encrypted HTTPS.” And CC will just go do it — apply for the certificate, set up auto-renewal, all of it.
• Database: the entire data backend of a site, like one big Excel sheet holding every user’s information, every action, orders, articles, so the backend can read it and the frontend can display it.
• Container / Docker: think of it as carving out a set of independent, mutually non-interfering spaces on a single server, like shipping containers, with your code, assets, frontend and backend files, and database all packed inside. You can copy it to someone else’s server and it still runs, and you can deploy multiple non-interfering services on one machine.
• Object storage / CDN: object storage gives your server a nearly unlimited cloud drive billed by usage; CDN distributes your assets to servers all over the world so nearby users read from a nearby copy — because even at the speed of light, accessing a US site from Beijing costs roughly a third of a second to half a second round trip.
• Plus SSH remote login, certificates, and dependencies (when you use someone’s skill or an MCP service, you often get told “dependencies aren’t installed” — dependencies are the runtime environment that lets a script or service run at all).

Tech stack choices, open source, and one deep trap

Tech stack and technology selection: there are many programming languages, and with a widely used language, when you hit a bug there’s a good chance a best practice already exists online and you’ll solve it faster; a niche or newer language may perform better, but the community is smaller and hard problems are harder to crack — which makes you more dependent on the raw ability of the AI model you’re using, and a good model handles that situation better.

Open source: you can open-source your product on GitHub, but there’s a really nasty trap here — a lot of people don’t clean up before open-sourcing and end up uploading their local passwords, even API keys, along with everything else. Someone who gets your API key can burn your credits generating images, which is effectively stealing from your wallet. So before open-sourcing, pay extra attention to whether you’ve handled the private information.

Further into the glossary there are explanations of LLMs, prompts, context, the difference between local deployment and API calls, and RAG (retrieval-augmented generation).

Treat AI as your architect: get the requirements straight before you start

Before you actually start a project, get the requirements straight and explain them to Claude Code: what kind of service I want to build, who it’s for, roughly what scale, whether it’s mostly text or involves large files like images and video, which models I plan to use. Once you’ve told it all of that, you can ask it to sketch a basic architecture and pick a language, and even to judge which models should go through API calls and which should be deployed locally, whether to use open or closed models — all of it is discussable with AI. You can treat it as a server ops helper, or talk to it as an architect.

Of course, if the product is genuinely going to be commercialized at scale, you still want professionals to sign off. Because it’s not only a question of “are there bugs, does it run” — there’s legal risk (user privacy leaks, say) and financial risk (a hole in the payment system letting someone drain your resources), both of which are dangerous.

Finally

I’ve put this glossary up on the blog too, go take a look. Whenever one of these words shows up in the feedback AI gives you, search it in there and build the most basic understanding — so that we can ask the questions that let AI build our products better. That’s it for today. See you next time.

Source: EP0031_audio.mp3 · ASR model gemini-2.5-pro (chunked parallel) · full text of the roughly 10-minute original recording

[00:00] Hu Yanbin shipped an app a while back and got roasted by senior engineers. They said the so-called products people who don’t know how to code vibe-code out are basically toys, riddled with holes. I posted a video about this a couple of days ago too, and the gist of it was: even if you don’t know how to code, you can still use AI to handle some of the security checks, to the point where you can ship a production-grade product. And a lot of people left comments under that video — programmers and non-programmers both. And there was one point they made

[00:25] that I found really eye-opening, which is about blind spots. The core problem for someone who doesn’t know how to code isn’t that they need to learn to code — it’s that during development, they need to ask the right questions. If you’re not even clear on some of the basic concepts, you don’t even know what question you should be asking to get AI to fill in the gaps. So this episode I made today is basically me pulling together roughly 122 entries, 122 concepts — the ones that, when we’re doing vibe

[00:50] coding, if we want to ship a good product, are basic concepts we need to understand. And what I’m going to do next is flip through this content and pick out a few to show you. Because as someone who doesn’t know how to code but still wants to ship their own product, these are the most basic concepts you have to get straight. Not that you need to study them to any professional depth — just that you should at least know what the big picture of each one is,

[01:15] so that you can raise the question of, how should I optimize this particular aspect. That’s the only way AI can do it for you. So let’s look through it, shall we? A lot of my friends are developers who don’t know how to code, and the earliest problem they hit is that a lot of their products and services run locally — the address they visit is local plus a port number, right? And once their computer shuts down, it’s unreachable. So the first concept I put in there is the concept of a Server.

[01:40] The concept of a server: whether you buy it on Tencent Cloud or Alibaba Cloud, or ByteDance’s Volcano, it’s the equivalent of a computer in some far-off data center that stays powered on 24 hours a day, running your service or your website, so that after your own computer is off, other people can still reach it. That’s the concept of a server. And you can see that on this page of mine, I explain all these concepts in really plain, easy language, and at the same time it tells you what the concept is worth, and when you might need it, including some of the common pitfalls you might hit.

[02:06] Frontend and backend I don’t need to explain. Next down, let me see what else there is. Right, domain names — domain names matter quite a bit too. You can go to these cloud providers and get a .com or a .AI or a .whatever domain. It’s like a mailing address. Once you have a server, the server gives you an IP address, and as long as you bind the IP address to the domain, everyone can use that domain to reach your address.

[02:31] And the technology mentioned in here is DNS, domain name resolution. There’s one more thing that beginners very easily overlook, which is the prefix that shows up automatically in the browser after you type a domain — the difference between HTTP and HTTPS. What’s actually different in there is encryption, and along with it you also have to apply for a certificate. Once you know that HTTP and HTTPS are not the same thing, and that HTTPS is encrypted

[02:56] and a better way to do it, you can go ask AI — ask Claude Code, say, my website is already live on a server, so what’s a way you can help me apply for a certificate so it can be accessed the encrypted HTTPS way. And at that point CC will actually help you, or even do the whole operation for you — apply for the certificate, auto-renew it, and so on. Next up, say, what is a database, right? A database, you can think of it as all the data backing a website,

[03:23] and it’s like one big Excel spreadsheet. Inside it you might store every user’s whole set of information on the site, even the information from every single action they take, including orders and articles, all of it can be stored in there, so the site’s backend can read it easily and the site’s frontend can display it easily. Including things like API endpoints, all of it gets mentioned in here. Then what is deployment, what are environment variables, what is a container? The container concept I’ll explain briefly too. So like I just said,

[03:49] after we buy a server we go deploy our website on that machine. A container is the equivalent of carving out separate, independent spaces on that machine, one after another. All the code in your website or service, or all the assets, all the frontend and backend files, including your database, all get put inside one of these areas that’s like a shipping container. And these shipping containers don’t interfere with each other,

[04:14] so that you can copy one over to someone else’s server and it’ll still work the same, or you can deploy multiple services or websites on one server without them interfering with each other. That’s what containers are for. And Docker is a related concept — you can all go read up on it yourselves. Then there’s object storage and CDN. So you know a computer’s hard disk is finite, right? Even if we buy a server, that server’s disk space also shrinks bit by bit as you use it.

[04:40] Object storage you can think of as fitting our server with a cloud drive, so that it has essentially unlimited storage space, and it charges you by usage as you go — that kind of cloud drive. Once you have object storage, there’s another concept called CDN. So you know network access actually has geographic limits, because network transmission is a signal of light, and even though light travels 300,000 kilometers per second,

[05:05] going from city to city still takes a certain amount of time. Like if we visit a Beijing website from Beijing, it might come back to you in a dozen-odd milliseconds. But if we’re in Beijing accessing a US website, the information going out and coming back — because there’s a very, very long distance in between, even with undersea fiber — a round trip needs maybe close to a third of a second, or half a second. And that’s just transmitting the simplest data. If what we’re transmitting is images or videos, it gets even slower. So CDN

[05:30] is the equivalent of taking the assets on your site and saving them in a distributed way onto servers all around the world, so that a user near one of them reads that content from the nearby copy, and it makes access faster. These are all concepts you’ll run into once our service covers more regions. Including SSH remote login for server management, and then what kind of certificate that certificate we mentioned is — it’s all in here. So let’s keep going.

[05:55] One that comes up often is probably the concept of dependencies. When we’re using someone else’s skill, or using someone else’s MCP service, it often tells us we haven’t installed the dependencies. So what are dependencies? Dependencies are what you’d call the runtime environment. If you want to run that script or that service, there’s actually a precondition, which is that you’ve installed, installed an environment capable of supporting that script or ser— service running.

[06:21] So let’s keep going. What else do I think is worth covering? Tech stack and stack selection. So you know there are a lot of programming languages, right? Some languages have more people using them worldwide, and if you use that kind of language to build your product or service, then during development, if we hit some bug or some challenge in implementing a certain feature, we can actually solve it much faster, because odds are online there’ll be

[06:47] best practices for solving that problem in that programming language, other people’s write-ups you can use. But take some niche language, or some newly emerging language: even though the product you write in it might perform better, because its developer community is smaller in headcount, when you hit a hard problem it might be harder to solve. And at that point you may end up relying on the raw ability of our coding AI model itself. A good model, in that situation,

[07:13] handles it better. Then open source. You all know we can open-source the products we build to GitHub. And there’s a deep pitfall in here: a lot of people, when they want to share their service with others, when they want to open-source it to GitHub, don’t do a cleanup pass first, and they end up packaging up their local passwords, or even some of their local — the API keys we just mentioned — and open-sourcing all of it to the world. One careless move and you’ve

[07:38] leaked it just like that. Someone gets your API key and they can use your API to generate images — it’s basically stealing out of your wallet. So when open-sourcing you absolutely have to take extra care about whether we’ve dealt with any private information. Next up, let’s see what else. Further on there are also some foundational large-model concepts, like prompts

[08:03] for large models, then context, including the difference between local deployment and API calls — it’s all covered in here. And then including RAG, retrieval-augmented generation, explanations of concepts like that. Honestly, before we kick off a project, sorting out our requirements — like telling Claude Code the requirements, saying, I want to build such-and-such a service, who it’s for,

[08:29] roughly what scale, and then whether the whole service is mainly text, or whether it’ll involve calling big files like images or video, including which models you plan to use — once you’ve told Claude Code all of that, you can actually ask it to do a basic architecture and pick the development language, and even, which models get called over the API

[08:54] and which models get deployed locally, and do I use an open-source model or a closed-source one — all of this you can discuss with AI. We can treat AI as a helper for server operations, and we can also talk to it as an architect. Of course, if our product is really going to be commercialized at scale, you still need to bring in professionals to sign off on things, because it’s not just about whether there are bugs

[09:19] and whether it runs properly. A lot of it involves legal risk, like leaking user privacy, or economic risk — if your system has payments wired up, and your payment system has a hole in it, and someone can exploit it to steal the resources on your side, that’s also a very dangerous situation. And this file of mine is going to go up on my blog too, so you can go read it.

[09:44] When the feedback AI gives us contains any of these words, you can search for them down there and get a most basic grasp of it, so that we can ask the questions that get AI to help us make the product better. That’s it for today’s content, so see you next time, bye.