The Smartest Intern in the World

Chapter 1: The Room

Understanding the LLM

The Desk (Context Window)

The intern has one desk. Everything they need must fit on this desk at once:

• The instruction card pinned to the wall (system prompt), always visible
• The stack of previous notes (conversation history)
• The phone book (tool definitions), we'll get to this
• Any documents you attached (files, specs, code)
• Space for the intern's answer

Once the desk is full, something has to be removed. Older notes get pushed off. The intern seems to "forget" earlier conversations. The desk is physically full.

The context window is working memory, like RAM. Not storage. Every API call, the desk gets cleared and rebuilt from scratch.

The Paper Slips (Tokens)

The intern doesn't read whole words. They process token-fragments, like Scrabble tiles:

• "Hello world" = 2 tokens
• "unbelievable" = 3 tokens: "un", "believ", "able"
• "Антропик" = probably 4+ tokens (non-English is expensive)
• Code is token-hungry: braces, indentation, semicolons all cost tokens

Why this matters:

• Pricing: you pay per token, both input and output
• Limits: context window is measured in tokens, not words
• Behavior: the intern generates one token at a time, each predicted based on ALL previous tokens

The Creativity Dial (Temperature)

There's a dial on the intern's desk.

• Dial at 0: The intern picks the most obvious next word. "The capital of France is" → Paris. Every time. Good for code, facts, JSON.
• Dial at 1: The intern explores. "The capital of France is" → "a place that smells of fresh bread and diesel." Good for brainstorming, creative writing.

Most coding tools keep the dial at 0.

The Amnesia Problem

Every time you slide a new note in, the intern has amnesia. They don't remember the last conversation. If you want them to remember what you discussed before, you reprint the entire previous conversation and slide it in again.

Chat UIs send the full conversation history with every message. Long conversations get expensive (more tokens each turn). The desk fills up and the oldest messages get dropped. The model seems to "forget" things from early in the conversation.

How the Intern Reads (Attention)

The intern doesn't read left-to-right. They look at ALL words simultaneously and figure out which ones relate to which.

"The server crashed because it ran out of memory." The intern understands that "it" refers to "server" (not "memory"), and makes this connection across the entire desk, from page 1 to page 500.

This is the foundation of prompt engineering: put the right information on the desk → the intern attends to it → better output.

Token IDs → Embeddings (8192-dim vectors) → [Attention + Feed-Forward] × 100 layers → Probabilities

The Wall Card (System Prompt)

The instruction card pinned to the wall. Always visible. Shapes everything the intern does.

"You are a senior TypeScript developer. Follow SOLID principles. Never use any type. Respond in Ukrainian when asked about documentation."

The intern reads this before every task. The same model can be a code reviewer, a writing assistant, and a customer support agent. Different wall cards, same brain.

The Paradigm Shift

Before LLMs, we didn't have an intern. We had a vending machine. Press button A3 → always get the same candy bar. getUser(42) → always { name: "Alex" }. Deterministic. Predictable. Testable.

Now we have the intern. Slide in the same question twice, get two different answers. Both correct, just phrased differently.

• "Write a function to sort an array" → Bubble sort today, quicksort tomorrow, different variable names each time.
• Same input → Different output. A different paradigm.

We went from programming vending machines to writing instructions for a brilliant but unpredictable intern. Different engineering practices apply.

Your message → Tokenize → Assemble full context (system + history + tools + message)
→ Forward pass through all 100+ layers → First token generated (this is the initial delay)
→ Append token, run again with KV-cache → Next token → Repeat until done

Chapter 2: The Phone

Giving the Intern Tools

The Problem

Our intern is smart but isolated. Without a phone, they can't:

• Browse the web or call any API
• Query your database
• Read files on your server
• Execute code or run tests
• Know today's date, current prices, or any live data

They know everything that was in their training data, but nothing about right now.

The Phone Book

You tape a list of phone numbers to the wall. Each entry describes a service the intern can call:

Name: "get_weather"
Description: "Get current weather for a city"
Parameters: { location: string (required) }

The intern reads the descriptions, decides if a call is relevant, and writes a request:

{ "tool": "get_weather", "arguments": { "location": "Kyiv" } }

They slide this request out through the slot. YOUR code makes the actual call, gets the weather data, and slides the result back in. The intern then uses that result to write their answer.

The intern NEVER leaves the room. They NEVER make the call themselves. They write "please call this number for me" on a slip. Your code does the actual work. Same on both Anthropic and OpenAI.

The Phone Call Protocol (4 Steps)

Step 1: You → [tools + prompt] → Intern
        "Here's a phone book and a question about weather"

Step 2: Intern → "I want to call get_weather('Kyiv')" → You
        The intern writes a structured call request

Step 3: You → [execute, get result: "12°C, cloudy"] → Intern
        YOUR code makes the call, slides the result back

Step 4: Intern → "It's 12°C and cloudy in Kyiv!" → You
        The intern writes the final answer using the result

Same Room, Different Phone Books

Anthropic calls it "Tool Use." OpenAI calls it "Function Calling." Same concept, same JSON Schema format for the phone book entries.

Two Types of Calls

Anthropic splits them:

1. Client tools — the call goes to YOUR infrastructure. You build the "kitchen."
2. Server tools — the call goes to Anthropic's servers (web search, etc.). No implementation needed.

OpenAI has five categories:

1. Hosted tools — web search, file search, code interpreter (on OpenAI servers)
2. Local tools — ComputerTool, ShellTool (on your machine)
3. Function calling — wrap any Python function as a tool
4. Agents as tools — one agent can call another
5. Codex tool — run coding tasks in a sandbox

What the Phone Unlocks

With a phone, the intern CAN:

• Search the web, fetch URLs
• CRUD operations on any database
• Read/write files, manage git repos
• Run tests, deploy code
• Interact with any service that has an API

The intern goes from "brain in a jar" to "brain with hands." Each hand needs to be wired up individually, which brings us to the next problem.

REQUEST 1:  You send [tools + "What's the weather in Kyiv?"]
RESPONSE 1: Claude returns stop_reason: "tool_use"
            + {name: "get_weather", input: {location: "Kyiv"}}

REQUEST 2:  You send [ENTIRE conversation + tool_result: "12°C, cloudy"]
RESPONSE 2: Claude returns "It's 12°C and cloudy in Kyiv!"

Chapter 3: The Intercom

MCP — The Universal Adapter

The Problem: Too Many Phone Numbers

Remember when every phone brand had a different charger? Nokia one connector, Samsung another, Motorola a third. You needed a drawer full of cables.

That's where AI tools are without MCP:

• Claude needs tools defined one way
• GPT needs them slightly differently
• Every data source needs a custom integration
• Every IDE/app rebuilds the same connectors
• 5 AI tools × 10 services = 50 custom integrations

The Intercom System

Instead of taping individual phone numbers to the wall, we install a standardized intercom system. Any service can plug into the intercom using the same standard connector.

With MCP: 5 AI tools + 10 services = 15 integrations. One protocol, one standard.

MCP stands for Model Context Protocol, an open standard created by Anthropic, now community-driven and adopted by OpenAI, Google, Microsoft, and hundreds of tool providers.

Architecture: Three Roles

THE BUILDING (MCP Host: Claude Desktop, VS Code, your app)
  └── INTERCOM PANEL ON THE WALL (MCP Client: protocol handler)
        ├── LINE → GitHub Server
        ├── LINE → Azure DevOps Server
        ├── LINE → PostgreSQL Server
        └── LINE → Your Custom API Server
  └── THE ROOM (LLM — the intern inside)

• Host = the building that contains the room (Claude Desktop, VS Code, Cursor)
• Client = the intercom panel mounted on the wall outside the room (routes requests to the right server). The intern can't touch it directly. They slide a note under the door saying "I need data from GitHub," and the building's intercom system handles the call.
• Server = each service plugged into the intercom (GitHub, database, Slack)

Three Buttons on the Intercom

Button 1 — Do Something (Tool Call):

The intern writes a note: "Search issues for 'bug login'." They slide it under the door. The building routes it through the intercom to the right server, which executes and returns results back through the slot.

Button 2 — Read Something (Resource):

The intern writes: "Read file config.yaml." Same process — note goes out, data comes back. Read-only.

Button 3 — Give Me a Template (Prompt):

The intern writes: "Give me the code review template for TypeScript." The server sends back a structured prompt ready to fill in.

The Wiring (Transport)

Two ways the intercom works:

1. stdio — the server runs locally, communicates via stdin/stdout. Like a Unix pipe between processes. Great for local dev tools, CLI integrations.

1. HTTP+SSE (Streamable HTTP) — the server runs remotely, communicates over HTTP. Like a REST API that can also push updates. Great for cloud deployments, enterprise setups.

Both speak the same MCP "language" — JSON-RPC 2.0.

CLIENT                          SERVER
  │── initialize ──────────────▶│  (exchange capabilities)
  │◀── result ──────────────────│  "I have tools + resources"
  │── tools/list ──────────────▶│  (discover available tools)
  │◀── result ──────────────────│  [{name: "search_issues", inputSchema: {...}}]
  │── tools/call ──────────────▶│  (LLM wants to call a tool)
  │◀── result ──────────────────│  {content: [{type: "text", text: "Found 3 issues..."}]}

Two Ways to Set Up the Intercom

Way 1: Build the intercom yourself (full control)

# Connect to MCP server, get tools, convert to Claude format
mcp_tools = await mcp_session.list_tools()
claude_tools = [{"name": t.name, "description": t.description,
                 "input_schema": t.inputSchema} for t in mcp_tools.tools]
# Pass to Claude API
response = client.messages.create(tools=claude_tools, ...)

Way 2: Use the MCP Connector (Anthropic's "easy button")

# Just point Claude at the MCP server URL — no client code needed
response = client.messages.create(
    mcp_servers=[{"type": "url", "url": "https://mcp.example.com/sse"}],
    ...
)

OpenAI supports MCP natively in both the Agents SDK and the Responses API.

Real-World Intercom Lines Your Team Can Use

MCP vs. Direct Tool Integration

MCP is REST for AI tools. Just as REST standardized web APIs, MCP standardizes AI-tool connections. Build once, works everywhere.

MCP Server → tools/list → {name, description, inputSchema}
     ↓ (MCP client translates)
Claude API → tools: [{name, description, input_schema}]  ← tokens on desk
     ↓ (LLM generates tool_use)
MCP Client → tools/call → {name, arguments}  ← translated back to MCP

Chapter 4: The Instruction Manuals

Skills — Teaching the Intern Procedures

The Gap

You gave the intern a phone (tools). They can call the weather API, search GitHub, query your database. But knowing how to use a drill doesn't mean you know how to build a kitchen.

• Tools = giving the intern a power drill
• Skills = giving them the blueprint, the building codes, and your company's style guide

A tool is a capability. A skill is knowledge of when and how to use capabilities, with all the domain context that makes the result professional.

What a Skill Actually Is

A Skill is a directory on the intern's desk containing an instruction manual:

my-skill/
├── SKILL.md          ← Required: instructions + metadata
├── scripts/          ← Optional: executable code
│   └── validate.py
├── templates/        ← Optional: reference templates
│   └── report.docx
└── assets/           ← Optional: images, data files
    └── logo.png

The SKILL.md file has two parts:

1. YAML frontmatter — metadata (name, description, when to trigger)
2. Markdown body — step-by-step instructions, rules, examples

---
name: quarterly-report
description: >
  Generate quarterly business reports following company
  template. Use when user asks for quarterly reports.
---

# Quarterly Report Generation

## Steps
1. Read the template from templates/report.docx
2. Extract financial data from provided spreadsheet
3. Generate executive summary
4. Fill in each section following the template structure
5. Validate formatting with scripts/validate.py

## Rules
- Always use company color scheme (#2E75B6 primary)
- Financial figures must include YoY comparison
- Executive summary must be under 200 words

Progressive Disclosure: The Table of Contents Trick

The intern doesn't load all manuals upfront. That would fill the desk. Instead:

STAGE 1: System prompt loads ONLY metadata
         (name + description for each installed skill)
         ≈ 50 tokens per skill

STAGE 2: User message triggers a skill match
         The intern reads just THAT SKILL.md
         ≈ hundreds of tokens

STAGE 3: Skill loads reference files, scripts,
         templates AS NEEDED
         ≈ thousands of tokens, loaded incrementally

Like a table of contents in a manual — the intern first sees chapter titles. When they need Chapter 7, they read just that chapter. They never load the whole manual upfront.

Why this matters for desk economics:

• 20 skills installed → ~1,000 tokens of metadata (tiny)
• Without progressive disclosure → 50,000+ tokens upfront (desk overflow)

OpenAI Adopts Skills

Skills were created by Anthropic in October 2025, published as an open standard in December 2025. By late 2025, OpenAI adopted them:

• GPT-5.4 lists "Skills" as a supported tool type
• Codex CLI uses skills for repo-level workflows
• AGENTS.md files reference skills via $skill-name triggers

Both platforms now support Skills + MCP + Tools. The ecosystem is standardizing.

Skills vs. No Skills — A Demo Idea

Ask the intern to create a PowerPoint WITHOUT skills → generic white slides, bullet points, boring layout.

Ask the same thing WITH the pptx skill loaded → professional design, branded colors, proper typography, icon usage, visual QA verification.

The SKILL.md that made the difference is a markdown file with instructions, built from hundreds of trial-and-error iterations.

Chapter 5: The Complete Stack

How It All Fits Together

The Layer Cake

These are layers, not alternatives:

Agent (orchestration)
  └── uses Skills (procedural knowledge)
       └── which reference Tools (capabilities)
            └── connected via MCP (standard protocol)
                 └── feeding the LLM (intelligence)
                      └── within Context Window (working memory)

Three Levels of Freedom

Level 1: Paper Slips (Chat mode)

Intern in the room. Notes in, notes out. No tools.

"Format this." "Explain this error." "Write a regex."

Everyone does this already.

Level 2: Intercom Access (Professional + MCP)

Intern has the intercom. Calls services when you ask.

"Analyze Raygun errors." "Create ADO tasks from this spec."

Where most teams are today.

Level 3: Keys to the Building (Agent mode)

Intern leaves the room. Picks tasks from the board, uses the intercom, handles errors, reports back.

"Monitor deploys, rollback if tests fail." "Auto-review incoming PRs."

The frontier.

All three levels stay relevant — Level 1 for quick questions, Level 2 for daily work, Level 3 for automation.

Chapter 6: Vending Machine, Intern, or Both?

When to Use Deterministic, Non-Deterministic, and Hybrid Approaches

The old world was a vending machine (deterministic). The new world is an intern (non-deterministic). You don't have to choose one. The best systems combine both.

The Spectrum

DETERMINISTIC                     HYBRID                      NON-DETERMINISTIC
(vending machine)              (intern + checklist)              (intern freestyle)
     │                               │                               │
if/else, regex,               LLM decides WHAT to do,        "Figure it out, here's
lookup tables,                code enforces HOW it's done     the goal, good luck"
SQL queries
     │                               │                               │
 Predictable                  Best of both worlds              Creative, flexible
 Testable                     Controlled creativity            Unpredictable
 Brittle                      Robust                           Hard to test

The Decision Framework

Real Scenarios from Our Work

Scenario 1: Parsing ADO work item into subtasks

❌ Pure non-deterministic: "Read this work item and create subtasks." The intern creates random subtask structures every time — different formats, inconsistent estimation scales, sometimes forgets fields.

❌ Pure deterministic: Regex-parse the work item description, extract keywords, create predefined subtask templates. Breaks the moment someone writes the description differently.

✅ Hybrid:

DETERMINISTIC: ADO API fetches work item fields (title, description, acceptance criteria)
NON-DETERMINISTIC: Intern reads the content, reasons about subtask decomposition
DETERMINISTIC: Output schema enforces {title, description, estimate, type} per subtask
DETERMINISTIC: Validation rejects estimates outside [0.5h, 16h] range
DETERMINISTIC: ADO API creates the subtasks

The intern does the thinking. The code does the structure enforcement. You get creative decomposition with predictable output format.

Scenario 2: Code review

❌ Pure deterministic: Linters, static analysis. Catches syntax issues and known patterns. Misses logic bugs, architectural problems, and "this doesn't match how we do things."

❌ Pure non-deterministic: "Review this code." Different results every time. Sometimes catches 10 issues, sometimes 3. No consistency in severity labeling.

✅ Hybrid:

DETERMINISTIC: Linter runs first (ESLint, StyleCop) → catches all mechanical issues
NON-DETERMINISTIC: Intern reviews for logic, architecture, patterns (with a skill!)
DETERMINISTIC: Skill enforces output format (MUST FIX / SHOULD FIX / CONSIDER)
DETERMINISTIC: CI gate — if "MUST FIX" count > 0, block merge

Linter handles what it's good at (100% reliable, instant). The intern handles what requires judgment. The skill constrains the output. The CI gate makes the decision deterministic.

Scenario 3: Test case generation

❌ Pure deterministic: Template-based test generation from API spec. Covers happy path and basic validation. Misses implementation-specific edge cases entirely.

❌ Pure non-deterministic: "Write tests." Inconsistent coverage, sometimes over-tests trivial things, sometimes misses critical paths.

✅ Hybrid:

DETERMINISTIC: Parse OpenAPI spec → generate all endpoint/method/status combinations
NON-DETERMINISTIC: Intern reads the actual code → adds edge cases from implementation
DETERMINISTIC: Merge both lists, deduplicate, validate against test schema
DETERMINISTIC: Convert to Playwright/Jest tests using deterministic templates
NON-DETERMINISTIC: Intern reviews final tests for completeness

Scenario 4: Incident response

❌ Pure deterministic: Alert → PagerDuty → human investigates. Works, but slow. The human is the bottleneck at 3am.

❌ Pure non-deterministic: "Investigate and fix this." Absolutely not for production. The intern might decide a rollback is fine when it isn't.

✅ Hybrid:

DETERMINISTIC: Alert triggers, error data collected automatically
NON-DETERMINISTIC: Intern analyzes logs, identifies probable cause, drafts fix
DETERMINISTIC: Fix goes through existing PR review + CI pipeline
DETERMINISTIC: Deploy requires human approval (the intern proposes, human disposes)

The intern accelerates investigation from 45 minutes to 5 minutes. But the human makes the final call on what ships to production.

The Golden Rule

Use the intern for reasoning. Use code for enforcement.

                    ┌─────────────────┐
  User input  ───▶  │   DETERMINISTIC  │  Validate input, fetch data
                    │   (your code)    │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ NON-DETERMINISTIC│  Reason, analyze, decide, generate
                    │   (the intern)   │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │   DETERMINISTIC  │  Validate output, enforce schema,
                    │   (your code)    │  apply business rules, execute action
                    └─────────────────┘

This is the "sandwich pattern": deterministic bread on both sides, non-deterministic filling in the middle. Your code ensures clean input and safe output. The intern does the thinking in between. Production AI systems work this way, and your Skills should be designed this way.

Chapter 7: Two Management Styles

Codex vs. Claude Code — A Deep Dive

Both Codex (OpenAI) and Claude Code (Anthropic) are coding agents. They give the intern tools and let them write code. They represent two different management philosophies.

The Autonomous Manager (Codex)

Philosophy: "Here's the task. I'll check in later."

You write a task on a card: "Add OAuth login with password reset." You slide it under the intern's door and walk away. The intern works in a soundproof office (cloud sandbox), writes code, runs tests, and when done, puts a finished PR on your desk for review.

┌──────────────────────────────────────────────────┐
│                  CODEX PLATFORM                  │
├──────────────────────────────────────────────────┤
│                                                  │
│  ┌────────────┐  ┌────────────┐  ┌───────────┐  │
│  │  Codex CLI │  │ IDE Plugin │  │ Codex     │  │
│  │  (terminal)│  │ (VS Code)  │  │ Cloud     │  │
│  └─────┬──────┘  └─────┬──────┘  └─────┬─────┘  │
│        └───────────┬───┘───────────────┘        │
│                    │                             │
│  ┌─────────────────▼───────────────────────────┐ │
│  │         RESPONSES API (unified API)         │ │
│  │                                             │ │
│  │  ┌──────────────────────────────────────┐   │ │
│  │  │           GPT-5.4 MODEL              │   │ │
│  │  │  Dynamic reasoning: auto-routes      │   │ │
│  │  │  none → low → med → high → xhigh    │   │ │
│  │  └──────────────────────────────────────┘   │ │
│  │                                             │ │
│  │  Built-in tools:                            │ │
│  │  Web search, file search, shell,            │ │
│  │  computer use (native!), code interpreter   │ │
│  │                                             │ │
│  │  External: MCP servers, Skills, AGENTS.md   │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  Conversation state / Compaction / Prompt cache  │
└──────────────────────────────────────────────────┘

Key architectural decisions:

GPT-5.4 is a convergence model. OpenAI merged separate model families (reasoning models like o3/o4-mini and coding models like Codex) into ONE model that dynamically adjusts how much it "thinks." Simple questions use the fast path; complex debugging uses deep reasoning. Under the hood, GPT-5.4 contains effectively three models in one (main, mini, nano tiers) with a built-in router.

The Codex platform offers three surfaces — CLI, IDE, Cloud — all hitting the same API. Codex Cloud is the most differentiated: you delegate entire features to a cloud sandbox. The agent clones your repo, creates a branch, makes changes, runs tests, opens a PR — all without you watching.

The Pair-Programming Manager (Claude Code)

Philosophy: "Walk me through your thinking."

You sit next to the intern's desk. They think out loud, show you their reasoning at each step, ask "should I go left or right here?" You steer in real-time.

┌──────────────────────────────────────────────────┐
│              CLAUDE CODE PLATFORM                │
├──────────────────────────────────────────────────┤
│                                                  │
│  ┌────────────┐  ┌────────────┐  ┌───────────┐  │
│  │ Claude Code│  │ VS Code /  │  │ Claude.ai │  │
│  │  CLI       │  │ JetBrains  │  │ (Cowork)  │  │
│  └─────┬──────┘  └─────┬──────┘  └─────┬─────┘  │
│        └───────────┬───┘───────────────┘        │
│                    │                             │
│  ┌─────────────────▼───────────────────────────┐ │
│  │          MESSAGES API (unified API)         │ │
│  │                                             │ │
│  │  ┌──────────────────────────────────────┐   │ │
│  │  │       CLAUDE OPUS 4.6 MODEL          │   │ │
│  │  │  Extended Thinking (visible!)         │   │ │
│  │  │  Interleaved thinking (think between  │   │ │
│  │  │  tool calls — Claude 4+ feature)      │   │ │
│  │  │  Adaptive: low → medium → high        │   │ │
│  │  └──────────────────────────────────────┘   │ │
│  │                                             │ │
│  │  Built-in tools (5 categories):             │ │
│  │  Read, Write, Execute, Browse, Orchestrate  │ │
│  │                                             │ │
│  │  External: MCP servers, Skills, CLAUDE.md   │ │
│  │  Hooks (pre/post tool execution)            │ │
│  │  Agent Teams (parallel instances)           │ │
│  └─────────────────────────────────────────────┘ │
│                                                  │
│  Compaction / Context editing / Prompt caching   │
└──────────────────────────────────────────────────┘

Key architectural decisions:

Claude Code's philosophy is an "agentic harness." The model is the brain. Claude Code is the body. Three phases per task: gather context → take action → verify results, blending in a loop.

Interleaved thinking is the differentiator. Claude 4+ models think between tool calls. After getting a tool result, the model reasons about it BEFORE deciding what to do next. Earlier models had to finish all thinking before tool use.

Agent Teams (Feb 2026): Spawn 4-16 Claude instances working in parallel on a shared codebase, each with a different role. A lead agent coordinates. The C compiler experiment: 16 agents, 2,000 sessions, 2 billion input tokens, $20,000 → 100,000 lines of production Rust code.

The Agentic Loops Side by Side

Codex's Loop:

You: "Fix the auth bug in the login module"
  │
  ▼
1. LOAD CONTEXT
   System prompt + AGENTS.md + Skills matched
   Reasoning level auto-selected (detects "hard" → high)
  │
  ▼
2. PLAN (reasoning tokens — internal)
   "I need to find the login module, read the auth flow,
    identify the bug, write a fix, run tests."
   [GPT-5.4 auto-decides depth per turn. Simple fix?
    Nano-tier. Race condition? Full reasoning.]
  │
  ▼
3. EXECUTE (tool calls)
   → shell: find . -name "*.ts" | grep "login"
   → file_read: src/auth/login.ts
   → file_edit: src/auth/login.ts (applies patch)
   → shell: npm test -- --grep "login"
   [If context fills → COMPACTION → continues seamlessly]
  │
  ▼
4. VERIFY
   Tests pass? → Done. Open PR.
   Tests fail? → Loop back to step 2.
   [Can iterate 7-24 hours autonomously]

Claude Code's Loop:

You: "Fix the auth bug in the login module"
  │
  ▼
1. GATHER CONTEXT
   System prompt + CLAUDE.md + Skills matched
   Git state, project structure scanned
  │
  ▼
2. THINK (extended thinking — VISIBLE to you)
   <thinking>
     The user wants me to fix an auth bug.
     Let me search for login-related files...
   </thinking>
  │
  ▼
3. ACT + THINK (interleaved!)
   → grep: "login" across project
   ← results
   <thinking>Found 3 files. session.ts looks relevant...</thinking>
   → view: src/auth/session.ts
   ← file content
   <thinking>I see the bug — token not being refreshed...</thinking>
   → edit: src/auth/session.ts
   → bash: npm test
   ← 2 tests fail
   <thinking>Need to fix the mock setup...</thinking>
   → edit: test/auth.test.ts

   This THINK-ACT-THINK-ACT pattern is unique to Claude 4+.
  │
  ▼
4. VERIFY
   Tests pass? → Show diff for approval.
   Tests fail? → Adjusts approach.
   You can interrupt ANY time to steer.

How They "Think" — Reasoning Architectures

GPT-5.4: The Auto-Router

GPT-5.4 contains a built-in intelligence router:

User query arrives
       │
  ┌────┴──────────┬────────────┐
  ▼               ▼            ▼
┌──────┐    ┌──────────┐   ┌────────┐
│ NANO │    │   MINI   │   │  FULL  │
│ tier │    │   tier   │   │ reason │
│      │    │          │   │        │
│93.7% │    │ Moderate │   │ 2x more│
│fewer │    │ tasks    │   │thinking│
│tokens│    │          │   │tokens  │
└──────┘    └──────────┘   └────────┘

Bottom 10% of turns use 93.7% fewer tokens. Top 10% think 2x longer. You can override with reasoning.effort: none/low/medium/high/xhigh.

Claude Opus 4.6: Adaptive Thinking

User query arrives
       │
       ▼
┌─────────────────────────┐
│   ADAPTIVE THINKING     │
│   (model reads context  │
│    to decide budget)    │
└───────┬─────────────────┘
       │
       ▼
┌─────────────────────────┐
│ EXTENDED THINKING BLOCK │
│ <thinking>              │
│   Visible to developers │
│   Interleaved with tools│
│ </thinking>             │
│                         │
│ Previous thinking blocks│
│ STRIPPED from future    │
│ turns (saves desk space)│
│ EXCEPT during tool-use  │
│ cycles                  │
└─────────────────────────┘

Control with /effort: low/medium/high. At medium effort, Opus 4.6 matches Sonnet 4.5's SWE-bench with 76% fewer output tokens.

The practical difference:

Codex is a senior engineer who goes away, works on the problem, and comes back with a solution. Claude Code is a pair programmer who narrates their thinking out loud. Both produce excellent code. Claude's approach is more transparent during execution.

Compaction: When the Desk Gets Full

Both platforms independently solved the same problem: how to work on tasks that exceed the context window.

A complex refactor might use 115,000+ tokens of context, growing with every turn. Without compaction, the agent hits the desk limit and stops.

The solution (both platforms):

Turns 1-15: Normal operation, desk fills up
                     │
                     ▼
Turn 16: COMPACTION TRIGGERED
         The intern summarizes their own work:
         "I'm refactoring the auth module.
          Done: fixed session.ts, updated 3 tests.
          Next: fix remaining test mock."
                     │
                     ▼
Turn 17: FRESH DESK
         [system + summary + current files]
         Intern continues where they left off.
         Can repeat multiple times.

The intern writes commit messages for their own work. When the desk gets cluttered, they write a summary, clear the desk, and keep going. The AI equivalent of going home, sleeping, and picking up from your notes in the morning.

Multi-Agent: The Team of Interns

Codex: Experimental multi-agent. Launch parallel tasks, each runs in Codex Cloud sandbox. Results merge via PR workflow.

Claude Code Agent Teams (more mature):

Lead Intern (you interact with this one)
    │
    ├── Intern 1: "Analyze auth module"
    │   └── Own desk, own tools, own thinking
    │
    ├── Intern 2: "Analyze database layer"
    │   └── Works in parallel with Intern 1
    │
    ├── Intern 3: "Analyze API endpoints"
    │   └── Independent desk and tools
    │
    └── Intern 4: "Cross-reference findings"
        └── Reads output from 1-3, synthesizes

All share the same codebase (building).
Each has their own desk (context window).
Lead intern coordinates and synthesizes.

The C Compiler benchmark: 16 interns, 2 weeks, $20,000, 100,000 lines of Rust that compiles the Linux kernel. One intern "cheated" by calling GCC when it couldn't solve a problem. Very intern behavior.

Head-to-Head Comparison

The Model Evolution Race

OPENAI (7 models in 6 months):
──────────────────────────────────
Sep 2025: GPT-5-Codex          (first dedicated)
Oct 2025: GPT-5-Codex-Mini     (cost-efficient)
Nov 2025: GPT-5.1-Codex        (improved)
Nov 2025: GPT-5.1-Codex-Max    (first compaction)
Dec 2025: GPT-5.2-Codex        (long-horizon)
Feb 2026: GPT-5.3-Codex        (most capable coding)
Mar 2026: GPT-5.4              (converged model)

ANTHROPIC (fewer releases, bigger jumps):
──────────────────────────────────
May 2025: Claude 4 (interleaved thinking)
Sep 2025: Claude Sonnet 4.5 (top SWE-bench)
Oct 2025: Agent Skills launched
Feb 2026: Claude Opus 4.6 (Agent Teams, 1M context)

When to Use Which

Chapter 8: The Messenger App

OpenClaw — The Intern Gets WhatsApp

What Is OpenClaw?

Someone connected the intercom system (MCP), the instruction manuals (Skills), and the intern's brain (LLM) to a WhatsApp/Telegram/Slack interface. Now you can text the intern from your phone.

"Hey, what broke in production?" The intern uses the intercom to check Raygun, reads K8s logs, searches GitHub, and texts you back. 24/7, from your phone, while you're at breakfast.

How It Maps to Our Analogy

Why It Went Viral

1. Simple memory. Notes stored as Markdown. No vector DBs. Readable, editable, grep-able.
2. Self-improving. The intern discovers gaps in its manuals and writes new ones.
3. Familiar interface. Text it like a colleague on WhatsApp or Telegram.
4. Models got smart enough. Claude Opus 4 and GPT-5 chain tools reliably. AutoGPT (2023) failed because the intern wasn't ready.

Security Concerns

The analogy gets darker here:

• Broad permissions. Email, calendar, code repos all accessible to the intern.
• Prompt injection. Malicious instructions hidden in data the intern reads.
• 800+ malicious skills found on ClawHub (Cisco research). Instruction manuals that steal data instead of helping.
• "If you can't run a command line, this is too dangerous for you." An actual quote from the community.

The intern has the keys to the building. Make sure the building has alarms.

Chapter 11: Writing Better Notes

Prompt Engineering in 60 Seconds

The intern is only as good as the notes you slide through the slot. Six rules:

1. Be Specific, Not Vague — "Refactor the authentication middleware to use async/await with proper error handling, following our existing pattern in loggingMiddleware.ts" beats "help with code."

1. Give Context — "I'm working on ADO #4521. The goal is adding pagination. Here's what we have now: [paste current code or say 'read it from GitHub']."

1. Show Examples — "Here's how we format PR descriptions: [example]. Now write one for my changes."

1. Say What You DON'T Want — "Don't use any external libraries. Don't change the existing API contract. Don't modify the database schema."

1. Ask for the Thinking — "Before writing code, explain your approach and what edge cases you see." This catches misunderstandings before the intern writes 200 lines of wrong code.

1. Break Big Tasks into Steps — Instead of "build the entire feature," say "Step 1: Read the spec. Step 2: Propose the approach. Step 3: Implement. Step 4: Write tests. Check in with me after each step."

The Prompt Template That Works

CONTEXT: [What you're working on, link to ADO item]
CODEBASE: [Which repo/folder to look at]
TASK: [Exactly what you want done]
CONSTRAINTS: [What NOT to do, patterns to follow]
OUTPUT: [What you expect back — code, explanation, test cases, etc.]

Example:

CONTEXT: ADO #4521 — adding cursor-based pagination to products API
CODEBASE: Check ProductsController.cs and OrdersController.cs (pagination reference)
TASK: Implement pagination on GET /api/products matching our existing pattern
CONSTRAINTS: Don't change the response schema for existing fields.
             Use cursor-based, not offset-based. Max page size = 100.
OUTPUT: Implementation code + unit tests + PR description

Chapter 12: Best Practices for Daily Work

Treating the Intern Right So They Do Their Best Work

You know what the intern can do. Now: how to work with them day-to-day for great results instead of hit-or-miss guesses.

The Desk Size Sweet Spot (Context Window Management)

Everything (your question, conversation history, system prompt, tool definitions, attached files) must fit on the desk. A bigger desk doesn't mean better work.

The problem with a cluttered desk (and why self-attention is the reason):

The intern doesn't skim top-to-bottom like a human. They use self-attention — for every single token on the desk, they compute a relevance score against every other token. Think of it as the intern drawing an invisible line between every pair of words and asking: "How much does word A matter for understanding word B?"

With 5,000 tokens on the desk, that's 25 million lines to draw. At 100,000 tokens, it's 10 billion lines. This happens across 128 parallel "attention heads" (each specializing in different relationships: syntax, logic, code structure, coreference) across 100+ layers. The math works, but the signal gets diluted. When the intern draws 10 billion relationship lines, the important ones ("this variable is null because that constructor wasn't updated") compete with millions of irrelevant connections. The attention "budget" (which sums to 1.0 via softmax) gets spread across more tokens, meaning each individual token gets a smaller slice of focus.

Example: you paste a 500-line file and ask the intern to find a bug on line 47. With just that file on the desk (~2K tokens), the intern's attention on line 47 is concentrated. It can relate line 47 to every other relevant line. Now paste 20 more files alongside it (~40K tokens). The intern still sees line 47, but allocates attention across 40K tokens. Line 47's share shrinks from ~0.05% to ~0.0025% of the attention budget. The intern is more likely to miss the relationship between line 47 and the DI registration on line 312 of a different file.

Smaller, focused context = sharper attention = better results.

Research shows:

Don't dump your entire codebase into the context "just in case." Give the intern what they need. Five relevant files beat fifty irrelevant ones.

How to right-size the desk:

• Let the intern fetch what they need. Instead of pasting 20 files, say "Read the ProductsController and its related service from GitHub." The intern uses MCP to grab those files. Nothing more.
• Use references, not copies. "Follow the same pattern as OrdersController" + MCP access to the repo is better than pasting the entire OrdersController into the prompt.
• Break big jobs into focused steps. Instead of "refactor these 15 files," say "Start with the data layer. Read the models. Propose changes. Then we'll move to the API layer." Each step has a clean, small desk.
• Watch for compaction. In long sessions, both Claude and Codex compact (summarize) earlier context to free up space. The intern summarizes their own notes. If you notice quality dropping in a long conversation, start a fresh one. Clean desk, focused prompt.

New Conversation vs. Continue (When to Reset the Desk)

One of the most common mistakes: having a 2-hour conversation, getting progressively worse results, and blaming the model.

Start a new conversation when:

• The topic changes significantly. You were reviewing a PR and now want to write a new feature? New conversation. The old PR context is noise on the desk.
• Quality starts dropping. If the intern seems to "forget" instructions or repeat mistakes, the desk is cluttered. Fresh start.
• After compaction. If you see the conversation compress/compact, important details may have been summarized away. Start fresh with a focused prompt.
• Context is over ~80K tokens. This is roughly 40–60 back-and-forth messages with code. Beyond this, you're in the degradation zone.

Continue the conversation when:

• The tasks are related. "Now write tests for the code you just generated." The intern already has the code on the desk.
• You're iterating on output. "Make it handle null inputs too." Keeping context is essential.
• The conversation is still short. Under ~20 messages? Keep going.

Rule of thumb: Treat conversations like browser tabs. Open a fresh one for each distinct task. Don't let a single tab become a 200-page novel.

One Task at a Time (Focused vs. Shotgun Prompts)

Bad: "Review my PR, also check if there are any related bugs in ADO, and while you're at it write release notes and update the wiki."

Good: "Review PR #387. Focus on: error handling, null safety, and test coverage."

The intern can do many things, but attention is finite. Four tasks in one prompt means the intern allocates ~25% of reasoning capacity to each. One task gets 100%. The quality difference is stark, especially for deep-thinking tasks like code review.

Exception: Simple factual multi-part questions ("status of items #101, #102, and #103?") are fine batched. The intern isn't reasoning, just fetching.

Show, Don't Tell (Examples Beat Instructions)

The intern learns patterns faster than rules. Compare:

Instruction-based: "Write commit messages using conventional commit format with a type prefix, scope in parentheses, and a concise description."

Example-based:

Write commit messages like these:
  feat(auth): add OAuth2 support for GitHub login
  fix(api): handle null response from payment gateway
  refactor(db): extract connection pooling into shared module

Now write a commit message for my changes.

The second approach works better because the intern's core skill is pattern recognition, trained on trillions of examples. Showing 2–3 examples activates the right pattern more reliably than a paragraph of rules. This is few-shot prompting, and it works for code style, PR descriptions, test formats, documentation templates.

Build a team skill (SKILL.md) that includes your examples. Every team member gets the same patterns without retyping them.

Temperature and Sampling: When to Tune

Most tools pick sensible defaults, but knowing when to adjust helps:

In Claude Desktop and Codex: You don't control temperature directly. The tools choose based on the task. Knowing this helps you understand why the intern sometimes gives different answers to the same question (temperature > 0), and why code generation is rock-solid (temperature ≈ 0).

Verify, Don't Trust (The Human-in-the-Loop)

The intern is smart but not infallible.

• Review generated code before merging. The intern writes plausible code that may have subtle bugs, especially around edge cases, concurrency, and security.
• Run tests. If the intern generates tests, run them. If they fail, the intern can fix them, but you verify the fix makes sense, not just that it passes.
• Check facts against tools. If the intern says "build #1847 succeeded," verify in Azure DevOps. The intern can hallucinate tool results if the MCP connection failed silently.
• Use the sandwich pattern. From Chapter 6: wrap LLM output in deterministic validation. Generated SQL? Run EXPLAIN before executing. Generated API endpoint? Test it against your contract tests.

The intern drafts, you approve.

Cost Awareness (Tokens = Money)

Every token costs real money. Smart habits save budget:

• Don't paste entire files when the intern can read them via MCP. Pasting a 2,000-line file into the prompt costs input tokens every message. Letting the intern read it via MCP costs tokens once, and only the relevant parts stay in context.
• Use prompt caching. If you have a system prompt + SKILL.md + repo conventions that stay the same across conversations, prompt caching means you pay full price once and ~90% less for subsequent calls. Both Anthropic and OpenAI support this.
• Output tokens cost 3–5x more than input tokens. If you ask for verbose explanations you don't need, you're overpaying. "Give me just the code, no explanation" saves tokens when you don't need the walkthrough.
• Compaction saves money in long sessions. When context gets compressed, subsequent turns process fewer tokens. Both Claude and Codex compact automatically for quality and cost.

Skills as Team Knowledge (Don't Reinvent the Wheel)

Skills are instruction manuals (Chapter 4). Using them as a team:

• Every repeated prompt should become a skill. If you've typed the same code review instructions three times, make a skill. If QA always needs the same test format, make a skill.
• Share skills via your repo. Put them in a /skills folder in your project repo. Everyone on the team gets them automatically.
• Version skills like code. PR reviews for skill changes. "We updated the code review skill to also check for logging." Everyone benefits immediately.
• Layer general + specific. A general "code-review" skill for the whole team, plus "frontend-code-review" that inherits the general one and adds React-specific checks.

The Daily Workflow Cheat Sheet