Beyond Prompt Engineering: Using AI to Discover the Unknown Unknowns
What Anthropic's "Map vs Territory" mindset teaches us about building better AI systems
Published: July 2026
For the past two years, the AI community has been obsessed with one question:
"How do I write the perfect prompt?"
Countless prompt libraries, templates, and frameworks have appeared, all promising better AI outputs.
But after watching Anthropic engineer Thariq Shihipar's recent presentation on Map vs Territory and the philosophy behind Claude Fable, I realized something important:
The future of AI isn't better prompting. It's better exploration.
The biggest failures in AI projects rarely come from bad prompts.
They come from things we never knew we should ask.
The Prompt Is Only the Map
Imagine planning a road trip.
A map shows:
- Roads
- Cities
- Highways
- Destinations
But it doesn't show:
- Road construction
- Traffic accidents
- Flooded roads
- Closed bridges
- Dangerous weather
Reality is always richer than the map.
AI works exactly the same way.
When we write a prompt, we're drawing a simplified map of a problem.
For example:
"Build an AI insight panel for our ERP system."
Seems straightforward.
But the real system may contain hundreds of hidden constraints:
- Legacy database structures
- Permission rules
- Missing customer data
- Slow API responses
- Mobile UI limitations
- Security restrictions
- Company-specific business logic
- Unexpected edge cases
These don't exist inside the prompt.
They exist in the territory.
The gap between the two is where most software failures happen.
The Four Types of Knowledge
One of the most interesting ideas discussed is the classic four-quadrant knowledge model.
1. Known Knowns
Things we know.
Examples:
- Customer table exists.
- Sales Invoice has a primary key.
- User authentication works.
These are easy.
2. Known Unknowns
Things we know we don't know.
Examples:
- Which API should be used?
- Where is the pricing rule stored?
- Does this customer support multi-currency?
These become investigation tasks.
3. Unknown Knowns
Things we know, but forgot to mention.
For developers, these are surprisingly common.
Examples:
- The database is read-only.
- Production only allows SELECT queries.
- Mobile users make up most of the traffic.
- Certain customers have custom workflows.
The AI cannot guess these reliably.
4. Unknown Unknowns
The dangerous category.
These are problems nobody even realized existed.
For example, the AI insight panel works perfectly until someone opens a customer created in 2009 that has:
- No currency
- Missing contact records
- Invalid addresses
- Duplicated identifiers
Nobody planned for it.
Nobody tested it.
The bug only appears in production.
Stronger Models Don't Remove Unknowns
This is an important lesson.
Many people believe:
Bigger model = fewer mistakes.
Not exactly.
A stronger model can:
- Reason better
- Plan longer
- Search larger codebases
- Understand architecture
- Perform better investigations
But it still cannot know information that doesn't exist in its context.
Instead of eliminating unknowns, strong models become better at finding hidden assumptions before implementation begins.
That is a very different capability.
Stop Treating AI Like an Auto-Complete Tool
Many developers still use AI like this:
Write feature
↓
Generate code
↓
Copy and paste
A more effective workflow is:
Understand
↓
Investigate
↓
Discover assumptions
↓
Identify risks
↓
Design
↓
Implement
↓
Validate
↓
Review remaining unknowns
Coding becomes only one step.
The real value comes from investigation.
AI Should Explore Before It Builds
Before writing a single line of code, ask AI questions like:
- What assumptions am I making?
- What information is missing?
- Which parts of this system are uncertain?
- What could break in production?
- Which requirements contradict each other?
- What should be investigated before implementation?
This transforms AI from a code generator into an engineering partner.
Applying This to Enterprise ERP Systems
Enterprise software is full of hidden complexity.
A Sales Order page might appear simple.
Behind it could be:
- 20 years of historical data
- Customer-specific workflows
- Approval chains
- Inventory reservations
- Taxation rules
- Country localization
- Document permissions
- Financial posting logic
No prompt can fully describe that.
Instead of immediately asking AI to implement a feature, ask it to investigate:
- Existing architecture
- Database relationships
- Security model
- Edge cases
- Performance risks
- Mobile behaviour
- Business assumptions
Only after that should implementation begin.
The Future of AI Engineering
Prompt engineering was an important first step.
But it is no longer enough.
The next generation of AI engineering is about building agents that can:
- Inspect repositories
- Search documentation
- Read specifications
- Analyse production behaviour
- Verify assumptions
- Perform testing
- Identify blind spots
- Challenge requirements
In other words, AI should continuously compare the map with the territory.
Whenever they differ, it should stop, investigate, and update the map.
Final Thoughts
The biggest takeaway from Thariq's presentation isn't a new prompt template.
It's a change in mindset.
Don't ask:
"How can I write a better prompt?"
Ask instead:
"What don't I know yet?"
The best AI engineers won't be the ones who can write the longest prompts.
They'll be the ones who build systems that continuously discover what was previously invisible.
Because in real engineering, the most expensive bugs are rarely caused by things we knew.
They're caused by the things we never realized we had overlooked.
Key Takeaways
- A prompt is only a map, not the real system.
- Production environments always contain hidden constraints.
- Strong AI models reduce blind spots but cannot eliminate unknowns.
- Investigation should happen before implementation.
- AI agents should act as explorers, not just code generators.
- The future of AI engineering is continuous discovery, not simply better prompting.
"The goal isn't to make AI answer faster. The goal is to make AI discover what humans forgot to ask."