If you have built an agentic coding workflow, you have watched this slow-motion failure mode:
Your agent retrieves a chunk of documentation through RAG, assumes it is the absolute truth, and confidently generates 500 lines of code.
The code fails.
The library updated its API signature three weeks ago, but your vector store still holds the old docs.
Instead of questioning the documentation, the agent enters a death spiral. It reads the error, references the exact same stale docs, and rewrites the broken code in a slightly different way.
It burns through tokens, latency, and your patience because LLMs are fundamentally engineered to be people-pleasing text continuers, not skeptical engineers.
To fix this, we have to change the agent's default epistemology.
We have to teach it to doubt its own context.
Defensive prompting shifts your agent from a naive read-and-write loop into a resilient read-verify-write workflow.
The Core Concept: Trust, but Probe
Human engineers do not read a doc and immediately write a massive implementation.
If we are not fully sure how a third-party API behaves, we open a REPL, hit the endpoint with cURL, or write a tiny test script to see what actually comes back.
Defensive prompting codifies that behavior.
Before the agent is allowed to write the core logic, it is forced to run a cheap, deterministic experiment against the live environment.
The point is not to make the agent slower.
The point is to catch wrong assumptions before they become large, expensive patches.
Strategy 1: The API Probe
When an agent needs to integrate with an external service or a deeply nested internal module, force it to test the payload structure first.
The prompt block can look like this:
You have been provided with documentation for the target API.
However, documentation is frequently stale.
Do not write the full implementation yet.
First, write a minimal, self-contained Python script under 15 lines that authenticates and makes a basic GET or POST request to the endpoint based on your current understanding.
Execute this script.
If the script returns a 4xx code or a payload structure that differs from the documentation, output an <Assumption_Correction> block detailing how the live API actually behaves.
Only proceed to full implementation once this probe succeeds.
This works because you trade a small amount of latency upfront for a much lower chance of burning tokens later.
If the docs are wrong, the agent learns the ground truth directly from the runtime environment before it starts producing the real implementation.
The probe does not need to be elegant.
It only needs to answer one question:
Is the assumption I am about to build on actually true?
For API work, that usually means checking:
- Authentication shape
- Required headers
- Request body structure
- Response body structure
- Status codes
- Pagination behavior
- Error payloads
The agent should learn those facts before it writes the main feature.
Strategy 2: The Type-Check Circuit Breaker
For strongly typed languages like TypeScript, Rust, and Go, the compiler is your best source of truth.
Stale RAG context frequently hallucinates property names, misses renamed exports, or incorrectly assumes nullability.
Instead of letting the agent discover that after writing the implementation, make the type system a gate.
Before implementing the business logic, generate the exact interface or type definitions based on the provided context.
Save these in types.ts.
Next, write a dummy file that imports these types and instantiates them with mock data.
Run tsc --noEmit.
If the compiler throws an error, the documentation you were provided is likely outdated.
Iteratively fix the types using the compiler errors as your ground truth.
Do not write the main feature code until the type definitions compile cleanly.
This turns the compiler into a circuit breaker.
The agent cannot proceed from "I think this API looks like this" to "I wrote production code against it" until the assumption survives a basic check.
That matters because most coding-agent failures are not dramatic reasoning failures.
They are small factual failures:
- The method was renamed.
- The return value is nullable.
- The enum has different variants.
- The config key moved.
- The package now exports from a different path.
Those mistakes are cheap to catch early and expensive to repair after the agent has built a full patch around them.
The Skeptical Agent System Prompt
To make this systemic, bake skepticism into the root system prompt.
Here is a framework you can adapt for an orchestrator like LangGraph, AutoGen, Claude Code, Codex, or a custom loop:
You are an expert, highly skeptical Principal Software Engineer.
You are provided with user instructions and retrieved documentation.
CRITICAL DIRECTIVE:
Assume all retrieved documentation is potentially deprecated, incomplete, or misleading.
Before generating production code, execute the following <Verification_Protocol>:
1. <Identify_Risks>
List the specific API boundaries, library versions, or data schemas the user's request depends on.
2. <Hypothesis_Testing>
For every risk identified, write and execute a minimal probe against the live environment.
Use a cURL command, a REPL script, a compiler assertion, or a small test file.
3. <Reconciliation>
Compare the runtime output of your probes against the provided documentation.
If they conflict, the runtime environment is the source of truth.
Discard the documentation's claim and record the correction.
4. <Execution_Plan>
Only after all probes pass successfully, outline your plan and generate the final code.
If you fail to fix an error loop more than twice, stop.
Do not blindly try again.
Write a script to introspect the module, schema, endpoint, or available methods.
This prompt changes the agent's posture.
It is no longer rewarded for immediately producing code.
It is rewarded for identifying what could be wrong, testing it cheaply, and then implementing from verified context.
Why This Belongs Before Code Generation
The default agent loop is often:
That loop is expensive because the agent discovers false assumptions after the heavy generation step.
Defensive prompting moves discovery earlier:
This is a better shape for agentic work.
Small probes are cheap.
Large failed patches are not.
The Economic Impact
Defensive prompting changes the math of an agentic workflow.
Without it, an agent might generate 1,500 tokens of code, fail, and pass those 1,500 tokens plus the error trace back into the context window for a retry.
It may do that four or five times before failing out.
With a verification step, the agent generates a tiny probe first.
If the probe fails, the error is caught early, and the ground-truth correction is appended to the context before the heavy generation phase begins.
You trade a slight increase in orchestration complexity for:
- Fewer failed edits
- Less retry churn
- Lower token waste
- Better use of compiler and runtime feedback
- Higher confidence that the final patch matches the real environment
That trade is usually worth it.
The important shift is simple:
Do not let the agent treat retrieved context as truth. Make it prove the risky parts first.
Where Ninelayer Fits
Defensive prompting works best when the agent starts with cleaner evidence.
If retrieval returns stale docs, noisy snippets, or low-authority pages, the agent has more assumptions to verify and more opportunities to drift.
Ninelayer is built for the step before defensive prompting: giving agents compact, source-aware evidence from the live web so they can reason before they act.
But even with better retrieval, the rule still holds.
Search should inform the agent.
Runtime verification should ground it.
Together, they create a healthier loop:
That is the difference between an agent that merely reads and an agent that checks its work.
The Practical Takeaway
AI coding agents are powerful, but they are still vulnerable to stale context.
The fix is not only better prompts, bigger context windows, or more retries.
The fix is a better workflow:
- Retrieve evidence.
- Identify risky assumptions.
- Probe the live environment.
- Treat runtime output as ground truth.
- Write code only after the assumptions survive.
Defensive prompting gives your agent the habit every good engineer already has:
Check before you build.
We are building Ninelayer for teams who want agents to retrieve better context, waste fewer tokens, and make fewer confident mistakes. If that sounds familiar, get started.