Forem: Anirban Majumdar

`@playwright/cli` Is Not `npx playwright test` — And That Difference Is Costing Your AI Agent Thousands of Tokens

Anirban Majumdar — Tue, 05 May 2026 07:26:40 +0000

As an SDET or Automation Engineer, failing tests are part of the daily grind. With the rise of Agentic AI, fixing scripts is easier than ever—but there’s a catch that tutorials rarely mention: Scale.

In a real-world enterprise suite, you aren’t dealing with 10 tests; you’re dealing with 500. When 200 of them fail right before a major release—often due to a single upstream change by another team—feeding all that data into an AI Agent is a "token bonfire." It’s expensive, slow, and often unnecessary.

So, what’s the move? Do you use a Playwright MCP, a standalone LLM, or the Playwright CLI?

The answer is: It depends on the scope of the fix.

In this post, we’ll explore how to leverage the Playwright CLI to analyze and resolve mass failures efficiently, keeping your token costs low and your velocity high.

What exactly is Playwright and where do you use it

Before we talk about tokens, let's clear up the confusion that tripped me up for weeks.

There are three different Playwright tools that all sound similar:

npx playwright test        →  the test runner you already know
                              runs your spec files, reports pass/fail

@playwright/cli            →  a NEW, separate package
(playwright-cli)              built specifically for coding agents
                              controls a live browser one command at a time

Playwright MCP Server      →  for persistent agent browser sessions
                              keeps browser alive across a long investigation

Most QA engineers know the first one. Almost nobody has heard of the second. And the confusion is understandable — they're both "Playwright", they both involve browsers. But they're built for completely different consumers.

npx playwright test is built for humans and CI pipelines. It runs your spec files, prints results to a terminal, exits with a code. A human reads the output. A pipeline checks the exit code. Done.

playwright-cli is built for coding agents. It was created specifically because tools like Claude Code and GitHub Copilot need to interact with a live browser — not run pre-written scripts, but actually observe a page, click things, see what changed, and loop. Every command returns a compact, structured snapshot of the current page state that a machine can read and reason about efficiently.

Installing It

# It's a separate package from @playwright/test
npm install -g @playwright/cli@latest

# This is important — installs structured command docs locally
# so Claude Code knows all available commands without running --help
playwright-cli install --skills

That --skills flag is a small thing that saves tokens on every single agent session. Instead of the agent running playwright-cli --help to discover commands (costing ~300 tokens), it reads the locally installed docs once at session start.

What It Looks Like In Use

# Open the live app in a browser
playwright-cli open https://habit-tracker-one-dun-53.vercel.app/

# Get the current page state — returns all interactive elements
playwright-cli snapshot

# Interact using element refs from the snapshot
playwright-cli click e45
playwright-cli fill e12 "Morning Run"
playwright-cli press Enter

# Capture state visually
playwright-cli screenshot

# Check what network calls are happening
playwright-cli network

The snapshot command is the key one. Here's what it actually returns:

Page: Habit Tracker
URL: https://habit-tracker-one-dun-53.vercel.app/

Interactive elements:
  e12  input[placeholder="Enter habit name..."]   textbox
  e13  input[type="date"]                         date picker
  e14  select.status-selector                     combobox
  e45  button.submit-habit-form                   button "Add Habit"
  e67  a[href="/trends"]                          link "Trends"
  e68  a[href="/about"]                           link "About"

That's it. ~150 tokens. Every interactive element on the page, with a ref ID the agent can use to interact. No noise, no full HTML, no CSS, no scripts — just what an agent needs to act.

This is the foundation of why playwright-cli is so much more token-efficient than alternatives. But let's make that concrete.

The App I'm Testing

Throughout this post I'll use a real example: a React Habit Tracker app I built and deployed on Vercel.

Live app: https://habit-tracker-one-dun-53.vercel.app/

One spec file, two test categories:

@smoke — happy path: add habit, mark complete, delete
@regression — edge cases, validation, error states

Nothing exotic. Simple enough to follow along, realistic enough to make the problem interesting.

The Token Problem With `npx playwright test` Alone

Here's what happens when a naive agent uses only npx playwright test to investigate a failure:

You: "Why is the add-habit smoke test failing?"

Agent (without playwright-cli):
  Step 1: Read entire spec file to understand the test    ~3,200 tokens
  Step 2: Read playwright.config.js for context             ~180 tokens
  Step 3: Run npx playwright test --reporter=list           ~800 tokens
  Step 4: Parse terminal output, identify failure           ~600 tokens
  Step 5: Read source components to find selector          ~2,800 tokens
  Step 6: Guess what the DOM looks like now                ~1,400 tokens
  Step 7: Propose a fix (might be wrong)                   ~700 tokens
  ──────────────────────────────────────────────────────
  Total:                                                  ~9,680 tokens
  Certainty of diagnosis:                                       ~60%

The agent is reading source files and guessing what the live DOM looks like. It never actually looks at the app. Its fix might be wrong and cost you another loop.

Here's the same task with playwright-cli:

You: "Why is the add-habit smoke test failing?"

Agent (with playwright-cli):
  Step 1: npx playwright test --grep "@smoke" --reporter=json  ~420 tokens
  Step 2: playwright-cli open + snapshot on failure            ~190 tokens
  Step 3: Read ONLY the failing test block                     ~280 tokens
  Step 4: Compare snapshot to test, diagnose                   ~480 tokens
  Step 5: Propose exact fix from what it actually saw          ~150 tokens
  ──────────────────────────────────────────────────────
  Total:                                                     ~1,520 tokens
  Certainty of diagnosis:                                        ~95%

84% fewer tokens. Higher confidence. No guessing.

The agent saw the actual live DOM. It didn't read five files hoping to reconstruct what the UI looks like — it just looked.

Why playwright-cli Is So Token-Efficient

1. Snapshot output is compact by design

The playwright-cli snapshot command returns a structured, minimal representation of the current page — only interactive elements, only what an agent needs to act:

playwright-cli open https://habit-tracker-one-dun-53.vercel.app/
playwright-cli snapshot

Output:

Page: Habit Tracker
URL: https://habit-tracker-one-dun-53.vercel.app/

Interactive elements:
  e12  input[placeholder="Enter habit name..."]   textbox
  e13  input[type="date"]                         date picker
  e14  select.status-selector                     combobox
  e45  button.submit-habit-form                   button "Add Habit"
  e67  a[href="/trends"]                          link "Trends"
  e68  a[href="/about"]                           link "About"

That's ~150 tokens. It tells the agent everything it needs: what elements exist, what their refs are, what their current classes and labels are.

Compare that to fetching the full page HTML — which would be 2,000–8,000 tokens of noise the agent has to parse to extract the same 6 elements.

2. Ref-based interaction means no selector archaeology

Once the agent has a snapshot, it uses refs — not selectors it has to guess:

playwright-cli click e45          # click "Add Habit" button
playwright-cli fill e12 "Morning Run"
playwright-cli press Enter
playwright-cli snapshot           # see what changed

No reading source code to figure out what class name the button has. No risk of using a stale selector from a file that hasn't been updated since last deploy. The snapshot tells you the current truth.

This is the core insight: playwright-cli trades file reading for direct observation. File reading costs hundreds to thousands of tokens per file. Observation costs ~150 tokens for the entire page state.

3. The `--skills` flag prevents repeated `--help` calls

playwright-cli install --skills

This installs structured command documentation locally. Claude Code reads it once at the start of a session — it never needs to run playwright-cli --help to discover available commands. That's another ~300 tokens saved per session, and it means the agent's responses about playwright-cli are accurate and consistent.

4. Scoped execution with `--grep` on the test runner side

The other half of token efficiency is on the npx playwright test side. Never let an agent run your full suite when it only needs a subset:

# Full suite — 200 tests, large JSON output, expensive to parse
npx playwright test --reporter=json

# Scoped to smoke — 6 tests, tiny JSON output, cheap to parse
npx playwright test --grep "@smoke" --reporter=json

# Single failing test — 1 result, minimal output
npx playwright test --grep "should add a new habit" --reporter=json

The JSON output for 1 test is ~80 tokens. For 200 tests it's ~3,000 tokens. The agent gets the same actionable information either way. Always scope.

The Complete Token Breakdown Across a Real QA Cycle

Here's a full pre-merge QA run on my habit tracker, with actual token estimates at each step:

Task: "Is the habit tracker ready to merge?"

─── Phase 1: Discovery ──────────────────────────────────────────
npx playwright test --list --grep "@smoke"
  → Returns 6 test names
  → Cost: ~80 tokens

─── Phase 2: Smoke Run ──────────────────────────────────────────
npx playwright test --grep "@smoke" --reporter=json
  → 5 passed, 1 failed
  → JSON output parsed by agent
  → Cost: ~420 tokens

─── Phase 3: Triage (playwright-cli) ───────────────────────────
playwright-cli open https://habit-tracker-one-dun-53.vercel.app/
  → Cost: ~30 tokens

playwright-cli snapshot
  → Returns current DOM state
  → Cost: ~150 tokens
  → Agent sees: button class is "submit-habit-form" not "habit-submit-btn"
  → Diagnosis: selector-broken. Immediate. No guessing.

playwright-cli screenshot
  → Visual confirmation
  → Cost: ~40 tokens

─── Phase 4: Read only the failing test block ───────────────────
  → ~280 tokens (one test block, not the whole file)

─── Phase 5: Fix proposal ───────────────────────────────────────
  → Agent writes the corrected selector
  → Cost: ~150 tokens

─── Phase 6: Verify fix ────────────────────────────────────────
npx playwright test --grep "should add a new habit" --reporter=json
  → 1 passed ✅
  → Cost: ~80 tokens

─── Phase 7: Regression (smoke now clean) ──────────────────────
npx playwright test --grep "@regression" --reporter=json
  → 14 passed ✅
  → Cost: ~900 tokens

─────────────────────────────────────────────────────────────────
TOTAL: ~2,130 tokens
Full investigation. Real diagnosis. Verified fix. Regression confirmed.

Naive approach (same outcome, no playwright-cli):  ~18,000–22,000 tokens

The Debugging Difference

Most Playwright engineers know --debug mode. Here's why it doesn't work for agents and why playwright-cli exists:

npx playwright test --debug
  → Interactive REPL
  → Pauses at each step, waits for human input
  → Requires a human sitting at the keyboard
  → Useless in CI, useless for autonomous agents

playwright-cli
  → Atomic commands, each returns structured output
  → No human needed between steps
  → Agent calls command → reads output → decides next command → loops
  → Works headlessly in CI, works autonomously in Claude Code

The mental model shift:

Human debugging:
  open browser → look → click → look → understand

Agent with playwright-cli:
  snapshot → reason → click → snapshot → reason → fix

Agent without playwright-cli:
  read file → read file → read file → guess → run test → read output → guess again

The agent without playwright-cli is flying blind. It's doing archaeology — piecing together what the live UI looks like from source files that may be outdated. playwright-cli gives the agent real-time ground truth.

What playwright-cli Commands Actually Look Like In Practice

Here's a real triage session my agent ran on a broken selector:

# Test failure: "locator('.habit-submit-btn') timed out"

playwright-cli open https://habit-tracker-one-dun-53.vercel.app/
# Agent: app loaded, ready to investigate

playwright-cli snapshot
# Agent reads:
#   e45  button.submit-habit-form  (button, "Add Habit")
# Agent: class is "submit-habit-form" not "habit-submit-btn"
# Diagnosis: selector-broken, CSS class renamed in a recent deploy

playwright-cli fill e12 "Morning Run"
playwright-cli snapshot
# Agent: input filled correctly, no issues with the input selector

playwright-cli click e45
playwright-cli snapshot
# Agent: habit appeared in the list, the button works
# Confirmation: it's purely a selector name issue, app logic is fine

playwright-cli screenshot
# Agent: captured visual proof of the working flow with correct selector

Total playwright-cli token cost for this investigation: ~420 tokens.
Time: under 10 seconds.
Outcome: exact diagnosis, zero guessing, confirmed fix path.

The Agent Files That Use playwright-cli

I run all of this through Claude Code sub-agents defined in .claude/agents/. Here are the two most important ones for the playwright-cli story.

`.claude/agents/qa-smoke-runner.md`

---
name: qa-smoke-runner
description: Runs @smoke Playwright tests against the Habit Tracker and
  triages failures using playwright-cli. Use proactively when code changes
  are made or when asked to verify the app works.
model: claude-sonnet-4-5
tools: Bash, Read, Glob
---

You are a QA smoke testing agent. Follow these steps exactly.

## Step 1 — Run smoke tests (scoped, JSON reporter only)
npx playwright test --grep "@smoke" --reporter=json 2>/dev/null

Parse the JSON. Extract: passed/failed counts, error messages per failure.

## Step 2 — If all pass
Output summary and stop. Never run regression from this agent.

## Step 3 — For each failure, triage with playwright-cli

DO NOT read source files first. Look at the live app first.

1. playwright-cli open https://habit-tracker-one-dun-53.vercel.app/
2. playwright-cli snapshot
   → Read the element refs. Compare against the error message.
   → Can you already see the problem? (renamed class, missing element?)

3. Reproduce the failing steps:
   playwright-cli fill <ref> "test value"
   playwright-cli click <ref>
   playwright-cli snapshot    ← after every interaction
   playwright-cli screenshot  ← at the failure point

4. Only THEN read the failing test block if needed for assertion details.
   Read ONLY that test block. Not the whole file.

5. Categorise:
   - selector-broken  → element exists, selector is wrong
   - timing           → element not ready when test interacts
   - real-bug         → app behaviour is actually wrong
   - env-issue        → Vercel/network problem
   - test-data        → hardcoded data assumption wrong

## Token rules
- --reporter=json always. Never --reporter=html.
- playwright-cli snapshot before reading any source file.
- --grep "@smoke" always. Never run full suite.
- Read only failing test block, not full spec.

## Output
Result: X passed / Y failed
[Per failure: category, root cause, playwright-cli commands used, fix]

`.claude/agents/qa-failure-triager.md`

---
name: qa-failure-triager
description: Deep-dives into a specific Playwright test failure using
  playwright-cli to reproduce and diagnose the exact root cause. Use
  when you need more than a summary — you need the exact fix.
model: claude-sonnet-4-5
tools: Bash, Read, Glob
---

You are a QA triage specialist. Your primary tool is playwright-cli.
Read source files only as a last resort.

## Investigation order (follow exactly)

### 1. Look at the live app first
playwright-cli open https://habit-tracker-one-dun-53.vercel.app/
playwright-cli snapshot

Before reading any code, answer from the snapshot:
- Does the element the test expects actually exist?
- Is its selector/class what the test expects?
- Is the page in the right state?

### 2. Reproduce the failure step by step
For each action in the failing test, execute it with playwright-cli:

playwright-cli snapshot                    # document initial state
playwright-cli fill <ref> "test value"     # replicate test actions
playwright-cli snapshot                    # observe state change
playwright-cli click <ref>
playwright-cli snapshot                    # observe result
playwright-cli screenshot                  # capture at failure point

### 3. Check deeper only if needed
playwright-cli network   # if failure could be API/data related
playwright-cli console   # if failure could be a JS runtime error

### 4. Read failing test code last
Only after playwright-cli investigation. Read only the failing test
block — find it by line number from the JSON reporter output.

### 5. Write the exact fix
// Before (broken)
await page.locator('.old-class').click()

// After (fixed — prefer role-based selectors)
await page.getByRole('button', { name: 'Add Habit' }).click()

### 6. Verify
npx playwright test --grep "[exact test name]" --reporter=json

## Output
Category: [category]
Divergence point: [step where expectation broke]
playwright-cli commands used: [list]
Root cause: [2-3 sentences]
Fix: [exact before/after code]
Verified: ✅ / ❌

The `--reporter=json` Detail Nobody Talks About

One more token efficiency lever that pairs with playwright-cli: always use --reporter=json when running tests for an agent to consume.

Here's the difference in what an agent has to process:

List reporter (default):

Running 6 tests using 1 worker

  ✓  1 [chromium] › add-habit-form.spec.js:12:5 › @smoke should add a new habit (1.2s)
  ✓  2 [chromium] › add-habit-form.spec.js:28:5 › @smoke should mark habit complete (0.8s)
  ✗  3 [chromium] › add-habit-form.spec.js:45:5 › @smoke should delete a habit (5.0s)

  Error: locator('.delete-habit-btn') - waiting for locator
    at add-habit-form.spec.js:52

Looks clean to a human. For an agent, it's unstructured text it has to parse with pattern matching — brittle and expensive.

JSON reporter:

{
  "stats": { "expected": 5, "unexpected": 1, "duration": 7243 },
  "suites": [{
    "title": "add-habit-form.spec.js",
    "specs": [{
      "title": "@smoke should delete a habit",
      "ok": false,
      "tests": [{
        "status": "failed",
        "results": [{
          "error": {
            "message": "locator('.delete-habit-btn') exceeded timeout",
            "location": { "file": "add-habit-form.spec.js", "line": 52 }
          }
        }]
      }]
    }]
  }]
}

Structured. Parseable. The agent extracts exactly what it needs in one pass: which test, what error, which file, which line. No pattern matching, no ambiguity, fewer tokens wasted on parsing overhead.

Combined with --grep to scope the run, you get the smallest possible output surface for an agent to work with.

When playwright-cli Isn't Enough: The MCP Server

playwright-cli is stateless — each command opens the browser, acts, closes. For most triage tasks that's fine. But some investigations need state across multiple steps:

Verify a habit persists after page refresh
Check that streak counts update correctly after adding habits on consecutive days
Explore an entire multi-page flow without re-navigating from scratch

For those cases, the Playwright MCP server keeps a browser alive across the entire agent session. Think of it as a playwright-cli session that doesn't close between commands.

For my habit tracker I use it in the qa-test-generator agent — the one that explores the live app and generates new test coverage. It needs to navigate multiple routes, build up app state, and compare across page transitions. playwright-cli per-command statelessness would make that awkward. The MCP server handles it naturally.

But — and this is important — don't reach for the MCP server by default. playwright-cli covers 90% of QA agent use cases with lower overhead. Use the MCP server specifically when your investigation needs persistent browser state.

The Mental Model, Simplified

npx playwright test    =  your test runner
                          answers: WHAT broke?
                          cost: low (with --grep + --reporter=json)

playwright-cli         =  your agent's eyes on the live app  
                          answers: WHY did it break?
                          cost: very low (snapshot is ~150 tokens)

playwright MCP server  =  your agent's stateful browser session
                          answers: WHAT ELSE might be broken?
                          cost: low, but only use when you need state

The shift is this: you stop reading files to reconstruct what the UI looks like. You just look at it. That's what playwright-cli makes possible for agents — and it's why the token difference is so dramatic.

Quick Reference: Token Cost By Command

npx playwright test --list                          ~80 tokens
npx playwright test --grep "@smoke" --reporter=json ~400 tokens
npx playwright test --reporter=json (full suite)    ~3,000 tokens

playwright-cli open <url>                           ~30 tokens
playwright-cli snapshot                             ~150 tokens
playwright-cli click <ref>                          ~20 tokens
playwright-cli screenshot                           ~40 tokens
playwright-cli network                              ~200 tokens

Reading entire spec file                            ~3,200 tokens
Reading one test block                              ~280 tokens
Reading playwright.config.js                        ~180 tokens

The pattern is clear. Every playwright-cli command costs less than reading a single source file. And it gives you ground truth about the live app rather than a static snapshot of code that may not reflect the current deployed state.

What I'd Do Differently

Use --grep from day one. My agents initially ran the full suite every time. Scoping to @smoke for quick checks cut token usage by 6x immediately.

playwright-cli snapshot before any file read. The answer is usually in the snapshot. Only go to source files when you need to understand assertion logic, not when you need to understand the DOM.

Role-based selectors over CSS classes. CSS class names change with deploys — getByRole('button', { name: 'Add Habit' }) stays stable. It also makes playwright-cli triage easier because role and name are visible in the snapshot output.

The GitHub Repo

All the agent files, CLAUDE.md, and the full test suite are here:

👉 *https://github.com/anirseven/habit-tracker/tree/main/.claude/agents

If you're building something similar or have questions, drop a comment. Happy to go deeper on any part of this.

Building a Full-Stack Habit Tracker with Claude Code - Part 2: Polish, Testing & Deployment

Anirban Majumdar — Mon, 04 May 2026 06:41:45 +0000

Building a Full-Stack Habit Tracker with Claude Code - Part 2: Polish, Testing & Deployment

Taking the habit tracker from MVP to production-ready with categories, analytics, comprehensive testing, and Vercel deployment

Welcome Back!

In [Part 1], we built a fully functional habit tracker MVP in about 6-8 hours using Claude Code as our AI pair programmer. We had:

✅ Basic CRUD operations for habits
✅ Date-based tracking
✅ Dark/light theme toggle
✅ localStorage persistence
✅ Simple analytics

So continuing my learning journey with Claude as I will be covering below topics and how I used claude to plan and work on them

Improving the Site An 8-category organization system
Improving the Site Real-time summary cards with progress bars
Improving the Site Advanced analytics with streak tracking
Improving the Site Smart category filtering
Testing of the App using Playwright 170+ automated test cases
Deployment of the app Production deployment to Vercel

Let's ship this! 🚢

Phase 9: The Category System (Organization FTW)

After using the app for a few days, I realized tracking "Morning workout" and "Finish quarterly report" in the same list felt... wrong. They're completely different types of habits.

I asked Claude: "Help me add a category system to organize habits better."

Step 1: Define the Categories

Claude suggested creating a constants file:

// src/constants/categories.js
export const CATEGORIES = [
  { id: 'health', name: 'Health & Fitness', emoji: '💪' },
  { id: 'work', name: 'Work & Productivity', emoji: '💼' },
  { id: 'learning', name: 'Learning & Growth', emoji: '📚' },
  { id: 'personal', name: 'Personal Care', emoji: '🧘' },
  { id: 'social', name: 'Social & Family', emoji: '👥' },
  { id: 'finance', name: 'Finance & Money', emoji: '💰' },
  { id: 'hobbies', name: 'Hobbies & Fun', emoji: '🎨' },
  { id: 'other', name: 'Other', emoji: '📌' }
];

Why this approach?

Centralized: One source of truth
Extensible: Easy to add more categories later
Type-safe: Could convert to TypeScript easily
Visual: Emojis make categories instantly recognizable

Step 2: Category Selector Component

// src/components/CategorySelector.js
import { CATEGORIES } from '../constants/categories';

function CategorySelector({ value, onChange }) {
  return (
    <div className="form-group">
      <label htmlFor="category">Category</label>
      <select
        id="category"
        value={value}
        onChange={onChange}
        className="form-select"
      >
        {CATEGORIES.map(cat => (
          <option key={cat.id} value={cat.name}>
            {cat.emoji} {cat.name}
          </option>
        ))}
      </select>
    </div>
  );
}

export default CategorySelector;

Step 3: Update the Data Model

Our habit objects now include category:

{
  id: "1712345678901",
  habit: "Morning workout",
  date: "2026-04-08",
  category: "Health & Fitness",  // NEW!
  status: "Completed"
}

Step 4: Category Filtering on Home Page

Here's where it got fun. I wanted users to filter habits by category:

// src/pages/Home.js
import { CATEGORIES } from '../constants/categories';

function Home({ habits, onAddHabit, onUpdateHabit, onDeleteHabit }) {
  const [selectedCategory, setSelectedCategory] = useState('All');

  // Filter habits based on selected category
  const filteredHabits = selectedCategory === 'All'
    ? habits
    : habits.filter(h => h.category === selectedCategory);

  return (
    <div className="home-page">
      {/* Add Habit Form */}
      <HabitForm onAddHabit={onAddHabit} />

      {/* Category Filter Buttons */}
      <div className="category-filter">
        <h3>Filter by Category:</h3>
        <div className="filter-buttons">
          <button
            className={selectedCategory === 'All' ? 'active' : ''}
            onClick={() => setSelectedCategory('All')}
          >
            🌐 All
          </button>

          {CATEGORIES.map(cat => (
            <button
              key={cat.id}
              className={selectedCategory === cat.name ? 'active' : ''}
              onClick={() => setSelectedCategory(cat.name)}
            >
              {cat.emoji} {cat.name}
            </button>
          ))}
        </div>
      </div>

      {/* Habit List (now filtered) */}
      <HabitList
        habits={filteredHabits}
        onEdit={onUpdateHabit}
        onDelete={onDeleteHabit}
      />
    </div>
  );
}

The UX touches that made it feel polished:

Active button gets a different background color
Smooth transitions between filter states
Count updates automatically when filtering
Empty state shows helpful message

💡 Learning #6: Small UX touches (active states, smooth transitions) make a huge difference in perceived quality.

Phase 10: Summary Cards (At-a-Glance Progress)

I wanted users to see their progress immediately when opening the app. Claude helped me create a beautiful summary system.

The Vision

Four cards showing:

📅 Today's Progress (completed/total)
📊 This Week's completion rate
🔥 Active streaks count
🎯 Total unique habits

Step 1: Analytics Utility

// src/utils/homeSummaryAnalytics.js

// Get today's habits and completion
export const getTodayProgress = (habits) => {
  const today = new Date().toISOString().split('T')[0];
  const todayHabits = habits.filter(h => h.date === today);
  const completed = todayHabits.filter(h => h.status === 'Completed').length;

  return {
    completed,
    total: todayHabits.length,
    percentage: todayHabits.length > 0
      ? Math.round((completed / todayHabits.length) * 100)
      : 0
  };
};

// Get this week's completion rate
export const getWeekProgress = (habits) => {
  const now = new Date();
  const weekAgo = new Date(now.getTime() - 7 * 24 * 60 * 60 * 1000);

  const weekHabits = habits.filter(h => {
    const habitDate = new Date(h.date);
    return habitDate >= weekAgo && habitDate <= now;
  });

  const completed = weekHabits.filter(h => h.status === 'Completed').length;

  return weekHabits.length > 0
    ? Math.round((completed / weekHabits.length) * 100)
    : 0;
};

// Count habits with active streaks
export const getActiveStreaks = (habits) => {
  // Group habits by name
  const grouped = groupHabitsByName(habits);

  // Count how many have current streaks > 0
  let activeStreaks = 0;

  for (const habitName in grouped) {
    const streak = calculateCurrentStreak(grouped[habitName]);
    if (streak > 0) activeStreaks++;
  }

  return activeStreaks;
};

// Count unique habit names
export const getTotalUniqueHabits = (habits) => {
  const uniqueNames = new Set(
    habits.map(h => h.habit.toLowerCase())
  );
  return uniqueNames.size;
};

Step 2: StatCard Component

// src/components/StatCard.js
function StatCard({ icon, value, label, children }) {
  return (
    <div className="stat-card">
      <div className="stat-icon">{icon}</div>
      <div className="stat-content">
        <div className="stat-value">{value}</div>
        <div className="stat-label">{label}</div>
        {children}
      </div>
    </div>
  );
}

Step 3: Progress Bar Component

For today's progress, I wanted a visual bar:

// src/components/ProgressBar.js
function ProgressBar({ percentage }) {
  return (
    <div className="progress-bar-container">
      <div
        className="progress-bar-fill"
        style={{ width: `${percentage}%` }}
      >
        <span className="progress-percentage">{percentage}%</span>
      </div>
    </div>
  );
}

export default ProgressBar;

With some beautiful CSS:

/* src/styles/progress-bar.css */
.progress-bar-container {
  width: 100%;
  height: 24px;
  background: var(--bg-secondary);
  border-radius: 12px;
  overflow: hidden;
  margin-top: 8px;
  border: 1px solid var(--border-color);
}

.progress-bar-fill {
  height: 100%;
  background: linear-gradient(90deg, #4a90e2 0%, #63b3ed 100%);
  border-radius: 12px;
  display: flex;
  align-items: center;
  justify-content: center;
  transition: width 0.5s ease;
  min-width: 30px;
}

.progress-percentage {
  color: white;
  font-size: 12px;
  font-weight: 600;
  text-shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
}

Step 4: Putting It All Together

// src/components/SummaryCards.js
import StatCard from './StatCard';
import ProgressBar from './ProgressBar';
import {
  getTodayProgress,
  getWeekProgress,
  getActiveStreaks,
  getTotalUniqueHabits
} from '../utils/homeSummaryAnalytics';

function SummaryCards({ habits }) {
  const todayProgress = getTodayProgress(habits);
  const weekProgress = getWeekProgress(habits);
  const activeStreaks = getActiveStreaks(habits);
  const totalHabits = getTotalUniqueHabits(habits);

  return (
    <div className="summary-cards">
      <StatCard
        icon="📅"
        value={`${todayProgress.completed}/${todayProgress.total}`}
        label="Today's Progress"
      >
        <ProgressBar percentage={todayProgress.percentage} />
      </StatCard>

      <StatCard
        icon="📊"
        value={`${weekProgress}%`}
        label="This Week"
      />

      <StatCard
        icon="🔥"
        value={activeStreaks}
        label="Active Streaks"
      />

      <StatCard
        icon="🎯"
        value={totalHabits}
        label="Total Habits"
      />
    </div>
  );
}

The Result:

Users now see their progress the instant they open the app. No scrolling, no clicking - just immediate feedback.

💡 Learning #7: Summary metrics should answer the question "How am I doing?" in under 2 seconds.

Phase 11: Restructuring for Deployment

After building all these features, my project structure was getting messy. Claude suggested reorganizing:

# Before: Everything in a subdirectory
habit-tracker/
  habit-tracker/
    src/
    public/
    package.json
  README.md

# After: Clean root structure
habit-tracker/
  src/
  public/
  package.json
  README.md
  vercel.json    # NEW!

Why? Deployment platforms like Vercel expect your project at the repository root.

The migration:

# Move everything up one level
mv habit-tracker/* .
mv habit-tracker/.gitignore .
rmdir habit-tracker

# Commit the restructure
git add .
git commit -m "Restructure repository for easier deployment"

💡 Learning #8: Plan your folder structure with deployment in mind from day one.

Phase 12: Deploying to Vercel

Time to ship! 🚀

Step 1: Create vercel.json

This crucial file tells Vercel how to handle React Router:

{
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Why is this needed?

Single-page apps (SPAs) need all routes to point to index.html so React Router can handle them. Without this, direct navigation to /trends would 404.

Step 2: Deploy via Vercel CLI

# Install Vercel CLI
npm install -g vercel

# Login to Vercel
vercel login

# Deploy!
vercel

# Follow the prompts:
# - Set up new project? Yes
# - Link to existing project? No
# - Project name: habit-tracker
# - Which directory? ./
# - Override settings? No

# Deploy to production
vercel --prod

30 seconds later: My app was live at habit-tracker.vercel.app 🎉

Step 3: Configure Auto-Deploy

Connected my GitHub repo to Vercel:

Went to vercel.com dashboard
Connected GitHub account
Imported the repository
Set build settings:
- Build Command: npm run build
- Output Directory: build
- Install Command: npm install

Now every push to main automatically deploys. Every PR gets a preview URL. Magic! ✨

💡 Learning #9: Vercel's free tier is ridiculously good for React apps. No excuses not to ship!

Phase 13: Comprehensive Testing with Playwright MCP

Here's where things got really interesting. I wanted to make sure the app actually worked before sharing it with the world.

I asked Claude: "Help me create a comprehensive testing strategy for this app."

What is Playwright MCP?

Playwright is a browser automation tool, and MCP (Model Context Protocol) integrates it directly with Claude Code. This means Claude can:

Navigate the actual running app in a browser
Take screenshots and accessibility snapshots
Interact with UI elements
Capture console logs and network requests
Generate detailed test reports

The Testing Process

# Start the dev server
npm start
# App running at http://localhost:3001

# Claude Code connects via Playwright MCP
# Opens browser, starts analyzing...

Claude methodically:

✅ Navigated to every page
✅ Tested every form input
✅ Checked all filters
✅ Verified localStorage persistence
✅ Tested theme switching
✅ Validated responsive design
✅ Checked accessibility

The Generated Test Report

Claude produced UI_TEST_REPORT.md - a 2,270-line comprehensive test plan documenting:

170+ test cases across 14 functional areas
Priority levels (High/Medium/Low)
Detailed test steps and expected results
Recommended testing strategies
Automation guidelines

Here's a sample:

**TC-FORM-013:** Verify habit is added when form is submitted with valid data
**Priority:** High | **Type:** Functional | **Automation:** Yes

**Steps:**
1. Enter "Morning workout" in habit field
2. Select category "Health & Fitness"
3. Select status "Completed"
4. Click "Add Habit"

**Expected Result:** Habit is created and appears in habit list

---

**TC-STORAGE-003:** Verify habits persist after page refresh
**Priority:** High | **Type:** Integration | **Automation:** Yes

**Steps:**
1. Add multiple habits
2. Press F5 to refresh
3. Verify all habits still appear

**Expected Result:** Habits remain after refresh

Test Coverage Summary

Feature Area	Test Cases	Priority
Navigation	7	High
Theme Toggle	7	Medium
Add Habit Form	20	High
Habit List Display	18	High
Summary Cards	12	High
Category Filter	10	High
Edit Habit	11	High
Delete Habit	6	High
LocalStorage	8	High
Trends Page	14	Medium
Accessibility	7	High
Integration/E2E	6	High

Total: 170+ test cases

Generated Artifacts

Claude created a .playwright-mcp/ directory with:

Page snapshots (accessibility trees)
Console log captures
Network request logs
Screenshots at various breakpoints

💡 Learning #10: AI-powered testing can generate comprehensive test plans faster than any human.

Phase 14: Documentation

The final piece: making the project maintainable and shareable.

README.md

Claude helped me create a comprehensive README covering:

Features overview - What the app does
Tech stack - What it's built with
Development journey - How we built it (perfect for blog posts!)
Getting started - Installation and running
Deployment guide - How to ship it
Testing strategy - How to validate it
Project structure - Where everything lives
Future enhancements - What's next

CLAUDE.md

I also created project-specific instructions for future Claude Code sessions:

# CLAUDE.md

This file provides guidance to Claude Code when working with this repository.

## Project Structure
- React 19 with Create React App
- Client-side routing with React Router DOM
- localStorage for persistence (no backend)
- CSS custom properties for theming

## Key Conventions
- Components use functional components with hooks
- Styles use CSS modules, NOT Tailwind or styled-components
- Date format: ISO (YYYY-MM-DD)
- Always update Navigation.js when adding new pages

## Testing
- 170+ test cases documented in UI_TEST_REPORT.md
- Use React Testing Library for unit tests
- Playwright for E2E tests

## Deployment
- Vercel auto-deploys from main branch
- vercel.json is required for React Router support

Why this matters: Future Claude sessions (or human developers!) can understand the project instantly.

💡 Learning #11: Good documentation is a gift to your future self.

The Final Stats

After two days of development with Claude Code:

What We Built:

✅ Full-featured habit tracker
✅ 8-category organization system
✅ Real-time analytics and trends
✅ Summary cards with progress bars
✅ Category filtering
✅ Dark/light themes
✅ 100% responsive design
✅ localStorage persistence
✅ Production deployment
✅ 170+ documented test cases
✅ Comprehensive documentation

The Numbers:

Lines of Code: ~3,500
Components: 15
Pages: 3
Test Cases Documented: 170+
Files Created: 47
Time Spent: ~12-15 hours total
Time Saved vs Solo: Estimated 70-80%

Repository Structure:

habitTracker/
├── .playwright-mcp/          # Test artifacts
├── public/                   # Static assets
├── src/
│   ├── components/          # 15 reusable components
│   ├── constants/           # Category definitions
│   ├── hooks/               # Custom hooks (theme)
│   ├── pages/               # 3 route pages
│   ├── styles/              # 4 CSS files
│   └── utils/               # Analytics functions
├── CLAUDE.md                # AI instructions
├── README.md                # Comprehensive docs
├── UI_TEST_REPORT.md        # 170+ test cases
├── blog-part-1.md           # This blog post!
├── blog-part-2.md           # This blog post!
└── vercel.json              # Deployment config

Key Takeaways: Working with Claude Code

After building this entire app with AI pair programming, here are my insights:

✅ What Claude Code Excelled At

Boilerplate Elimination: No more typing import React from 'react' a hundred times
Architecture Suggestions: Claude's patterns were consistently better than my first instincts
Comprehensive Testing: Generated 170+ test cases I wouldn't have thought of
Documentation: Created better docs than I would have written alone
Learning Tool: Every suggestion came with explanations

⚠️ Where I Still Had to Think

Product Decisions: What features to build and when
UX Design: The "feel" of the app
Code Review: Reading and validating everything
Architecture Strategy: High-level decisions about structure
Debugging Edge Cases: Some bugs required human intuition

🎯 The Optimal Workflow

I found this rhythm worked best:

1. Describe what I want ("Add a progress bar to today's stats")
2. Let Claude write initial implementation
3. Review and test the code
4. Ask questions about anything unclear
5. Request refinements ("Make the animation smoother")
6. Validate the final result
7. Move to next feature

Time ratio:

30% describing what I want
10% waiting for Claude to write code
40% reviewing and testing
20% refining and polishing

Real Talk: Is AI Replacing Developers?

What used to be:

80% writing code
20% thinking about architecture

Is becoming:

30% writing code
70% thinking about architecture, UX, and product decisions

Claude Code didn't replace my job as a developer. It elevated it. I spent more time on:

User experience decisions
Feature prioritization
Design polish
Testing strategy
Documentation quality

And less time on:

Typing boilerplate
Looking up syntax
Fighting with CSS
Writing repetitive tests

The result? A better app, built faster, with more thorough testing.

Resources & Links

Tools Used:

Claude Code - AI pair programming
React - UI framework
React Router - Client-side routing
Vercel - Deployment platform
Playwright - Browser automation

With Claude Code, I:

✅ Built a production app in 2 days instead of 2 weeks
✅ Learned new React patterns and best practices
✅ Generated comprehensive testing documentation
✅ Created better docs than I would have alone
✅ Shipped a polished product I'm proud of

But I also:

✅ Made every product decision
✅ Designed the user experience
✅ Reviewed every line of code
✅ Tested everything thoroughly
✅ Brought the creative vision to life

What did you think of this series? Drop a comment below!

Want to see more builds like this? Follow me for future AI-powered projects.

Questions about the code or process? Ask away - I'll respond to everyone!

Thank you for reading! 🙏

If you found this valuable:

❤️ Leave a reaction
💬 Share your thoughts in the comments
🔖 Bookmark for later
📱 Share with your dev friends

Happy coding! 💻

AI #React #WebDev #Testing #Deployment #ClaudeCode #ProductivityTools #Tutorial

Built with Claude Code, deployed on Vercel, documented for the community. This is the way. ✨

Building a React Habit Tracker with Claude Code - Part 1: From Idea to MVP

Anirban Majumdar — Sat, 25 Apr 2026 04:59:44 +0000

Building a Full-Stack Habit Tracker with Claude Code - Part 1: From Idea to MVP

Introduction: Why Another Habit Tracker?

I started this a demo project to learn how can claude code help as an AI dev partner , I used this demo project to understand and learn different ways to effectively use Claude code and its feature

Here are some important topics that I learned while making this project

Claude.md file
context window
Tools and permission
Planning and Thinking
Slash Command
Custom Slash command
MCP Server
Sub Agents

Follow along to see how I used this learning while creating this Habit Tracker app in React.

Here is what the app does:

🚀 Fast - No login, no setup, just start tracking
🎨 Beautiful - A UI I'd actually want to use daily
📊 Insightful - Show me trends, not just checkboxes
🔒 Private - My data stays in my browser

I built this entire app with Claude Code as my AI pair programmer. And I'm going to show you exactly how.

But first lets start with basics

What is Claude Code?

Before we dive in, let me explain what made this project possible. Claude Code is Anthropic's official CLI tool that brings Claude AI directly into your development workflow. Think of it as an AI pair programmer that can:

Read and understand your entire codebase
Write, edit, and refactor code
Run terminal commands
Debug issues
Suggest architecture improvements

It's not just a chatbot - it's a full development partner.

The Game Plan

Here's what I wanted to build:

Core Features (MVP):

✅ Add, edit, and delete habits
✅ Track habits by date
✅ Four status types: Completed, To Do, Not Completed, Skipped
✅ Data persistence with localStorage
✅ Dark/light theme toggle
✅ Basic analytics and trends

Tech Stack:

React (latest version)
React Router for navigation
Pure CSS (no frameworks - keeping it simple)
localStorage for data persistence (no backend needed!)

Let's build it! 🛠️

Phase 1: Project Setup (The Boring-But-Essential Part)

I started by asking Claude Code to initialize a React project:

npx create-react-app habit-tracker
cd habit-tracker
npm install react-router-dom

Claude suggested this project structure, which turned out to be perfect:

src/
├── components/       # Reusable UI components
├── pages/           # Route components (Home, Trends, About)
├── hooks/           # Custom React hooks
├── styles/          # CSS modules
└── utils/           # Helper functions

💡 Learning #1: Having a clear structure from day one saves hours of refactoring later.

Phase 2: Building the Data Model

The first real code we wrote together was the data model. I described what I wanted, and Claude helped me design a simple but extensible structure:

// Each habit entry looks like this:
{
  id: "1712345678901",           // Timestamp-based unique ID
  habit: "Morning workout",       // What you're tracking
  date: "2026-04-08",            // ISO date format
  status: "Completed"            // Completed | To Do | Not Completed | Skipped
}

Clean, simple, and stored as a JSON array in localStorage. No over-engineering!

Phase 3: State Management Strategy

Here's where Claude Code really shined. Instead of reaching for Redux or Zustand, it suggested a simple but powerful approach:

// App.js - The main component
function App() {
  // Load habits from localStorage on mount
  const [habits, setHabits] = useState(() => {
    const saved = localStorage.getItem('habit-tracker-habits');
    return saved ? JSON.parse(saved) : [];
  });

  // Auto-save to localStorage whenever habits change
  useEffect(() => {
    localStorage.setItem('habit-tracker-habits', JSON.stringify(habits));
  }, [habits]);

  // ... rest of the app
}

💡 Learning #2: You don't always need a state management library. React hooks + localStorage can handle a lot!

Phase 4: The HabitForm Component

This was our first real UI component. I asked Claude to create a form that felt intuitive, and here's what we built together:

// src/components/HabitForm.js
import { useState } from 'react';
import TextInput from './TextInput';
import DateSelector from './DateSelector';
import StatusSelector from './StatusSelector';

function HabitForm({ onAddHabit }) {
  const [habit, setHabit] = useState('');
  const [date, setDate] = useState(new Date().toISOString().split('T')[0]);
  const [status, setStatus] = useState('To Do');

  const handleSubmit = (e) => {
    e.preventDefault();

    if (!habit.trim()) return; // Basic validation

    onAddHabit({
      id: Date.now().toString(),
      habit: habit.trim(),
      date,
      status
    });

    // Clear form
    setHabit('');
    setStatus('To Do');
  };

  return (
    <form className="habit-form" onSubmit={handleSubmit}>
      <h2>➕ Add New Habit</h2>

      <TextInput
        label="Habit"
        value={habit}
        onChange={(e) => setHabit(e.target.value)}
        placeholder="Enter habit (e.g., Morning workout, Read 30 mins)"
      />

      <div className="form-row">
        <DateSelector
          value={date}
          onChange={(e) => setDate(e.target.value)}
        />

        <StatusSelector
          value={status}
          onChange={(e) => setStatus(e.target.value)}
        />
      </div>

      <button type="submit" className="btn-primary">
        ➕ Add Habit
      </button>
    </form>
  );
}

Key Design Decisions:

Composition over monolith: Breaking the form into smaller components (TextInput, DateSelector, StatusSelector) made it easier to maintain and reuse.
Emojis as icons: Instead of icon libraries, we used emojis. Lightweight and universally supported!
Immediate feedback: The form clears immediately after submission, giving users a sense of accomplishment.

💡 Learning #3: Small, focused components are easier for AI (and humans!) to understand and modify.

Phase 5: Displaying Habits - The HabitList Component

Now came the fun part - displaying habits in a beautiful, organized way. I wanted habits grouped by date, with special labels for "Today" and "Yesterday".

Claude Code helped me build this smart grouping logic:

// src/components/HabitList.js
function HabitList({ habits, onEdit, onDelete }) {
  // Group habits by date
  const groupedHabits = habits.reduce((groups, habit) => {
    const date = habit.date;
    if (!groups[date]) {
      groups[date] = [];
    }
    groups[date].push(habit);
    return groups;
  }, {});

  // Sort dates in descending order (newest first)
  const sortedDates = Object.keys(groupedHabits).sort((a, b) =>
    new Date(b) - new Date(a)
  );

  // Format date labels
  const formatDateLabel = (dateString) => {
    const date = new Date(dateString);
    const today = new Date();
    const yesterday = new Date(today);
    yesterday.setDate(yesterday.getDate() - 1);

    if (dateString === today.toISOString().split('T')[0]) {
      return 'Today';
    } else if (dateString === yesterday.toISOString().split('T')[0]) {
      return 'Yesterday';
    } else {
      return date.toLocaleDateString('en-US', {
        weekday: 'long',
        year: 'numeric',
        month: 'long',
        day: 'numeric'
      });
    }
  };

  if (habits.length === 0) {
    return (
      <div className="empty-state">
        <span className="empty-icon">📝</span>
        <h2>No habits tracked yet</h2>
        <p>Add your first habit to get started!</p>
      </div>
    );
  }

  return (
    <div className="habit-list">
      <h2>Your Habits</h2>
      {sortedDates.map(date => (
        <div key={date} className="date-group">
          <div className="date-header">
            <h3>{formatDateLabel(date)}</h3>
            <span className="habit-count">
              {groupedHabits[date].length} {groupedHabits[date].length === 1 ? 'habit' : 'habits'}
            </span>
          </div>

          <div className="habits-grid">
            {groupedHabits[date].map(habit => (
              <HabitCard
                key={habit.id}
                habit={habit}
                onEdit={onEdit}
                onDelete={onDelete}
              />
            ))}
          </div>
        </div>
      ))}
    </div>
  );
}

Why this works:

Smart date grouping: Uses reduce() to organize habits efficiently
User-friendly labels: "Today" and "Yesterday" are more intuitive than dates
Empty state: Always handle the zero-state gracefully
Responsive grid: CSS Grid makes the layout adapt to any screen size

Phase 6: The Theme System (Making It Pretty)

I'm a sucker for dark mode. I asked Claude to implement a theme system that would:

Toggle between light and dark
Remember user preference
Apply smoothly without flashing

Here's the elegant solution we built:

// src/hooks/useTheme.js
import { useState, useEffect } from 'react';

function useTheme() {
  const [theme, setTheme] = useState(() => {
    const saved = localStorage.getItem('habit-tracker-theme');
    return saved || 'light';
  });

  useEffect(() => {
    // Apply theme to root element
    document.documentElement.setAttribute('data-theme', theme);
    // Save to localStorage
    localStorage.setItem('habit-tracker-theme', theme);
  }, [theme]);

  const toggleTheme = () => {
    setTheme(prev => prev === 'light' ? 'dark' : 'light');
  };

  return { theme, toggleTheme };
}

export default useTheme;

And the CSS magic:

/* src/index.css */
:root[data-theme="light"] {
  --bg-primary: #ffffff;
  --bg-secondary: #f5f5f5;
  --text-primary: #333333;
  --text-secondary: #666666;
  --border-color: #e0e0e0;
  --shadow: rgba(0, 0, 0, 0.1);
  --button-bg: #4a90e2;
  --button-hover: #357abd;
}

:root[data-theme="dark"] {
  --bg-primary: #1a1a1a;
  --bg-secondary: #2d2d2d;
  --text-primary: #e0e0e0;
  --text-secondary: #a0a0a0;
  --border-color: #404040;
  --shadow: rgba(0, 0, 0, 0.5);
  --button-bg: #4a90e2;
  --button-hover: #357abd;
}

/* Now all components just use CSS variables */
.habit-card {
  background: var(--bg-primary);
  color: var(--text-primary);
  border: 1px solid var(--border-color);
  box-shadow: 0 2px 4px var(--shadow);
}

💡 Learning #4: CSS custom properties + the data-theme attribute = the cleanest theme system.

Phase 7: Analytics & Trends

This is where the app went from "useful" to "actually cool". I wanted to show users:

Current streaks
Completion rates
Trends over time

Claude helped me build a utility file for all the calculations:

// src/utils/habitAnalytics.js

// Calculate current streak for a habit
export const calculateCurrentStreak = (habitEntries) => {
  if (!habitEntries.length) return 0;

  // Sort by date descending
  const sorted = [...habitEntries].sort((a, b) =>
    new Date(b.date) - new Date(a.date)
  );

  let streak = 0;
  const today = new Date().toISOString().split('T')[0];
  let checkDate = new Date(today);

  for (const entry of sorted) {
    const entryDate = entry.date;
    const expectedDate = checkDate.toISOString().split('T')[0];

    if (entryDate !== expectedDate) {
      break; // Streak broken
    }

    if (entry.status === 'Completed') {
      streak++;
      checkDate.setDate(checkDate.getDate() - 1);
    } else {
      break; // Not completed = streak broken
    }
  }

  return streak;
};

// Calculate completion rate for a habit
export const calculateCompletionRate = (habitEntries) => {
  if (!habitEntries.length) return 0;

  const completed = habitEntries.filter(h => h.status === 'Completed').length;
  return Math.round((completed / habitEntries.length) * 100);
};

// Group habits by name (case-insensitive)
export const groupHabitsByName = (habits) => {
  return habits.reduce((groups, habit) => {
    const name = habit.habit.toLowerCase();
    if (!groups[name]) {
      groups[name] = [];
    }
    groups[name].push(habit);
    return groups;
  }, {});
};

These pure functions made testing easy and the code maintainable.

Phase 8: Routing with React Router

Finally, I wanted to organize the app into multiple pages:

Home: Main tracker interface
Trends: Analytics dashboard
About: Info about the app

// src/App.js
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import Navigation from './components/Navigation';
import Home from './pages/Home';
import Trends from './pages/Trends';
import About from './pages/About';

function App() {
  // ... state management code ...

  return (
    <Router>
      <div className="App">
        <header className="app-header">
          <h1>Habit Tracker</h1>
          <Navigation />
          <ThemeToggle />
        </header>

        <main>
          <Routes>
            <Route path="/" element={
              <Home
                habits={habits}
                onAddHabit={handleAddHabit}
                onUpdateHabit={handleUpdateHabit}
                onDeleteHabit={handleDeleteHabit}
              />
            } />
            <Route path="/trends" element={<Trends habits={habits} />} />
            <Route path="/about" element={<About />} />
          </Routes>
        </main>
      </div>
    </Router>
  );
}

💡 Learning #5: Keep routing simple. Pass data as props instead of reaching for context too early.

Working with Claude Code: What I Learned

After spending hours pair programming with Claude Code, here are my biggest takeaways:

1. Be Specific About What You Want

❌ Bad: "Add a form"
✅ Good: "Create a form component that accepts habit name, date, and status, with validation and clear button"

2. Let Claude Suggest Architecture

I often asked: "What's the best way to structure this?" Claude's suggestions were consistently better than my first instincts.

3. Iterate in Small Steps

Instead of "build the entire app", I worked feature by feature. This made reviewing code easier and kept momentum high.

4. Ask for Explanations

When Claude wrote code I didn't understand, I asked "Why did you do it this way?" The explanations taught me new patterns.

5. Review Everything

AI is powerful, but not infallible. I read every line of code Claude wrote and tested thoroughly.

The MVP After One Day

After about 6-8 hours of focused development with Claude Code, I had:

✅ A fully functional habit tracker
✅ Clean, maintainable code
✅ Dark/light theme support
✅ Data persistence with localStorage
✅ Responsive design
✅ Basic analytics

Lines of code written: ~1,200
Number of manual file operations: Almost zero
Time saved vs coding alone: Estimated 60-70%

What's Next?

In Part 2, I'll cover:

🎨 Adding an 8-category system with emoji icons
📊 Building comprehensive analytics with streak tracking
📈 Creating beautiful summary cards with progress bars
🚀 Deploying to Vercel with proper configuration
🧪 Testing with Playwright MCP (170+ test cases!)
📝 Generating comprehensive documentation

Try It Yourself

Want to build along? Here's the starter template we used:

npx create-react-app habit-tracker
cd habit-tracker
npm install react-router-dom
npm start

Then open Claude Code and start with: "Help me build a habit tracking app with React. Let's start with the data model."

Conclusion

Building with Claude Code felt like having a senior developer sitting next to me, ready to:

Write boilerplate instantly
Suggest better patterns
Explain complex concepts
Catch bugs before I ran the code

Is it perfect? No. I still reviewed every line and made adjustments.

Is it faster? Absolutely. What would have taken me a weekend took an evening.

Did I learn? More than I expected. Claude's explanations taught me new React patterns and best practices.

In Part 2, we'll take this MVP and turn it into a production-ready app with advanced features, comprehensive testing, and real deployment. Stay tuned!

Resources:

Questions? Drop them in the comments below! I'll be responding to all of them.

Found this helpful? Give it a ❤️ and follow me for Part 2!

Part 2 coming next week: "Advanced Features, Testing, and Deployment"

AI #React #WebDev #Tutorial #ClaudeCode #ProductivityTools

Setting Up a Java Project in VS Code - TestNG

Anirban Majumdar — Sat, 14 Mar 2026 15:55:21 +0000

Setting Up a Java Project in VS Code: A Step-by-Step Guide

Introduction

In this guide, I’ll walk you through setting up a modern Java project using Maven and TestNG in Visual Studio Code (VS Code). We’ll cover everything from project creation to running your first test, leveraging the VS Code Java Extension Pack for a seamless experience.

1. Installing the VS Code Java Extension Pack

To get started, install the Java Extension Pack by Microsoft in VS Code. This pack includes essential tools for Java development, such as language support, debugging, and Maven integration.

2. Creating a Maven Project

Open VS Code and launch the integrated terminal. Run the following command to generate a Maven project using the quickstart archetype:

mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.2:generate \
  -DarchetypeArtifactId="maven-archetype-quickstart" \
  -DarchetypeGroupId="org.apache.maven.archetypes" \
  -DarchetypeVersion="1.4" \
  -DgroupId="com.example" \
  -DartifactId="tutorial"

This creates a project structure with src/main/java and src/test/java folders, and a pom.xml for dependency management.

3. Setting Up TestNG

To use TestNG for testing, add the TestNG dependency to your pom.xml:

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>7.8.0</version>
    <scope>test</scope>
</dependency>

4. Creating a SimpleTest Class

Inside src/test/java/com/example/, create a file named simpleTest.java:

package com.example;

import org.testng.annotations.Test;

public class simpleTest {
    @Test
    public void testMethod() {
        System.out.println("TestNG is running!");
    }
}

5. Configuring testng.xml

Create a testng.xml file in your project root to specify which tests to run:

<?xml version="1.0" encoding="UTF-8"?>
<suite name="Tutorial Suite">
    <test name="SimpleTest">
        <classes>
            <class name="com.example.simpleTest"/>
        </classes>
    </test>
</suite>

6. Updating pom.xml for TestNG

Ensure your pom.xml includes the TestNG dependency and is set up for Java 21 (LTS):

<properties>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
</properties>

7. Running Your Tests

Build and run your tests using Maven:

mvn test

You should see output from your simpleTest class, confirming TestNG is working.

Conclusion

With VS Code, Maven, and TestNG, you have a powerful setup for Java development. The Java Extension Pack streamlines your workflow, and TestNG makes testing easy. Happy coding!

Demystifying Promises, Async, and Await in JavaScript/TypeScript with Playwright and Cypress

Anirban Majumdar — Fri, 29 Aug 2025 09:54:41 +0000

One of the most common challenges for automation engineers using JavaScript/TypeScript is handling asynchronous code. Whether you’re writing tests in Playwright or Cypress, you’ll often deal with actions that don’t resolve instantly — such as page navigation, element interactions, or API calls.

That’s where Promises, async, and await come in. Let’s break them down with automation-specific examples.

What is a Promise?

A Promise represents the eventual completion (or failure) of an asynchronous operation. Think of it like a “contract” — “I’ll give you the data when it’s ready.”

Example: Fetching Data

const dataPromise = fetch('https://api.github.com/users');
dataPromise.then(response => response.json())
           .then(data => console.log(data));

In test automation, every browser action is often a Promise.

Async & Await Simplified

async marks a function as asynchronous.

await pauses the function until the Promise is resolved.

This makes code look synchronous and much easier to read.

Using Async/Await in Playwright

Playwright heavily relies on async/await. Almost every browser interaction returns a Promise.

Example: Playwright Test with Async/Await

import { test, expect } from '@playwright/test';

test('Search on Amazon', async ({ page }) => {
  await page.goto('https://www.amazon.com');
  await page.fill('#twotabsearchtextbox', 'Laptop');
  await page.click('input[type="submit"]');

  const results = page.locator('span.a-size-medium');
  await expect(results.first()).toBeVisible();
});

Notice how await makes each step sequential and readable.
Without it, you’d be chaining .then() everywhere, making tests messy.

Using Async/Await in Cypress

Cypress is slightly different — it uses built-in command chaining instead of raw async/await. Cypress commands like cy.get() and cy.click() are asynchronous but auto-managed.

Example: Cypress Test with Implicit Async Handling

describe('Search on Amazon', () => {
  it('should search for Laptop', () => {
    cy.visit('https://www.amazon.com');
    cy.get('#twotabsearchtextbox').type('Laptop');
    cy.get('input[type="submit"]').click();
    cy.get('span.a-size-medium').first().should('be.visible');
  });
});

Here, Cypress internally queues commands and resolves them without you writing await.

Mixing Promises with Playwright

Sometimes you need to handle multiple promises, e.g., waiting for API + UI events together.

Example: Waiting for Navigation and Click (Playwright)

await Promise.all([
  page.waitForNavigation(),
  page.click('text=Login')
]);

This ensures the test doesn’t miss the navigation event.

Mixing Promises with Cypress

Cypress doesn’t expose Promises directly, but you can wrap them:

cy.wrap(Promise.resolve(42)).then(value => {
  cy.log('Resolved value:', value);  // 42
});

Common Pitfalls & Tips

Forgetting await in Playwright

page.click('button#submit'); // ❌ Won’t wait  
await page.click('button#submit'); // ✅ Correct

Using async/await incorrectly in Cypress
Cypress commands don’t return raw Promises, so don’t do:

const text = await cy.get('h1').text(); // ❌ Not supported

Instead, use

.then():

cy.get('h1').then($el => {
  cy.log($el.text());
});

Parallelization with Promises
For Playwright, prefer Promise.all when waiting for multiple things.

Conclusion

Understanding Promises, async, and await is essential for writing clean, reliable automation in JavaScript/TypeScript.

In Playwright, always use async/await to control flow.

In Cypress, commands are asynchronous but automatically queued.

For advanced scenarios, leverage Promise.all (Playwright) or cy.wrap (Cypress).

Mastering these concepts makes your automation more readable, stable, and maintainable.

Using MCP Server to Supercharge Playwright Automation

Anirban Majumdar — Fri, 29 Aug 2025 09:32:45 +0000

Automation at scale often struggles with two pain points:

Slow test development (boilerplate code, selectors, retries).

Flaky tests due to fragile locators.

With Model Context Protocol (MCP), we can connect Playwright to an AI server that assists in writing, fixing, and maintaining automation tests. In this blog, we’ll set up MCP with Playwright to automate real-world scenarios on Amazon.com.

🔹 1. Prerequisites

Make sure you have the following installed:

Node.js (>=18)

Playwright

MCP server implementation (e.g., mcp-server
or custom server)

OpenAI/GitHub Copilot or another LLM provider

Install Playwright

npm init playwright@latest

Add TypeScript config if needed:

npm install -D typescript ts-node @types/node

🔹 2. Folder Structure

playwright-amazon/
 ┣ tests/
 ┃ ┣ amazon-search.spec.ts
 ┃ ┣ amazon-cart.spec.ts
 ┣ mcp/
 ┃ ┣ server.ts
 ┃ ┣ config.json
 ┣ playwright.config.ts
 ┗ package.json

🔹 3. MCP Server Setup

Your MCP server is the middleware between Playwright and the LLM. It provides structured prompts like “Suggest resilient Playwright locator for Add to Cart button”.

Example MCP Config (mcp/config.json)

{
  "name": "playwright-mcp",
  "description": "MCP server for Playwright automation",
  "capabilities": {
    "selectors": true,
    "code-gen": true
  },
  "llmProvider": "openai",
  "llmModel": "gpt-4o-mini"
}

Example MCP Server (mcp/server.ts)

import express from 'express';
import bodyParser from 'body-parser';
import { generateLocator } from './utils/locator-generator';

const app = express();
app.use(bodyParser.json());

app.post('/locator', async (req, res) => {
  const { request, context } = req.body;
  const locator = await generateLocator(request, context);
  res.json({ locator });
});

app.listen(4000, () => console.log('MCP server running on port 4000'));

🔹 4. Playwright + MCP Integration

We’ll call MCP server from within our Playwright tests whenever we need AI-assisted selectors or snippets.

Utility to Call MCP (tests/utils/mcp-client.ts)

import axios from 'axios';

export async function getLocator(request: string, context: string): Promise<string> {
  const response = await axios.post('http://localhost:4000/locator', { request, context });
  return response.data.locator;
}

🔹 5. Example Test – Amazon Search

tests/amazon-search.spec.ts

import { test, expect } from '@playwright/test';
import { getLocator } from './utils/mcp-client';

test('Amazon Search for Laptop', async ({ page }) => {
  await page.goto('https://www.amazon.com');

  // Get locator dynamically from MCP
  const searchBox = await getLocator("Search input field", "amazon-homepage");
  await page.fill(searchBox, 'Laptop');

  const searchButton = await getLocator("Search button", "amazon-homepage");
  await page.click(searchButton);

  // Validate results
  const results = page.locator('span.a-size-medium');
  await expect(results.first()).toBeVisible();
});

Here MCP generates resilient locators, so even if Amazon updates their DOM slightly, the AI can adapt.

🔹 6. Example Test – Add to Cart

tests/amazon-cart.spec.ts


import { test, expect } from '@playwright/test';
import { getLocator } from './utils/mcp-client';

test('Add product to Amazon Cart', async ({ page }) => {
  await page.goto('https://www.amazon.com');

  // Search product
  const searchBox = await getLocator("Search input field", "amazon-homepage");
  await page.fill(searchBox, 'iPhone 15');
  const searchButton = await getLocator("Search button", "amazon-homepage");
  await page.click(searchButton);

  // Click first result
  const firstResult = await getLocator("First product link", "amazon-search-results");
  await page.click(firstResult);

  // Add to cart
  const addToCart = await getLocator("Add to Cart button", "amazon-product-page");
  await page.click(addToCart);

  // Validate cart
  const cartCount = page.locator('#nav-cart-count');
  await expect(cartCount).toHaveText('1');
});

🔹 7. Benefits

✅ Resilient selectors – MCP auto-generates robust locators.
✅ Reduced flaky tests – Fewer selector breakages on UI changes.
✅ Faster automation – Engineers describe tests; AI scaffolds code.
✅ Scalable – Can plug into CI/CD for continuous improvement.

🔹 Conclusion

Using MCP with Playwright transforms how we build automation. Instead of spending hours debugging fragile selectors, engineers can focus on test strategy, while MCP + AI handles the scaffolding.

Forem: Anirban Majumdar

`@playwright/cli` Is Not `npx playwright test` — And That Difference Is Costing Your AI Agent Thousands of Tokens

What exactly is Playwright and where do you use it

Installing It

What It Looks Like In Use

The App I'm Testing

The Token Problem With npx playwright test Alone

Why playwright-cli Is So Token-Efficient

1. Snapshot output is compact by design

2. Ref-based interaction means no selector archaeology

3. The --skills flag prevents repeated --help calls

4. Scoped execution with --grep on the test runner side

The Complete Token Breakdown Across a Real QA Cycle

The Debugging Difference

What playwright-cli Commands Actually Look Like In Practice

The Agent Files That Use playwright-cli

.claude/agents/qa-smoke-runner.md

.claude/agents/qa-failure-triager.md

The --reporter=json Detail Nobody Talks About

When playwright-cli Isn't Enough: The MCP Server

The Mental Model, Simplified

Quick Reference: Token Cost By Command

What I'd Do Differently

The GitHub Repo

Building a Full-Stack Habit Tracker with Claude Code - Part 2: Polish, Testing & Deployment

Building a Full-Stack Habit Tracker with Claude Code - Part 2: Polish, Testing & Deployment

Welcome Back!

Phase 9: The Category System (Organization FTW)

Step 1: Define the Categories

Step 2: Category Selector Component

Step 3: Update the Data Model

Step 4: Category Filtering on Home Page

Phase 10: Summary Cards (At-a-Glance Progress)

The Vision

Step 1: Analytics Utility

Step 2: StatCard Component

Step 3: Progress Bar Component

Step 4: Putting It All Together

Phase 11: Restructuring for Deployment

Phase 12: Deploying to Vercel

Step 1: Create vercel.json

Step 2: Deploy via Vercel CLI

Step 3: Configure Auto-Deploy

Phase 13: Comprehensive Testing with Playwright MCP

What is Playwright MCP?

The Testing Process

The Generated Test Report

Test Coverage Summary

Generated Artifacts

Phase 14: Documentation

README.md

CLAUDE.md

The Final Stats

Key Takeaways: Working with Claude Code

✅ What Claude Code Excelled At

⚠️ Where I Still Had to Think

🎯 The Optimal Workflow

Real Talk: Is AI Replacing Developers?

Resources & Links

AI #React #WebDev #Testing #Deployment #ClaudeCode #ProductivityTools #Tutorial

Building a React Habit Tracker with Claude Code - Part 1: From Idea to MVP

Building a Full-Stack Habit Tracker with Claude Code - Part 1: From Idea to MVP

Introduction: Why Another Habit Tracker?

But first lets start with basics

What is Claude Code?

The Game Plan

Phase 1: Project Setup (The Boring-But-Essential Part)

Phase 2: Building the Data Model

Phase 3: State Management Strategy

Phase 4: The HabitForm Component

Phase 5: Displaying Habits - The HabitList Component

Phase 6: The Theme System (Making It Pretty)

Phase 7: Analytics & Trends

Phase 8: Routing with React Router

Working with Claude Code: What I Learned

1. Be Specific About What You Want

2. Let Claude Suggest Architecture

3. Iterate in Small Steps

4. Ask for Explanations

5. Review Everything

The Token Problem With `npx playwright test` Alone

3. The `--skills` flag prevents repeated `--help` calls

4. Scoped execution with `--grep` on the test runner side

`.claude/agents/qa-smoke-runner.md`

`.claude/agents/qa-failure-triager.md`

The `--reporter=json` Detail Nobody Talks About