The Questions You Didn't Know to Ask: How Zaguán Blade Surfaces Unknown Unknowns

There’s a Hole in Your Thinking

You know the feeling.

You’ve been working on a feature for hours. The code compiles. The tests pass. You’ve handled the edge cases you thought of. You push the PR feeling good about it.

Then someone on the review says: “Did you consider what happens when the database connection drops mid-transaction?”

You hadn’t. Not because you’re careless. Because the question never occurred to you. It was an unknown unknown — something you didn’t know you didn’t know.

This is not a rare event. It is the default state of software development. Every commit, every design decision, every architecture choice carries assumptions that the author isn’t aware they’re making. Some of those assumptions are harmless. Some of them are the bugs, the security holes, and the outages that show up months later.

The problem isn’t that developers don’t ask good questions. The problem is that they don’t ask the questions they can’t see.

Most AI coding assistants do not solve this by default. Some make it worse. They’re excellent at answering what you ask. They’re not designed to surface what you didn’t ask. They operate inside the frame of your prompt, which means they amplify the known and leave the unknown alone.

We built something different.

The Rumsfeld Problem

In 2002, Donald Rumsfeld famously said there are “known knowns, known unknowns, and unknown unknowns.” He was talking about military intelligence, but the framing maps perfectly onto software engineering:

Known knowns: You know the API contract and you know it works. You’ve tested it.
Known unknowns: You know the database schema migration is risky. You’ve flagged it, added a rollback plan.
Unknown unknowns: You didn’t realize your authentication middleware short-circuits on a specific header combination that an upstream proxy adds automatically. You couldn’t flag it because you didn’t know it was there.

The first two categories are manageable. Standard engineering discipline handles them: code review, testing, monitoring, documentation.

The third category is where the real damage happens. Unknown unknowns are the source of the worst bugs, the subtlest security vulnerabilities, and the most expensive architectural mistakes. Not because they’re inherently complex — often they’re simple — but because they’re invisible to the person making the decision.

This is not a tooling gap. It’s a cognitive one. You cannot search for what you don’t know is missing. You cannot test for a behavior you don’t realize exists. You cannot review an assumption you don’t know you’re making.

But an AI can help.

Not because AI is magically smarter than you. It isn’t. The value is that it has different blindspots, different pattern memory, and no emotional attachment to the design you just spent six hours building. It reads the same codebase from a different angle. It doesn’t share your assumptions. And when it’s designed to look specifically for what’s absent rather than what’s present, it can surface patterns that no amount of self-review would catch.

That’s the idea behind the Blindspot Radar.

How Most AI Assistants Fail at This

The typical AI coding assistant is optimized for responsiveness. You ask a question, it answers. You describe a task, it implements. You paste an error, it debugs.

This is useful, but it’s reactive. The assistant only operates within the frame you give it. If you ask “implement user authentication,” it will implement user authentication. It will not ask whether your threat model accounts for session fixation, or whether the password reset flow creates an open redirect, or whether the rate limiter you didn’t mention is actually present.

These are not exotic concerns. They’re standard security considerations. But they’re outside the frame of the request, and most assistants don’t challenge the frame.

Some assistants try to be “helpful” by adding unsolicited suggestions. But these tend to be generic — “consider adding error handling,” “you might want to add tests” — which is the AI equivalent of telling someone to eat more vegetables. True, but not actionable, and not specific enough to change a decision.

What’s missing is a structured mechanism for surfacing specific, grounded unknowns — not generic best practices, but actual assumptions, omissions, and failure modes that are particular to your code, your design, and your current objective.

The Blindspot Radar: How It Works

The Blindspot Radar is a skill built into Zaguán Blade and powered by zcoderd, our AI coding daemon. You activate it when you want to know what you’re not seeing.

You can trigger it with phrases like:

“What am I missing?”
“Run blindspot radar on this plan.”
“Find my unknown unknowns.”
“What assumptions am I making?”

What comes back is not a generic checklist. It’s a focused report of 3-5 specific blindspots, each grounded in evidence from your actual workspace.

Here’s how it works.

Phase 0: Scope the Objective

Before looking for blindspots, the radar identifies what it’s actually looking at. Is it code? A design document? A bug? An implementation plan? The target matters because different artifacts hide different kinds of unknowns.

A codebase hides missing error paths and unhandled edge cases. A design document hides unstated assumptions and ambiguous success criteria. A bug description hides incomplete reproduction paths and unverified hypotheses.

If the target is too vague to identify a useful scope, the radar asks one concise question before proceeding. It does not scan the entire repository looking for general problems — that produces noise, not signal.

Phase 1: Build the Evidence Ledger

This is where the radar separates what it knows from what it’s guessing from what it can’t verify.

Every finding is classified as:

Observed: Directly supported by files, tool results, or explicit context. “The error handler at line 142 returns nil without logging.”
Inferred: A reasonable conclusion from observed evidence, but not directly proven. “Given that this middleware runs before authentication, the rate limiter likely doesn’t have user context.”
Needs verification: Plausible but missing enough evidence to confirm. “The upstream API may have changed its rate limit behavior — this needs an external check.”

This matters because confidence must track evidence. A “High” confidence finding requires at least one Observed data point. Inferred evidence alone supports at most Medium confidence. Needs-verification is Low unless multiple strong signals align.

Most AI systems don’t do this. They present conclusions as if they’re equally certain. The evidence ledger forces intellectual honesty — and it gives you, the reader, a way to evaluate whether the finding is worth acting on.

Phase 2: Probe Four Mental Vectors

This is the core of the radar. After the evidence exists, the system runs four distinct probes — each designed to catch a different category of unknown unknown.

1. Silence Forensics: What is the codebase not doing?

This is the most counterintuitive probe, and the most powerful. Instead of looking for what’s present, it looks for what’s absent.

Missing failure fallbacks. Unhandled edge-case states. Absent telemetry for the riskiest operations. Missing tests for the most dangerous code paths. Product questions that should be asked but aren’t. Concerns that would be present in a mature implementation but are conspicuously absent here.

Silence forensics is about reading the gaps, not the text. It’s the difference between reading what someone wrote and noticing what they didn’t write.

2. Dependency Drift: Which external assumptions may be stale?

Every project rests on assumptions about its dependencies: library behavior, API contracts, platform limits, runtime characteristics, pricing, licensing. These assumptions decay over time. The library you pinned six months ago may still behave the same, but the platform around it may not: runtime versions, API responses, browser behavior, pricing, and provider limits all drift.

Dependency drift asks: what breaks if a trust assumption is violated tomorrow? And which assumptions haven’t been verified recently?

3. Pattern Interrupt: Where is this project repeating itself into a trap?

Every codebase develops habits. Certain patterns worked once and get reused — sometimes appropriately, sometimes not. The defensive error handling added after an incident becomes cargo-culted into every new module. The simple function that worked for three cases gets turned into an over-engineered abstraction when a fourth case appears. Duplicated logic that should have been extracted into a shared utility stays duplicated because no one noticed the pattern.

Pattern interrupt looks for habits that have become traps. It’s not about whether the pattern is good or bad in isolation — it’s about whether the repetition is serving the current context or just following inertia.

4. Constraint Cascade: What shatters first if the rules change?

If the primary constraint shifts by an order of magnitude — data volume, request latency, user count, context size, memory use — which specific component fails first? And what cascades from that failure?

Constraint cascade is about finding the brittle edge. Not the things that are slow now, but the things that will break when the world changes. It’s the difference between a system that degrades and a system that collapses.

Phase 3: Prioritize Ruthlessly

After running all four probes, the radar returns only the strongest 3-5 blindspots. Not 15. Not 10. Three to five.

If fewer than 3 strong blindspots exist, it reports fewer. It does not invent filler to satisfy a quota.

And it explicitly discards any finding that sounds like generic software advice. “Consider edge cases” is not a blindspot. “Add more tests” is not a blindspot. “Handle errors better” is not a blindspot. Those apply to almost any project and are therefore not blindspots — they’re just ambient anxiety.

A valid blindspot must be specific to this codebase, this objective, and this moment. It must expose a hidden assumption. It must reveal something the developer was unlikely to ask about directly.

The quality bar is simple: a good Blindspot Radar report should make you think, “I had not considered that specific failure mode.”

A Concrete Example

A real report is not always this clean. Findings can be messy, some land at Medium confidence, and a few will need verification you can’t do from the editor. But this is the shape of the output.

Imagine you’re building a multi-tenant API with row-level authorization. You’ve implemented the auth middleware, the tenant context, and the database queries. Tests pass. You feel good.

You run the Blindspot Radar. It returns:

1. Silent tenant context loss in background jobs

Vector: Silence Forensics
Why it matters: Your auth middleware sets tenant context on the request, but three background workers process jobs without HTTP context. They default to the system tenant — meaning they can read and write data across tenant boundaries.
Signal: The GetTenantContext() function only appears in HTTP middleware files. It’s never called in the worker directory.
Evidence: Observed — the function is only imported in middleware/auth.go and middleware/context.go. The workers in jobs/ import the database package directly.
Confidence: High

2. The ORM’s soft-delete filter bypasses row-level security

Vector: Dependency Drift
Why it matters: Your ORM’s Unscoped() method removes the soft-delete filter. But your row-level security is implemented as a scope on top of the soft-delete scope. Calling Unscoped() also removes the tenant filter.
Signal: The WithTenant() scope is composed with NotDeleted(). There are 14 calls to Unscoped() in the codebase.
Evidence: Inferred — the composition order suggests the scopes are coupled, but the exact behavior needs a specific test to confirm.
Confidence: Medium
Next verification: Run a query with Unscoped().Where("tenant_id = ?", ...) and check if the tenant filter persists.

3. Admin API inherits the same rate limiter as the public API

Vector: Pattern Interrupt
Why it matters: The admin endpoints use the same rate limiter middleware as the public API because they were added using the same router group. An attacker who triggers rate limiting on the public API also locks out admins.
Signal: Both publicRoutes and adminRoutes apply RateLimitMiddleware() with identical configuration.
Evidence: Observed — the middleware is applied in routes/setup.go on lines 23 and 41.
Confidence: High

None of these are generic. None of them apply to “almost any project.” Each one is specific to this codebase, this architecture, and this moment. Each one reveals an assumption the developer was making without realizing it.

That’s what a blindspot looks like when you find one.

Why This Works Better Than “Just Think Harder”

The obvious response to unknown unknowns is: “Just be more careful. Think about more things. Ask more questions.”

This doesn’t work. It can’t work. You cannot systematically examine what you don’t know is there. Cognitive biases — confirmation bias, anchoring, the availability heuristic — are not character flaws. They’re how human cognition works. They’re efficient for most situations and dangerous in exactly the situations where the stakes are highest.

The Blindspot Radar works because it doesn’t rely on you remembering to think about something. It systematically probes categories of unknowns that are invisible from inside your own perspective — what’s absent rather than present, what’s decayed rather than current, what’s habitual rather than deliberate, what’s brittle rather than working.

These four vectors aren’t arbitrary. In practice, they cover many of the places where unknown unknowns hide in software: missing behavior, stale assumptions, repeated patterns, and hidden fragility. Probing all four in a structured pass catches more than any amount of unstructured “thinking harder” ever could.

And because the radar is grounded in actual workspace evidence — real files, real code, real configuration — its findings are specific enough to act on. You don’t get “consider edge cases.” You get “the GetTenantContext() function is only called in HTTP middleware, not in background workers.”

The Bigger Picture: AI as a Question Engine, Not an Answer Engine

Most AI coding tools are built as answer engines. You ask, they answer. The quality of the interaction is bounded by the quality of the question.

But the most valuable thing an AI can do isn’t to give you a better answer. It’s to help you ask a better question.

This is a philosophical shift, not just a feature. It changes what you expect from the tool:

Answer Engine	Question Engine
”Implement this."	"What am I not considering before I implement this?"
"Fix this bug."	"What caused this category of bug, and where else might it exist?"
"Review this code."	"What assumptions is this code making that I haven’t verified?"
"Is this secure?"	"What attack paths am I not seeing?”

The answer engine gives you what you asked for. The question engine gives you what you didn’t know you needed.

Both are useful. But in a world where AI can already implement features, fix bugs, and write tests competently, the marginal value of another answer engine is shrinking. The marginal value of a question engine — something that makes you see what you’re missing — is growing.

How It Fits Into Zaguán

The Blindspot Radar doesn’t exist in isolation. It’s part of the Zaguán skills system, and it connects naturally to several other skills:

Workflow Discovery catches unknown unknowns before you start coding. When your request is ambiguous or underspecified, it asks targeted clarifying questions rather than assuming the most likely interpretation and running with it. This is the pre-emptive version of blindspot detection — catching the unknown before it becomes a problem.
Security Audit is the deep-dive version. Where the Blindspot Radar might flag “your auth middleware assumes HTTP context,” the Security Audit traces the full attack path: how an unauthenticated request reaches the worker, what data it can access, and what the exploit value would be.
Feature Development uses a 7-phase workflow that includes explicit discovery and architecture phases before implementation begins. Part of that workflow is asking: what are we not seeing? What assumptions are baked into the requirements?

Together, these skills form a layered defense against unknown unknowns. Workflow Discovery catches them before you start. Blindspot Radar catches them while you’re working. Security Audit catches them before you ship.

What It Does Not Do

The Blindspot Radar does not prove that a blindspot is a bug. It does not replace tests, code review, threat modeling, or production telemetry. It also does not guarantee that every report contains a breakthrough.

Its job is narrower: surface grounded suspicions worth checking. Sometimes the best result is one uncomfortable question and a concrete verification step.

The Real Test

We don’t think the Blindspot Radar is interesting because it’s a clever prompt. It is a clever prompt — but that’s not what makes it work.

What makes it work is the discipline baked into the process:

Read before you conclude. The radar must inspect actual files before generating findings. No guessing the architecture.
Separate evidence from inference. If you can’t point to a file, a line, or a specific fact, it doesn’t get High confidence.
Reject generic advice. If it would apply to almost any project, it’s not a blindspot.
Cap the output. Three to five findings, maximum. More is noise, not signal.
Make verification concrete. Every finding includes one specific action: a file to inspect, a test to write, a question to ask, a fact to confirm.

The real test isn’t whether the radar finds interesting things. It’s whether the things it finds change your next decision. If you read the report and think, “Huh, I hadn’t considered that” — and then you go verify it — the radar has done its job.

The Uncomfortable Truth About Unknown Unknowns

Here’s the thing about unknown unknowns: finding them is uncomfortable. The radar is telling you something about your own thinking — not that you made a mistake, but that there’s a dimension of this problem you weren’t tracking. That can feel like criticism, even though it’s meant as illumination.

The most valuable unknown unknowns are the ones that challenge an assumption you didn’t know you were making. That’s inherently uncomfortable. If it felt natural, it wouldn’t be unknown.

That’s why the radar’s grounding in evidence matters. A vague warning — “you might be missing something” — is easy to dismiss. A specific observation — “the GetTenantContext() function is only imported in middleware files, not workers” — is not. Evidence turns discomfort into specificity, and specificity turns dismissal into investigation.

The Question Is the Product

We started building Zaguán Blade as an AI coding assistant — something that could implement features, fix bugs, and write code. That’s useful. We still do that.

But over time, we realized that the most valuable moments in the tool weren’t when it gave us the right answer. They were when it asked us the right question. When it surfaced something we hadn’t considered. When it pointed at a gap we didn’t know was there.

The Blindspot Radar is our attempt to make those moments systematic rather than accidental. Not to replace your judgment, but to expand the set of things your judgment has to work with.

Because in the end, the quality of your software isn’t determined by the quality of your answers. It’s determined by the quality of your questions. And the best questions are the ones you didn’t know you should ask.

The Blindspot Radar is part of Zaguán Blade, an AI-powered coding environment. Feedback and contributions are welcome.