A prompt sent to an AI is a snapshot of what you know at the exact moment you type it.
That sounds obvious, but it carries a consequence people rarely sit with: the output is bounded not by the model, but by the request. A better model fills the same shape more fluently. It does not expand the shape.
Consider a common scenario: you ask a coding agent to "add email verification with a 6-digit code." You get a working feature in minutes. Weeks later, you uncover edge cases one by one:
- The code never expires.
- Nothing stops a brute-force script from testing all 1,000,000 combinations.
- Changing an account's email address skips verification entirely.
- Requesting a resend generates a new code without invalidating the previous one.
None of these were in the initial request. The agent didn't mess up. It built exactly what was asked, quietly picking defaults for everything left unspecified.
The crucial detail here is that you didn't forget these points. Forgetting implies you knew them and they slipped your mind. You simply didn't know these questions existed in the first place. Someone who has shipped verification flows before would have raised every single one before writing a line of code, not because they are inherently smarter, but because their experience is largely a catalogue of questions that turned out to matter.
Known Unknowns vs. Unknown Unknowns
There is an old distinction between things you know you don't know (known unknowns) and things you don't know you don't know (unknown unknowns).
The first kind is a to-do list: you can look it up, read the docs, or ask a colleague. The second kind is completely invisible from the inside. You cannot list what never crossed your mind. That isn't a character flaw. It's the definition of the category.
Most of what we call expertise lives in that second category. It isn't just knowing how to answer a question, but knowing that the question needs to be asked in the first place.
This is precisely the part of the work an AI assistant cannot take off your plate, because it can only respond to what you ask. If anything, AI sharpens this gap. Fluent code and passing tests create an illusion of completeness. The missing questions stay hidden until they hit production or a code review.
The most critical skill when working with AI tools is metacognitive: knowing where the edge of your own knowledge lies so you can write the request from the far side of it. Good results come from good requests, and a good request is written by someone who knows what they don't know.
Why Prompt Checkers Keep Getting Turned Off
The obvious fix seems simple: check the prompt before sending it out. Think prompt linters, clarifying dialogs, or "did you mean..." popups. Yet almost everyone who tries these turns them off within a day.
The issue isn't the intent; it's structural UX:
- They intercept: Something stands between you and the agent on every single prompt, forcing a checkpoint you didn't ask for.
- They add latency: A model has to inspect your prompt before the primary model can even start. The delay sits directly on your critical path.
- They waste resources: A quick "ok, go ahead" gets the exact same heavy-handed processing as "migrate the primary database table."
The insights these tools produce are valuable, but the delivery mechanism makes them unaffordable. A thinking aid you disable is worth nothing.
What a Real Solution Looks Like
If delivery is the problem, the constraints for a proper fix are straightforward:
- Decide cheaply if it's worth checking: Most prompts don't have a critical blind spot. A fast, lightweight classifier can clear simple prompts instantly.
- Inspect thoroughly only when necessary: When a potential blind spot is flagged, a full model reads the request against your codebase and identifies what an experienced developer would have considered.
- Never block: The prompt should pass to the agent immediately. The check runs asynchronously alongside it.
- Stay out of the main session: Don't inject noise into the agent's context. The feedback lands quietly in a side panel for you to fold into your next prompt.
That last point is key. The goal isn't to fix the current prompt. It's to shift your awareness before you write the next one.
How I Implemented It: jev-blindspot
Based on jev, I built a lightweight tool around these exact constraints for Claude Code and Codex CLI called jev-blindspot.
When you submit a prompt, a local hook sends it to a background daemon. A quick classifier evaluates whether a blind spot exists. If it passes the threshold, a read-only instance of the agent inspects the project directory and generates concise cards showing:
- The missing consideration
- Why it matters in this specific context
- A copy-pasteable line you can drop into your next prompt
These cards appear silently in a side panel. Your active AI session never notices a thing. It doesn't rewrite your prompt, interrupt execution, or pollute the conversational context. It simply advises on the request, the one piece of the loop that belongs entirely to you.
It isn't perfect. Distinguishing between a genuine blind spot and generic checklist advice remains a subtle judgment call, and models can lean toward the generic. But the broader takeaway holds regardless of the tool:
When building with AI, the limiting factor is rarely the model. It is the request, and the request is bounded by what you know you don't know. Anything that broadens that boundary, whether a tool, a reviewer, or simply asking "what would a domain expert ask first?" elevates every result downstream. Good results start with good requests.
I put these thoughts together to help fellow developers write better requests from the far side of their knowledge edge. What is the one question you wish you had asked your AI agent before starting your last big feature? Feel free to leave your questions, thoughts, or counterarguments in the comments.
Top comments (0)