all things vibecoding

a tool, or the act of using it, that scans source code for likely bugs, style problems, and risky patterns without running the program. the tool itself is called a linter.

an automatic proofreader for your code. it flags mistakes and sloppy spots before the app ever runs, so problems get caught early. people also say "a lint" to mean one such automated check.

ga stands for general availability. to ga something, past tense "ga'd", is to release it from beta or preview into a stable, fully supported version available to everyone.

it went from "try it at your own risk" to officially released and safe to rely on. if a feature is ga'd, it is finished and open to all users, not an experiment.

negative prompting is telling a model what to avoid or exclude rather than what to do, for example "do not mention pricing", or in image tools, listing what you do not want in the picture. anti-negative prompting is the counter-practice: because models tend to fixate on whatever you name, even to forbid it, you instead phrase everything as what you do want.

telling the ai "don't do x" can backfire, because naming x can make it show up more. the fix is to say what you do want instead of what you don't. "write it in plain language" works better than "don't be wordy".

when false, malicious, or low-quality information gets into a model's context window, the text it is currently working from, and then skews everything it produces afterward, because the model treats whatever is in context as true and keeps building on it.

once bad info gets into the ai's working memory for a session, it keeps trusting and repeating it, so later answers get contaminated too. the usual fix is to start a fresh chat.

the exact rules for how code must be written in a given language, the required punctuation, keywords, spacing, and order, so the computer can read it. break the rules and the code will not run.

grammar for code. every language has strict rules about brackets, commas, and spelling, and getting one wrong stops the whole thing from working.

a named, reusable block of code that does one job. you define it once, then call it by name whenever you need that job done, optionally handing it inputs and getting a result back.

a labeled mini-machine in your code. you build it once and reuse it everywhere by name, instead of rewriting the same steps over and over.

the large, prominent section at the very top of a page, usually a headline, a short pitch, and a main button, that is the first thing a visitor sees.

the big banner at the top of a landing page. headline, one line about what you do, and the main button. it sets the first impression.

the overall structure of a software system, how its parts are divided, what each one is responsible for, and how they connect and talk to each other.

the blueprint of your app. not the individual code, but the big-picture layout of which pieces exist and how they fit together.

application programming interface. a defined set of requests one piece of software can make to another, and the responses it gets back, so two systems can talk without knowing each other's internals.

a menu one program offers to others. you send a request in the agreed format and get data or an action back, the way an app pulls in weather or payments without building them itself.

an organized store of data that an app can quickly save to, search, and update, usually structured into tables of records.

your app's filing cabinet. it is where the real information lives, users, orders, posts, so it sticks around and can be looked up later.

the defined shape of your data, what tables and fields exist, their names, types, and how they relate, that the database enforces.

the blueprint for your filing cabinet. it spells out exactly what information each record holds and in what form, so the data stays consistent.

starter data loaded into a database to fill it with realistic example records, so the app has something to show and test against before real users arrive.

fake-but-realistic sample data you pour in so a fresh app is not empty. handy for testing screens and demos before real users show up.

named values stored outside your code, like api keys, passwords, and settings, that the app reads while running. they can differ between your laptop and the live site, and keep secrets out of the codebase.

settings and secrets kept outside the code. things like passwords and keys live here so they are not exposed, and can change between your machine and the real site. often shortened to env vars.

the shared, named set of rules and reusable parts that define how your whole app looks and behaves, its colors, spacing, fonts, and prebuilt pieces, defined once so every screen stays consistent.

one rulebook for how your app looks. instead of styling each screen from scratch, you define the look once and everything pulls from it. when you tell the ai to "use the design system", it builds new screens from the agreed set instead of inventing new styles every time. the three pieces below, tokens, components, and the design contract, are what it is made of.

named values for the small design decisions, colors, spacing, font sizes, corner radius, stored once and referenced everywhere instead of hard-coding the raw numbers.

nicknames for your design values. instead of "#1d4ed8" you say "primary color", instead of "16px" you say "space-md". change the token once and it updates everywhere. telling the ai to "use the tokens" keeps it from sprinkling random colors and sizes around.

the reusable, prebuilt ui pieces of a design system, the button, the card, the input, each styled to the system's rules, so you assemble screens from them instead of building each one fresh.

the ready-made building blocks of your app's look, a button, a card, a form field, already styled to match. tell the ai to "use the existing component" and it reuses the one you have instead of inventing a new, slightly different button.

an agreed, written spec of what a screen or component must look like and do, its layout, states, spacing, and behavior, that the build is expected to match exactly.

the rules the design has to follow, written down before the build so there is a clear target. for vibecoding it is what you hand the ai so it builds to a fixed spec instead of guessing, and what you check the result against.

a saved snapshot of your code at a point in time, recorded in version control with a short message describing what changed. the history of a project is a chain of these snapshots.

a save point for your project. each commit freezes the current state with a note, so you can look back, undo, or see exactly what changed and when.

continuous integration and continuous delivery. an automated pipeline that, on every code change, builds the app, runs the tests, and ships it to production if everything passes.

a robot assembly line for shipping code. every time you push a change, it automatically checks it and, if all is well, puts it live, so you are not doing it by hand.

a small, automated check that tests one piece of code, a single function or component, in isolation, run the instant you write it so you know right away if that piece still works.

a tiny auto-check on one bit of your code that runs the moment you save. it tells you immediately if you just broke that piece, instead of finding out later.

a test that re-checks existing, already-working features after you make a change, to catch a regression, something that used to work breaking because of new code.

a test that makes sure your new change did not break old stuff that already worked. it re-runs the things that used to pass, so a fix in one place does not quietly break another.

a strict, enforced set of code-style and quality rules that the linter applies automatically, often paired with auto-formatters like prettier, black, or ruff that rewrite your code into the agreed style on save.

turning the code proofreader up to strict and letting a formatter fix things for you. tools like prettier, black, or ruff reformat your code automatically so everything stays clean and consistent.

a dated, ordered list of notable changes made to a project, each new feature, fix, and breaking change, usually grouped by version or release so anyone can see what shipped and when.

the "what's new" list for your app. every release adds a line or two saying what got added, fixed, or changed, so users and teammates can catch up at a glance.

a running journal kept during development, notes on what was built, what was decided and why, problems hit, and what to do next. it is for the people building the app, not the end users.

the builder's diary. unlike a change log, which lists what shipped for users, a dev log captures the messy details, decisions, dead ends, and reminders, so you can pick the thread back up later.

a high-level plan of what is going to be built and roughly when, ordered by priority, showing the direction of the product over the coming weeks or months.

the big-picture to-do list for the whole product. it lays out what is coming next and in what order, so everyone knows the plan without the fine detail.

the prioritized list of work not yet started, features, fixes, and ideas, waiting to be picked up. items leave the backlog when someone begins them.

the holding pen for everything you want to do but have not started. new ideas land here and get pulled out when it is their turn.