Part 2: The Language of Building (So AI Actually Understands You)

Hi, it's G again.

Welcome back. If you're here, that means one of two things: either you actually did the Part 1 checkpoint and wrote your six canonical docs (salamat, you're one of the real ones), or you skipped it and came straight here hoping Part 2 would be easier.

Spoiler: it won't work that way. But I'm not your dad, so do what you want.

For those who did the work, here's what we're tackling today: the vocabulary.

See, the reason most people fail at vibe coding isn't just lack of documentation. It's also that they don't know what words to use when talking to AI. They say things like "make it look better" or "fix the layout" and wonder why AI gives them random outputs.

It's like going to a carinderia and saying "bigyan mo ako ng masarap." Ano yun? Adobo? Sinigang? Pritong itlog? The tindеrа will just stare at you. Be specific, or you'll get whatever's easiest for them to serve.

Same with AI. If you can't describe what you want in clear, specific terms, AI will serve you whatever's easiest to generate. And that's usually garbage.

So in Part 2, we're learning the language of building. The actual words and concepts you need to describe UI, UX, components, state, layout, styling, and all the other things that make an app actually work.

By the end of this, you'll be able to tell AI exactly what you want, and AI will stop guessing.

Ready? Let's go.

UI vs UX (And Why You Need to Know the Difference)

Everyone throws these terms around. Nobody explains them simply.

UI is what it looks like.
Colors. Fonts. Button shapes. Spacing. The visual layer.

UX is how it feels to use.
Can someone figure out what to do? Is the flow intuitive? Do people get stuck? Are they frustrated or delighted?

You can have beautiful UI and terrible UX. Pretty buttons that nobody knows how to click. Like those fancy restaurant menus na walang presyo, and you're too embarrassed to ask, so you just order the cheapest-sounding thing and hope for the best.

You can also have ugly UI and great UX. Functional, clear, people know exactly what to do, but it looks like it was designed in 2003. Think Craigslist. Pangit pero effective... (buhay pa ba Craiglist?..lol)

When you talk to AI, be specific about which one you mean:

UI prompt: "Make the button gradient blue to purple, 16px padding, rounded corners."

UX prompt: "Make it easier for users to find the checkout button. Maybe move it to the top right and make it stand out more."

Both: "Make the checkout button more obvious. Use a bright orange color (#FF6B35), position it top right, and add a subtle drop shadow so it pops."

See the difference? One describes appearance. One describes experience. The third combines both with specifics.

Design Styles You Need to Know

These are the visual languages dominating right now. When you reference them in your FRONTEND_GUIDELINES.md or in prompts, these terms unlock specific aesthetics instead of vague descriptions.

Glassmorphism

Frosted glass effect. Translucent elements with background blur, subtle borders, soft shadows floating over colorful backgrounds.

Think Apple's macOS, Windows 11, Spotify's mobile app.

In CSS: backdrop-filter: blur()

Creates depth and hierarchy without heavy shadows. Looks premium. Works great for cards, modals, navigation bars, dashboards.

The risk: transparency can reduce readability. Keep text contrast high. Parang yung glass walls sa mall, maganda tingnan pero minsan nakakabangga ka pa rin kasi di mo nakita.

Prompt example: "Create a card with glassmorphism effect, white background at 20% opacity, backdrop blur 10px, subtle white border."

Neobrutalism

Raw, bold, intentionally unpolished. High-contrast colors, thick black borders, flat shadows, clashing palettes, quirky fonts.

Think Gumroad, early Notion vibes. It's minimalism with attitude.

Works well for creative brands, portfolios, indie tools. Stands out because everything else looks the same.

Like wearing a bright yellow raincoat to a formal event. Everyone's in black suits, but you? You're memorable.

Prompt example: "Design in neobrutalist style with thick 3px black borders, bold primary colors (#FF0000, #00FF00), and flat drop shadows offset 8px."

Neumorphism (Soft UI)

Elements look like they're extruded from or pressed into the background. Soft, diffused shadows on both sides create a tactile, 3D feel.

Subtle and elegant but tricky for accessibility. Low contrast makes buttons hard to distinguish.

Like those massage chairs na sobrang comfortable pero pag tinignan mo, di mo sure kung saan yung power button...lol

Works best for small UI elements: toggles, sliders, cards. Not great as your entire design language.

Prompt example: "Create a toggle switch with neumorphic style, soft inset shadow when off, subtle outset shadow when on, same color as background (#E0E5EC)."

Bento Grid

Modular layouts where content is arranged in blocks of different sizes, like a Japanese bento box.

Apple popularized this. Cards of varying dimensions create visual rhythm and hierarchy. Big cards for important content, smaller cards for secondary info.

Responsive by nature. The grid rearranges on mobile.

Perfect for dashboards, product pages, feature showcases, portfolios.

Like Tetris, but intentional. Each piece has its place, and the whole thing just works.

Prompt example: "Create a bento grid layout, 4 columns on desktop, main feature card spans 2x2, secondary cards 1x1, auto-reflow to single column on mobile."

Dark Mode

Not just a preference toggle anymore. It's a design system.

Dark backgrounds with light text, careful contrast ratios, muted accent colors.

Reduces eye strain, saves battery on OLED screens, looks premium.

If you're building any consumer app, plan for both light and dark mode from the start. Don't add it randomly later. Define both palettes in your FRONTEND_GUIDELINES.md.

Like having both day and night playlists. Different moods, same vibe.

Prompt example: "Define dark mode palette: background #111827, surface #1F2937, text #F9FAFB, primary #3B82F6 (same as light mode for consistency)."

Kinetic Typography

Text that moves, stretches, reacts to scroll or cursor. Headlines that animate on entry, text that scales as you scroll, interactive type treatments.

Not just fade-ins. With modern CSS and libraries like Framer Motion, this is achievable without heavy JavaScript.

Use sparingly for hero sections and key moments. Too much and it's annoying, like yung kapitbahay na laging malakas ang music.

Prompt example: "Animate the hero headline on scroll, scale from 80% to 100% and fade from 0.5 to 1.0 opacity as it enters viewport."

Micro-interactions

Small animations that respond to user actions.

A button that subtly scales on hover. A checkbox that bounces when clicked. A loading spinner that feels alive.

These tiny details separate polished products from amateur ones. They communicate that the interface is responsive and alive.

Like when you tap a tricycle and the driver immediately looks back. That instant feedback? That's what micro-interactions do.

Prompt example: "Add hover state to button: scale 1.05, transition 200ms ease-out. On click: scale down to 0.95 then back to 1.0 with spring animation."

How to Reference Design Styles with AI

Don't say "make it look modern." That means nothing.

Say: "Glassmorphism cards with bento grid layout, dark mode, and micro-interactions on hover states."

That's specific. Buildable. Clear.

Lock your design decisions in FRONTEND_GUIDELINES.md before coding starts. Pick one or two styles, define your color palette, spacing scale, border radius, shadow values, animation timing.

If this isn't documented, every component will look different. Your app will look like it was built by five different people in five different moods. Parang group project sa college na hindi nag-usap.

Components (The Lego Blocks of Your App)

A component is a reusable piece of interface.

Think legos. Each brick is a component. You snap them together to build something bigger.

A button is a component. A navigation bar is a component. A card showing a product is a component. A form is a component made of smaller components (inputs, labels, buttons).

Why This Matters for Vibe Coding

When you say "build me a landing page," AI has to decide what components to create. If you don't specify, it guesses. And it might build everything as one giant mess instead of clean, reusable pieces.

Bad prompt:
"Build a landing page."

Good prompt:
"Build a landing page with these components: navbar (logo left, nav links right), hero section (headline, subheadline, CTA button), features grid (3 cards with icon, title, description), testimonial carousel, CTA section, footer."

Now AI knows exactly what pieces to create. Each piece is isolated. Each piece can be edited independently.

That's the power of thinking in components.

Real Example from Resiboko

When I was building the recipe app, I didn't say "build the recipe page."

I said: "Build a recipe card component with: image (16:9 ratio, rounded corners), title (20px bold), description (14px, 2 line clamp), author info (avatar, name), timestamp, save button (heart icon)."

AI created that component once. Then I reused it everywhere: on the feed, in search results, in the user's saved recipes. One component, multiple uses. That's efficiency.

Component Naming Matters

Name your components clearly. Not "Card1" and "Card2." Use descriptive names: RecipeCard, ProfileCard, TestimonialCard.

When you come back to your code in three months, "RecipeCard" tells you what it is. "Card1" tells you nothing. It's like labeling your tupperware. "Ulam" is better than "Container 3."

Layout (Where Things Actually Go)

Layout is where things go on the page.

Every website is boxes inside boxes. Master this concept and you'll understand 90% of web design.

The Main Boxes

Header/Navbar at the top
Main content in the middle
Optional sidebar beside it
Footer at the bottom

Inside main content, more boxes:

• Sections that divide the page
• Containers that control width
• Grids that organize items into rows and columns
• Cards that group related content

Describing Layout to AI

Vague: "Put the sidebar on the left."

Specific: "Two-column layout. Sidebar on the left, 250px wide, fixed position (doesn't scroll). Main content takes remaining space, max-width 1200px, centered."

AI now knows exactly what to build.

Real Example

When I built the AI For Pinoys dashboard, I described the layout like this:

"Three-column layout on desktop:

• Left sidebar: 280px wide, fixed, contains navigation
• Center content: flexible width, min 600px, main feed
• Right sidebar: 320px wide, sticky, shows community highlights

On mobile (below 768px):

• Single column
• Left sidebar becomes hamburger menu
• Right sidebar moves below main content"

That level of detail? Zero guessing. Clean output.

State (Why Your Button Doesn't Do Anything)

State is data that changes.

When you click a button and something happens, state changed. When you type in a form and see your text appear, state changed. When you toggle dark mode and colors flip, state changed.

State is why your app feels alive. Without state, everything is static. Nothing responds.

Common State Examples

• Is the menu open or closed?
• Is the user logged in or logged out?
• What items are in the shopping cart?
• What text is in the input field?
• Is this loading or done loading?
• Did this succeed or fail?

When Your Button Doesn't Work

90% of the time, it's a state problem.

The click happened, but nothing told the app to update. It's like pressing a doorbell na walang battery. You pressed it, pero walang sound.

Talking to AI About State

Vague: "Make the modal work."

Specific: "When the user clicks the 'Add Recipe' button, set the modal state to open. When they click the X button or click outside the modal, set it to closed. When they submit the form, close the modal and show a success message."

AI now knows what state to track and when to change it.

Styling (Making Things Not Look Like Shit)

Styling is how you make things look good.

CSS is the language that controls appearance. Colors, spacing, fonts, sizes, positions.

Tailwind: The Shortcut System

Instead of writing CSS files, you add classes directly to elements.

bg-blue-500 makes background blue
text-xl makes text bigger
p-4 adds padding
rounded-lg adds rounded corners

It's faster. It's consistent. It's what most modern vibe coders use.

Like texting shortcuts. Instead of typing "Hahaha natatawa ako," you just send "HAHAHA." Same meaning, less effort.

Design Tokens: Your Secret Weapon

Design tokens are consistent values you reuse everywhere.

Your brand blue isn't just any blue. It's #3B82F6 everywhere. Your spacing isn't random. It's always multiples of 4px (4, 8, 12, 16, 24, 32, 48, 64). Your border radius is the same on every card. Your shadow values are identical on every elevated element.

This is what separates amateur apps from polished ones.

When every component uses the same design tokens, your app feels cohesive. When each component invents its own values, it looks like five different people built it during different mental breakdowns.

Lock It Down in FRONTEND_GUIDELINES.md

Before you start coding, document:

Your color palette with exact hex codes:

• Primary: #3B82F6
• Secondary: #8B5CF6
• Background: #F9FAFB
• Surface: #FFFFFF
• Text: #111827
• Border: #E5E7EB
• Success: #10B981
• Error: #EF4444
• Warning: #F59E0B

Your spacing scale:
4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px

Your font stack:

• Font: Inter (Google Fonts)
• Heading sizes: 32px, 24px, 20px (bold)
• Body: 16px (regular)
• Small: 14px (regular)

Your border radius:
8px (cards, buttons), 12px (modals), 16px (large containers)

Your shadows:

• Small: 0 1px 3px rgba(0,0,0,0.1)
• Medium: 0 4px 6px rgba(0,0,0,0.1)
• Large: 0 10px 20px rgba(0,0,0,0.1)

Your transitions:
200ms ease-out (default), 300ms ease-in-out (modals), spring animation for delightful moments

When AI has this doc, every component it generates matches. Without it, you'll spend hours manually fixing inconsistencies that shouldn't exist.

Trust me, I've been there. Three days fixing random colors because I didn't lock them down. Never again.

Responsive Design (So Your App Doesn't Break on Phones)

Responsive means your site works on all screen sizes.

Your laptop is wide. Your phone is narrow. Same site, different layouts.

The Basic Rules

On big screens: show more columns, full navigation, side-by-side layouts

On small screens: stack things vertically, hamburger menu, single column

Breakpoints: Where Design Changes

These are the screen widths where your layout shifts.

Mobile: 0-640px
Tablet: 640-1024px
Desktop: 1024px and up

Mobile-First: The Right Way to Build

Design for the smallest screen first, then add complexity for larger screens.

This is how Tailwind works by default. Styles without a prefix apply to all screens. Prefixed styles like md: and lg: only kick in at those breakpoints.

Example:
flex flex-col md:flex-row

Translation: stacked on mobile, side by side on tablet and up.

Why Mobile-First Matters

50%+ of your users are on phones. If you only test on your laptop, you'll ship a broken experience for most people.

Like cooking adobo and only tasting it while it's hot. When it cools down (aka when users see it on mobile), it might taste completely different. Test both temperatures.

Define Responsive Patterns in FRONTEND_GUIDELINES.md

"Navigation: hamburger menu below 768px, full horizontal nav above. Grid: single column mobile, two columns tablet, three columns desktop. Font sizes: scale up 15% at each breakpoint."

When AI has these rules documented, every component it builds responds correctly to every screen size.

Pages vs Routes

A page is what the user sees.
A route is the URL that shows that page.

yoursite.com/ shows the home page
yoursite.com/about shows the about page
yoursite.com/products/123 shows product 123

Static vs Dynamic Routes

Static: /about always shows the same page

Dynamic: /products/[id] shows different products based on the id

Like how every tricycle driver knows their routes. "Dito lang ako, Robinson's to SM." That's their route. Same path, different passengers (data) every trip.

Describing Routes to AI

Vague: "I need a product page."

Specific: "I need 4 pages: home (/), about (/about), all products (/products), single product (/products/[id])."

AI now knows the full structure. It builds navigation that links correctly and creates the right files in the right places.

Frontend vs Backend (And Why You Need to Know Both)

Frontend is what users see and interact with. The interface. Runs in their browser.

Backend is what happens behind the scenes. Database, user accounts, processing. Runs on a server.

The Flow

1. Frontend collects your input
2. Sends it to the server
3. Server validates and saves it
4. Server sends back confirmation
5. Frontend shows success message

Like ordering food sa Grab. You (frontend) pick what you want, send the order (API call), restaurant (backend) receives it, cooks it, sends it back, you receive confirmation and eventually your food.

When Do You Need a Backend?

You need one when:

• Users can create accounts
• Users can save their own content
• You need to store submissions
• You have data that grows over time

You don't need one when:

• Static site, same content for everyone
• Portfolio with no user interaction
• Landing page that just collects emails through a form service

Telling AI Which One You Need

"This is frontend only, just a landing page."

vs

"This needs a backend with user accounts and a database for saving recipes."

Completely different outputs.

APIs (How Your App Talks to Other Apps)

An API is how two systems talk to each other.

Your frontend needs data from your backend? It asks via an API.

Your app needs weather data? It asks a weather service via their API.

Your app needs to process payments? It talks to Stripe via their API.

Think of an API as a Waiter

You tell the waiter what you want. Waiter goes to the kitchen. Brings back your order.

You don't go in the kitchen yourself. You don't cook. You just tell the waiter, and the waiter handles it.

Common Patterns

GET: retrieves data ("get me all products")
POST: sends data ("save this new recipe")
PUT: updates data ("change the recipe title")
DELETE: removes data ("delete this recipe")

Talking to AI

"When the page loads, make a GET request to /api/products and display the results in a grid."

AI knows exactly what to build.

Databases (Where Your Stuff Actually Lives)

A database is where you save stuff permanently.

Without a database, everything resets when you refresh. User signs up, refresh, gone. Item added to cart, refresh, gone.

Like writing your grocery list on a whiteboard. Someone accidentally erases it, boom, nawala lahat.

When Do You Need One?

• Users can create accounts
• Users can save their own content
• You need to store submissions
• You have data that grows over time

When Do You NOT Need One?

• Static site, same content for everyone
• Portfolio with no user interaction
• Landing page that just collects emails through a form service

The Easiest Start: Supabase

Free tier. Good docs. Handles auth too.

If you're not sure what to use, use Firebase.

Talking to AI

"Use Firebase. I need a users table with email and password, and a posts table with title, content, and user_id."

AI knows your data structure and builds everything to match.

Authentication (Login/Logout AKA Proving Who You Are)

Authentication is harder than it looks.

Passwords need to be encrypted. Sessions need to be managed. Tokens need to be handled. It's easy to mess up.

Don't Build Auth from Scratch

Use a service.

Clerk: Simplest, great UI out of the box
Firebase Auth: Works if you're already using Firebase for your database

Like why would you make your own suka when Datu Puti exists? Use what's already proven to work.

Talking to AI

"Use Clerk for authentication. Users can sign up with email or Google. After login, redirect to the dashboard."

Let the service handle the hard parts.

File Types (What All Those Files Actually Are)

You'll see a lot of files in your codebase. Here's what they mean:

.html - structure of a webpage
.css - styling rules
.js - JavaScript that makes things interactive
.jsx - JavaScript with HTML-like syntax for React
.ts - TypeScript (JavaScript with types that catch errors)
.tsx - TypeScript with React
.json - structured data
.md - markdown, formatted text
.env - environment variables and secrets
.gitignore - tells git which files to skip

The Important One: .env

This is where you put API keys, secrets, passwords.

Never share this file.
Never commit it to git.
Never screenshot it.

If you leak your .env, you leak access to everything. Some lucky hacker will run up your API bill for thousands of dollars.

Like leaving your wallet open on a jeepney. Wag ganun.

Folder Structure (Where Your Files Live)

Where your files go matters. A messy project confuses AI.

Standard Structure

my-app/
├── src/
│   ├── app/           → pages and routes
│   ├── components/    → reusable UI pieces
│   ├── lib/           → utilities, helpers
│   └── styles/        → CSS files
├── public/            → images, static files
├── .env               → secrets (never share)
├── CLAUDE.md          → AI rules and context
├── progress.txt       → session tracking
├── PRD.md             → product requirements
├── APP_FLOW.md        → user flows
├── TECH_STACK.md      → dependencies
├── FRONTEND_GUIDELINES.md → design system
├── BACKEND_STRUCTURE.md   → database spec
├── IMPLEMENTATION_PLAN.md → build sequence
├── package.json       → dependencies list
└── README.md          → project overview

Tell AI Where to Put Files

"Create the button component in src/components/Button.tsx."

If you don't specify, AI might put files anywhere. And nothing connects properly. Parang hinahanap mo yung remote, pero nandun pala sa kusina. Walang sense.

Your Part 2 Checkpoint

If you made it this far, you now have the vocabulary. You know what components are. You know the difference between UI and UX. You can describe layout, state, styling, responsive design. You understand pages vs routes, frontend vs backend, APIs, databases, auth.

This is the language of building. Use it.

Here's what you need to do before Part 3:

Practical Checkpoint:

Step 1: Update your FRONTEND_GUIDELINES.md
Go back to the doc you created in Part 1. Add:

• Specific design style (glassmorphism, neobrutalism, etc.)
• Complete color palette with hex codes
• Spacing scale (4px increments)
• Typography system (font, sizes, weights)
• Border radius values
• Shadow definitions
• Transition timing
• Responsive breakpoints and rules

Example addition:

Design Style: Glassmorphism with bento grid layouts

Colors:
- Primary: #3B82F6
- Background: #F9FAFB
- Text: #111827
- Border: #E5E7EB

Spacing: 4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px

Typography:
- Font: Inter (Google Fonts)
- H1: 32px bold
- Body: 16px regular
- Small: 14px regular

Border Radius: 8px (cards), 12px (modals)

Step 2: Describe your app's layout in specific terms
Write down (doesn't have to be formal, can be in notes):

• What's in your header/navbar?
• How is your main content organized?
• Do you need a sidebar? Where?
• How does the layout change on mobile?

Example: "Two-column layout desktop, left sidebar 280px with navigation, main content flexible width, single column on mobile with hamburger menu."

Step 3: List your components
Based on your APP_FLOW.md, write down every component you'll need. Be specific.

Example for a recipe app:

• Navbar (logo, nav links, user avatar)
• RecipeCard (image, title, description, author info, save button)
• RecipeForm (title input, ingredients list, steps list, photo upload)
• SearchBar (input, search icon, filters dropdown)
• Footer (links, social icons, copyright)

Step 4: Practice describing something to AI
Pick one component from your list. Describe it to AI using the vocabulary from this post.

Bad example: "Make a card for recipes."

Good example: "Create a RecipeCard component with: image (16:9 ratio, object-cover, rounded-t-lg), title (text-xl font-bold, text-gray-900), description (text-sm text-gray-600, line-clamp-2), author info (flex items-center gap-2, avatar 32px rounded-full, name text-sm), save button (heart icon, text-red-500 when saved, text-gray-400 when not saved). Use design tokens from FRONTEND_GUIDELINES.md. Mobile: full width, desktop: 320px fixed width."

See the difference? The second one leaves zero room for guessing.

Step 5: Test yourself
Can you answer these without looking back?

• What's the difference between UI and UX?
• What's a component?
• What's state?
• What are design tokens?
• What's the difference between frontend and backend?
• When do you need a database?
• What's mobile-first design?

If you can't answer these clearly, re-read those sections. Seriously. The vocabulary is your foundation.

If you completed this checkpoint, you're ready for Part 3.

If you didn't, I'm not mad. Just disappointed. (Joke lang. Do it at your own pace. Pero talaga, the system only works if you do the work.)

In Part 3, we're diving into the tools and the actual build process. Cursor modes, Claude Code, Kimi K2.5, Codex. When to use each one. How to iterate. How to debug. How to ship.

This is where theory becomes practice. Where documentation becomes working code. Where you finally see why all this setup was worth it.

But only if you did Parts 1 and 2 properly.

See you in Part 3.

— G

P.S. If you're actually following along and building something real, send me a screenshot of your FRONTEND_GUIDELINES.md. I'm genuinely curious what you're building. And if you found a typo or something didn't make sense, tell me. I'm writing this on a laggy laptop between 3PM and 5PM, so errors happen. Pasensya na.