Gemini 2.5 made long context feel operational

Gemini 2.5 Pro made long context feel like an operational choice.

The useful shift was not “send a huge prompt.” It was deciding what belongs in a working set, what stays out, how much reasoning to spend, and when retrieval remains the better tool.

A repository makes the distinction concrete:

{
  "task": "update auth callback behavior",
  "context_strategy": "large_curated_context",
  "sources": [
    { "path": "src/routes/auth/callback.ts", "role": "target" },
    { "path": "src/lib/session.ts", "role": "dependency" },
    { "path": "tests/auth/callback.test.ts", "role": "verification" },
    { "path": "docs/auth-flow.md", "role": "domain_context" }
  ],
  "excluded": [
    { "path": "dist/", "reason": "generated" },
    { "path": ".env", "reason": "secret" }
  ]
}

That manifest explains why this slice belongs in context and keeps omissions visible. If the answer is wrong, review can ask whether the callback, session helper, tests, or docs were missing. “The model saw a lot of code” is not a useful diagnosis.

For a real task, I want a small but complete working set:

target: src/routes/auth/callback.ts
dependencies: src/lib/session.ts, src/lib/oauth/*
verification: tests/auth/callback.test.ts
domain context: docs/auth-flow.md
excluded: dist/, .env, generated files

Long context is useful when the question depends on keeping source material together. Retrieval is better when the material is too large, stale, sensitive, or expensive to carry whole.

A planner should be able to reject noise. More capacity does not make generated bundles, irrelevant logs, or secrets appropriate input. The operational win is structure around the window, not the token count alone.