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 while you’re building, you have to be able to ask the right questions. If you don’t know the basic concepts, and don’t know what you should be asking, AI can’t fill in the gaps for you either.

So this episode I compiled about 122 entries—the basic concepts you need when you’re vibe coding and trying to build something good. Not so you can study them to a professional depth, but so you at least have a rough sense of what each one is. Enough to ask: “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 needs a certificate you have to apply for. 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 one server into separate walled-off spaces that don’t step on each other, like shipping containers, with your code, assets, frontend and backend files, and database all packed inside. Copy one to someone else’s server and it still runs, and you can put several services on one machine without them interfering.
• Object storage / CDN: object storage gives your server a nearly unlimited cloud drive billed by usage. A CDN spreads your assets across servers all over the world so nearby users read from a nearby copy. Even at the speed of light, reaching a US site from Beijing costs a third of a second to half a second round trip.
• Plus SSH remote login, certificates, and dependencies (use someone’s skill or an MCP service and you’ll 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 a lot of programming languages. Pick a widely used one and when you hit a bug, odds are a best practice is already posted online and you’ll fix it faster. A niche or newer language may perform better, but the community is smaller and hard problems get harder to crack. That leaves you leaning on the raw ability of whatever AI model you’re using, and a good model handles those situations 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 they publish, and they upload their local passwords, even their API keys, along with everything else. Someone who gets your API key can burn your credits generating images—that’s stealing straight out of your wallet. So before you open-source anything, check hard that you’ve stripped the private information out.

Further into the glossary there are entries on 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 start a project, get the requirements straight and walk Claude Code through them: what kind of service you want to build, who it’s for, roughly what scale, whether it’s mostly text or pulls in big files like images and video, which models you plan to use. Once it has all of that, ask it to sketch a basic architecture and pick a language. It can also weigh which models should go through API calls and which should run locally, and whether to use open or closed models. All of it is worth talking through with AI. 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. It’s not only a question of “are there bugs, does it run.” There’s legal risk—user privacy leaks, say—and financial risk, like a hole in the payment system that lets someone drain your resources. Both are dangerous.

Finally

I’ve put this glossary up on the blog too, so go take a look. Whenever one of these words shows up in what AI tells you, search it in there and get the most basic footing—enough to 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 what people who don’t know how to code vibe-code out barely counts as a product—it’s a toy, and it’s 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, far enough that you can actually 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 what I did for this episode today was pull 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 actually ask the question: how do I make this part better? That’s the only way AI can go 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 first problem they run into 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 basically a computer sitting 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 it also tells you what the concept is worth and when you might need it, plus some of the common pitfalls you might hit.

[02:06] Frontend and backend I don’t need to explain. Further 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. Things like API endpoints too—it all 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 like carving out separate, self-contained 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 data on a network travels as a light signal, 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 takes 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] basically takes the assets on your site and saves copies of them out 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. Plus SSH remote login for managing a server, and what kind of certificate that certificate we mentioned actually 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 a lot smaller, 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 you open-source, you have to be extra careful about whether we’ve cleaned out 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 basic understanding 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.