SESSION 05 / 06
“Just figure it out”
does not work
Vocabulary · CLI · A 30-second assignment
Jee Jun Young
Business major → Journalism · Overseas sales → Software development
iOS · Android · Frontend About 5½ years (sixth year)
Developed iOS/macOS apps for an enterprise collaboration tool
Since 2026 Solo web and server development and commercialization through vibe coding
TODAY · 5 PARTS
Today — where we start and finish
The PART number stays on the left so you know where you are.
PART 1 — Review of session 4
You tried F12, right?
That is principle #8.
pk_* · anon) versus secret (sk-* · service_role) — if stolen, is it your bill or your database?Today, one step further: precision in language.
The order-sheet analogy from session 2 — RECALL
“Just figure it out” gets you slapdash work.
🎨 A design analogy — the same problem · Asking for “modern yet traditional, futuristic 23rd century” → does not produce what the client wanted.
To write a detailed order, you need words.
Those words are technical vocabulary.
CASE
The same project, different results
HttpOnly cookie sessions,
RLS separation by user,
server-side password hashing.
Prevent duplicate clicks with a full-screen loading layer,
and Material Design animation.”
The difference: B knew the words.
Claude writes the code.
YOU ALREADY KNOW THESE
Terms we have encountered in the last four sessions
+ New vocabulary today (session 5) — previewed on slide 40 of session 4
Clean architectureMVVMFSDDesign patterns“Oh, that existed?” · “I cannot remember the word.”
“Is there something else I should ask?”
— The fact that you are thinking about this means
you are ahead of someone who has not started.
You do not have to memorize everything.
But you need to recognize that a term exists.
You need the word to ask AI, “What is that?”
Not knowing does not stop you from starting.
If you do not know, ask. But you need to know what to ask.
WHY · CONTEXT ROT
Why design patterns, architecture, and technical terms
directly affect cost
Your bedroom is littered with snack bags, a computer, a gas stove, eggshells, and instant rice.
A cleaner walks in and quotes — hundreds of thousands of won? A million? They might just walk out.
A tidy room used only for sleep and rest, on the other hand: two hours, done, cheap.
That cleaner is AI.
The quote is the tokens you pay for.
The messier the room, the more AI costs you.
If it is extremely messy, it runs off mid-job or takes a four-hour break. It has lost its mind.
The research term is Context Rot — literally, “decay of context.” The concept from session 3.
AI forgets the middle and gets lost while reading long code or documents (Liu et al., 2023, Lost in the Middle).
That is why design patterns and architecture are not developers showing off,
but central to lower costs and more reliable AI collaboration in vibe coding.
BIG PICTURE
Design patterns and architecture — at a glance
Analogy: recipes in a cookbook.
Use the same pattern for the same problem.
Examples: Singleton · Factory · Observer · Repository · Adapter
Source: GoF (Gang of Four), 23 patterns, 1994
Analogy: city planning (roads, districts, electricity).
Big decisions that are hard to change later.
Examples: MVC · MVVM · Clean · Hexagonal · FSD
Common architectures — one-line analogies
A vending machine. Keep the interface and data separate.
→ Explained on the next slide
Concentric circles like an onion.
Inside: core logic. Outside: supporting parts (DB, screens, APIs).
The inside works without knowing the outside — changing the DB does not change the core.
A café headquarters and its franchises.
Headquarters (domain): menu and manuals only.
Franchises (adapters): customers, ingredients, and payments. Change a franchise and headquarters stays the same.
Two divisions: six vertical layers and stores by domain. Frontend-specific.
→ Explained with a department-store analogy on the next slide
These are all methods tested over decades.
MVC 1979 · Hexagonal and MVVM 2005 · Clean 2012 · FSD from 2018
So they are well represented in AI training data.
Give Claude one term and it understands exactly. That is why we cover vocabulary today.
INSTRUCTOR CASE · GRIMOIRE
The instructor’s own case — Hexagonal + simplified FSD
First: self-assessment, not blind adoption
I first had Claude read all my iOS app code, then asked:
“At this code level, could I maintain a web FSD and hexagonal server setup? Assess it.”
Did I trust Claude’s answer completely? No. I asked other AIs the same question to size it up.
Result ① — Server (grimoire-server)
Adopted hexagonal architecture (Ports & Adapters).
The domain at the center; DB, external APIs, and HTTP routers separated as adapters.
Code structure: domain / application / adapter / infrastructure
Result ② — Web (grimoire-web)
Simplified FSD — not a strict six-layer setup,
just core slices (features/auth · features/payment · features/works) organized by domain.
The message: architecture is not something to memorize.
“Is this suitable for my level?” — Ask AI to assess it.
VOCABULARY VIA ANALOGY
Explain technical terms through everyday analogies
Design patterns, architecture, algorithms — fields full of unfamiliar terms.
Trying to memorize every letter makes it hard.
A tip: the same patterns exist in everyday life. Add one layer of software logic, and you get design patterns, architecture, and algorithms. That mindset reduces resistance.
Demonstration — three data structures in everyday life
A convenience-store drinks shelf.
Staff load new drinks at the back; customers take from the front. First in, first out.
Books stacked on a desk.
Put new books on top; take them from the top. Last in, first out — Ctrl+Z also uses a stack.
School lockers.
Know the student number (key) and go straight to the compartment (value). No need to check each one in order.
When you meet a new term, ask “What is similar in everyday life?”
We will explain MVVM, FSD, Clean, and SOLID through familiar examples: a vending machine, department store, onion, and sushi kitchen.
MVVM
What is MVVM? — A vending machine
Analogy — a vending machine
View = buttons and display (what the user sees)
ViewModel = internal circuitry (handles a button press)
Model = drink inventory and prices
Press a button → the circuitry (VM) dispenses a drink.
The user need not know how.
Why it helps — the View and data are separate.
Change only a button’s appearance (color or layout), and the circuitry (VM) stays.
Change its function (branching or a new action), and the circuitry needs work too.
iOS · Android · Vue · WPF — a widely used pattern.
Source — Microsoft’s John Gossman, 2005.
Between the “screen” and “data” sits circuitry that does the work (ViewModel).
Source: John Gossman, Microsoft, 2005 (introduced for WPF).
FSD · FEATURE-SLICED DESIGN
What is FSD? — Departments in a department store
Analogy — a department store (horizontal: domain departments)
Section 1 cosmetics · Section 2 womenswear · Section 3 menswear · Section 4 food
Separate departments (slices) for each domain.
Put a grocery aisle inside cosmetics? Customers get confused. Sales drop.
FSD likewise separates domains horizontally into departments (slices).
FSD’s six official layers (vertical hierarchy and dependency rules)
Upper layers may use only lower layers (never the reverse). Within each layer are slices (domains), such as `features/auth` and `features/payment`.
I use a simplified version — just a few concepts.
The point is to organize by purpose and set rules.
Without adopting the full six-layer hierarchy → ① organize folders by feature (slice) (`features/auth`, `features/payment` …) ② only upper layers call lower ones (dependency direction) ③ use consistent naming and import rules.
Source: emerged in 2018–2020; official site feature-sliced.design. For frontends (React/Vue).
⚠ A pattern commonly seen in web projects
One file contains button colors / price calculations / server API calls / calls to Claude and GPT
— all in one place.
What happens? The Context Rot and loss of attention discussed earlier.
Like the cleaner who gives up and walks out, Claude gets lost and starts doing pointless things.
CLEAN ARCHITECTURE · UNCLE BOB
What is Clean Architecture? — An onion’s rings
Analogy — an onion
Think of an onion. The core is at the center. The outside is skin.
Inside = domain (what you actually want to build — core business logic)
Outside = DB, screens, external APIs, frameworks (supporting parts and skin)
One rule
The inside works without knowing the outside.
“The domain code does not know whether I use PostgreSQL or MySQL.”
→ Change databases a year later without changing the core code. Move from web to mobile with the same business logic.
Keep the core inside and make the outside replaceable.
Source — Robert C. Martin (Uncle Bob), 2012 blog post → 2017 book Clean Architecture.
DESIGN PATTERNS
Design patterns — worth knowing
The customer asks for “bulgogi pizza”. The shop handles dough and oven temperature. — Encapsulates object creation
Subscribe to a channel and get automatic notifications for new videos. No daily checks. — Pub/sub pattern
Card, bank transfer, Payco, Kakao Pay — the payment interface stays the same. — Swaps algorithms
A Korean appliance in a US socket — a 110V↔220V adapter. — Converts interfaces
⚠️ Singleton — the most misused pattern in human history
Analogy — a president. One per country. Two people declaring “I’m the president” would shake the country.
Misuse — the president makes every decision. Centralizing everything paralyzes the country.
In code: hard to mock, broken dependency injection, multithreaded races. Easy to introduce → very hard to remove later.
Use a singleton only when you truly need one instance (DB connection pool or logger).
Otherwise, do not make it a habit.
SOLID · 5 PRINCIPLES
SOLID’s five principles — everyday analogies
Dividing kitchen work — one person slices fish, another makes noodles, another takes payment.
Ask one person to do all three at once and everything falls apart.
Socket and plug — keep the socket. Plug in the new appliance.
You do not dismantle the socket each time. = Extend existing code without modifying it.
A stand-in worker — when owner Kim takes a holiday, worker Park should do the same job.
“I don’t make kimchi stew” would confuse customers. = A child must be able to replace its parent.
Menus — with a 30-page combined menu, changing one Korean dish means reprinting everything and making every customer read it again. Split it into four categories, and a Korean menu change leaves Western-food customers unaffected.
Customers see only their category. = Clients do not depend on methods they do not use.
ATM — what if it accepts only Shinhan cards? Each new issuer (KB or Woori) means changing the ATM code again. Define a “card interface” once, and new issuers fit it.
The ATM (high level) does not depend directly on issuers (low level); both depend on the card interface (abstraction). Dependency is inverted. = Depend on abstractions, not concrete implementations.
Source: developed by Robert C. Martin (Uncle Bob) in the early 2000s.
L was introduced by Barbara Liskov in 1987 (back to Dijkstra and Liskov from Session 3).
SOLID × CLAUDE
Why Claude, too, likes SOLID code
Five principles mapped to preventing Context Rot
↪ Fish restaurant kitchen — fish, noodles and payment kept separate
One file, one responsibility → Claude tracks one responsibility. Mix jobs and guesswork grows → Context Rot accelerates.
↪ Socket and plug — keep the socket, change the plug
Add features without touching existing code → directly prevents Claude’s “break it while editing” pattern.
↪ Stand-in worker — Park does the same job while Kim is away
The parent signature predicts child behavior → Claude can safely assume how a function behaves.
↪ Menus — four categories instead of one 30-page menu
Small interfaces → Claude needs only what the class uses in context. Avoids a large dump.
↪ ATM — any issuer’s card works (it sees only the “card interface”)
The domain depends on abstractions → DB and API changes leave domain code untouched → a direct link to hexagonal architecture.
In one line: SOLID = preventing Context Rot + safer code changes by Claude.
Session 3’s Separation of Concerns (SoC) is in fact SOLID’s S.
PART 2
The depth of the CLI
CLI · COMMAND LINE INTERFACE
CLI = a screen for text commands
Why developers use CLIs — faster than GUIs.
The real reason — ideal for giving work to Claude.
Browser GUI operation is inefficient: viewing screens uses many tokens, and unfamiliar pages can make click targets hard to find. Text-based CLIs avoid that ambiguity.
CLI · how a command travels
Person → Claude → CLI → external service — six steps
→ The CLI acts as Claude’s hands and feet. GUI operations are hard; command lines can be entered directly.
GitHub repo”
CLI command
gh repo
create ...gh · HTTPSOAuth Token
api.
github.com→ Claude → person
Same pattern, different CLIs
gh (GitHub) · wrangler (Cloudflare) · supabase (Supabase) · gcloud (GCP) · az (Azure) · vercel (Vercel) — the same six-step structure. Only the service changes.
The person states the intent. Claude converts it into a command, runs it and interprets the result.
Full delegation — in Claude Code, Claude operates the terminal directly.
You do not need to type the commands.
10-minute break
Coming up — “How to keep going when a word is unfamiliar.”
PART 3
How to keep going
when a word is unfamiliar
What to do
when Claude throws four new terms at you.
The time when you need books will come. But waiting instead of acting misses the moment.
One page of a book = 3 minutes. One Claude prompt = 30 seconds.
Six times faster.
Today’s terms are those very tools.
Those who never ask never find out.
5 SESSIONS — CUMULATIVE
What you have built over five sessions
You are already ahead of anyone who has not even started
vibe coding.
BONUS · new criteria for choosing technology
We covered design patterns and SOLID. So which technology do you choose?
Before (through 2024)
Developers chose technology by digging through documentation and researching the industry.
Now (from 2026) — two new criteria for vibe coders
① Has AI trained extensively on it? Are references easy to find?
② Is the service easy for AI to access and operate? How usable are its CLI and API?
Alongside your own effort to build a service, you now need to ask:
“Does this system make it easy for AI to work automatically?”
Criterion ① · AI training coverage
Technology well represented in AI training = a safe choice
Example 1 — frontend: React vs Vue
React: about 100 million weekly npm downloads
Vue: about 10 million
→ Roughly a tenfold difference (May 2026, npm trends). AI training material (GitHub and Stack Overflow answers) differs along similar lines.
React dominates on training coverage. For vibe coding, React is safer.
Example 2 — mobile: Flutter
Flutter’s strength — one codebase builds for iOS, Android, Web and Desktop.
For AI, that means reading one codebase, without separate iOS and Android code.
→ A structure that is easy for AI to handle.
Criterion ① — “Has AI trained enough on this technology?”
New technology with little training coverage may look attractive, but is risky for vibe coding.
Criterion ② · AI access
Does the service make it easy for AI to work automatically?
Hosting — Cloudflare vs others
Cloudflare (Wrangler CLI) and Vercel (specialized for Next.js) are easiest for Claude to handle.
Simple CLIs, RESTful APIs and plentiful documentation.
A CLI can make or break Claude automation
Has a CLI → Claude automates it with one command.
No CLI / GUI only → inefficient for Claude to operate directly. Clicking and tracing through Chrome MCP is possible, but costs many tokens and may fail on unfamiliar pages.
→ GCP (gcloud) ≈ Azure (az): both have CLIs. GCP is slightly simpler.
A vibe coder’s decision — “Does this system make it easy for AI to work automatically?”
TODAY'S KEY TAKEAWAY
PART 5
Today’s
homework
A 30-second assignment at home.
Do not trust one model 100%. Ask another AI the same question for a second assessment.
▸ Small project (personal use or MVP) → “Can Vercel and Supabase do this? Do they have CLIs, and how do I configure them?” Or: “Would Firebase be better? Does it have a CLI?”
▸ Hosting or a production server → “Would Cloudflare or a Korean service such as Toast or NCP be better? Explain why and assess CLI support.”
▸ Production server setup → “Which fits my constraints: Azure, GCP or AWS?”
▸ Ultimately → “Which provider and solution are easiest for Claude to operate and configure?”
BEFORE WE CLOSE — META
Why we covered these terms
MVVM, FSD, Clean, SOLID, Context Rot — at first they sound dull and pointless.
The reason lies in human cognition. We need words to define phenomena. LLMs are crude copies of that cognitive system. Unless you name the terms explicitly, Claude’s scope does not expand either.
— Wittgenstein · Tractatus Logico-Philosophicus (1922), proposition 5.6
“The limits of my language
mean the limits of my world.”
Without a word, you cannot define the phenomenon.
“Why does Claude keep breaking things it wasn’t asked to touch?” You may experience it daily, but without a term for it, all you can do is complain that “AI is stupid.”
People who have the words
can direct AI.
SESSION 05 / 06
Thank you
for today.
Next time — the sixth and final session.
“Now you can do it on your own” · remote setup and where to go next.
OPEN CHAT
Questions?
Use the KakaoTalk open chat.