Claude 5 for Python Developers: What 1M Context Actually Changes

Most coverage of Claude 5's 1M context window focuses on the number. "You can fit 700,000 lines of Python." "Analyze your entire codebase in one prompt."

That's true. It's also not the interesting part.

The interesting part is what 1M context changes about how you prompt. Because the failure mode isn't "the model can't fit your code" — it's "you handed the model 200,000 tokens and got back a three-paragraph summary that didn't actually help you."

Context window and useful output are not the same thing. After six months of prompting Claude 5 with large codebases, here's what I actually learned.

---

What 1M context window means for Python work

Before Claude 5, code review with an LLM meant slicing your code into chunks. You'd pick the file you suspected had the bug, paste it in, and ask the model to look at it. If the bug involved two files interacting — a FastAPI route calling a database helper that relied on a config loaded in a third file — you were either copying all three manually or hoping the model could infer the context from one.

Claude 5 with 1M context means you can paste the entire project. Not just the file — the project.

# This used to be the workflow
with open("api/routes/users.py") as f:
    code = f.read()
prompt = f"Review this code for bugs:\n\n{code}"

# Now the workflow is
import subprocess
result = subprocess.run(
    ["find", ".", "-name", "*.py", "-not", "-path", "./.venv/*"],
    capture_output=True, text=True
)
files = result.stdout.strip().split("\n")
codebase = ""
for path in files:
    with open(path) as f:
        codebase += f"# === {path} ===\n{f.read()}\n\n"

# codebase is now 150,000+ tokens — passes fine into Claude 5

The shift isn't just mechanical. It changes what questions you can ask.

---

Three things that only work at 1M scale

1. Cross-file dependency analysis

"Find all places in the codebase where we pass unsanitized user input into a SQL query — including indirect paths through helper functions."

Before large context, this required either a static analysis tool or manually tracing every call site. Now it's a prompting problem. The model can hold your entire ORM layer, your route handlers, and your helper utilities simultaneously and trace the data flow.

This works well. The caveat: you need to ask for it explicitly and in a format that forces the model to enumerate rather than summarize.

Prompt that works:

You have the entire codebase above. Find all locations where:
1. User input from an HTTP request (query params, request body, path params)
   flows into a database query
2. There is NO explicit parameter binding or ORM usage — raw string interpolation only

For each finding, output:
- File path and line number
- The function name
- The exact code snippet (5 lines of context)
- The input source (where the user data originates)
- Whether it's definitely unsafe, possibly unsafe, or safe-looking but suspicious

If you find none, say explicitly: "No raw SQL injection candidates found."

Prompt that doesn't work:

Review this codebase for SQL injection vulnerabilities.

The second prompt will produce a paragraph explaining what SQL injection is and some general guidance. The first one produces a table you can actually act on.

---

2. Refactoring impact analysis before you commit

The classic Python refactoring problem: you're changing a widely-used utility function. You want to know every call site, every place that depends on the current signature, and every test that will break.

At 1M context:

I'm changing this function:

python
def parse_timestamp(ts: str) -> datetime:
return datetime.strptime(ts, "%Y-%m-%dT%H:%M:%SZ")

New signature:

python
def parse_timestamp(ts: str, tz: timezone = timezone.utc) -> datetime:
...

Review the entire codebase above and list:
1. Every call site for parse_timestamp — file path + line number + current call signature
2. Which call sites pass a second argument (will break)
3. Which test files include parse_timestamp assertions (will need updating)
4. Any place that imports and re-exports parse_timestamp

plaintext

You get back a complete impact assessment. Zero-context answer for a 30-file codebase takes 90 seconds of manual grepping. Prompted answer takes 10 seconds.

---

3. Architecture consistency audits

"Does this codebase actually follow the patterns we said we'd follow?"

Large teams write architecture decisions. Six months later, three developers have each interpreted the decisions differently. Before large context, auditing this meant a code review checklist and manual spot-checking.

Review the codebase for consistency against these architectural decisions:
1. All database operations go through repository classes — never raw ORM queries in route handlers
2. API responses are always serialized through Pydantic response models — no dict() calls in routes
3. Configuration is accessed only through the Config class — no direct os.environ access

For each rule, list:
- COMPLIANT: files following the rule
- VIOLATION: file + line + what the violation is
- UNCLEAR: ambiguous cases

Be exhaustive. Don't summarize — enumerate every instance.

markdown

This produces the kind of output a senior engineer would spend an afternoon producing manually.

---

Why bigger context requires more structured prompts, not fewer

Here's the counterintuitive finding: at 1M context, vague prompts get worse, not better.

With a 200-line file, "review this code" produces specific feedback because there's not much to summarize. The model has to engage with the code.

With a 150,000-token codebase, "review this code" gives you a high-level summary of what the codebase does and three general suggestions. The model optimizes for a concise, readable response. Your 150K tokens are visible to the model — but without a structured ask, the response collapses back to a few paragraphs.

The fix is forcing the model into enumeration mode:

• Specify output format: "For each issue, output: file path, line number, the problem, and a concrete fix."
• Prohibit summaries: "Do not summarize. Do not provide general guidance. List specific instances only."
• Set a minimum bar: "If you find fewer than 5 issues, you probably haven't looked carefully enough. Look again."
• Confirm negative results explicitly: "If you find none, say 'No issues found in this category' — don't omit the category."

The prompts in this post aren't accidental. They're patterns I iterated on for months. Most of the prompts in the AI Dev Toolkit were written and refined with exactly this in mind — they produce consistent, structured output at scale, whether you're reviewing a 50-line utility function or a 50-file FastAPI backend.

---

The practical workflow for codebase analysis

Here's how I actually run cross-codebase analysis with Claude 5 via the Python SDK:

import anthropic
from pathlib import Path

def load_codebase(root: str, extensions: list[str] = [".py"]) -> str:
    """Load all source files, respecting .gitignore patterns."""
    chunks = []
    for path in sorted(Path(root).rglob("*")):
        if path.is_file() and path.suffix in extensions:
            # Skip common non-source dirs
            parts = path.parts
            if any(x in parts for x in [".venv", "__pycache__", ".git", "dist", "build"]):
                continue
            try:
                content = path.read_text(encoding="utf-8", errors="ignore")
                chunks.append(f"# === {path} ===\n{content}")
            except Exception:
                pass
    return "\n\n".join(chunks)


def analyze_codebase(root: str, question: str) -> str:
    codebase = load_codebase(root)

    client = anthropic.Anthropic()

    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=4096,
        messages=[
            {
                "role": "user",
                "content": f"Below is a complete Python codebase.\n\n{codebase}\n\n---\n\n{question}"
            }
        ]
    )
    return response.content[0].text


# Example: find all places that bypass authentication
result = analyze_codebase(
    root="./src",
    question="""
    Find every HTTP route handler in this codebase that does NOT apply authentication.

    For each one, output:
    - File path and line number
    - The route path and HTTP method
    - Why you believe it lacks authentication (no dependency, no decorator, etc.)

    Routes that are intentionally public (health checks, OAuth callbacks) — note them separately.
    Do not summarize. List every instance.
    """
)
print(result)

For a 20-file FastAPI project, this runs in under 15 seconds and costs roughly $0.15 with Sonnet 5. For a 100-file project, roughly $0.60.

---

What doesn't change: the model still hallucinates at scale

One thing 1M context doesn't fix: the model will still confidently describe code that doesn't exist if you prompt poorly.

Specific failure modes I've hit:

• Fabricated line numbers: the model says "line 47 of users.py" but the issue is on line 89
• Summarized findings: asked for every call site, got "several places in the routes directory"
• Confident false negatives: "No SQL injection candidates found" followed by me finding one manually

The mitigations are the same as always:

1. Ask for code snippets, not line numbers — snippets are verifiable
2. Require exhaustive lists, not summaries
3. Verify before acting on security-critical findings

Large context shifts the ratio — you get fewer hallucinations about code the model actually has in context vs. code it's inferring. But it doesn't eliminate them.

---

Where this fits in a real dev workflow

The use cases that work best at 1M context are the ones where manual effort scales with codebase size but model effort doesn't:

Task	Manual effort	Claude 5 effort
Find all SQL injection candidates	Scales with codebase	Roughly constant
Trace a data flow across files	Scales with file count	Roughly constant
Audit architecture consistency	Scales with team size	Roughly constant
Refactoring impact analysis	Scales with call sites	Roughly constant
Debug a single function	Already fast	About the same
Write new code	Already fast	About the same

The 1M window is a force multiplier for analysis and audit tasks — things that were previously either expensive (senior engineer time) or tooling-dependent (build a custom linter). For greenfield development, you were already fast.

---

The prompt library angle

Everything I've written above requires prompting discipline that takes time to develop. After six months of iterating on codebase-scale prompts, I packaged the patterns that actually worked: 272 prompts organized by task type — code review, API design, security audit, refactoring, debugging, performance analysis.

They were all written for Python/backend work specifically, tested against real codebases of various sizes, and refined until they produced consistent, structured output rather than summaries.

With Claude 5's 1M context, the code review and security audit prompts now work against your entire codebase in a single pass. That's what "structured prompts at scale" looks like in practice.

AI Dev Toolkit — 272 Python developer prompts ($29)

---

Peyton Green is a Python backend developer. This is part of an ongoing series on AI-augmented Python development workflows.