Module 2: How LLMs Work (What You Need to Know as a Developer)
What LLMs Can and Cannot Do
Description
After understanding tokens, context windows, next-token prediction, and hallucinations, this capsule synthesizes everything into something directly practical: on which tasks can you trust an LLM and on which can't you?
The answer isn't "trust everything" or "trust nothing." It's a nuanced map that lets you calibrate your confidence based on the task. This map connects directly with the trust calibration from Module 05 and the R→P→E→V workflow from Module 06.
The Mental Model: Pattern Matching vs Understanding
What LLMs really do
LLMs DO PATTERN MATCHING AT MASSIVE SCALE.
They've processed trillions of tokens of:
→ Code in all popular languages
→ Technical documentation
→ Stack Overflow, GitHub, technical blogs
→ Academic papers
→ Books, articles, conversations
When you generate code, the model:
→ Recognizes the PATTERN of what you're asking for
→ Generates the most PROBABLE continuation of that pattern
→ Based on the millions of similar examples it has seen
THIS IS NOT "UNDERSTANDING":
→ It doesn't comprehend why the code works
→ It doesn't reason about correctness like a human
→ It doesn't have a mental model of your system
→ It doesn't understand the intent behind the requirements
When pattern matching is enough
PATTERN MATCHING WORKS when:
→ The pattern is common (many examples in the training data)
→ The task is standard (CRUD, boilerplate, design patterns)
→ The context is clear (the prompt has enough information)
→ Correctness is easily verifiable (tests, compilation)
PATTERN MATCHING FAILS when:
→ The pattern is rare or unique
→ The task requires reasoning about global state
→ The context is ambiguous or incomplete
→ Correctness requires domain knowledge
The medical student analogy
Imagine a student who has MEMORIZED 10 million clinical cases.
→ If you show them common symptoms: they diagnose correctly
(It's a pattern they've seen thousands of times)
→ If you show them symptoms of a rare disease: they may fail
(They don't have enough patterns to compare)
→ If you show them a case that combines two diseases: they may get confused
(The combined pattern is infrequent)
→ They don't "understand" medicine — they recognize patterns of symptoms and diagnoses
An LLM works the same way with code:
→ Common patterns → excellent
→ Rare combinations → prone to errors
→ It doesn't "understand" programming → it recognizes code patterns
What LLMs Are Good At
Level 1: Excellent (high reliability)
BOILERPLATE AND SCAFFOLDING
→ Creating the structure of a new project
→ Generating configuration files (tsconfig, eslint, etc.)
→ Writing imports, exports, and basic setup
→ Creating the structure of classes/components
WHY:
→ They're extremely common patterns
→ Thousands of examples in the training data
→ Almost no "creative" variation needed
→ Verifiable immediately (it compiles or it doesn't)
EXAMPLE: "Create an Express project with TypeScript,
with the standard folder structure"
→ Result: predictable and correct 95%+ of the time
KNOWN DESIGN PATTERNS
→ Singleton, Factory, Observer, Strategy
→ Middleware chains, error handling
→ React component patterns (hooks, HOC)
→ CRUD operations
WHY:
→ They're extensively documented and taught patterns
→ The training data has thousands of implementations
→ There's little ambiguity in the implementation
EXAMPLE: "Implement an error handling middleware
in Express following the standard pattern"
→ Result: predictable and correct 90%+ of the time
CODE TRANSFORMATIONS
→ Converting between languages (Python ↔ JavaScript)
→ Mechanical refactoring (rename, extract function)
→ Converting formats (JSON ↔ YAML ↔ XML)
→ Updating syntax (var → let/const, callbacks → async/await)
WHY:
→ They're transformations with clear rules
→ The model has seen both formats side by side
→ The pattern matching is direct
EXAMPLE: "Convert this callback function to async/await"
→ Result: generally correct if the function is standard
Level 2: Good (moderate reliability)
IMPLEMENTATION OF STANDARD FEATURES
→ JWT authentication (basic pattern)
→ CRUD with an ORM (Prisma, TypeORM, SQLAlchemy)
→ Basic REST APIs
→ Forms with validation
WHY:
→ Well-established patterns but with more variation
→ Depends on the version of the libraries
→ May require adaptation to the existing codebase
CAUTION:
→ Verify API versions
→ Check that it integrates with your codebase
→ Security review for auth
CODE EXPLANATION
→ "What does this function do?"
→ "Explain this regex"
→ "Why might this code fail?"
WHY:
→ The model recognizes code patterns effectively
→ It can describe what a pattern does without "understanding it"
→ Generally accurate for standard code
CAUTION:
→ For very complex code, the explanation can be superficial
→ For code with subtle bugs, it may not detect the problem
→ "Explain" ≠ "verify correctness"
WRITING TESTS
→ Unit tests for pure functions
→ Basic integration tests
→ Test fixtures and mocks
WHY:
→ Tests follow very repetitive patterns
→ describe/it/expect is a template the model handles well
→ It generates good coverage of basic cases
CAUTION:
→ It may not cover the domain's edge cases
→ The mocks may not reflect the real behavior
→ Check that the tests actually test what matters
Level 3: Variable (low reliability)
SPECIFIC BUSINESS LOGIC
→ Financial calculations (taxes, interest)
→ Complex business rules
→ Domain-specific algorithms
→ Compliance and regulations
WHY IT FAILS:
→ The model doesn't know YOUR domain
→ The business rules aren't in the general training data
→ The "almost right" problem: it looks correct but omits rules
EXAMPLE:
"Calculate income tax for an employee in Mexico"
→ The model generates something that LOOKS correct
→ But it probably omits updated tables, deductions,
subsidies, and specific rules
→ Confidence: LOW — requires verification by an expert
ARCHITECTURE AND DESIGN DECISIONS
→ "Should I use microservices or a monolith?"
→ "Which database is best for my case?"
→ "How should I structure this system?"
WHY IT FAILS:
→ There's no ONE correct answer
→ It depends on context the model doesn't have
→ The model gives "average" answers that are generic
→ It doesn't consider YOUR specific constraints
CORRECT USE:
→ As input for your decision, not as the decision itself
→ "Give me pros and cons" → useful
→ "Tell me what to do" → dangerous
DEBUGGING COMPLEX PROBLEMS
→ Race conditions
→ Subtle memory leaks
→ Integration bugs between systems
→ Non-obvious performance problems
WHY IT FAILS:
→ It requires understanding STATE over time
→ The model sees static code, not dynamic execution
→ It can't "run" complex scenarios mentally
→ Pattern matching isn't enough for dynamic state
Level 4: Poor (don't trust)
SECURITY
→ Critical authentication code
→ Handling encryption/hashing
→ Preventing vulnerabilities (OWASP Top 10)
→ Managing secrets and permissions
WHY NOT TO TRUST:
→ The training data includes INSECURE code (tutorials, examples)
→ The most "probable" pattern can be the insecure one
→ Veracode 2025: 45% of AI code has vulnerabilities
→ A security error can be catastrophic
RULE: AI-generated security code ALWAYS
requires a complete review by someone who understands security.
GLOBAL STATE AND SIDE EFFECTS
→ Complex database migrations
→ Operations that affect multiple systems
→ Code that depends on the order of execution
→ Concurrency and parallelism
WHY NOT TO TRUST:
→ The model doesn't have a mental model of the global state
→ It sees individual files, not the complete system
→ It can't predict side effects between components
→ Pattern matching fails with complex interactions
The "Almost Right" Problem
The most insidious problem
THE MOST DANGEROUS ERROR ISN'T THE ONE THAT CLEARLY FAILS.
IT'S THE ONE THAT LOOKS CORRECT.
Stack Overflow Developer Survey 2025:
→ 66% of developers report that AI code
is "functional but requires modifications"
→ "Almost right" = works in the demo, fails in production
EXAMPLES:
→ Email validation that accepts 99% of valid emails
but rejects "user+tag@domain.co"
→ Rate limiting that works with one server but not with a cluster
→ Auth that works over HTTP but doesn't handle HTTPS redirect
→ Query that works with 100 records but times out with 1M
Why "almost right" is worse than "wrong"
CLEARLY INCORRECT CODE:
→ Doesn't compile → you detect it immediately
→ Crash at runtime → you detect it quickly
→ The fix is clear: rewrite
"ALMOST RIGHT" CODE:
→ Compiles → ✅ (looks fine)
→ Basic tests pass → ✅ (looks fine)
→ Works in the demo → ✅ (looks fine)
→ Fails in production with real data → ❌ (expensive to fix)
→ Finding the bug is hard (the code "looks" correct)
→ The fix may require a redesign
COST OF "ALMOST RIGHT":
→ It gets further in the pipeline → more expensive to fix
→ It generates false confidence → the pattern repeats
→ Debugging is harder (there's no obvious error)
Confidence Calibration Framework
The task × confidence matrix
TASK CONFIDENCE VERIFICATION
──────────────────────────────────────────────────────────
Boilerplate / scaffolding HIGH Light
Design patterns HIGH Light
Code transformations HIGH Light
CRUD / basic APIs MODERATE Focused
Unit tests MODERATE Focused
Code explanation MODERATE Focused
Business logic LOW Complete
Architecture LOW Complete (+ human)
Complex debugging LOW Complete
Security VERY LOW Complete + review
Global state VERY LOW Complete + review
How to use this matrix
1. IDENTIFY the type of task
2. LOOK AT the confidence column
3. APPLY the corresponding level of verification
HIGH CONFIDENCE + LIGHT VERIFICATION:
→ Accept with a quick review
→ Run existing tests
→ Verify that it compiles
MODERATE CONFIDENCE + FOCUSED VERIFICATION:
→ Review the code's decision points
→ Run specific tests
→ Verify integration
LOW CONFIDENCE + COMPLETE VERIFICATION:
→ Read every line of code
→ Write edge case tests
→ Verify against the documentation/spec
VERY LOW CONFIDENCE + REVIEW:
→ All of the above
→ ADDITIONALLY: review by someone with expertise in the area
→ NEVER accept without review for security
What Will Improve and What Won't
What improves with each generation of models
IMPROVING:
→ Context window size (more code it can process)
→ Reasoning capacity (more powerful chain-of-thought)
→ Fewer hallucinations in common patterns
→ Better comprehension of complex code
→ Better instruction following
EVIDENCE:
→ GPT-3 (2020) → GPT-4 (2023) → GPT-4.5 (2025):
dramatic improvement in code quality
→ Claude 2 → Claude 3 → Claude 4:
significant improvement in reasoning
→ The coding benchmarks improve every generation
What probably won't improve soon
FUNDAMENTAL LIMITATIONS:
→ Next-token prediction is probabilistic (not deterministic)
→ There's no real "comprehension" of the code
→ The training data will always have a cutoff
→ The context window will always be finite
→ It can't run code mentally
→ It can't reason about dynamic state reliably
THIS MEANS:
→ The principles of this guide will remain relevant
→ Verification will still be necessary
→ Trust calibration will still be necessary
→ R→P→E→V will still be the correct workflow
→ The developer as director isn't going to change
Practical Exercise
Exercise 1: Classify your tasks
Think about the last 10 tasks you did with AI and classify them:
TASK 1: _______________
→ Confidence: □ High □ Moderate □ Low □ Very low
→ Was the result correct? □ Yes □ Almost right □ No
→ Did you verify appropriately? □ Yes □ No
[repeat for each task]
PATTERN:
→ On which tasks do you trust too much? _______________
→ On which tasks do you distrust more than necessary? ___________
→ Does your verification level match the risk? ___________
See guided reflection
Common patterns developers discover:
-
Overconfidence in business logic: Many accept business-rule code without complete verification because "it looks correct." This is the most dangerous (the "almost right" problem).
-
Excessive distrust of boilerplate: Some review configuration or basic CRUD code line by line, which the model generates correctly 95% of the time. This wastes verification time that should go to higher-risk areas.
-
Uniform verification: The most frequent error is applying the same level of review to everything. This capsule's task × confidence matrix gives you a guide: light verification for boilerplate, complete for business logic, and complete + review for security.
-
Key question: Are you investing your review time proportionally to the risk? If you spend 10 minutes reviewing imports and 2 minutes reviewing auth logic, the proportion is inverted.
Exercise 2: The "almost right" test
Ask the model to implement a function you know well:
FUNCTION: _______________________________________________
1. Does the generated code work with the basic case? □ Yes □ No
2. Test it with 5 edge cases you come up with:
Edge case 1: ___________ → □ Works □ Fails
Edge case 2: ___________ → □ Works □ Fails
Edge case 3: ___________ → □ Works □ Fails
Edge case 4: ___________ → □ Works □ Fails
Edge case 5: ___________ → □ Works □ Fails
Is it "almost right"? _______________
Which edge cases were missing? _______________
See solution
Expected result:
The most likely outcome is that the code works with the basic case but fails on at least 1-2 edge cases. Typical examples where the model fails:
- Empty or null inputs:
"",None,[],0 - Extreme values: Very large numbers, very long strings, lists with millions of elements
- Special characters: Unicode, emojis, control characters, leading/trailing spaces
- Unexpected types: Passing an integer where a string is expected, or vice versa
- Concurrency: If the function is called simultaneously from multiple threads
The "almost right" pattern: The model generates the most frequent implementation in the training data, which usually covers the happy path. Edge cases require domain knowledge and adversarial thinking that the model doesn't apply by default.
Takeaway: Always test with at least 3-5 edge cases before accepting AI-generated code, especially for business-logic functions.
Exercise 3: Create your personal guide
Based on your experience and this module:
TASKS WHERE I TRUST THE LLM:
1. _______________________________________________
2. _______________________________________________
3. _______________________________________________
TASKS WHERE I VERIFY CAREFULLY:
1. _______________________________________________
2. _______________________________________________
3. _______________________________________________
TASKS WHERE I NEVER TRUST WITHOUT REVIEW:
1. _______________________________________________
2. _______________________________________________
3. _______________________________________________
See guided reflection
Reference guide based on the capsule:
Tasks where you can trust (light verification):
- Project boilerplate and scaffolding
- Standard design patterns (CRUD, middleware, hooks)
- Code transformations (mechanical refactoring, format change)
- Conversions between languages for standard code
Tasks where you should verify carefully:
- Features with third-party APIs (verify versions and methods)
- Unit tests (verify they test what matters, not just that they pass)
- Explanations of complex code (the explanation can be superficial)
- Implementations that touch multiple files
Tasks where you should never trust without review:
- Security code (auth, encryption, permissions)
- Business logic specific to your domain
- Database migrations
- Code that handles money, sensitive data, or compliance
Your personal guide should reflect your specific stack and domain. Update it as you gain experience with AI and discover in which areas the model gives you reliable results and in which it doesn't.
Connection with the Rest of the Guide
THIS MODULE gave you the FUNDAMENTALS:
→ Tokens and context windows (input)
→ Next-token prediction (process)
→ Hallucinations (errors)
→ Capabilities and limitations (calibration)
WITH THESE FUNDAMENTALS you'll understand:
→ Module 03: How the LLM becomes an agent (tools + loop)
→ Module 04: Which tools extend the LLM's capabilities
→ Module 05: Why the developer is the circuit breaker
→ Module 06: Why R→P→E→V is necessary
→ Module 07: How to configure an LLM in your mini-agent
Module Summary
MODULE 02: HOW LLMs WORK
Capsule 01: Why understanding LLMs matters for developers
Capsule 02: Tokens and context windows (the "unit" and the "limit")
Capsule 03: Next-token prediction (how it generates, one token at a time)
Capsule 04: Hallucinations (why it invents, kinds of errors)
Capsule 05: Capabilities and limitations (what to trust)
THE CENTRAL MESSAGE:
→ LLMs do pattern matching, they don't "understand"
→ They generate the most PROBABLE, not the most CORRECT
→ They're excellent for common patterns, weak for the specific
→ Verification is mandatory because the model can be "almost right"
→ Your confidence must be calibrated based on the type of task
FOR THE FOLLOWING MODULES:
→ You understand the engine (LLM) — now you'll see the vehicle (agent)
→ You know the limitations — now you'll learn to compensate for them
→ You have the technical foundation — now comes the practice
Resources
- Andrej Karpathy: Intro to LLMs — The best general introduction
- Stack Overflow Developer Survey 2025: AI Section — Industry data on trust and use
- Veracode State of Software Security 2025 — Vulnerabilities in AI-generated code
- Google DORA Report 2025: AI Section — Data on adoption and productivity
- Anthropic Research: Scaling & Capabilities — What improves with each generation
- François Chollet: On the Measure of Intelligence — To understand the difference between pattern matching and intelligence