First Hour with Claude Code: Install to Output

What You'll Build in 60 Minutes

Picture this. It is 9 AM on a Tuesday. You have a codebase you know well, a terminal you trust, and an hour before the next meeting. By 10 AM, you will have an AI agent installed on your machine, trained on your project's conventions, and proven on three real tasks from your own backlog.

Here is what you walk away with:

1. Claude Code installed and authenticated on your machine.
2. A CLAUDE.md file that makes Claude Code understand your project's architecture and conventions.
3. Three completed tasks on your actual codebase — not a toy project, your real code.

Every section has a time estimate. Track your pace. Fall behind on one, make it up on the next.

Prerequisites:

• macOS, Windows, or Linux
• A Claude Pro subscription ($20/month) or an Anthropic API key
• A real project with at least a few source files (any language)
• A terminal you are comfortable with

No prior AI coding tool experience required.

Minute 0-5: Install Claude Code

One command. No Node.js. No npm. No package manager drama.

macOS and Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell):

irm https://claude.ai/install.ps1 | iex

Homebrew (macOS alternative):

brew install --cask claude-code

After installation, run:

claude

Your browser opens. Log in with your Claude.ai account — the same one tied to your Pro subscription. If the browser refuses to cooperate, press c to copy the login URL to your clipboard and paste it manually.

Once authenticated, you see the Claude Code prompt in your terminal. Credentials live in ~/.claude/. You will not log in again unless you explicitly log out.

What you should see: A clean prompt with a version number and a cursor. If you see an authentication error, check claude.ai/settings and confirm your Pro subscription is active.

Time check: Under 5 minutes. Browser authentication hiccups are a one-time cost — do not let them rattle you.

Minute 5-10: Your First Prompt

Navigate to a real project. Not a fresh directory — pick something you have been building. A project with 5-10 files gives Claude Code enough to work with.

cd ~/projects/your-actual-project
claude

Type this:

Explain the architecture of this project. What are the main modules,
how do they connect, and what patterns does the codebase follow?

Watch what happens. Claude Code scans the directory structure, opens key files — package.json, config files, entry points — and assembles a mental map of your codebase. A few seconds pass.

Good output looks like this: A structured summary that names your framework, maps the directory layout, traces data flow between modules, and identifies patterns — MVC, repository pattern, feature-based folders. It mentions specific file paths from your project.

Bad output looks like this: Vague generalities. "This appears to be a web application." If Claude Code cannot name your framework, your router, or your state management, the codebase is too small or the model did not read enough files. Try being specific: "Read the main entry point and trace the request flow from the API endpoint to the database."

This first prompt is read-only. Claude Code reads files but changes nothing. Zero risk.

Time check: 5 minutes in. You have a working installation and your first useful output — an architecture overview you can share with teammates or drop into documentation.

Minute 10-20: Create a CLAUDE.md File

That architecture explanation was decent. Now you make it dramatically better.

Why CLAUDE.md Matters

Think of onboarding a new developer. You hand them a doc that says: here is our stack, here are our conventions, here is why we do things this way. CLAUDE.md is that doc — except the reader is an AI agent, not a human.

Every time Claude Code starts a session in your project, it reads CLAUDE.md from the project root. This file tells it things code alone cannot convey: your team's naming conventions, your preferred patterns, constraints that live in tribal knowledge rather than linter rules, the "why" behind architectural decisions.

Research from ETH Zurich found that overly detailed context files degrade agent performance. The sweet spot is 200-500 words of high-signal information. Every line should pass one test: "Would removing this cause Claude Code to make a mistake?" If the answer is no, delete it.

A Working Template

Create CLAUDE.md in your project root:

## Project Overview
[One paragraph: what this project does, who it serves, what problem it solves]

## Architecture
- Framework: [e.g., Next.js 15 App Router]
- Database: [e.g., PostgreSQL via Prisma]
- Auth: [e.g., NextAuth.js v5]
- Styling: [e.g., Tailwind CSS]
- Testing: [e.g., Vitest for unit, Playwright for e2e]

## Code Conventions
- [e.g., TypeScript strict mode everywhere]
- [e.g., Prefer server components; 'use client' only when necessary]
- [e.g., Error handling uses Result types, not try/catch]
- [e.g., No default exports except for pages/layouts]

## Directory Structure
- src/app/ — routes and pages
- src/components/ — shared UI components
- src/lib/ — business logic and utilities
- src/db/ — database schema and migrations

## Hard Constraints
- [e.g., Never modify migration files directly]
- [e.g., All API routes must validate input with Zod]
- [e.g., No external HTTP calls in server components]

Fill this in with your project's real details. Five minutes. Do not overthink it. You will refine it over time as you discover which instructions the model actually needs.

Key principles:

• Keep it under 100 lines. Claude Code's own system prompt uses about 50 of its ~200 instruction slots. Your CLAUDE.md should be lean.
• Prefer pointers over copies. Write See src/lib/errors.ts for the error handling pattern instead of pasting the code. Snippets in CLAUDE.md go stale. File references stay accurate.
• Do not duplicate linter rules. If ESLint already enforces something, do not restate it. Claude Code runs your linters as hooks — let deterministic tools handle deterministic rules.

See the Difference

Run the same architecture prompt again:

Explain the architecture of this project. What are the main modules,
how do they connect, and what patterns does the codebase follow?

The difference is immediate. With CLAUDE.md loaded, Claude Code uses your terminology, references your conventions, structures its answer around the architecture you described. It stops guessing. It speaks your project's language.

Time check: 20 minutes in. Installed, authenticated, configured. Everything from here is actual productivity.

Minute 20-35: Your First Real Task

Time to make Claude Code earn its subscription. Pick a concrete, well-scoped task from your actual backlog. If you do not have one handy, use this universal example:

Add input validation to the signup API endpoint.
Validate email format, password minimum 8 characters,
and username between 3-30 alphanumeric characters.
Use Zod for the schema. Return specific error messages
for each validation failure.

The Interaction Flow

Step 1: Claude Code reads. It identifies the relevant files — the signup route, existing validation patterns, schema definitions. Each file access is logged in your terminal. You see exactly what it is looking at.

Step 2: Claude Code plans. Before writing a line, it shows you its intent: "I'll create a Zod schema in src/lib/validations/auth.ts, import it in the signup route at src/app/api/auth/signup/route.ts, and add error formatting that returns field-specific messages." This is the moment to course-correct before any code is written.

Step 3: You review and approve. Claude Code shows proposed changes as diffs. This is the permission model:

• File reads happen automatically — no approval needed.
• File writes require your explicit approval. Claude Code shows you exactly what it wants to write before writing it.
• Shell commands (like npm install zod) also require approval.

Review the diff carefully on your first few tasks. Over time, you develop a feel for when to approve immediately and when to push back.

Step 4: Claude Code executes. After your approval, files are written. It often runs follow-up actions — creating files, adding imports, sometimes running your test suite to verify the change.

Step 5: Verify. This is the habit that separates productive developers from reckless ones:

Run the tests related to the signup endpoint.
If there are no tests, write them first.

Never accept a code change without verification. Claude Code can run your test suite, check for TypeScript errors, and confirm correctness — but only if you ask.

What to Watch For

• Does Claude Code respect your CLAUDE.md conventions? If you specified Zod for validation and it reaches for a different library, your CLAUDE.md needs a stronger constraint.
• Are the changes minimal? A good change touches only what needs touching. If Claude Code modified 8 files for a simple validation task, something went wrong.
• Can you understand the code? If the generated code is clever but unreadable, tell Claude Code plainly: "Simplify this. I should be able to read each function in 10 seconds."

Time check: 35 minutes in. You have completed a real task with code review and verification. This is the core Claude Code loop — everything else builds on it.

Minute 35-50: Multi-File Task

Single-file changes are nice, but they are not where Claude Code separates itself from autocomplete. The real advantage is multi-file reasoning — tracing dependencies, updating imports, maintaining consistency across a codebase. Like a surgeon who sees the whole patient, not just the incision.

Pick a task that spans multiple files. If you do not have one:

Refactor the error handling in this project to use a centralized
error class. Create a base AppError class with status code, error code,
and user-friendly message. Replace all ad-hoc error throws with
specific subclasses (ValidationError, NotFoundError, AuthError).
Update the error handling middleware to use the new classes.

What Happens Differently

1. Broad file scanning. Claude Code reads not just error handling code but the entire middleware chain, every route handler that throws errors, and the tests that assert on error behavior. It maps the full error surface before proposing changes.

2. Cross-file planning. The plan is multi-step: create the error class hierarchy, update each route handler, modify the error middleware, update tests. File-by-file, with rationale for each change.

3. Ordered execution. The base class is created first. Then consumers are updated. Order matters — updating route handlers before the error class exists would break the build between steps.

4. Import management. Every file that references the new error classes gets its imports updated. Tedious work that Claude Code handles mechanically.

5. Test updates. If tests assert on specific error messages or status codes, they are updated to match the new structure.

Review the full changeset before approving. This is a larger change — take 2-3 minutes to read through the diffs. Verify the class hierarchy makes sense, no error cases were missed, and the middleware correctly catches the new types.

Show me a summary of all files changed and what changed in each one.

After approval and execution, verify:

Run the full test suite. Show me any failures.

Time check: 50 minutes in. You have completed a non-trivial refactoring across multiple files — the kind of task that typically consumes 30-60 minutes of manual work.

Minute 50-60: Set Up Your Workflow

Claude Code works on your codebase. Now make it part of your daily routine.

Configure Permissions

Claude Code's permission system lives in .claude/settings.json in your project root. It controls what runs automatically and what requires approval.

A practical starting configuration:

{
  "permissions": {
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)",
      "Bash(npx tsc --noEmit)"
    ]
  }
}

This lets test and lint commands run freely while file writes and other shell commands still require confirmation. Start conservative. Expand the allowlist as trust builds.

Learn the Key Commands

Inside a Claude Code session:

• /help — Shows all available commands
• /compact — Compresses conversation context when sessions get long
• /clear — Resets the session when context becomes cluttered
• /effort — Controls reasoning depth (higher for complex tasks, lower for simple ones)

Understand Subagents

For large tasks, Claude Code spawns subagents — isolated child sessions that handle a subtask without polluting your main conversation. Think of them as worker threads. The main session stays clean while subagents do focused work in the background.

You can also delegate explicitly:

Use a subagent to research all the places in this codebase
where we handle authentication tokens. Report back with
file paths and a summary.

The subagent gets its own context window, does its work, and reports back. Your main session stays uncluttered.

Set Up Your Terminal for Multi-Task Work

The natural daily setup: Claude Code in one pane, your test runner in another, your editor in a third. Running them side by side means you can watch Claude Code work while verifying its output in real time.

A proper multi-pane setup lets you drag files directly into the Claude Code terminal, keep a dedicated pane for verification commands, and monitor git status alongside your AI agent. This side-by-side workflow is where the productivity multiplier shows up.

Install Useful Skills

Claude Code supports skills — reusable instruction sets created by you or the community. Skills can define workflows, enforce patterns, or add specialized knowledge. The ecosystem of community skills covers common tasks like PR review, test generation, and documentation writing.

What's Next

Sixty minutes. You now have a working Claude Code setup with project context, experience on real tasks, and a configured workflow. Here is where to go from here:

Go deeper on the tool landscape. The 2026 AI CLI Tools Complete Guide covers every major AI CLI tool — Claude Code, Gemini CLI, Copilot CLI, Codex CLI, and six others — with full pricing, capability comparisons, and multi-agent workflow patterns.

Optimize your costs. Claude Code Pro at $20/month is the entry point, but you can stretch it further. The dual-tool strategy shows how to pair Claude Code with Gemini CLI's free tier — use Gemini for exploration and simple tasks, save Claude Code for the complex work that actually needs it. Many developers cut their effective costs by 60-70% this way.

Build your CLAUDE.md over time. The template you created today is a starting point. After a week of daily use, you will know which instructions Claude Code follows reliably and which it ignores. Refine based on the mistakes it actually makes, not the ones you imagine.

Set up hooks for enforcement. CLAUDE.md instructions get followed about 70% of the time. For rules that must be enforced 100% — like running the linter before every commit or blocking writes to certain directories — use hooks. Hooks are shell scripts that fire at specific points in Claude Code's workflow and enforce rules deterministically.