The Coding Terms Every Vibe Coder Should Understand

You ask an AI to build a website. It gives you something beautiful. Then it asks for an API key, tells you to configure an environment variable, suggests connecting an MCP server, and casually mentions deploying the backend. Ei. You came with an idea, and suddenly there is a vocabulary examination.

I understand the appeal of skipping all that and typing, “Just make it work.” My background is Tourism Management, and I build with AI. I am hardly going to argue that everyone needs a computer science degree before touching a website.

But there is a point where unfamiliar words become expensive decisions. Where does this code run? Who can access that file? Is this connection allowed to delete things? Whose account pays when somebody presses Generate fifty times?

You can delegate writing code. You still need enough understanding to judge what the code is being allowed to do.

Your IDE is the workshop

An IDE, or integrated development environment, brings development tools into one workspace: editing code, navigating files, running programs, and investigating errors. A code editor can grow into a similar workspace through extensions. The labels overlap in everyday use.

Visual Studio Code, for example, gives you an editor, file explorer, terminal, and debugging tools. Your AI assistant may work inside that environment. It is still useful to distinguish the workspace from the assistant using it.

A terminal is the interface where you type commands. A CLI, or command-line interface, is how a particular tool accepts those commands. Installing packages and deploying an app are common examples. A command can change real files and services, so “the AI suggested it” is a poor substitute for knowing its purpose.

The frontend is what visitors use. The backend does the trusted work

Imagine a small tourism website that generates Cape Coast itineraries.

The frontend is the interface in the visitor’s browser: the destination field, date picker, and Generate button. The backend is the server-side part that can check permissions, call a paid service using a secret credential, and save results. A database stores organised information, such as accounts and saved itineraries.

This is a simplified client-server arrangement. Managed services can provide much of the backend for you; you still have to configure access correctly.

Anything delivered to a visitor’s browser should be treated as inspectable. Hiding an admin button does not prevent someone from requesting the underlying action. The service handling that action must enforce permission.

An API is the interface between programs

API means application programming interface: the rules and capabilities software exposes for other software to use. APIs exist within devices and programs too; the internet is not a requirement.

In our itinerary app, a web API could let the backend send a destination to an AI service and receive a suggested itinerary. An endpoint is the particular address used for an operation. The request is what you send; the response is what comes back.

JSON is a common text format for exchanging structured data: fields such as destination, days, and budget. It is a format, not a database.

MDN describes an API as an interface or contract. That is the useful idea: a service accepts specified inputs and returns specified outputs. Your app must handle what happens when that agreement produces an error.

An API key is a credential, not the API itself

An API key is a string a service can use to identify the calling project or application. Depending on the provider, possessing it may enable billable requests or access to capabilities. It is not necessarily proof of an individual user’s identity.

For a secret paid-service key, a common arrangement is for the browser to contact your backend, which checks the request and calls the provider. The backend must also limit abuse; moving the key there does not automatically make an unlimited public endpoint safe.

Google’s key-management guidance recommends restrictions and keeping secret keys out of client code and repositories. Avoid exposing them in screenshots, logs, or shared prompts too.

There is a useful exception: keys restricted to Firebase services are generally public configuration, rather than database passwords. Firebase still needs correctly configured security rules and other access controls. The right question is what this particular key permits.

If a secret leaks, revoke or rotate it. Deleting the visible line is insufficient when copies or Git history may remain. GitHub recommends dealing with the credential first.

A .env file is configuration, not a hiding spell

An environment variable supplies a setting to a running process. A .env file is one common way development tools load those settings. Deployment platforms have their own configuration and secret-management mechanisms.

The trap is assuming that moving a key into .env automatically makes it private. Some build tools deliberately copy selected variables into browser code. Vite exposes variables prefixed with VITE_ to the client.

Keep secret-bearing environment files out of version control, use placeholder values in shared examples, and check what the build actually exposes. A filename cannot protect a secret that your app sends to every visitor.

An SDK is the toolkit that saves repetitive work

An SDK, or software development kit, provides tools and libraries for building with a platform. It might include convenient functions for signing in or calling an API, so you do not write every request from scratch. MDN’s SDK explanation covers that distinction.

A dependency is software your project relies on. A package manager helps install and manage packages. An SDK can be one of those dependencies.

Convenience does not remove the need to understand what you installed, which version you use, or whether it belongs in browser or server code. Ask your assistant to explain each new dependency before your tiny website acquires the luggage allowance of an international flight.

MCP connects an AI application to tools and context

MCP stands for Model Context Protocol. It standardises how AI applications connect to external tools and information. Its architecture includes a host application, clients, and servers. Servers can expose tools for actions, resources for context, and reusable prompts.

For example, a coding assistant could use an MCP connection to inspect repository issues. The MCP server might call the repository platform’s API underneath. An API and MCP can therefore be parts of the same connection.

MCP does not train a model, and connecting a server does not make the model an expert. It gives the application an interface to capabilities or information.

Permissions deserve attention. Read access to documentation differs considerably from permission to modify a database. Ask what can be read, changed, or executed. The official security guidance also makes clear that local servers and authorisation flows have risks. “Connected” is not a certificate of trust.

Authentication asks who you are. Authorisation asks what you may do

Signing in is authentication. Deciding whether that signed-in account can approve a submission or view another person’s data is authorisation.

A user can pass the first check and fail the second. That is exactly what should happen when an ordinary contributor tries to use an administrator’s function.

Firebase Authentication, for instance, provides sign-in capabilities. Your application still needs to enforce its access policy. Test with different accounts; a working login screen proves very little about who can access the records behind it.

Git records changes. GitHub hosts repositories

Git is a version-control system. A repository holds your project and its recorded history. A commit records a checkpoint; a branch lets work develop along a separate line. GitHub is a platform that hosts repositories and supports collaboration.

Version control lets you inspect and recover recorded changes. Before asking AI to redesign half your application, having a known working commit is a beautiful thing.

There are limits. Reverting code does not necessarily undo a deleted database record or an email already sent. Data backups and recovery plans serve a different purpose.

Localhost, deployment, and production are different stages

Localhost points to the device making the request. A site working on your laptop is not automatically available on somebody else’s phone.

A build prepares code and assets for a target environment. Deployment puts the needed software or files into a hosting environment. Production is the environment serving real users; staging is a separate place to test changes before release.

Firebase Hosting can serve a website, but a separately running backend may require its own deployment and configuration. Check the public link, sign-in, permissions, and real requests after deployment.

As I argued when writing about building the UCC SRC app, maintenance continues after the impressive demonstration. Publishing gives your decisions an audience.

Errors and quotas are information you can use

A log records events that help explain what happened. An HTTP status code describes the outcome of a web request. Typically, 401 points to missing or invalid authentication, 403 to refusal, 404 to a missing resource, and 429 to too many requests. Provider-specific details still matter; read the response and its documentation.

A rate limit restricts activity over time. A quota is an allocation or ceiling. For language models, tokens are units of processed content; other services may bill by image, audio duration, or operation. These are reasons to inspect usage rather than repeatedly pressing Retry.

Check whether a budget setting only sends alerts or actually stops spending. Cloud Run’s cost guidance, for example, distinguishes budget alerts from hard caps.

Ask your AI to explain the system it is building

You do not need to memorise every acronym tonight. Start with your own app and ask:

Explain this project in plain English. Where does the frontend run? What handles trusted operations? Where is data stored? Which credentials are public configuration and which are secret? What can each user role and connected tool do? What triggers a paid request? How do I test a change and recover if it fails? Point to the relevant files and settings without printing secrets.

Then verify the answer against the project and provider documentation. The assistant can be wrong about its own work.

I like what AI has opened up for people who did not begin in software. I am one of them. But access to building should come with access to understanding.

The moment an app can touch someone’s data, act on their behalf, or spend money, “I only wrote the prompt” stops being much of an explanation.