An AI that watches a developer's whole arc of work and reflects intent-drift back to them — without ever competing for the cognition that produced it.
This is not a finished study. The document grows alongside the tool itself — it begins as market and problem research (the current phase), and as the work moves into technical spec, prototype, MVP, testing, and real users, each phase's findings are added here rather than replacing what came before. The end state is a complete research record — problem, philosophy, design decisions, what was tried, what testing and real users showed — meant to be publishable, possibly alongside the tool when it ships. Every section below is current best understanding, not settled history.
AI should witness, not compete for cognition.
Cognitive drift is what happens when AI-assisted development lets output outrun understanding — a thousand small, locally-reasonable acceptances that compound into a system nobody actually chose. Every current tool responds by adding another AI to the loop: more specs, more agents, more synchronization. The Observer takes the opposite position. It watches a Claude Code session in VS Code — the spec you gave it, the prompt you wrote, what the AI produced, what you did next — and the moment a seam opens between what you meant and what is happening, it shows a quiet flag. It never writes, suggests, or scores. Its only job is to make sure you still recognize what you are building, and why.
The Observer is not a linter, a spec-sync tool, or a second AI coding assistant. It is something that watches a developer's whole arc of work — the task, the reason for the task, where it is headed, how it touches the current and future state of the system — and periodically reflects that back, so the developer can see whether they have drifted from their own plan.
The one-line version is the right one: AI should witness, not compete for cognition. That is not a feature description. It is a claim about the role AI should play in a workflow, and it is deliberately stated against the grain of the current market.
Cognitive drift, defined precisely: everything related to the current task — why you are doing it, where it leads, how it affects current and future state — and whether what you are doing now has drifted from your original plan as AI assistance accumulates. It is worth separating this into layers, because each is a different engineering problem and a different reason a developer notices something has gone wrong.
| Layer | The drift | How it's noticed today |
|---|---|---|
| Intent decay | You forget why you made a decision six days or six weeks ago | Git-blame archaeology, Slack search, staring at a comment that no longer makes sense |
| Plan drift | The system diverges from your intended architecture, one AI-accepted suggestion at a time | A sudden "wait, why does it look like this now" |
| Task drift | Mid-session, you've solved a different problem than the one you sat down to solve | Realizing at 6pm that the ticket is still open |
| State drift | Your mental model of the codebase no longer matches what's actually in it | A bug that "shouldn't be possible" given what you thought was true |
| Compounding drift | Small, locally-reasonable steps that add up to something nobody would have chosen on purpose | The "how did we end up here" retrospective |
This framing matters because it says the tool is not solving one problem. It is solving the meta-problem: that these small divergences are invisible in the moment and only legible in hindsight — usually someone else's hindsight, in a postmortem.
This space got crowded fast. It is worth knowing exactly how, so as not to rebuild something that already exists — and so the gap becomes visible.
Across the current ecosystem, "drift" almost always means one thing: the AI agent's output no longer matches a written specification.
CLAUDE.md,
.cursor
rules, etc.) as an organizational asset and runs "automated drift detection, pre-commit enforcement, and
cross-file consistency checks" against them.6
Notice what these share: the artifact being checked is a document — a spec, a rules file, an API contract. The checker is another AI agent or a static analyzer. The audience is a pipeline, a reviewer, or a team lead. None of them are checking for drift in the developer's own head.
One essay gets unusually close. A Stack Overflow contributor describes "black box AI drift — the gap between what you need in a design and the AI translation of your intent into code," arguing that prompts go in, output comes out, and the decisions made in between are hidden from view — and because of the volume and velocity of AI-assisted generation, those gaps are proliferating faster than we can chase them.4
This is close. But its proposed fix is still tool-side: making the AI's own reasoning visible. The Observer's is developer-side: making the developer's drift from their own intent visible. That is a meaningfully different product, even if it starts from the same anxiety.
Developer-experience research has isolated the three variables this tool is implicitly designed around: feedback loops (the speed at which developers receive information about their work), cognitive load (the mental effort required to complete tasks), and flow state (the state of full immersion and enjoyment).1 Critically, recent longitudinal work notes that how AI coding assistants affect flow state is not yet well understood.2 This is a young, unsettled area — not a solved one.
There is real evidence that AI assistants can be net-negative for flow specifically because of the interruption pattern, not the assistance itself. The same longitudinal study reports a productivity–experience paradox: productivity perceptions held stable (84% reporting improvement at both time points), yet among matched participants the proportion reporting worsened developer experience in at least one dimension nearly doubled, from 14% to 27%, with flow state and cognitive load eroding even as feedback loops improved.2
"Unwanted or poorly timed suggestions, verbose outputs, interface switching, and the need to constantly verify generated code introduce frequent interruptions that break developers' flow continuity."
This is the empirical case for the principle. Every existing AI dev tool adds a participant to the developer's cognition; the evidence says that is exactly what damages flow and inflates cognitive load. A tool whose entire design constraint is "never interrupt, never suggest, only reflect back on request" argues directly against the grain of where the industry is building — and the research suggests the grain is wrong.
Design research on human–AI collaboration keeps circling the same discomfort. In one recent study, designers reacted to a hypothetical AI agent that could act autonomously mid-task; the pushback was consistent — one participant said they would want to stay in control at that stage rather than let the agent "listen and execute," and another insisted the AI should always leave the last decision to the human.9 Tellingly, when it came to a tool meant to hold onto a person's own material — the closest existing analogue to an observer archive — the same participants were unambiguous: such a tool is useful only as long as it is user-controlled, user-generated, and user-owned.9
That is close to the "code ownership vs. allowed ownership" thinking behind this project. It suggests the appetite for a tool that only holds up a mirror — without asserting authorship, suggestion, or authority over the work — is already there, articulated by people who do not yet have a name for what they are asking for.
Checked directly for this framing and adjacent ones. Nothing in the current market — spec tools, IDD platforms, context-ops platforms, observability-for-devex tools — states this as a philosophy. Without exception they position themselves as making the AI more involved, more synchronized, more embedded in the loop. That phrase, and the stance behind it, is open ground as of today.
An earlier draft argued that reflection should be "retrospective and requested, not real-time and pushed," and implied the interface problem was the hardest part of the whole idea. Both were quietly overreaching, and it is worth naming exactly how — because the correction is the product.
The real distinction isn't "during the session" vs. "after the session." It's interruption vs. ambient presence.
A popup, a modal, a sound, a notification badge that demands a reaction now. This is the mechanism the flow-state research condemns — the poorly-timed suggestion that breaks flow continuity.
A small, silent, passive indicator — a dot changes color — sitting in peripheral vision, asking nothing until you choose to look. Closer to a git status light or a linter gutter mark than to a suggestion engine.
A tool can watch and flag during the session without ever interrupting, as long as the signal is visual, small, silent, and entirely optional to check. That is fully consistent with "witness, not participant" — the witness is present in the room the whole time, but never taps you on the shoulder. It speaks only when you turn and ask.
So the design rule is: the tool may change its own indicator state at any moment; it may never demand attention at any moment. To be unambiguous about scope — it only ever changes its own flag state (on/off). It never touches the developer's code, files, or environment, under any circumstance. That is not a feature limitation to justify; it is simply outside what a witness does.
On the "hardest design problem" claim specifically: the original draft framed "how to show drift without a dashboard" as the hardest open problem in the product. That framing was itself an unrequested drift — it had already been settled that there should be no metric, no score, no KPI, only a sentence. Turning that into an open "hard problem" quietly reintroduced the very thing that had been ruled out. The correct standing answer, stated once:
There is no metric. There is no dashboard. There is a sentence.
Something like: "The task was to decrease the margin. You're changing the background color of a neighboring element." Plain, specific, comparing stated intent to observed action, in the developer's own terms — not a number, not a severity score beyond a simple flag color, not a trend line. If a red or yellow indicator appears, clicking it reveals one sentence. That is the entire surface area of the output. (This is refined further in §8 — the default view is now a raw comparison, with the generated sentence available only as a clearly-labeled secondary action.)
What the tool should watch and ingest is genuinely still open. But the research narrows the space of good answers.
The Seam B example (AI adds unrequested tests) matters beyond illustrating the mechanism: it establishes that this tool has no opinion on whether the AI's output was good. Only on whether it was asked for. If a developer's own prompt was flawed, or their next step is a mistake, the tool has nothing to say — that mistake is theirs, made knowingly, by their own hand. The tool's entire value is that when something goes wrong, the developer can trace it back to a decision they actually made, not one that was quietly made for them. Faithfulness to stated intent is the only axis this tool measures. Quality is out of scope, permanently.
The true case (a prompt that traceably connects to a spec fragment) was defined first; the false case needs
its own definition, by the same standard used for Seams B and C: "still the same task" is false when the
prompt's content has no traceable connection to any part of SPEC.md
— for example, a prompt that introduces a new external API, a new tool, or a design-system change nowhere
referenced in the spec.
This is deliberately framed as "no traceable connection," not "introduces something new" — because a spec can be incomplete, and a developer introducing something the spec never anticipated may be entirely correct to do so. The tool cannot and should not try to distinguish "developer went off-spec" from "spec didn't anticipate this and the developer is right to deviate." Those two cases get names of their own — new-but-justified vs. new-but-drifted — in §7, where it is decided that the distinction belongs to the developer's judgment, not the tool's logic. The tool only reports the absence of a traceable connection; what that absence means is the developer's call.
It is also worth noting when Seam A drift is likely to occur: rarely on the first prompt of a task (which tends to cleanly reference the spec), and increasingly as a session goes on — new ideas surface mid-development, and a few unrelated asks get folded into an otherwise-correct prompt. Seam A checks may need to matter more, not less, as a session lengthens.
An early next-step check could have passed cleanly — the first prompt referenced the spec perfectly. The drift emerged several edits later, within the same apparent task. Nobody chose "let's rebuild payments today"; it accumulated. This is exactly the case that makes single-point checks insufficient (see the re-checking open question, §8).
SPEC.md,
and for how long?A real question surfaced during this research: at what point does a developer have the standing right to explore, trial-and-error, or research something unrelated to the spec, without that being treated as drift? This is not a detection-mechanism question (that is what Seam A answers) — it is a policy/usage question about how strictly any given developer or team wants their own spec to bind them, and whether that strictness can flex mid-session (e.g., an explicit "exploration mode" toggle vs. spec-as-law throughout). The tool should not answer this on the developer's behalf. But the concept doc should eventually state whether v1 assumes spec-as-constant-authority or builds in a declared exploration window. Left open for now — addressed in full in §7.
All worked examples so far describe clean matches or clean mismatches. Real sessions will produce partial matches — a prompt related to the spec but scope-expanded (spec says "component," prompt says "component plus basic validation"). Whether that counts as drift, a soft flag, or no flag at all is not yet decided, and should not be treated as implicitly resolved by the clean-case examples.
Drift can appear at any seam between these four stages. The tool's job is to sit across all four and notice when a seam has opened.
.md, a .pdf, pasted or typed text, a
prompt written directly into the session — any combination. The one and only source of truth for "what
was supposed to happen." No inference, no guessing at unstated goals.seam A: prompt ↔ spec · seam B: output ↔ prompt · seam C: next-step ↔ any of the above
An observation point is the location/mechanism that gives the tool access to a piece of content — not a comparison, and not a tool in its own right. Git-diff, for instance, is a tool; the observation point is "the workspace file tree, watched via VS Code's file-watcher API," which git-diff operates inside of.
| Layer | Observation point | Status |
|---|---|---|
Spec / intent (SPEC.md etc.) |
VS Code file read/watch on the workspace file | Standard, low-risk |
| Prompt | Claude Code's session / chat log | Unconfirmed — see §4.6 |
| AI output | Same session log, response side | Unconfirmed — see §4.6 |
| Developer's next step | VS Code file-watcher + git-diff (working tree, not commit history) | Standard, low-risk |
A seam-check runs in the background continuously, for each seam, whenever that seam's pair of inputs is available. The flag is surfaced only when "still the same task" evaluates to false — a passing check produces no visible signal at all. For Seam C specifically, the triggering event is defined as: every file save, but only when that save contains an actual code change. The tool's attention is anchored to code changing, not to any timer or idle-detection — no code change, no check.
If a seam passes once, it is not yet decided whether it should be re-checked as the developer continues within what is nominally the same task window. This matters most for Seam C: the Stripe example above shows an early check passing cleanly while drift emerges several edits later, within the same apparent task. Whether Seam C needs continuous re-evaluation across a task's full duration, rather than a single point check, is left open for the next phase.
Every seam definition and the observation-point mapping above quietly assumes a VS Code extension can read a Claude Code session's prompts and outputs as they happen. That assumption is unverified. It is the single largest risk to the concept as scoped: if it is false, or only partially true, Seams A and B — both of which depend on reading the prompt and the AI's output — need a different architecture, and possibly a different integration point than "VS Code extension" entirely.
This is now the top research priority, ahead of any further concept-doc writing. A dedicated research prompt for this exact question, meant to be run against Anthropic's own documentation, is the next concrete step.
The tool watches continuously through the session, not only at the end. What it must never do is interrupt. The mechanism that satisfies both is ambient: a single, small flag indicator that appears somewhere in the editor chrome the moment a seam opens, changes nothing else, makes no sound, opens no modal — and reveals its content only when the developer clicks it. The tool does not grade severity or decide how much a given drift matters; it only notices that a seam opened. Whether it is a big deal or a shrug is the developer's judgment to make. Ignoring the flag costs nothing. That is the whole interaction model.
Everything in §§1–6 is about mechanism. This section is different in kind — it is about how strictly the tool should be trusted to mean what it reports. A policy question that surfaced directly while working through Seam A's false case, kept distinct from mechanics so the two don't get tangled.
At what point does a developer have the standing right to explore, trial-and-error, or research something unrelated to the spec — without the tool treating that as drift? And can that standard change mid-session, or must it be fixed for the whole task?
This is not a detection problem. Seam A already does its one job correctly when it reports "no traceable
connection between this prompt and SPEC.md."
The policy question is what happens after that report — how much weight the developer, or a team,
chooses to give it.
A seam-check can tell you a prompt has no traceable connection to the spec. It cannot tell you why — because "why" splits into two cases that look identical from the outside:
The spec was incomplete or didn't anticipate this, and the developer is right to go beyond it.
The developer has quietly wandered off the task, one reasonable-seeming step at a time, without meaning to.
Both produce the exact same raw signal: no connection found. The tool has no way to see the developer's reasoning, only their actions and their stated intent — and stated intent, by definition, doesn't cover things the developer hasn't yet said. Trying to make the tool guess which case it is looking at would mean giving it an opinion on the developer's judgment, which is precisely the thing "witness, not participant" rules out. The moment the tool starts deciding whether your reason is good enough, it has stopped witnessing and started managing you.
So this isn't a gap to close later with a smarter model. It is a permanent boundary, for the same reason the tool never grades quality: the tool's only claim is "no connection found." Whether that is a problem is always, unconditionally, the developer's call.
The distinction is genuinely useful — just not as something the tool computes. It belongs one layer up, as language the developer uses once they are looking at a raw comparison. A few ways it could show up in v1, in order of how soon they are realistic:
SPEC.md is treated as the
constant source of truth for the duration of a task, with no built-in "exploration mode" toggle in
v1. A seam-check flags any prompt or action with no traceable connection to it, every time,
without exception-handling for intent. The developer decides, per flag, whether that is new-but-justified or
new-but-drifted — and the documentation should actively teach that vocabulary rather than pretend the tool
can make the call. If a more flexible model (an explicit toggle, a declared research window) turns out to be
needed once there is real usage, that is a v2 conversation, not a v1 blocker.
.md, .pdf, pasted text, or a
prompt typed into the session, in any combination. Nothing more elaborate for v1.SPEC.md, and can that
change mid-session? Addressed in §7. Standing answer for now: constant authority for v1, no
exploration-mode toggle yet. Worth revisiting once there is real usage.Cognitive drift is what happens when AI-assisted development lets output outrun understanding — a thousand small, locally-reasonable acceptances that compound into a system nobody actually chose. Every current tool responds by adding another AI to the loop: more specs, more agents, more synchronization. This tool takes the opposite position. It watches a Claude Code session in VS Code — the spec you gave it, the prompt you wrote, what the AI produced, what you did next — and the moment a seam opens between what you meant and what's happening, it shows a quiet flag. Click it, and it tells you in one sentence, not a score: this is where you drifted. Ignore it, and it costs you nothing. It never writes, suggests, or scores. Its only job is to make sure you still recognize what you're building, and why.
AI should witness, not compete for cognition.
Sources behind the load-bearing claims above, verified against primary material where possible (mid-2026). Figures are attributed to their source and dated; where the evidence is thin or a source could not be independently re-verified in this research pass, that is noted rather than smoothed over.
Note on the "SmartBear / Swagger" mention (§3.1): stated from general knowledge of the API-spec tooling market and not tied to a specific dated source in this pass.