Plain English can now stand in for code, but it comes with a catch: describing software precisely takes words most people have never needed. The builders who get the most from AI aren't the ones who learned syntax; they're the ones who can name exactly what they want.
This lesson builds that vocabulary: a small set of concepts covering where an app's code runs, where its data lives, how it talks to other services, and what it means to put it on the internet. There's no syntax and no setup involved, only the concepts and why each one matters.
Along the way, the lesson shows what the words buy: sharper prompts, cheaper mistakes, and the ability to spot when an AI-built app has a quiet hole in it. These concepts feed directly into every prompting lesson that follows.
English as a programming language
In January 2023, Andrej Karpathy posted that "the hottest new programming language is English" [1]. The line captured a genuine shift: AI models now translate plain-language descriptions into working code, so the person building no longer has to write that code by hand.
Jakob Nielsen describes the same shift as a new interaction paradigm, the first in roughly 60 years: instead of issuing step-by-step commands, people specify the outcome they want and the computer figures out how to produce it [2].
The catch is that the leverage moves from syntax to description. Karpathy himself notes that AI now holds the low-level details even for experts, while the fundamentals still have to live in a human head [3]. When English is the programming language, word choice is the engineering.
The articulation barrier
The articulation barrier is Jakob Nielsen's name for the catch inside prompt-driven AI: "users must be highly articulate to write the required prose text" [4]. Getting good results from a prompt box is a writing task, and writing tasks aren't equally easy for everyone.
Nielsen's synthesis of literacy research places roughly half the adult population of rich countries in the low-literacy category, which makes a prose-first interface a real usability regression for them. Some critics push further and argue that prompt literacy simply replaces coding literacy as tech's new gatekeeping mechanism.
The counter is cost. A concept vocabulary of roughly 20 words is orders of magnitude cheaper to learn than syntax fluency, and it's the smallest toll anyone has found for crossing the barrier. That's the bet this lesson makes: if articulation is the barrier, vocabulary is the ladder over it.
Frontend vs. backend

Every web app splits into two layers. The frontend is the part people see and touch: buttons, screens, and animations running in the browser on the user's own device. The backend does the remembering and deciding, running on a server the builder controls [5].
The split isn't visuals versus logic; it's where the code runs and who can reach it. Everything in the frontend gets sent to the user's device, where a curious visitor can inspect and change it. The backend stays on hardware that visitors never touch.
The distinction shapes prompts. Asking for a feature "on the backend" or "in the frontend" tells the AI where the work happens, which is often the difference between an app that works and one that only appears to.
What is a database?
A database is an organized, persistent store of records that an app can query and update. The nearest everyday analogy is a spreadsheet: tables of rows and columns, where each row is one record, such as a user, an order, or a saved note.
Maggie Appleton told a 2024 conference audience that newcomers "probably don't know what a database is," then listed persisting data among the few ingredients most everyday software needs [6]. A database also isn't the same thing as hosting: the database holds the app's data, while hosting is where the app itself lives. The two fail differently, which is why they're separate words; when an AI agent deleted a company's production database in 2025, the app survived but the records were gone [7].
The practical rule: anything the app must not forget, like accounts, posts, and orders, needs a database behind it, and asking for one by name is the reliable way to get it.
What is an API (Application Programming Interface)?
An API (application programming interface) is a menu of requests that one piece of software agrees to answer for another. In the classic restaurant analogy, the app is the customer, the API is the menu and the waiter, and the outside service is the kitchen. The term dates back to the late 1960s, but the idea has stayed simple: software asks, and other software answers.
APIs are where non-coder projects meet the real world. Weather data, payment processing, sending email, and generating images all arrive through API calls to someone else's service. Most APIs require a secret key that identifies the account, and many charge money per request.
Those two facts explain the two most expensive beginner mistakes: keys that leak because they were left in frontend code, and bills that balloon because every visitor's click triggered a metered call. One sentence of understanding prevents both.
Pro Tip! Before wiring an outside API into a project, checking whether the service bills per request prevents the most common surprise cost.
Hosting and deployment
Hosting means an always-on computer, called a server, runs the software so anyone on the internet can reach it. Deployment is the act of putting code on that server and wiring up everything it needs. Neither resembles the share button on a document: publishing a doc shares a file, while deploying an app starts a machine running code around the clock.
The step is famously harder than it sounds. When Andrej Karpathy built his MenuGen app with AI, he reported that "the hard part was not writing the code" but deploying it: wiring services, DNS, auth, payments, secrets, and production configuration [8].
Modern platforms increasingly compress deployment into one click, but the concept still governs what a builder is consenting to: a deployed app is live, reachable by strangers, and running on rented hardware. That's the moment the stakes jump.
The cost of a missing word
In March 2025, a founder launched Enrichlead, a paid product built almost entirely with AI and, by his own account, no handwritten code. Within days, users were bypassing the paywall and running up charges, because the payment check lived in frontend code and secret keys sat exposed on the user's side [9].
The instructive part isn't the hack; it's the missing words. The founder didn't have "server-side," "API key," or "access control" in his vocabulary, so he couldn't ask for them, and the AI built what he described rather than what he needed. Nielsen Norman Group's evaluations of AI generation point the same way: requirement-rich prompts consistently beat short, vague ones [10].
The general rule is uncomfortable but useful: nobody can specify what they can't name. A missing word doesn't produce an error message; it produces a working app with a silent hole in it.
Frontend isn't just design
A common shorthand maps the frontend to design and the backend to functionality. It's wrong in a way that costs money. Both layers function; the real split is where the code runs and who can tamper with it, since frontend code travels to the user's device, where a curious visitor can inspect it, edit it, and skip any check it performs [11].
That's exactly why the Enrichlead paywall failed: a payment check that runs only on the frontend is a sign saying "please pay," not a lock. Real enforcement, meaning prices, permissions, and access rules, has to happen on the backend, out of users' reach.
For anyone arriving from design tools, this is the correction worth keeping: the visual layer and the trust boundary are different things, and prompts should treat them differently.
Words that sharpen prompts
Vocabulary pays off at the prompt box. "Make it remember stuff" leaves the AI guessing, while "store this in a database so it's still there tomorrow" names a mechanism and becomes a requirement. Ethan Mollick calls the underlying skill finding the "minimum viable knowledge" needed to collaborate with AI on a project [12].
Habits that put the words to work:
- Sketch the project in concept terms before prompting: what's the frontend, is there data to keep, which outside services does it talk to, and where will it live
- Name the mechanism, not the wish: "database" beats "memory," "login" beats "private," and "API call" beats "get the weather from somewhere"
- Say where a rule must live, because a check that matters belongs on the backend
Tool-specific prompt tricks churned throughout 2025, while these underlying concepts persisted [13]. The words are the durable layer, and every prompting lesson that follows builds on them.
Pro Tip! When the AI uses an unfamiliar term, asking it for a one-sentence definition costs nothing and pays off in every later prompt.
Topics
References
- Andrej Karpathy (@karpathy) on X | X (formerly Twitter)
- AI Is First New UI Paradigm in 60 Years
- Sequoia Ascent 2026 summary | karpathy
- The Articulation Barrier: Prompt-Driven AI UX Hurts Usability
- Client-server overview - Learn web development | MDN | MDN Web Docs
- Home-Cooked Software and Barefoot Developers
- Vibe coding service Replit deleted production database | theregister
- Sequoia Ascent 2026 summary | karpathy
- ‘Guys, I’m under attack’ — AI ‘vibe coding’ in the wild | Pivot to AI
- Testing AI with Real Design Scenarios: Evaluation Methodology and Prompts | Nielsen Norman Group
- Client-server overview - Learn web development | MDN | MDN Web Docs
- Speaking things into existence
- From vibe coding to context engineering: 2025 in software development | MIT Technology Review

