Building the frontend the way it works now

01The job changed. The understanding didn’t.

Let me be straight with you about something colleges have not caught up with. Professional developers no longer type most of their code. Tools like Claude Code — an AI that runs in your terminal, reads your whole project, writes and edits files, and runs commands — do the typing. The developer’s job moved one seat up: decide what to build, direct the AI, and review everything it produces.

Here is the trap, and I want you to hear it early: if you skip understanding and just accept whatever the AI writes, you become exactly the person from Chapter 1 again — someone who has code but no picture, and who goes blank in interviews. The AI multiplies what you understand. It cannot replace it, because the reviewer is you. Everything in this chapter assumes you read Chapter 1.

02What frontend work is actually made of

Before the tools, know the material. Every frontend, in every framework, is the same seven jobs:

• Screens (pages) — what the user sees at each URL — /login, /dashboard, /profile.
• Components — reusable lego pieces — a button, a card, a navbar — built once, used everywhere.
• State — what the screen currently remembers — the cart items, whether the menu is open, what you typed.
• Styling — colours, sizes, spacing — the design made real.
• Routing — which URL shows which screen, and moving between them without reloading.
• Talking to APIs — sending requests to the backend and painting the responses — the loop from Chapter 1.
• The unhappy paths — loading spinners, error messages, empty screens — the part beginners skip and professionals are judged on.

Every frontend interview question is one of these seven in disguise. Keep the list; we will touch all of them.

03Choosing a language is the secondary decision

Students agonise over “React or Angular or Vue?” as if it decides their life. It does not. Underneath every framework sits the same ground floor — HTML, CSS, JavaScript — and every framework is just an organised way of writing them. The seven jobs above stay the same; only the spelling changes.

For this journey we will use React with Next.js and TypeScript, for two honest reasons: it is what companies in India hire for most, and TypeScript’s type checking catches the AI’s mistakes automatically — which matters more than ever when an AI writes the code. But understand this clearly: the process you learn in this chapter works with any stack. The process is the skill. The framework is a detail.

04Setting up Claude Code

Claude Code is a terminal program. You install it once, open it inside a project folder, and talk to it in plain language. It reads your files, proposes changes, shows you exactly what it wants to edit, and waits for your approval.

npm install -g @anthropic-ai/claude-code

cd my-first-frontend     # go into your project folder
claude                   # start it — first run asks you to log in

Three things to learn on day one. First, /init — run it in any existing project and Claude writes its first CLAUDE.md (next section) by studying your code. Second, plan mode — before big tasks, ask Claude to plan first and show you the plan before touching files; you approve the plan, then it builds. Third, /clear — wipes the conversation so a new task starts fresh. There is also a VS Code extension if you prefer clicking to typing; same brain, different window.

05CLAUDE.md — your project’s memory

Here is the single most important habit of AI-era development. Claude starts every session knowing nothing about your project except what it can read. CLAUDE.md is a plain text file at the root of your project that Claude reads automatically, every single session. It is where you write down what a new teammate would need to know — because that is exactly what Claude is: a very fast teammate with no memory of yesterday.

# CLAUDE.md

College notice-board app. Next.js 14 + TypeScript + Tailwind.
Frontend only for now — data comes from mock files in src/lib/data.

## Commands
- npm run dev     -> start on localhost:3000
- npm run build   -> production build (run before every commit)
- npm run lint    -> must pass, no warnings

## Structure
- src/app/        -> one folder per screen (route)
- src/components/ -> shared pieces; one component per file
- src/lib/        -> helpers, mock data, types
- docs/           -> specs live here; READ the relevant doc before building

## Rules
- TypeScript strict. Never use "any".
- Small components: if a file passes ~150 lines, split it.
- Every screen needs loading, error, and empty states.
- Do not add libraries without asking me first.

Notice what it contains: commands, structure, and rules — short, factual, no essays. And one discipline that separates juniors from professionals: when you correct Claude twice about the same thing, stop and put that correction into CLAUDE.md. From then on, every future session already knows. That is how the file grows — from real friction, not imagination.

06The documentation process — feed the AI real specs

Amateur AI coding looks like this: type “make me a website”, get something random, complain the AI is dumb. Professional AI coding looks like this: write down what you want first, as files in the project, then point the AI at them. Claude can read every file in your repo — so your documentation is not for humans only anymore. It is the AI’s working instructions.

docs/
  architecture.md    # the boxes-and-arrows drawing from Chapter 1, in words:
                     # what screens exist, what data each needs, what talks to what
  api-contract.md    # every request the backend will answer:
                     # "POST /login takes {email, password}, returns {token}"
  conventions.md     # naming, folder rules, how components are structured
  screens/
    dashboard.md     # one file per screen: what it shows, every state,
                     # what happens on every click

Then your build instruction becomes: “Read docs/screens/dashboard.md and docs/api-contract.md, then build the dashboard screen following conventions.md.” The difference in output quality is not small — it is the whole game. And notice the bonus: you just learned to write specifications, which is precisely what senior engineers and architects do. The AI made the junior skill (typing) cheap and the senior skill (specifying clearly) valuable. This chapter is teaching you the senior skill.

07MCPs — giving Claude hands and eyes

Out of the box, Claude Code can read files, write files, and run commands. MCP (Model Context Protocol) is a standard plug for giving it more abilities. Remember the API-as-menu idea from Chapter 1? MCP is the same idea pointed the other way: a menu of tools the AI is allowed to use.

For frontend work, one MCP matters above all the rest:

Playwright MCP — the eyes. Playwright is a tool that drives a real browser from code. Plugged into Claude, it means the AI can open your page, click your buttons, and take screenshots of what it built. Why does that change everything? Because without it, Claude writes UI code blind — it never sees the result. With it, the loop closes: build → open in browser → look → fix → look again. That is exactly how a human frontend developer works.

# the browser — Claude can now open and SEE your pages
claude mcp add playwright -- npx @playwright/mcp@latest

# settings are saved in .mcp.json — commit it, and every
# teammate (and every future session) gets the same tools

Two more worth knowing, when you need them: a Figma MCP lets Claude read a designer’s Figma file directly, so “build this screen from the design” becomes a real instruction; a GitHub MCP lets it work with issues and pull requests. Start with Playwright only — tools you are not using just eat the AI’s attention.

08Folder structure — organised for humans, optimised for AI

Here is a truth that surprises people: a repo organised for AI is just a well-organised repo. The AI raises the reward for discipline and the punishment for mess. When every file is small and has one job, Claude finds the right place instantly and edits precisely. When everything lives in one 2000-line file, the AI gets as confused as a human — and breaks unrelated things.

my-first-frontend/
  CLAUDE.md               # the project's memory  (section 05)
  .mcp.json               # the AI's tools        (section 07)
  docs/                   # the specs             (section 06)
    architecture.md
    api-contract.md
    conventions.md
    screens/
  src/
    app/                  # SCREENS — one folder per route
      page.tsx            #   home
      login/page.tsx      #   /login
      dashboard/page.tsx  #   /dashboard
    components/
      ui/                 # shared lego: Button.tsx, Card.tsx, Input.tsx
      notices/            # feature pieces: NoticeList.tsx, NoticeCard.tsx
    lib/
      api.ts              # ALL backend calls live here — one door out
      types.ts            # shared TypeScript types
      data.ts             # mock data until the backend exists
  public/                 # images, icons, fonts
  package.json

The rules that make this work, in plain words:

• One obvious home for everything. A new API call goes in lib/api.ts. A shared button goes in components/ui. Nobody — human or AI — should ever wonder where something belongs.
• Small files, one job each. Claude edits by file. Small files mean precise edits and readable diffs you can actually review.
• Group by feature, not by type. Everything about notices sits together in components/notices — so “change the notice card” touches one folder, not five.
• One door to the backend. All requests go through lib/api.ts. When the API changes, one file changes — and Claude always knows where the network lives.
• Types + lint as the safety net. TypeScript and the linter catch the AI's mistakes mechanically, before your eyes have to.

09The loop — how a feature actually gets built

Now put it all together. This is the architecture of the development system itself — you, the AI, its tools, and your repo — and the loop you will run many times a day:

1. 1Specify. Write (or update) the screen's doc in docs/. Plain words: what it shows, every state, every click.
2. 2Plan. Ask Claude to read the docs and propose a plan — which files it will create and why. Read the plan. Fix the plan, not the code — it is ten times cheaper.
3. 3Build. Approve. Claude writes the files, runs lint and the build, fixes its own errors.
4. 4Verify. Claude opens the page with Playwright, screenshots it, and compares against the spec. You look too — your eyes are the final gate.
5. 5Review & commit. Read the diff — every line. Ask about anything you don't understand (it will explain patiently, forever). Then commit with git: the diary entry from Chapter 1.
6. 6Clear. /clear, next task. Small tasks, fresh context, better results.

One session with this loop and you will feel it: the bottleneck is no longer typing speed. It is how clearly you can say what you want, and how sharply you can judge what came back. Those two skills are the career.

10Context hygiene — the AI’s working memory

One limitation to respect from day one. Claude’s working memory for a session — called the context window — is large but finite, and everything competes for it: your files, the conversation, its own thinking. When it fills up, quality quietly drops; the AI starts forgetting decisions from twenty messages ago.

The fix is habits, not heroics. Keep tasks small — “build the login screen”, not “build the whole app”. Run /clear between tasks so each one starts fresh — CLAUDE.md and your docs survive, which is exactly why they live in files and not in the chat. And point Claude at the two or three relevant files instead of saying “look at everything”. Files are the project’s permanent memory; the chat is disposable. Act accordingly.

11What you must still learn by hand

I will not lie to you the way the internet does. There is a failure mode called building on vibes — accepting AI output you cannot read. It works for a demo and collapses the day something breaks and the AI’s fix also breaks. Then you are helpless in front of your own project — and an interviewer can smell it in two questions.

So three non-negotiables. Read every diff — if a line confuses you, ask Claude to explain it; being tutored by the same tool that wrote the code is the most underrated feature it has. Learn to read HTML, CSS and JavaScript even though you rarely write them from scratch — a reviewer must read the language fluently. And learn the browser’s DevTools — right-click, Inspect — because that is where the frontend tells you the truth about what it is actually doing.

12Do this today

Reading builds nothing. Today: install Claude Code, make an empty folder, and write two files yourself by hand — a CLAUDE.md copied from section 05 and edited to your project, and docs/screens/notice-board.md describing a college notice board: a list of notices, a search box, a “new notice” form, plus loading, error, and empty states. Then tell Claude: “Read the docs and build it.” Watch the loop happen. Read every file it creates. Ask it to explain the two you understand least.

When you can walk a friend through that folder — why every file exists and what each one does — you have done something most final-year students in this country have not: shipped a real frontend the way the industry actually ships them. The deeper version of this workflow — where it scales to full products — is written up in One Architect + Claude + MCP = A Full Engineering Squad. Next chapter, we cross to the other side of the wire and build the backend the same way.