September 10, 2026 · 17 min read · VibedSites team
Speak the Language of Code (and AI)
A plain-English glossary for people who have never coded. Every term is explained from zero and paired with a sentence you can copy straight into a prompt, with live examples for the visual ones.

Most bad results from an AI builder are not the model being dumb. They are two people using different words for the same thing. You say "make the top part smaller" and the model guesses which top part you mean. You say "make the bar at the very top of the page shorter, keep the logo the same size", and you get exactly what you pictured.
This is a vocabulary article for someone who has never seen these words before. Every definition assumes you know nothing about how websites are made. Each term has three things: what it is, explained the way you would explain it to a friend, and a sentence you can copy straight into a prompt. Steal the prompt lines. That is what they are for.
Read the first section now. It covers about ninety percent of what you will ever need to describe a web page. The other two are for later, when you start asking for behavior instead of appearance. Come back when you need them.
How to use a term in a prompt
Three habits make every word below work harder.
- Name the thing, then the change. "In the footer, make the links stack vertically on phones."
- Say what must not change. "Change the button color to the brand green, leave the size and text alone."
- Ask for one visible outcome at a time. Two changes in one sentence is where guessing starts.
If you cannot name the part of the screen you want changed, describe it by what it contains. "The box with the price in it" is a perfectly good name.
Noob: the words for what you see
Element
Any single piece of a page you can point at. A heading is an element. A photo is an element. A button is an element. A single line of text is an element. The whole web page is just a pile of elements arranged on top of and next to each other. Prompt: "Center this element on the page and give it a little space above it."
div
The plainest possible box on a web page. It has no look and no meaning of its own. It exists for two reasons: to hold other elements together as one unit, and to give those elements a shared style, like a background color or spacing. When someone says "wrap it in a div", they just mean "put those things in the same box so they move and look together." Prompt: "Wrap the photo and the caption in one box so they move together."
Section
One big chunk of a page with its own topic. Your homepage is almost certainly a stack of sections: a welcome area at the top, then a features area, then maybe testimonials, then pricing. Each one is a section. Saying the word "section" tells the AI you mean one of those big chunks, not a single word or button. Prompt: "Add a new section below the welcome area called How it works, with three short steps."
Container
An invisible frame around the content of a page that stops it from stretching edge to edge on a wide screen. Without one, text on a big monitor would run the full width and become exhausting to read. When your content suddenly looks like it is touching the edges of the screen, this is the word to reach for. Prompt: "Keep this section's content inside the same width as the rest of the page, with equal space on both sides."
Headline and subhead
The headline is the biggest line of text in a section, the one your eyes land on first. The subhead is the smaller supporting sentence directly underneath it. When you tell the AI "change the title", it has to guess whether you mean the headline, the subhead, or a card title. These words end the guessing. Prompt: "Keep the headline as it is and rewrite the subhead in one shorter sentence."
Heading levels (h1, h2, h3)
Webpages do not just have "big text" and "small text". Headings come in numbered levels, like an outline. h1 is the single main title of the whole page, and a page should have exactly one. h2 marks each major section under it. h3 marks a point inside a section. Search engines and screen readers use this order to understand your page, so it matters even though it looks like just a size change. Prompt: "Use one h1 for the page title and h2 for each section heading."
Body copy
All the normal paragraph text on a page. Not headings, not buttons, not labels, just the regular reading text. When the AI wrote three paragraphs and you only want one, this is the word. Prompt: "Shorten the body copy in this section to two sentences and keep the same meaning."
Button
Something you click that makes something happen: save, submit, buy, open. The click triggers an action. That is the whole definition, and the difference from a link matters. Prompt: "Add a prominent button that says Get started and links to the signup page."
Link
Text or an image that takes you somewhere else when you click it. A link goes to a place. A button does a thing. If clicking "Contact us" opens the contact page, that is a link. If clicking "Save" keeps you on the page and stores your changes, that is a button. Telling the AI the right word gets you the right behavior the first time. Prompt: "Make the company name in the footer a link to the homepage."
Call to action (CTA)
The single thing you most want a visitor to do on a screen, usually one obvious button. Sign up, buy, try it. If a screen has two equally loud buttons, it has no call to action and people hesitate. Naming this in a prompt lets you say "this one matters, the other should be quiet". Prompt: "Give this section one clear call to action and make the second button quiet."
Hero
The first screen of the page, the part you see before you scroll. It almost always has a headline, a subhead, one call to action, and sometimes an image. It is called a hero because it is the star of the page. When you say "the top part", the AI guesses. When you say "the hero", it knows exactly which screen you mean. Prompt: "Make the hero shorter so the main button is visible without scrolling on a laptop."
Navigation (nav)
The set of links that lets visitors move around your site, usually sitting across the top. Not the links inside your page content, the persistent menu of where to go. Prompt: "Add Pricing to the main navigation, between Features and About."
Header and footer
The header is the strip across the very top of the page, usually holding the logo and the navigation. The footer is the strip at the very bottom, usually holding legal links, contact details, and the copyright line. Nearly every page on a site shares the same header and footer. Prompt: "Keep the header visible at the top even when I scroll down the page."
Types of menus
Saying just "menu" gives the AI a coin flip to guess which kind you mean. Each one has a name.
Prompt: "On phones, collapse the navigation into a hamburger menu that slides in from the right."
- Navbar: the horizontal row of links across the top of the page.
- Hamburger menu: the little three-line icon, mostly on phones, that opens the navigation when tapped.
- Dropdown: a small panel of extra choices that appears when you click a navigation item.
- Sidebar: a vertical column of links running down one side, common inside apps and dashboards.
- Tabs: a row of switches on one page that swap the content below without leaving the page.
- Context menu: the small menu that appears on right-click, or from a three-dot icon next to an item.
Card
A small box that groups one item: usually a picture, a title, a couple of details, and sometimes a button. Product grids, listing pages, and team pages are built out of cards, one card per item. When your results look like a wall of unstyled text, asking for cards is often the whole fix. Prompt: "Show these results as cards in a three-column grid, two columns on tablets, one on phones."
Grid and list
The two ways to arrange a set of items. A grid places them in rows and columns, like a photo gallery. A list stacks them one per row, like search results. Neither is better; they fit different content. Prompt: "Let people switch this page between grid view and list view."
each box is one card; the layout is the grid or the list
Modal, dialog, drawer, toast
Four ways to show something on top of the current page without leaving it.
Prompt: "When saving succeeds, show a toast instead of opening a modal."
- Modal or dialog: a box that opens in the middle of the screen and blocks the page behind it until you close it. Used for things that need a decision, like confirming a deletion.
- Drawer: a panel that slides in from an edge of the screen, often from the right, often holding details or a menu.
- Toast: a small temporary message that appears in a corner and fades away on its own, like "Saved."
- Choosing between them is a real design decision. A toast for success, a modal for danger.
Form, field, label, placeholder
A form is the group of inputs you fill out together, like a signup or contact form. A field is one single input, like the box where you type your email. A label is the permanent text next to or above the field saying what it is, like "Email address". A placeholder is the grey hint text inside the field, which vanishes the moment someone starts typing, so never trust it with important instructions. Prompt: "Add a visible label above each field and keep the placeholder as a short example only."
Type without an @ and click away to see validation.
Validation
The check that runs on what someone typed, plus the message they see when it is wrong. "Enter a valid email address" appearing under the email field is validation doing its job. Good validation tells people early and politely; bad validation waits until they hit submit and then scolds them. Prompt: "Show the email error under the field as soon as they click away from it, not after they submit."
Padding, margin, whitespace
Three words for space, and mixing them up causes half of all "the spacing looks wrong" fights with an AI. Padding is the space inside a box, between the box's edge and its contents, like the cushion inside a picture frame. Margin is the space outside a box, pushing its neighbors away. Whitespace is the general idea of breathing room everywhere. Prompt: "Increase the padding inside the cards and reduce the margin between them."
Alignment
Where things sit relative to each other: lined up on the left, centered, pushed right, or spread out evenly. When text or buttons feel slightly off and you cannot say why, alignment is usually the culprit. Prompt: "Left align this text block and right align the button on the same row."
Responsive, breakpoint, viewport
The viewport is simply the visible area of the screen, which is big on a laptop and small on a phone. Responsive means the layout rearranges itself to fit whatever viewport it is in. A breakpoint is the screen width where that rearrangement happens, for example switching from three columns to one column at phone width. Prompt: "Check this page at phone width and make sure nothing sticks out past the edge of the screen."
drag the slider: three columns collapse to one at the breakpoint
Above the fold
Everything visible on the screen before any scrolling. The phrase comes from newspapers folded in half on a stand: what was on the top half sold the paper. On a website, if your price or main button is below the fold, some visitors will never see it. Prompt: "Get the price above the fold on phones."
Hover, focus, active, disabled
The different states a control can be in, each of which can look different. Hover: the mouse is over it. Focus: it is selected, usually by the keyboard, so someone tabbing through the page knows where they are. Active: it is being pressed right now. Disabled: it is switched off and cannot be used. A button with no visible hover or focus state feels dead. Prompt: "Give the buttons a clear hover style and a visible keyboard focus outline."
Icon, favicon, logo
Three small images people constantly confuse. An icon is any small symbol inside the page, like a magnifying glass for search. A favicon is the tiny picture in the browser tab, next to the page title. A logo is your brand mark. When the AI shows a blank browser tab, the fix is "add a favicon". Prompt: "Use the site logo as the favicon and keep it square."
Alt text
A short written description attached to an image. Visitors do not normally see it. Screen readers read it aloud for people who cannot see the image, and browsers show it if the image fails to load. Every meaningful image should have it. Prompt: "Add short descriptive alt text to every image on this page."
Font, typeface, weight, size
The typeface is the design of the letters, like Arial versus a serif book face. Weight is how thick the strokes are, from thin to extra bold. Size is how big the letters are. "Make it bolder" works, but "increase the weight of the headline" leaves nothing to guess. Prompt: "Use the heading typeface for the headline at a heavier weight and leave the body text alone."
Color palette, contrast, dark mode
The palette is the small set of colors your site uses everywhere. Contrast is how clearly text stands out against its background; grey text on a light grey background is a contrast failure and genuinely hard to read. Dark mode is a version of the site with a dark background and light text. Prompt: "Keep the text contrast high enough to read comfortably on the dark background."
Page and route
A page is a screen your visitor sees. A route is the address that shows it, like /pricing or /about. When you want a new screen, you are asking for a new route, and saying the address out loud makes the request unambiguous. Prompt: "Create a page at /pricing and link to it from the navigation."
Loading state and empty state
Two screens people forget to design. The loading state is what visitors see while information is on its way, maybe a spinner or a grey placeholder. The empty state is what they see when there is simply nothing to show yet, like a brand new account with no saved items. An unhandled empty state looks like a broken page. Prompt: "Show a skeleton placeholder while results load and a short friendly message when there are no results."
loading state: skeletons while data arrives
Preview, publish, deploy
The preview is your private working version that only you can see. Publishing or deploying makes it live on the internet for everyone. Until you publish, nobody sees your changes, which means experimenting is free. Prompt: "Do not change anything live yet, I want to look at it in preview first."
KETBD: the words for how it behaves
You know enough to be dangerous when you stop describing what the page looks like and start describing what it should do. These words keep that ambition from turning into a mess. You still do not need to write code; you need to describe behavior precisely.
Frontend and backend
Every web app has two halves. The frontend is the part that runs inside the visitor's browser: everything they can see and, with a little effort, poke at. The backend is the part that runs on a server they cannot touch. The practical rule: anything that must be trusted, like prices or permissions, belongs on the backend, because a determined visitor can change anything on the frontend. Prompt: "Keep the price calculation on the backend so it cannot be edited in the browser."
Component
A piece of interface that is defined once and reused in many places, like a product card that appears on the homepage, the search page, and the category page. When it is a component, changing it once changes it everywhere. When it is copy-pasted, you get three versions that slowly drift apart. Prompt: "Make this card a reusable component and use it on the homepage and the search page."
Props and state
Two ways information reaches the screen. Props are values handed into a component from outside, like the title and price handed into each product card. State is information a screen remembers while you use it, like what you have typed so far or which tab is open. If your page forgets something when you switch tabs, that is state being lost. Prompt: "Remember the selected filters in state so they survive switching tabs."
Source of truth
The one official place a piece of information lives. If the saved count lives in two places, eventually they disagree and your header says 7 while the page says 5. Declaring a single source of truth means every place that needs the number asks the same place. Prompt: "Use one source of truth for the saved list so the header count and the page always agree."
Database, table, row, column, record
The database is where your app's information is stored permanently. Inside it, a table holds one kind of thing, like listings or users, the way a spreadsheet tab does. A column is one field, like title, the way a spreadsheet column is. A row, also called a record, is one single item, the way a spreadsheet row is. Prompt: "Add a column for the maker note to the listings table and show it on the detail page."
Query
A question asked of the database: which rows, matching what, in what order, how many. "Give me the twenty newest published listings" is a query. Being specific about the question is how you get a specific page. Prompt: "Sort this query by newest first and only return published items."
API and endpoint
An API is a way for two programs to talk to each other, usually your app asking a service for something. An endpoint is one specific address in that conversation, like one phone extension at a big company: this one fetches the weather, that one processes a payment. Prompt: "Call the endpoint once when the page loads and reuse the result instead of calling it again."
Request and response
The ask and the answer. Your app sends a request; the server sends back a response. A huge share of bugs come from the response containing something different than what the app assumed. When something fails, the first question is always "what did the response actually say". Prompt: "Log what the response contains when this fails so we can see the real shape."
CRUD
The four basic things you do to any record: create it, read it, update it, delete it. Nearly every feature is some combination of these four. Saying "add full CRUD for posts" is a compact way to ask for the whole lifecycle. Prompt: "Let a signed-in owner create, edit, and delete their own posts, and no one else's."
Authentication and authorization
Two words people swap constantly, and the difference is a security issue. Authentication is proving who you are, which is signing in. Authorization is what you are allowed to do once you are signed in. You can be authenticated and still not authorized to delete someone else's post. Getting these backwards is exactly how people end up with access they should not have. Prompt: "Check on the server that the person is signed in and owns this record before saving."
Session and token
A session is the period during which you are signed in. A token is the little credential that proves it, passed along quietly with each request so you do not have to sign in on every page. When someone says their login "doesn't stick", the session or its token is the place to look. Prompt: "Keep people signed in across page refreshes and sign them out everywhere when they ask."
Permissions and roles
A role is a label given to a user, like admin or moderator. Permissions are the specific things that label can do, like publish an article or remove a comment. Keeping the two ideas separate means you can adjust what a role can do without inventing new roles. Prompt: "Only admins can publish an article; everyone signed in can comment."
Row level security (RLS)
Rules inside the database itself about which rows each person is allowed to see or change, like "people can only read their own drafts". Because the rule lives in the database, it holds even if the app code above it has a bug. It is the safety net under everything else. Prompt: "Add a database rule so people can only read their own drafts."
Environment variable and secret
An environment variable is a setting stored outside the code, like an API key or a database address, so it can change without editing the app. A secret is one that must never reach a visitor's browser: keys, passwords, tokens. If a secret ends up in browser code, anyone can see it, so secrets live on the server only. Prompt: "Read the API key on the server only, never in browser code."
Validation schema
A written definition of what acceptable input looks like, checked before anything is saved: the title must be under 120 characters, the email must look like an email. Without it, junk data slides in silently and explodes later in some other part of the app. Prompt: "Reject a title longer than 120 characters with a clear message instead of trimming it silently."
Cache and cache key
A cache is a saved copy of an answer so the app does not have to work it out again, like keeping the search results for "planner" instead of searching twice. The cache key is the label on that saved copy. If the label leaves out something that changes the answer, like the current filters, people get handed someone else's results. That is the classic cache bug. Prompt: "Include the selected filters in the cache key so a filtered view never shows unfiltered results."
Optimistic update
Showing a change instantly, before the server confirms it, because waiting makes the app feel slow. Click save, the interface updates immediately, and if the save turns out to have failed, the change quietly rolls back with a message. It is a confidence trick that only works if the rollback is real. Prompt: "Update the save button instantly and roll it back if the request fails."
Pagination and infinite scroll
Two ways to handle a long list of results. Pagination splits them into numbered pages. Infinite scroll keeps loading more as you reach the bottom. Pagination is easier to get right and easier to share ("I was on page 3"); infinite scroll feels smoother and is harder to build well. Prompt: "Load twenty results per page with a Load more button instead of infinite scroll."
Slug, URL parameter, query string
Three parts of a web address worth naming. The slug is the readable name in the address, like speak-the-language-of-code in this article's URL. A URL parameter is a variable part of the address, like the article name in /blog/anything. The query string is the part after the question mark, carrying things like search terms and filters, like ?q=planner&sort=newest. Prompt: "Keep search and filters in the query string so a filtered view can be shared as a link."
Redirect
Sending a visitor from one address to another automatically. When you rename a page, every old link in the wild breaks unless the old address redirects to the new one. This is the plumbing that keeps old bookmarks and shared links alive. Prompt: "Redirect the old address to the new one so existing links keep working."
Webhook
An automatic message one service sends your app when something happens on their side, instead of your app having to ask over and over. A payment service pinging your app to say "this order was just paid" is a webhook. The catch: anyone can send your app a message claiming to be that service, so webhooks must be verified before you trust them. Prompt: "Receive the payment webhook, verify it is genuine, then mark the order paid."
Rate limit
A cap on how often something can be done, like five submissions per hour per account. It stops both abuse and accidents, like a broken script hammering your server a thousand times a minute. Prompt: "Limit submissions to five per hour per account and explain the limit when it is hit."
Migration
A recorded, repeatable change to the structure of your database, like adding a new column. Instead of clicking around in a dashboard and hoping you remember what you did, a migration is written down so it can run the same way every time and be reviewed like code. Prompt: "Add this field as a migration so the change is recorded, not done by hand."
Console, network tab, logs
The three places you look when something breaks. The console is a panel in the browser showing errors from the page itself. The network tab shows every request the page made and what came back. Logs are the record of what happened on the server. "It doesn't work" is a hard bug to fix. "Here is the console error" is a solvable one. Prompt: "Here is the console error, find the cause instead of guessing."
Model, context, prompt, token, hallucination
The five words for talking about the AI itself. The model is the engine doing the work. Context is everything it can currently see, your conversation plus whatever else has been fed in. A prompt is your instruction to it. Tokens are the small chunks of text it reads and writes, and roughly how its limits are measured. A hallucination is a confident answer that is simply not true, which is why important claims get checked. Prompt: "Only use the files and details I gave you, and tell me if something you need is missing."
Refactor
Rearranging the insides of working code so it is cleaner, without changing what it does. Like reorganizing a workshop: same tools, same output, less tripping. Done on purpose, refactors keep a growing app from collapsing under its own clutter. Prompt: "Refactor this so both pages share one function, and do not change the behavior."
Regression
Something that used to work and no longer does, usually broken by a change that seemed unrelated. You add a filter feature and suddenly saving breaks. The defense is a habit: before calling any change done, re-test the things that were already working. Prompt: "Before finishing, check that submitting still works. I do not want a regression."
Engineer: the words for consequences
At this level the words are less about what is on the screen and more about what happens when things go wrong: two people clicking at the same moment, a service sending the same message twice, a database under real load, or a stranger trying to get in. You will not need these on day one. You will be glad they exist on day ninety.
Idempotency
A fancy word for a simple promise: doing the same operation twice has the same effect as doing it once. It matters everywhere things can repeat, like a payment webhook that arrives twice or a user double-clicking buy. Without it, repeats create duplicates: two charges, two orders, two accounts. Prompt: "Make this handler idempotent so a repeated webhook cannot create a second charge."
Race condition
What happens when two things run at the same time and finish in an order you did not plan for, producing a result that should be impossible. Two people buying the last ticket at the same instant is the classic case. The fix usually lives in the database, because the app layer cannot see the other request coming. Prompt: "Two fast clicks must not create two records. Handle that in the database."
Transaction and atomicity
A transaction wraps a group of changes so they either all happen or none do, never half. Moving money is the standard example: the debit and the credit must both succeed, or neither does, otherwise money vanishes or appears from nowhere. Atomicity is the property being described: indivisible, all or nothing. Prompt: "Write both rows in one transaction so a failure cannot leave an orphan record."
Constraint and unique index
Rules the database itself enforces, like "this field is required" or "this pair of values can only appear once". A unique index is the tool for the second one. Enforcing "one rating per person per site" as a database rule means no app bug, race, or script can ever break it, because the database refuses. Prompt: "Enforce one rating per account per site with a unique constraint, not just a check in the app."
Normalization boundary
The single place in your code where messy data from the outside world gets turned into your clean internal shape. Outside data is unpredictable: fields missing, wrong types, surprise values. Converting it once, at the boundary, means every screen inside your app deals with the same dependable shape instead of each one guessing. Prompt: "Normalize the response once at the boundary and reuse that shape everywhere."
Contract
The agreed shape of a request and its response, written down and shared by both sides: these fields exist, this one is optional, this one can be empty. When the two sides disagree about the contract, you get bugs where one side sends data the other silently ignores. Prompt: "Define the shared request and response types first, then update every consumer."
Server side rendering and hydration
A way of building pages where the server sends a complete, ready-to-view page and then the browser "wakes it up" and makes it interactive. Hydration is the waking-up step. The trap: code that assumes a browser exists while the server is still building the page will crash, because there is no browser yet on the server. Prompt: "Only read browser storage after the page hydrates, not during rendering."
N plus one query
A slow pattern where the app fetches a list, then runs one extra database query for each item in it. Ten items, eleven queries, fine. Ten thousand items, ten thousand and one queries, and your page takes forever. The fix is almost always fetching everything in one go. Prompt: "Fetch these in one query instead of one per row."
Index and query plan
An index is a lookup shortcut the database keeps for a column, like the index at the back of a book: instead of reading every page, it jumps straight to the rows you want. A query plan is the database explaining how it intends to find your rows, which is how you discover it is reading every page. When a filter is fast with a hundred rows and slow with a million, a missing index is the usual suspect. Prompt: "This filter is slow at scale. Add the index it needs."
Denormalization
Deliberately storing a copy of something you could calculate, like keeping a comment count on the post instead of counting comments every time. It trades cleanliness for speed. The catch is that the copy must be updated every time the real thing changes, or the two drift apart. Prompt: "Keep a comment count on the row and update it in a trigger."
Least privilege
The principle that every person and every part of the system gets the smallest access needed to do its job, and nothing more. A comment form does not need permission to delete users. Every extra permission is extra damage when something goes wrong or someone gets in. Prompt: "Do not use privileged credentials here. Run it as the signed-in person."
Trust boundary
The line where your system stops believing what it was sent. Anything arriving from a visitor's browser is a claim, not a fact, because a determined person can send you anything at all. So checks that matter, like "does this person own this record", happen on the server side of the boundary, every time. Prompt: "Treat every field from the client as untrusted and re-check ownership on the server."
SSRF and input sanitization
Two attack defenses worth knowing by name. SSRF is when an attacker tricks your server into fetching an address it should not, like an internal-only service, by handing you a URL to fetch. Input sanitization is cleaning anything a user types before it is stored or displayed, so a comment cannot smuggle in a script that runs in someone else's browser. Prompt: "Block private and loopback addresses when fetching a user supplied link, including after redirects."
Audit log
A record of who did what and when, which can only be added to and never edited or deleted. When something goes wrong, or someone claims they never changed that setting, the audit log is how you find out what actually happened. The append-only part is the point: a log anyone can rewrite proves nothing. Prompt: "Append every moderation decision to an audit log with the actor and the reason."
Observability
The ability to answer questions about what your system is doing that you did not think to ask in advance, using logs, metrics, and traces. Without it, debugging a live problem is guesswork. With it, you can follow one failed request end to end and see exactly where it died. Prompt: "Add enough structured logging to trace one failed submission end to end."
Feature flag
A switch that turns a feature on or off without deploying new code. It lets you ship a feature to everyone, a few people, or no one, and to switch it off in seconds if it misbehaves. It is the difference between "roll it back tonight" and "flip the switch". Prompt: "Put this behind a flag so we can turn it off without redeploying."
Rollback
Returning to the previous known good version, quickly, when a new release goes wrong. The important word is quickly: a rollback plan you figure out during an outage is not a plan. It is decided before deploying, not during the fire. Prompt: "Before we deploy, confirm how we roll this back in one step."
Graceful degradation
The design goal that when one piece fails, the rest keeps working and the visitor sees something sensible instead of a broken page. The image service is down, so show the original image. The recommendations are down, so hide that section. Small failures stay small. Prompt: "If the image service fails, show the original file rather than a broken page."
Backward compatibility
The promise that new code keeps working with old data and old links. People have bookmarks, saved drafts, and records created last year. Compatibility means none of that breaks when you improve the system, usually by reading the old shape while you migrate to the new one. Prompt: "Keep reading the old field while we migrate, then remove it in a separate change."
Technical debt
A shortcut taken on purpose, with interest due later. Like financial debt, it is fine in small amounts when you know you took it and plan to repay it, and dangerous when it piles up unrecorded. The phrase is most useful as an honest label: "we are borrowing time here." Prompt: "Do the simple version now and note clearly what we owe later."
What to do with this
Pick five terms from the Noob list you did not know an hour ago and use them in your next three prompts. Say "section" instead of "part". Say "padding" instead of "space". Say "keep everything else the same" every single time.
Precision is not showing off. It is the cheapest speed increase available to you, and it costs one better sentence.
Comments
Sign in to join the discussion on this article.
Loading the conversation…