Words to Know: A Simple Glossary for Building With AI

Building with AI

AI agent. A program that can read your files, write code and run commands for you. Examples: Claude Code, Cursor, Codex.

Prompt. The message you write to the agent. A good prompt says what to build, for whom, and how you will check it.

Vibe coding. Building software mostly by describing what you want to an AI, instead of writing every line yourself.

Instructions file. A text file in your project, often called AGENTS.md or CLAUDE.md, that the agent reads every time. You put your rules there once, so you do not repeat them.

Context. Everything the agent knows at a given moment: your message, your files and what was said before. When the context is wrong or missing, results get worse.

MCP server. A connection that gives your agent extra tools or data. For example, the HorizonX MCP server lets an agent search and fetch HorizonX components.

Design words

UI (user interface). What the person sees and touches: buttons, text, menus, forms.

UX (user experience). How easy and pleasant it is to use. Good UX means people finish what they came to do.

Component. A reusable piece of interface, like a button, a card or a menu. You build it once and use it many times.

UI kit. A set of ready-made components and screens, usually in Figma, that share the same style.

Template. A ready-made website or app that you change to make your own.

Design tokens. Named values for your style, such as color-primary = #1E40AF or space-4 = 16px. Using tokens keeps everything consistent.

State. How a component looks in a certain moment: normal, hover (mouse over it), focus (selected with the keyboard), pressed, disabled, loading, error, empty.

Empty state. What a screen shows when there is no data yet, for example "You have no orders yet".

Hero. The first big section at the top of a page.

CTA (call to action). The main button that asks the person to do something, like "Start free trial".

Building words

Frontend. The part of the app that runs in the browser and that people see.

Backend. The part that runs on a server: it saves data, sends emails and checks passwords.

Responsive. The layout changes to fit phones, tablets and computers.

Breakpoint. The screen width where the layout changes, for example at 768 pixels.

Repository (repo). The folder that holds your project's code and its history, often on GitHub.

Commit. A saved step in the history of your code, with a short note about what changed.

Branch. A separate copy of your code where you can try changes without breaking the main version.

Build. Turning your code into files that a browser or server can run.

Deploy. Putting the built files on a server so people can use them.

Preview. A private or temporary copy of your site, used to check changes before they go live.

Production (prod). The real, live version that your users see.

Bug. Something that does not work as expected.

Console. A panel in the browser that shows errors. Open it with F12 or right-click and "Inspect".

Quality words

Accessibility (a11y). Making sure everyone can use your product, including people who use a keyboard only, a screen reader or large text.

Contrast. The difference between text color and background color. Low contrast is hard to read.

Performance. How fast the page loads and reacts.

Test. A check, often automatic, that proves part of your code works.

QA (quality assurance). Checking the product carefully before people use it.

What "done" really means

This is the most important word on this page. "Done" is not one thing. There are five different steps, and an agent often says "done" after the first one.

1. Written. The code exists. Nobody has checked it yet.
2. Tested. Someone ran it and checked that it works. Ask: tested how? On which screen?
3. Approved. The person who asked for it looked at it and said yes.
4. Published. It is on the live site, and real people can use it.
5. Checked live. Someone opened the live site and saw that it works there too.

When an agent says "done", ask: "Done at which step? Show me the proof."

Good proof looks like this:

• a screenshot of the real page on a phone and on a computer;
• the result of a test that ran, with no errors;
• a link to the live page that you can open yourself.

A message that only says "it should work now" is not proof.