DEV Community: Uranusist

Your AI Model Isn’t Limited. Your Request Is. So I used jev to fix it.

Uranusist — Wed, 23 Sep 2026 11:19:04 +0000

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.

I drew my Claude Code sessions as a timeline, with the why behind each decision

Uranusist — Thu, 17 Sep 2026 00:08:17 +0000

A code graph draws one layer of a project: the code. Functions, calls, imports, what depends on what. It is a good picture and people read it fine.

Under that layer there is another one, and it has no picture. The sessions you ran. What you typed into each of them. The moments the agent chose one way over another, and its reason. The work a later session picked up from an earlier one. All of it exists, in transcripts and in someone's memory, and no one has seen it drawn.

session-trail is a Claude Code plugin that draws that layer. It sits next to a code graph, not in place of it.

What is on the picture

One lane per session. A node per decision or finished piece of work. A curve between lanes when a later session continues a line an earlier one started. Small ticks on each lane for every prompt you typed. Read left to right, it is the story of the project.

Click a node and you get its title, what, why and how, the files touched around it, the session id and the path of the local transcript. Click a tick and you get the prompt, as typed.

The why, and your own words

Two things I most wanted on this picture.

The why, in the agent's words, at the moment it chose. When the agent makes a choice with lasting consequences, or finishes a unit of work, it passes a short brief to a Sonnet subagent, which writes the node. The why has to name the options that were passed over. That is the sentence you cannot get back from a diff.

Your own words, as typed. Every prompt is stored word for word by a hook. No model in that path, no summary in between. Weeks later, "what did I ask for back then" has an answer in the original wording, and the transcript path on the node takes you to the conversation.

Side by side on one axis, the request and the reason it produced are the part of the history that used to vanish first.

Many sessions, one picture

The hardest thing to see in agent work is how it spreads across sessions. A session starts, does something, ends; the next one picks up part of it, or does not. Here each session is a lane, and when a later one continues an earlier line, a curve joins the two. The time axis is linear inside a session and compressed across idle gaps, so a month with three active days fits on one screen.

The same picture for the person and the agent

The viewer is the product. It is drawn for people to read, and the agent's read side sits on top of it: three commands (show, why <path>, search) that it uses in one situation, right before reversing a choice that looks intentional. No history is pushed into the context on edits.

The point is that you and the agent look at the same history. You in the viewer, weeks later, or a teammate joining the project; the agent at the start of a session, or when it is about to undo something. Working with an agent, what you lose first is context: the reasons, the sequence, the story. This puts them back where a person can see them.

How it is built

One append-only file, .session-trail/events.jsonl, in the project folder. The graph is a pure reduction over it. Commit it to share the history with your team, or gitignore it.
Node 18+, no npm dependencies. The viewer is vanilla JS and SVG, no build step.
Hooks do the mechanical part (sessions, file touches, prompts) and run async, so the conversation is not slowed. The Sonnet subagent writes nodes in the background; the main agent does not wait for it.

Try it

/plugin marketplace add jsk4581/session-trail
/plugin install session-trail@session-trail

Work as usual, then /session-trail:view opens the timeline.

Repo: https://github.com/jsk4581/session-trail (MIT)

I would like to hear what else you would want on a timeline like this, and how you keep track of work that spans many agent sessions today.