Context Window Budget for FE Tasks

AI models have a finite context window (32k–200k tokens depending on model). Every token you use on irrelevant file content is a token not available for chain-of-thought reasoning, tool output, or conversation history. More critically: retrieval quality degrades as the window fills with low-relevance content.

The "lost in the middle" effect (Liu et al., 2023) showed GPT-4's recall for facts dropped significantly when those facts were placed in the middle of long contexts. Relevant information buried in a file dump is harder to retrieve than the same information presented alone.

// ❌ Low-signal context: 400-line file dump
// Model has to search for the bug in noise

// ✅ High-signal context: targeted excerpt
// Error: "Cannot read properties of undefined (reading 'map')"
// Stack: ProductList.tsx:47

function ProductList({ products }) {
  return (
    <ul>
      {products.map(p => <li key={p.id}>{p.name}</li>)} {/* line 47 */}
    </ul>
  );
}

// Called from: Dashboard.tsx — products comes from useProducts() hook
// useProducts returns: { data, isLoading, error } from React Query
// Question: why is products undefined on first render?

This context is 12 lines — enough for the model to diagnose that products is undefined before React Query resolves, and suggest products ?? [] as a default.

What went wrong technically: the model's 10,000-line paste used most of the context window before the actual question even started. The relevant function was on line 4,847 — roughly in the middle of the context. The "lost in the middle" effect (Liu et al., 2023) shows that retrieval accuracy for facts placed in the middle of long contexts drops significantly compared to facts placed at the start or end. The bug was there — but positionally disadvantaged. The model's attention was spread across thousands of unrelated lines.

The curated context for his bug report looked like this: error message (3 lines), the crashing component function (12 lines), the TypeScript interface for its props (6 lines), the one hook call that feeds it (4 lines), and the question. Total: ~180 tokens vs ~7,800 tokens for the full file dump. The model answered correctly on the first attempt. The delta wasn't model capability — it was signal clarity. Relevant information at the start of a short context outperforms the same information buried in the middle of a large one, every time.

Count the tokens in each mode. The overloaded context uses ~2,400 tokens; the curated context uses ~180 tokens — 13× less. The answer quality is equal or better because the model isn't distracted by irrelevant code.

Three chunking strategies for larger codebases in AI workflows:

• File-per-turn — send one file per message in a multi-turn conversation. The model builds understanding incrementally without window saturation.
• Semantic relevance chunking — embed all files, cosine-search against the task description, send only the top-N chunks. Works well for RAG-style code assistants.
• API surface only — for dependencies, send only exported function signatures and their JSDoc — not the full implementation. The model needs the contract, not the code.

// Tool call pattern: incremental context in agentic loop
const tools = [{
  name: 'read_file',
  description: 'Read a file by path. Call once per file needed.',
  // Model requests only what it needs, on demand
}];
// Instead of: stuffing all files upfront