Acronyms and insider jargon have a way of splitting a room: either you're in the club or you're quietly nodding along. I have a low tolerance for acronyms, and this happens to be one of the few things Elon Musk and I see eye to eye on. He sent out a memo banning unnecessary acronyms and "nonsense words" at Tesla and SpaceX, on the grounds that people shouldn't need to memorise a glossary before they can do their job.

Anyway.

Below is a list of common AI terminology, explained in plain English with practical examples. If you work in design or product, you don't need the math. But knowing what these words mean is the difference between taking part in the conversation and just following along.

AGI (Artificial General Intelligence)

A hypothetical future AI that matches human capability across any task: not narrowly good at writing or image recognition, but flexible and self-directed. We're nowhere near it, and experts can't agree on when, or if, we'll get there.

Example: Today's AI is exceptional at some things and hopeless at others. AGI would pick up a new skill, move through the physical world, reason when information is incomplete, and make ethical calls. Everything a person can do.

Agent / Agentic workflow

An agent doesn't just answer. It takes a sequence of actions to finish a job for you. An agentic workflow is what happens when you hand over an entire task and the AI works out the steps, picks its tools, checks its own results, and keeps going until it's done.

Example: You ask an AI to "plan my team's quarterly offsite." Rather than handing you a checklist, it looks at your calendar, researches venues, drafts an agenda, and sends the invites, with no further input from you.

Agent skills

Reusable, self-contained abilities you plug into an agent so it can handle particular jobs, a bit like apps on a phone. They can be combined to build more capable agents.

Example: Claude has a design skill that reads your Figma files, picks up component names and styles, and generates code matching your existing design system instead of inventing components from nothing.

AI assistant

A product built to help you get things done through conversation: answering questions, drafting content, managing tasks. The "assistant" label usually signals that it waits for instructions rather than acting on its own.

Example: Claude, ChatGPT, and Gemini are assistants. You ask, they answer. An agent, by contrast, might take action before you've asked.

AI experience design (AIX)

The practice of designing how people experience AI products. Not only the UI, but how the system communicates uncertainty, handles failure, earns trust, and sets realistic expectations.

Example: Good AIX might mean a confidence indicator on outputs, an explanation of why a recommendation was made, or a graceful response when the AI simply doesn't know.

AI slop

Generic, low-effort content that's obviously machine-generated with no human thought or editing behind it. Technically fine, but hollow, repetitive, and impersonal.

Example: A blog where every article opens with "In today's fast-paced digital world..." and says nothing new, each one produced in 30 seconds and never touched by a human.

Anthropomorphism

Treating AI as though it has feelings, opinions, or intentions. It's an instinctive response, especially when a product is designed to sound warm, but it can push users toward overtrust or unhealthy attachment.

Example: Assistants are often built to be friendly, use your name, and respond with empathy. That's good UX. But some people start to feel real companionship, share personal struggles, and feel genuinely stung when the AI "doesn't care." Designers are increasingly on the hook for that dynamic.

API (Application Programming Interface)

The invisible pipe connecting two pieces of software. When a product "uses AI," it's almost always calling an AI company's API, sending a request and getting a response. You pay per use, which turns cost into a genuine design constraint.

Example: Type into a support chatbot and your message goes to OpenAI's or Anthropic's API, comes back with an answer, and appears on screen, all within seconds.

Claude Code

Anthropic's coding tool that lives in your terminal or editor. It writes, edits, explains, and debugs code, runs commands, and manages entire projects. Closer to a junior developer than an autocomplete.

Example: A designer describes a component in plain English; Claude Code writes the React component, creates the file, and drops it in the right folder. No manual coding.

Context window

How much text an AI can hold in view during a single conversation. Think short-term memory: anything that falls outside the window is gone.

Example: Paste a 200-page report into a model with a small context window and it might only take in the first 50 pages. A bigger window means the whole document stays in mind.

Copilot

A design pattern (and Microsoft's brand name) for AI that works next to you rather than instead of you, suggesting, assisting, speeding you up, while you keep the final say.

Example: GitHub Copilot proposes the next lines as a developer types. Microsoft Copilot drafts a paragraph in Word when you're stuck. Accept, reject, or edit. The decision stays yours.

Eval (Evaluation)

A test that checks whether your AI is performing well. Evals are how teams measure accuracy, tone, safety, and helpfulness before and after changing a model or prompt. A typical eval has four parts: test inputs, the AI's responses, expected answers to compare against, and a scoring method.

Example: Before shipping a new version of your support bot, you run it against 500 real past conversations to see whether it beats the old one, scoring accuracy, tone, and how often it stayed away from hallucinating.

Feedback loop

The system that lets users flag whether a response was good or bad, and feeds that signal back into improving the model. Thumbs up/down is the simplest version.

Example: Every 👍 or 👎 on a ChatGPT response feeds the loop. Across millions of interactions, those signals teach the model what people actually find useful.

GenAI (Generative AI)

AI that produces new content (text, images, video, audio, code) instead of only analysing or classifying what already exists. It's the category covering ChatGPT, Midjourney, and Claude. When people say "AI" in a product or design context today, this is nearly always what they mean.

Example: You type a brief into Midjourney and get a mood board image that didn't exist a moment ago. You describe a user flow to Claude and it writes the copy for every screen. Neither is retrieving something. Both are making something.

Gen UI (Generative UI)

When AI builds the interface itself (buttons, maps, cards, layouts) on the fly, based on what you asked, rather than serving a screen designed in advance. The interface forms around the content.

Example: Ask "where's a good coffee shop near me?" and instead of text you get a live map with pins. Ask for hotels in Lisbon and instead of a list you get cards with photos, prices, and ratings, assembled in the moment for that specific question.

Guardrails

The rules and limits built into an AI product to keep it from going off-script: dangerous advice, off-brand tone, embarrassing statements. The product's code of conduct.

Example: A children's education app sets guardrails so the AI never touches violence or adult topics, stays encouraging, and steers off-topic conversations back to learning.

Hallucination

When AI states something false with total confidence: a made-up statistic, a person who doesn't exist, a wrong date. It isn't lying. It's pattern-matching into convincing nonsense.

Example: You ask for sources to back a claim and get three plausible academic papers that were never written, complete with invented authors and journals.

Human-in-the-loop (HITL) / Supervisor

A pattern where a person reviews or approves an AI action before it happens. Essential for high-stakes moments where a mistake would be costly or humiliating.

Example: An AI drafts a refund response to an angry customer, but a human support agent reads it and clicks "approve" before it sends. The AI drafts; the human makes the judgment call.

LLM (Large Language Model)

The engine underneath most AI tools you use. It's trained on enormous quantities of text to predict what comes next, an approach that turns out to be remarkably good at understanding and producing language.

Example: ChatGPT, Claude, and Gemini are all products sitting on top of LLMs. The LLM is the brain; the chat interface or app is the body.

MCP (Model Context Protocol)

A universal plug standard letting AI connect to different tools and data sources. USB-C, but for AI. Rather than every app building its own custom connector from scratch, MCP makes those connections reusable.

Example: Thanks to MCP, Claude can talk to your Notion, Gmail, and Google Calendar at once, instead of needing a separate bespoke integration for each.

Memory

An AI's ability to hold onto things between conversations, not just inside one. It can be built in or layered on top, and it's what makes an assistant feel persistent rather than like a stranger you meet again every time.

Example: You mention that you prefer short bullet-point answers. A week later, unprompted, it's still answering in bullets.

OpenAI Codex

OpenAI's model built specifically for reading and writing code. It powers GitHub Copilot and turns natural-language descriptions into working code across many languages.

Example: A PM types "create a function that takes a list of user emails and removes duplicates" and Codex writes it in Python, JavaScript, or whatever the project uses.

Prompt

The instruction or question you send an AI. Everything you type into the chat box is a prompt. How specific and well-structured it is directly shapes what you get back.

Example: "Write something about coffee" is vague. "Write a 200-word Instagram caption about oat milk lattes for a cosy café. Tone: warm and slightly witty." is a good prompt.

Prompt engineering

The craft of writing instructions that get the best possible output. It comes down to giving context, setting a role, specifying format, and offering examples. Copywriting, but for AI.

Example: Instead of "write a bio," a well-engineered prompt reads: "Write a 3-sentence professional bio for a UX designer with 5 years of experience. Tone: warm but confident. Audience: potential clients."

RAG (Retrieval-Augmented Generation)

A technique that hands the AI specific documents or data at the moment it answers. An open-book exam rather than one from memory. The result is more accurate and more current.

Example: A law firm's assistant uses RAG to search a decade of internal case files before answering, instead of guessing from general knowledge.

Sentiment analysis

AI reading the emotional tone behind text: positive, negative, neutral, or finer shades like frustration or delight. Useful for understanding how people feel at scale.

Example: A product team runs sentiment analysis across 10,000 app reviews and immediately catches a spike in negativity after a recent update, saving hours of manual reading.

Skills

Predefined capabilities you hand an agent: searching the web, writing code, reading files, sending emails. Modular "superpowers" you mix and match by task.

Example: A design AI gets three skills: access to a Figma library for existing components, brand guidelines to stay on-brand, and an image generation tool for mockups. Together they turn a one-line brief into a full draft layout.

System prompt

Hidden instructions written by the product team before any user shows up. They set the AI's role, personality, rules, and limits. Users rarely see them, but they shape everything the AI says.

Example: A banking chatbot's system prompt might read: "You are a helpful financial assistant. Never give specific investment advice. Always suggest speaking to a human advisor for complex queries. Use formal language."

Token

The unit AI uses to measure text. Not quite a word, not quite a letter. Roughly a syllable or a short word. Models cap how many tokens they can handle at once, and you're usually billed by the token. Longer prompts mean more tokens, which means higher cost.

Example: "I love great design" is about 5 tokens. A 10-page document might be 5,000. A 100,000-token limit is roughly a 75,000-word novel.

Tool calling

When an AI stops mid-task, reaches for an external tool (a calculator, a database, a web search), takes the result, and carries on. It's how AI moves from knowing things to doing things.

Example: You ask a design assistant to "check if this button colour meets accessibility standards." It pauses, calls a contrast checker with your hex values, gets the answer, and tells you whether it passes WCAG, rather than guessing from training data.

Training data

The vast body of content an AI learned from: books, websites, conversations, code. What went in shapes what the model knows, what biases it carries, and where it's strong or weak.

Example: If a hiring AI trained mostly on CVs from one demographic, it may quietly favour candidates who resemble that group, even though nobody set out for that to happen.

Vibe coding

Building software by describing what you want in plain language and letting AI write the code. You iterate through conversation instead of typing a single line yourself. Fast for prototypes, risky the moment it becomes production code without proper review.

Example: A product manager with no coding background builds a working clickable prototype of a new feature in an afternoon, just by describing it to a tool like Cursor or Bolt.

Dieter Rams wrote his good design principles back when design meant physical objects. Don Norman helped us make sense of digital interfaces through affordances and feedback loops. Hick's Law, Fitts's Law, the Gestalt principles: all of them came from watching how people interact with the world, and all of them still hold up.

But the design experience is shifting. AI doesn't only change what a product does. It changes how the interaction itself works. The system isn't simply responding anymore. It's guessing at what you want, taking actions for you, and occasionally doing things you never fully asked for.

These 8 principles draw on research from Google's PAIR, Microsoft's HAX guidelines, and the emerging field of agentic AI design, written in plain language any designer can pick up and use. They apply whether you're working on a recommendation engine, a generative tool, an AI assistant, or anything in between.

1. Start with a real problem, not a cool feature

Don't add AI because you can. Add it because it genuinely makes something easier or better. Users don't care whether something is "powered by AI." They care whether it works for them. If you stripped the AI label off, would the feature still be worth building? If not, go back to the drawing board.

Questions to ask:

• Does this solve a problem users actually have, or one we assumed they have?
• Would users notice or care if the AI wasn't there?
• Have we talked to real users about whether this helps them?

2. Keep the human in charge

AI should feel like a very smart assistant, not a boss. People need to feel like they're the ones making decisions and the AI is just helping them get there faster. The moment users feel something is happening to them rather than for them, you've lost them.

Questions to ask:

• Can the user override, ignore, or undo what the AI does at any point?
• Does the interface make it obvious that the human has the final say?
• Are there moments where the AI acts without giving the user a chance to review?

3. Set honest expectations from the start

AI isn't magic, even when it feels like it, and users will work that out quickly if you oversell it. Help people understand what the AI is good at and where it's likely to fail, before they discover it themselves at the worst possible moment. Trust builds slowly and breaks fast.

Questions to ask:

• Does our onboarding explain what the AI can and can't do in plain language?
• Are we showing confidence levels when the AI is unsure, instead of always sounding certain?
• What happens when a user trusts the AI too much and it gets something wrong?

4. Make intent explicit: ask before acting

Don't let the AI guess, especially when something important is at stake. Start with suggestions before actions. For bigger tasks, be upfront about what the AI is going to do, what it won't touch, and what needs approval before anything happens.

Questions to ask:

• Does the AI ask clarifying questions before taking on complex or important tasks?
• Do users know exactly what the AI is about to do before it does it?
• Are there clear limits on what the AI can act on without explicit permission?

5. Be transparent where it changes what users do

Background AI can be invisible, and that's completely fine. A recommendation algorithm quietly doing its job doesn't need a label. But when AI shapes a decision the user cares about, they should be able to understand why it happened and opt out if they want.

Questions to ask:

• Do users know when AI is influencing what they see or what happens next?
• Is there a clear, accessible way to find out why the AI made a specific suggestion?
• Can users opt out of AI features they don't want?

6. Give users real control over high-stakes decisions

Some decisions are too important to happen automatically. When an action is irreversible or consequential, like deleting data, sending a message, or making a financial decision, design for proper human review. Make it visible, make it clear, and make sure the user is genuinely the one deciding.

This is not the same as adding a confirmation dialog. It's about making sure users actually understand what they're confirming, and that they have everything they need to make the call themselves.

Questions to ask:

• Have we identified which actions in our product are high-stakes or irreversible?
• Are we giving users a real preview of what will happen, not just "are you sure?"
• Does the user have enough information at this moment to make a genuinely informed decision?

7. Make it easy to fix mistakes

AI will get things wrong. That's not a bug, it's just reality. What matters is how easily those mistakes can be caught and corrected. If fixing an error feels like more work than doing the task manually, users will stop trusting the feature altogether.

Graceful failure is a design skill. The best AI experiences don't hide errors or pretend they didn't happen. They surface them clearly and make correction feel effortless.

Questions to ask:

• How many steps does it take to undo or correct what the AI did?
• Is it obvious when the AI is uncertain or might be wrong?
• Does every AI action have a clear fallback or recovery path if it fails?

8. Create feedback loops

Every AI output needs a way for users to say "this was wrong" or "this helped." That loop is what rebuilds trust when things go badly, makes users feel heard, and improves the product over time. If users can't talk back to the AI, they'll just walk away from it.

Feedback mechanisms don't have to be complicated. A thumbs up, a simple edit, a "why did this happen?" link: small signals add up to a much stronger product over time, and they tell users that someone is actually listening.

Questions to ask:

• Is there a simple way for users to rate, correct, or flag any AI output?
• Do we have a way for users to understand why the AI did what it did?
• Are we actually using that feedback to improve things, or just collecting it?

These principles aren't final. As AI changes, some of this will need updating. What matters today might matter less tomorrow, and we'll run into new problems nobody has thought of yet. But they work for building AI products right now.

The design field is learning as it goes. We're all figuring out what works together, in real time. One thing stays the same though: it's still about the person using your product. Keep the human in the loop, yes, but more than that, keep them at the centre. In the end it comes down to trust. Earn it and you have something people actually use. Skip it and you have another feature nobody cares about.

Vibe coding tools and projects is my happy place. I could do this for hours. I've built pages before with HTML/CSS, but AI has handed me new powers, and now all my ridiculous tool/product/app ideas can actually go live.

I recently built an email signature generator. If you're a professional or a business owner, a branded signature matters for trust and credibility. But anyone who's tried to make one knows most providers don't make it easy.

There are third-party solutions and templates out there, though design-wise most of them look clunky. So as a designer my next thought was obvious: why don't I build one?

The idea is simple. A well-designed template, basic customization, easy content editing, and a one-click way to copy it into your email provider. Clean, simple, works across providers, looks good on mobile, and doesn't scream "this was vibe-coded."

So I started building. I'm not a technical person. I know a bit of HTML/CSS and what good design looks like, so the MVP had to be minimal. No scary words like API, database, PR, git, or terminal. Those are future-me problems.

Process

1. Vibe code the first prototype. Quick, dirty, ugly. We're thinking about functionality here, not polishing the UI. Lovable, Replit, Claude, or something similar, just to get something working.
2. Brainstorming. Share the prototype with Claude and/or ChatGPT (HTML, screenshot, or link), explain what I'm building, ask for feedback on what's missing and what could be improved. During this phase I'm thinking about MVP scope and UX. It has to be simple and light. The goal is a working tool quickly, with fewer but better-quality features. I dismiss suggestions that are too complex or just unnecessary for the first iteration.
3. Build. Once I had the feature list, I asked Claude and/or ChatGPT to build the HTML. I can't comment on code quality, but the UI at this stage was drastically better, and Claude was clearly superior here. So now I've got the meat. Time to iterate and polish.
4. Polishing. This is the trickiest stage and it took far more time than it should have. I maxed out the limits multiple times and kept jumping between Claude and Codex. The hard part is that even with a plan, the plan is never perfect. I kept coming up with improvements along the way. The classic drill: add, remove, make bigger, replace, repeat.
5. UI. As a designer, I couldn't go with default purple gradients or generic Claude UI, so this stage also took some time. Mostly research on Pinterest for inspiration and shadcn/ui for structure. In general the UI was built with clear, specific instructions rather than vibes like "make it minimal/clean/modern," which usually produce a very generic look.
6. Check-up. Once I was more or less happy with the tool, I asked both Claude and ChatGPT to review the code and functionality: clean up code, check best practices, that sort of thing. Running this on both is genuinely useful because they end up checking each other's mistakes. There were cases where ChatGPT couldn't fix mobile behaviour even with detailed instructions. I took the code to Claude and it fixed it immediately.
7. Testing. Since my tool is an email signature generator, I had to test how it actually works in real life: on different email providers, how it behaves when you add the signature, and how it looks on the receiver's side. This part seems easier than it is, because an email signature isn't rendered the same way as regular HTML across providers. Broken UI, different colours, missing icons, broken layout on mobile, to name a few. I took the issues I found back to Claude/ChatGPT and fixed them through further iterations.

Lessons learned

Literally, just ask. You don't need to know all the technicalities, best practices, and solutions. Stuck on something? Delegate the problem to AI.

Brutally cut the scope. AI amplifies the temptation to add every bell and whistle, but don't. At least not for V1. It only creates more problems to solve.

Use both Claude and ChatGPT. It felt like having two colleagues. If one gets tired (aka hits the token limit), I bring the code to the other. If I don't like a proposed solution, I go for a second opinion.

Vibe coding something to production can genuinely be a single-prompt affair if all you need is a memory game for your grandma. But building something decent still takes time. It's the thinking, the crafting, the designing of the experience. That's the part I actually enjoy, and honestly, that part hasn't changed with AI. The tools are new, the process is the same.

Hope this was helpful. Feel free to test and use it yourself, and let me know how it went in the comments.

Try the email signature generator ↗︎

Sometimes a random question pops into my head and I just need to figure it out. This was one of those times — so why the humanoid robots and can't we design something better?

I saw this video the other day Is the Figure 03 Robot Ready to Clean Your House? A tall, sleek humanoid robot walking around, moving its fingers, folding laundry, trying to act natural. Weird to see in action, if you ask me, but that's another topic. This got me thinking: do these robots really have to look like us? Is that intentional? They look kind of awkward, so can't we design something better than humans? Or, to put it a more human-friendly way — isn't there a more efficient way to design machines that help us? So I got curious and decided to dig into it a bit.

The world is built for humans

From Tesla's Optimus to Figure 03, today's most hyped robots look like us. Two arms, two legs, five fingers, a head. Sometimes even features that resemble eyes and a mouth — creepy. And that is not intentional in a sense that they are trying to build a human replica (or are they?). It is because the world was simply designed for the human body.

Our homes, offices, and cities follow design ergonomics based on how humans reach, grip, move, and interact with objects. Everything from light switches to kitchen drawers, doorknobs, chairs, and stairs assumes a certain height, range of motion, and dexterity. If a robot needs to operate in this environment without redesigning the entire space, it has to mimic the human form.

Take a simple example from one of Tesla's Optimus demos, where the humanoid was working as a bartender. The counter height, the size of the glass, and the placement of tap handles were all designed for human ergonomics. The robot did not need to be shaped like a person for the task itself, but it had to fit into a space designed entirely around human bodies.

Some robots don't bother mimicking

But not all robots are trying to pass as people.

Plenty are designed solely for their task. Boston Dynamics' Spot, for example, is a four-legged robot-dog built for rough terrain, inspection, and emergency response. It doesn't need arms — it needs agility. Your favorite Roomba is just a simple rolling disc that vacuums floors. In warehouses, you'll find robotic arms that lift, weld, or pack with extreme precision.

These task-specific robots are usually more efficient, cheaper, and more reliable than humanoids because they are not trying to do everything. They are built to do one job, and they do it well.

The challenge of general-purpose robots

Where it gets tricky is when you want one robot to do many human tasks, especially in unpredictable environments like homes, offices, or hospitals.

Engineers have tried alternative shapes, but when it comes to things like opening doors, climbing stairs, unloading groceries, or picking up a dropped spoon, the human form still wins on flexibility. Even a basic doorknob needs reach, grip, and wrist rotation. These are surprisingly hard to replicate without a hand and an arm.

That said, the human body isn't a piece of a perfect design either. Roboticists struggle to match our dexterity, especially with delicate tasks like handling fruit or threading a needle. However, some grippers, like suction cups or soft robotic tentacles, actually outperform human hands in specific situations. But they fall short when it comes to general versatility.

So while it's tempting to imagine a smarter or more efficient form, in practice, the most adaptable robot still ends up looking like us. Not because humans are the best design, but because the world is built as if we are.

Recently I've seen more people calling out how AI-designed sites all look the same (meaning ugly?). I decided to dig into why that's happening.

Models learn patterns, not design rules

Vibe coders are trained on huge datasets of HTML, CSS, and screenshots. They don't learn taste or visual hierarchy, only what repeats most often. If purple gradient buttons show up in a lot of examples, those become the "safe" choice. Same with glowing cards, gradient headlines or rounded corners.

The model doesn't understand when to use those things. It only learns that they are popular. So when it generates a page, it stacks everything that scored high in the data. The result looks busy, loud, and artificial, even if each part came from real aesthetic designs.

It's like an intern who goes to Pinterest, finds the best-looking pieces, and uses them all at once, because they all look great. Separately. On different pages. Or even different projects.

Knows structure, not restraint

These models understand structure fairly well. They know a landing page has a header, a hero section, a list of features, maybe testimonials and a footer. That's easy to learn because those elements appear in a predictable order.

What they don't learn is visual restraint. They can build the bones, but they don't know that only one part of the layout should attract attention. They can place a hero section correctly, but they don't know that background and cards shouldn't all fight for focus at once.

Training data favors flashy components

A big part of the sameness comes from what's easy to scrape. Dribbble, Behance, and UI showcases are full of isolated components with strong colors, gradients, shadows, and motion. Those are clean, easy to parse, and labeled. Real websites are harder to process and often more restrained, so they don't appear as clearly in training data.

The model ends up focusing too much on flashy standalone components. It learns from what looks exciting on a single card, not from what works on a big picture. When you ask for a full layout, it combines all the shiny pieces it knows instead of understanding how they visually balance each other.

Prompting acts as a design filter

Since the model doesn't come with taste, prompts act as guardrails. A vague instruction like "modern, vibrant startup website" usually results in the typical purple gradient soup, spiced up with shadows, rainbow icons, and corners that are either too sharp or too soft.

A more precise prompt like "minimal layout, one accent gradient on the CTA, flat neutral background" forces the AI to stay within limits.

Prompt templates exist because the model can't manage style consistency on its own. They're how you apply design rules — until the tools learn to do it better.

Let's not be too judgmental or demanding. It's still early days for all this tech. Remember the early Midjourney images? Yeah. I think AI vibe coders are somewhere around the happy people with six fingers stage right now.

Could this be fixed inside the model

Yes, in theory. It would require training on complete, labeled websites, not just fragments. The system would need to learn relationships between sections, visual hierarchy, and when repetition hurts clarity. That kind of dataset barely exists right now, and it would take real human annotation to build.

Until then, the only way to get coherent results is to guide the model with clear constraints. Guardrails inside the model will come eventually, but for now the designer's direction still matters more than the generator.