Context engineering: The skill any AI tool becomes useless without

What context engineering actually is

Prompt engineering = how you talk to the model.

Context engineering = what the model knows before you say a word.

Context engineering is the practice of designing and managing everything a model has access to at the moment it generates code.

This includes:

• what memory it holds,
• which files it sees,
• what architectural rules are pre-loaded as hard constraints,
• what external data gets pulled in on demand – documentation, vector databases, codebase indexes.

Think of it as a meta-layer above prompts. Instead of writing increasingly clever prompt macros, you design the information pipeline – the code index, the filtering rules, the domain tags, the long-term memory, the project profile.

The simplest way to put it: you’re not teaching the model to write better. You’re curating what it knows so it can’t write badly.

Why AI tools can break your architecture without context

The same model, the same codebase, the same developer can produce brilliant code one day and architectural chaos the next. The differentiator is the state of the context.

Here’s what’s happening technically:

The lost-in-the-middle effect.

Large language models (LLMs) don’t read context linearly – they weight it unevenly. With a bloated context window, critical architectural details buried in the middle (e.g. your bounded context definitions, your integration contracts, your naming conventions) get systematically under-weighted. The model technically “saw” them but didn’t prioritize them.

Context as noise, not signal.

Without deliberate curation, what a model receives is a jumble: half the chat history, whatever files the IDE happened to grab, fragments of documentation. This is not a representation of your system’s architecture. It’s an information landfill. The model calculates whatever it can pattern-match – and those patterns are often from its training data, not your codebase.

What tools like Cursor and Claude Code solve on their own – and what they don’t

Cursor auto-indexes repositories, chunks code, generates embeddings, and supports @-references to files. That’s real infrastructure. But the quality of what comes out still depends entirely on how you’ve organized your repository, your documentation, your module boundaries, and your naming. The tool handles the mechanics. You have to handle the meaning.

Claude Code explicitly recommends aggressive context management - frequent /clear commands, deliberate file inclusion, vector database integrations – because a polluted, sprawling context degrades output quality measurably.

The vibe coding trap. Thoughtworks framed this well in 2025: there’s a shift underway from vibe coding (throwing a model at a repository and trusting it to figure things out) to deliberate context engineering, where you design what the AI knows and in what form. The former is exciting and fast. The latter is what makes the code actually shippable.

The concrete symptoms of bad context management look like this:

• AI that generates controllers calling repositories from a different bounded context,
• AI that creates duplicate DTOs because the existing ones are buried in a module it didn’t properly index,
• AI that builds REST endpoints in a system where inter-service communication should flow through events.
• AI that your senior engineers spend more time correcting than writing themselves.

How Boldare approaches codebase indexing

When we onboard a new project, we don’t install a plugin and start chatting. We build a four-layer context architecture before any AI touches production code.

Layer 1: The architectural contract

Before the AI sees a single line of code, we define the constraints it must operate within:

• bounded contexts,
• module boundaries,
• architectural style (hexagonal, modular monolith, event-driven),
• integration rules,
• communication patterns between services.

These become short, AI-readable rule documents – files that describe what good code looks like on this project, what’s explicitly prohibited, with concrete examples of both. Architecture Decision Records (ADRs) are formatted to be retrieval-friendly. These are always pulled as top-priority context – the guardrails that override everything else the model might infer from patterns.

Layer 2: Codebase indexing

This is more complex than “scan the folder.” A modern indexing pipeline for a large codebase looks like this:

Semantic chunking. We use parser-level tools (Tree-sitter and equivalents) to break files into logical units (functions, classes, modules), rather than arbitrary character-count blocks. A chunk containing one complete function with its docstring retrieves far better than a chunk that starts halfway through one function and ends halfway through another.

Embeddings with enriched metadata. Each chunk gets embedded and stored in a vector database (Pinecone, Weaviate, or Chroma depending on the project). We enrich chunks with domain tags (billing, onboarding, authentication), module names, and links to related ADRs and test files. This dramatically improves retrieval precision.

Scope configuration. We explicitly define what goes into the index. Generated artifacts, node_modules, build outputs, and legacy dead code are excluded. The index represents the living system, not its debris.

Delta updates. When a file changes, only the affected chunks are re-embedded. This keeps the index current without the cost of full re-indexing – which matters at scale where a full run is expensive.

Access governance. In multi-team projects, we increasingly segment indexes by team and service boundary (both for cost control and compliance). An agent working on the payments module doesn’t need (and shouldn’t have) full-text retrieval over the user identity module.

Layer 3: Task context assembly

When a developer formulates a task: “add a subscription payment endpoint” – they’re not dropping it into a raw chat window. A pipeline assembles the relevant context package:

• The architectural contract rules pertaining to the payments domain
• The related bounded context files and module interfaces
• The relevant existing code and its tests
• Any ADRs touching payment processing decisions

Claude Code or Cursor receives this curated package, not the entire monolith. The model isn’t guessing which conventions apply. They’re given to it explicitly, prioritized correctly, trimmed to what’s relevant. Boundaries get respected because the model is never given the opportunity to violate them without noticing.

Layer 4: Feedback loop and context evolution

Architecture changes, so the context system has to evolve with it. When a significant refactor happens, the affected ADRs are updated, domain tags are revised, and if necessary, new guardrail rules are added – for example: “this dependency is now deprecated, suggest the new pattern instead”.

We also monitor for failure modes. If code review starts catching repeated boundary violations in AI-assisted PRs – say, the application layer repeatedly reaching directly into infrastructure – that’s a signal to inspect the context structure, not to blame the model. Usually it means a gap in the architectural contract documentation, or a retrieval issue where the relevant constraint isn’t surfacing reliably.

The deeper shift this represents

Context engineering is not a feature you configure once. It’s a discipline closer to information architecture than to prompt writing. It asks engineering teams to think carefully about how their codebase’s knowledge is structured, tagged, and made retrievable.

The teams who’ve figured this out don’t talk about AI as unpredictable or unreliable. They talk about it the way they talk about a well-onboarded junior engineer: one who knows the codebase, knows the rules, and asks the right questions when uncertain.

The teams who haven’t yet built this layer talk about AI as something between “impressive demo” and “expensive liability.”

It turns out the question separating those two groups isn’t which model you use, or how good your prompts are. It’s whether you’ve built the infrastructure to give the model something worth knowing.

Boldare builds software products and helps companies navigate AI-assisted development at scale.

If you want to discuss how context engineering applies to your architecture, let’s talk!