If an assistant knows the right code but returns it in the wrong format, you probably have a prompt problem.
If it confidently recommends creating a service your company already has in another repository, rewriting the prompt won't fix the missing knowledge.
You have a context problem.
Anthropic describes context engineering as the set of strategies for curating and maintaining the information available to an LLM during inference. Its September 2025 engineering guide makes the core constraint explicit: context is finite, and more information isn't automatically better. Read Anthropic's guide to effective context engineering.
For engineering teams, that gives us a useful rule:
Prompt engineering tells the model what to do. Context engineering decides what the model knows when it does it.
Where prompt engineering still matters
Prompt engineering isn't obsolete.
It's extremely useful when the model already has the information it needs and the problem is how it interprets or uses that information.
Good prompts can clarify:
- the task
- expected format
- constraints
- available tools
- sequence of work
- what the model should do when uncertain
GitHub's guidance for Copilot still treats custom instructions, reusable prompts and agent configuration as important ways to improve results. Its January 2026 article on context engineering describes instructions and reusable prompts as part of a larger system for supplying Copilot with the information and behavior a team wants. See GitHub's Want better AI outputs? Try context engineering.
Prompting is particularly effective for requests such as:
“Return a migration plan with risks before writing code.”
“Use our API conventions.”
“Don't change public interfaces.”
“Explain every assumption you can't verify.”
Those instructions shape behavior.
But look at the second example:
“Use our API conventions.”
The prompt can request that behavior.
It can't tell the model what your API conventions actually are unless those conventions are already present somewhere it can access.
That's where prompting stops and context begins.
The easiest diagnostic: ask what information is missing
When a coding assistant gives a bad answer, teams often instinctively add more instructions.
“Be more careful.”
“Think step by step.”
“Search the entire repository.”
“Don't hallucinate.”
Sometimes that helps.
Sometimes it produces a more carefully written wrong answer.
Before changing the prompt, ask:
Could the model have produced the correct answer from the information it had?
If yes, improve the prompt.
If no, improve the context.
That one question separates a surprising number of failures.
DO YOU HAVE A PROMPT PROBLEM OR A CONTEXT PROBLEM?
Mostly prompt problems?
Improve task instructions first.
Mostly context problems?
Inspect where the model's system knowledge comes from.
Context engineering isn't just filling the window
A lot of writing about context engineering focuses on one session.
Which files should you attach?
What should you place first?
When should you summarize the history?
When should you start a fresh session?
That work is real. GitHub's own January 2026 practical guidance recommends actively managing context windows, including starting new conversations when older context is no longer relevant. See GitHub's lessons from working with Copilot context windows.
Anthropic goes further and frames context as a finite resource that agents need to curate continuously, deciding what information should remain immediately available and what can be retrieved later.
The problem for an engineering organization is that session-level context disappears.
An engineer finds six relevant files.
They add an architecture note.
They explain which service is authoritative.
The model finally understands the problem.
Session ends.
Tomorrow another engineer asks a similar question and rebuilds nearly the same context from scratch.
That repeated reconstruction is the structural weakness a durable context layer is meant to remove: useful system knowledge should not disappear with the session and have to be rebuilt manually tomorrow.
That's the difference between context engineering as a technique and context as infrastructure.
The durable version has four parts
For code context to become reusable across a team, four questions need answers.
1. Source: where does the context come from?
Different sources answer different questions.
Code tells you what the system currently does.
ADRs and PRs can tell you why a decision was made.
Documentation can explain concepts, processes and business meaning.
Tickets show requested changes.
People contribute judgment and history that nobody recorded.
For structural questions about software, code is particularly important because it changes with the implementation.
A diagram can become stale.
The executing system can't quietly drift away from its own implementation.
That doesn't make code sufficient for every question. It makes it the natural anchor for questions about current structure.
2. Freshness: how does the context stay current?
This is where many internal AI systems quietly fail.
The company builds a beautiful knowledge index.
Six months later, engineers no longer trust it.
If context requires manual synchronization every time code moves, it inherits the same maintenance problem as a wiki attempting to mirror implementation.
For code-derived context, the stronger model is incremental updates connected to repository changes.
The question isn't:
“Did we index our code?”
It's:
“How long after the code changes does the AI stop describing the old version?”
3. Selection: how much of it reaches the model?
A source can be present and current and still be unhelpful if the model receives too much of it.
Selection is the retrieval problem: returning the four relevant files, not the forty related ones.
The sections on context size and retrieval below explain why that selection step matters.
4. Delivery: how does the context reach the model?
A useful context layer shouldn't need a bespoke integration for every assistant an engineering team adopts.
That is one reason MCP matters.
The Model Context Protocol specification describes MCP as an open protocol for connecting LLM applications to external data sources and tools.
The architectural idea is straightforward:
context source → standard interface → whichever compatible assistant needs it
That lets an organization invest in the knowledge layer rather than rebuilding integrations around every new model.
More context isn't better context
The instinct when an AI system doesn't know enough is to give it more.
Bigger window.
More files.
Longer conversation.
Entire repository.
That strategy runs into two different constraints.
The first is cost.
Everything added to context has to be processed somehow.
The second is reasoning quality.
A 2025 controlled study across five open and closed models found that performance degraded as inputs became longer even when retrieval was perfect and all relevant evidence remained available. Depending on model and task, the measured degradation ranged from 13.9% to 85%. Read Context Length Alone Hurts LLM Performance Despite Perfect Retrieval.
Software-engineering research published in February 2026 found a similar issue specifically in automated bug fixing. Successful agentic trajectories typically stayed below 20-30k tokens, while artificially expanding inputs to 64K–128K tokens caused sharp performance degradation even when the relevant files were guaranteed to be present. Read The Limits of Long-Context Reasoning in Automated Bug Fixing.
That doesn't mean long contexts are useless.
The practical lesson isn't “short context good, long context bad”.
It's:
Selection and retrieval matter more than maximum window size.
The model needs enough context to solve the problem.
Not every context you can possibly find.
[IMAGE 3 HERE — Diagram: More context vs better context]
Retrieval quality deserves its own engineering work
Once context becomes dynamic, retrieval becomes part of product quality.
It isn't enough for a system to “search the code”.
It has to retrieve the right code.
Anthropic's work on Contextual Retrieval demonstrates how much retrieval quality can matter. In its experiments, adding contextual information to embeddings and BM25 reduced failed retrievals by 49%. Adding reranking reduced them by 67%. Read Anthropic's Contextual Retrieval research.
The useful principle is broader:
retrieval is an optimization problem, not a checkbox.
For code context, a retrieval system needs to answer questions such as:
- What is actually relevant?
- How much should be returned?
- What happens when confidence is low?
- Can the user verify the result?
- Are cross-repository relationships included?
- Does the answer still reflect the latest code?
An important behavior is often overlooked:
What happens when nothing relevant exists?
A system that always returns something can be more dangerous than one willing to say:
“I don't have enough grounded context to answer.”
Retrieval precision matters more than volume, and below a relevance threshold the useful answer can be nothing rather than a best guess.
That's less impressive in a demo.
It's considerably more useful in engineering work.
Every model still needs organizational context
Context engineering sometimes gets framed as a solution only for general-purpose frontier models.
It isn't.
Consider three paths.
Frontier model
Very capable.
No built-in knowledge of your private repositories.
Needs current private context.
Small local model
Cheaper and easier to keep inside controlled infrastructure.
Usually has less general capability.
Needs precise private context even more.
Fine-tuned model
Can absorb organization-specific patterns during training.
But training captures a state of the world.
The change merged this morning wasn't part of yesterday's training data.
A fine-tuned model can still need retrieval for fresh system state.
Different models change how much reasoning capacity you have.
They don't remove the need to supply current facts.
Where Tentaro fits
Tentaro is built around the durable version of context engineering.
It isn't another prompt-management layer and it doesn't generate code itself.
Tentaro indexes private code and turns it into grounded context that engineers and compatible AI assistants can retrieve when they need to understand the existing system. Its shipped product boundary includes code-context extraction and MCP delivery rather than code generation.
That maps directly onto the Source–Freshness–Selection–Delivery model.
Source
Private repositories provide the structural ground truth.
Freshness
Tentaro supports incremental indexing, so changed code can be processed without rebuilding the entire repository index.
Selection
Indexed code context can be retrieved when engineers or compatible assistants need it, rather than rebuilding the same context manually in every session.
Delivery
Context can be exposed through MCP to compatible developer tools and assistants.
The point isn't to replace Claude Code, Copilot, Cursor or whatever comes next.
Coding agents are a channel for context, not necessarily the product Tentaro is trying to replace.
That is strategically important because the agent market changes quickly.
The codebase changes too.
The organization should own the layer connecting the two.
Prompt engineering and context engineering work together
There is no sensible “prompt engineering is dead” conclusion here.
A strong coding workflow needs both.
Context engineering gives the model:
the right information
Prompt engineering tells it:
what to do with that information
Consider:
“Find the implementation responsible for retry behavior, identify all downstream dependencies, then explain the risk of changing it. Cite the relevant source files and say when the available context isn't enough.”
The instruction is prompt engineering.
Retrieving the relevant implementation, dependencies and current code is context engineering.
Remove either half and the result gets weaker.
Good instructions over bad context produce articulate fiction.
Excellent context under vague instructions can produce technically correct but unhelpful output.
The best systems treat the two as separate engineering problems.
[IMAGE 4 HERE — Decision card: Source → Freshness → Selection → Delivery → Prompt]
Before rewriting your prompt, ask:
1. Did the model have the necessary facts?
No → Context problem
2. Were those facts current?
No → Freshness problem
3. Were the relevant facts selected rather than buried in noise?
No → Selection problem
4. Did the same context reach the model consistently?
No → Delivery problem
5. Did the model misunderstand what it should do with good context?
Yes → Prompt problem
Bottom: Fix the first failing layer, not the easiest layer to edit.
Context engineering becomes infrastructure when teams stop rebuilding it
The biggest shift isn't from prompts to context.
It's from personal context assembly to organizational context infrastructure.
If every developer creates their own collection of files, instructions and explanations, the organization hasn't solved context engineering.
It has distributed the work of rebuilding context to every employee.
A durable system should answer:
- Where does the information come from?
- How do we know it's current?
- How is relevance determined?
- How does the model receive it?
- Can the user verify the sources?
- What happens when the answer isn't known?
Once those questions have shared answers, context stops being a clever trick inside one chat session.
It becomes something the engineering organization owns.
Before you rewrite the prompt again, test the context
Pick one question your developers regularly ask an AI coding assistant.
Run the Source–Freshness–Selection–Delivery test:
SOURCE → Does the answer exist somewhere the model can access?
FRESHNESS → Does that source reflect the current implementation?
SELECTION → Will the model receive the relevant context without burying it in noise?
DELIVERY → Will the relevant context reliably reach whichever assistant the engineer uses?
If any answer is “no”, another line of prompt engineering probably isn't your highest-leverage fix.
Tentaro is designed for that layer: private code becomes grounded, current context that can be delivered to compatible AI tools through MCP, while your existing assistants continue handling generation and reasoning.
