Table of Contents
- The Invisible Problem
- Why Post-Write Validation Isn't Enough
- The Documentation Precision Problem
- What Would Actually Solve This?
- A Potential Approach
- The Workflow Shift
- Why This Pattern Matters
- The Missing Infrastructure Layer
- What This Unlocks
- The Broader Implication
Everyone's excited about AI coding agents. Claude writes React components. Copilot autocompletes your Python. Cursor refactors entire modules.
But there's a gap nobody's really addressing:
what happens when the code you're working on isn't public?
1. The Invisible Problem
AI agents are trained on GitHub, Stack Overflow, Maven Central, npm. They know Spring Boot inside out. They can write Jackson serializers in their sleep. Apache Commons? No problem.
But the moment you're working on a codebase that uses internal frameworks, custom SDKs, or proprietary libraries living in a private Nexus/Artifactory behind your VPN — the agent starts guessing.
And those guesses don't compile.
The model has never seen com.yourcompany.platform.OrderService. It doesn't know what methods exist on it. So it hallucinates a plausible API:
orderService.submit(order) // sounds reasonable, right?
Except the real method is:
OrderResult submitOrder(OrderRequest req, ExecutionContext ctx) throws OrderException
The code fails. You correct it. The agent tries again. Rinse and repeat 3-4 times until you're basically just telling it exactly what to write.
2. Why Post-Write Validation Isn't Enough
Most teams already have layers of context for their agents:
- System prompts describing architectural patterns and conventions
- RAG/knowledge bases with API documentation and usage examples
- LSP integration (Language Server Protocol) that catches errors after code is written
And these help! An agent with good system prompts and documentation access is better than one working blind. LSP integration in tools like Claude Code now provides real-time diagnostics — red squiggles, error messages, suggested fixes.
But there's still a fundamental gap.
LSP works after you've written code. It's reactive validation — you write something wrong, LSP catches it, the agent sees the error, corrects, and retries. That's a correction loop.
What's missing is proactive verification — the ability to check "what does this API actually look like?" before writing any code.
3. The Documentation Precision Problem
Even with good documentation, there's a subtle issue: internal docs are often informal.
They're written for humans who can infer intent, fill in gaps, and cross-reference with their IDE. Parameter names might be described loosely. Return types might be implied. Method overloads might not be fully enumerated.
An agent reading "use submitOrder with an order object and context" might still generate:
orderService.submitOrder(order, context) // close, but wrong types
When the actual signature requires specific types:
OrderResult submitOrder(OrderRequest req, ExecutionContext ctx) throws OrderException
The documentation was conceptually correct but syntactically imprecise. The agent writes plausible-looking code. LSP catches the error. Correction loop triggered.
4. What Would Actually Solve This?
The insight: agents need signature verification before writing, not just validation after writing.
The same way a human developer would:
- Read the documentation (conceptual understanding)
- Understand the architectural pattern (mental model)
- Check IntelliJ's autocomplete for the exact signature (syntactic precision)
- Write the code with confidence
Steps 1 and 2 are covered by system prompts and RAG. LSP handles post-write validation. But step 3 — the pre-write signature check — is missing.
This isn't LSP. LSP is reactive: write → error → fix. What agents need is proactive: query → verify → write correct code from the start.
5. A Potential Approach
What if agents had a tool they could call to:
-
Search for a class — "Find all classes named
OrderServicein my project's dependencies" -
Query its signature — "What methods does
com.yourcompany.platform.OrderServiceactually have?" - Get the exact types — Parameter types, return types, exceptions, modifiers
- Verify before writing — Check the real API, then write code that compiles on first try
This happens at inference time, not training time. The agent queries it the same way it queries web search or file operations — as a tool call during code generation.
6. The Workflow Shift
Current state (even with LSP):
Agent reads docs → writes code → LSP reports errors → agent sees errors → agent rewrites → repeat
With pre-write signature verification:
Agent reads docs → queries signature → writes correct code → LSP validates (no errors)
From "write, catch errors, then fix" to "verify, then write correctly".
7. Why This Pattern Matters
This isn't specific to Java or Maven. The same problem exists across:
- Python agents working with internal PyPI packages
- Go agents using private module repositories
- JavaScript agents calling proprietary npm libraries
- Any domain where the API isn't in the public training corpus
The solution pattern is universal: give agents a pre-write signature lookup mechanism — not just post-write error detection.
Think of it as the difference between:
- Spell-check (reactive: flags errors after you type)
- Autocomplete (proactive: shows valid options before you finish typing)
Agents have spell-check (LSP). What they need is autocomplete (signature verification).
8. The Missing Infrastructure Layer
Right now, most teams solve this by:
- Writing extensive documentation (which agents still misinterpret)
- Pasting relevant code snippets into context (doesn't scale)
- Relying on LSP correction loops (works but inefficient)
What's missing is tool infrastructure for pre-write verification.
The Model Context Protocol (MCP) is one attempt at standardizing this. Instead of cramming everything into the context window, you give agents callable tools:
- "What does this class look like?"
- "What's the schema of this database table?"
- "What endpoints does this GraphQL API expose?"
These tools work alongside system prompts, RAG, and LSP — not instead of them:
- System prompt sets the mental model
- Knowledge base provides conceptual guidance
- Signature verification provides syntactic precision (pre-write)
- LSP validates the final result (post-write)
- Agent writes correct code that passes validation immediately
9. What This Unlocks
When agents can verify signatures before writing:
- Fewer correction loops — code compiles on first try instead of 3rd or 4th attempt
- Lower token cost — no retry cycles burning context window
- Better developer experience — workflow stays in agentic mode instead of falling back to manual editing
- Confidence on proprietary codebases — agents work just as well on internal APIs as on public ones
This is the difference between agents being a novelty and agents being genuinely integrated into professional software development.
10. The Broader Implication
As AI agents mature, the bottleneck won't be "can they write code" — it'll be "do they have accurate context about the system they're writing for?"
Public knowledge is covered by training data. Private knowledge needs infrastructure:
- System prompts for mental models ✓
- RAG for conceptual guidance ✓
- LSP for post-write validation ✓
- Pre-write signature verification ← this is the missing piece
This is the infrastructure problem nobody's talking about yet. But as more teams adopt agentic workflows on real enterprise codebases — where documentation is informal, APIs are numerous, and correction loops are expensive — it's going to become the obvious next frontier.
The future isn't just agents that write code. It's agents that verify first, then write correctly.
If you're using AI coding agents on internal codebases, are you seeing correction loops when agents work with private APIs? How are you handling signature verification?
Top comments (0)