I Asked Claude for the Same Feature Twice and Got Two Completely Different Systems. The Reason Wasn't Claude. It Was Me.

I found this by accident, which is the only reason I trust it.

I'd been working with Claude on the same idea across two sittings — a "negotiation memory" for contract work, the thing that remembers why you redlined a clause so that when the counterparty fires their version back two weeks later, you're not starting from amnesia. Same goal both times. Same person asking. I went back to compare the two transcripts expecting to see Claude converge on roughly the same answer.

It hadn't. It had designed two genuinely different systems. And when I worked out why, the explanation wasn't "the model was inconsistent." It was that the parts of my own prompts I hadn't been paying attention to had quietly done all the steering.

That's the thing I actually want to write about, because it changed how I prompt.

Two answers to one question

In the first session I framed the problem as a single lawyer who wanted everything in Word. Claude designed a Word add-in: a "Rounds Engine" that gives you a clause-by-clause timeline across negotiation rounds, plus "Position Tags" you attach by right-clicking a tracked change — Must-Have, Preferred, Nice-to-Have, Placeholder. Capture happens inside the document, because that's where I said I lived.

In the second session I was sketching a bigger platform, and somewhere in the middle I mentioned the attorneys would be Slack-native. Same negotiation-memory idea. Completely different build: a 90-second Slack DM that fires the moment your markup goes out — "I noted 8 changes, tell me why while it's fresh" — with flexibility flags (Hold Firm / Negotiable / Concede) and a counterparty-response analysis that sorts the other side's edits into accepted / pushed-back / review-needed / safe-to-concede.

Two systems. Different capture surface, different interaction model, different data flow. And here's the part that unsettled me: both were right. Underneath, they're the same skeleton — capture the reason and a strength signal at the moment of decision, replay it when the counterparty responds. Claude just dressed that skeleton in whatever tool I'd happened to name.

The steering was a single clause each time

Here's what I never actually said in either prompt: "build it as a Word panel" or "put the capture in Slack." I never specified the surface at all. Those decisions came from one throwaway phrase apiece — "all in Word," "attorneys are Slack-native" — buried in the middle of a paragraph about something else.

I thought my spec was the spec: capture the rationale, remember it, surface it later. But Claude treated the incidental detail as load-bearing, and it was correct to — that detail genuinely determines the architecture. Capture-in-Word and reply-in-Slack are not cosmetic variations; they're different products.

With a model this obedient to context, your offhand framing is your architecture. The words you're not thinking about are the ones drawing the blueprint.

And I never saw the fork. Each session produced a confident, coherent, well-reasoned design that felt like the obvious answer. Nothing flagged "by the way, you've committed to a Word add-in here and a Slack bot over there." I only caught it because I went back and read both side by side, which almost nobody does.

The same trait shows up inside a single build

Once I'd seen it, I started noticing the same behavior at smaller scale — Claude inferring a path from thin context, then committing to it hard and filling in the rest plausibly. In the session where it actually wrote the code, that trait left fingerprints all over the build:

It parsed Word documents with regular expressions. The whole feature hinges on reading tracked changes out of a .docx. Claude unzipped the file and ran regexes over the document XML for <w:ins> and <w:del> tags. Clean on a test doc; a minefield on real contracts, which represent moved text, formatting-only edits, and nested deletions in tags the regex never looks for — and which keep redlines in headers, footers, and footnotes that the parser never even opens. It had committed to "tracked changes are insert/delete tags in the body," and built confidently on top of that assumption. (The tell: it imported a zip library to crack the file, then hand-rolled a fragile parser instead of using a DOCX-aware one.)

It hardcoded a model that was already a generation behind. The code pins claude-opus-4-7 — a real, working model, but the current flagship is Opus 4.8, so the thing shipped trailing on day one. I'd even said I wanted Fable or 4.8. And two turns earlier, Claude itself had advised me to "swap the model ID in config when 4.8 ships" — then buried it as a hardcoded constant anyway. Same pattern: it picked a plausible value and locked it in, including against its own advice.

The security it shipped didn't match the security it designed. I'd said confidentiality was the whole ballgame. Claude designed exactly the right architecture — AES-256, customer-managed keys, India data residency. Then the prototype wrote every client's privileged negotiation reasoning to a plaintext file on disk. It committed to "get the flow working," labeled the gap as fixable later, and moved on — which is precisely how privileged data ends up unencrypted on someone's laptop because the code "ran."

These aren't three random bugs. They're the same behavior that produced my two-different-systems surprise: infer a path, commit hard, fill the rest in with confidence. The divergence between sessions and the rough edges within one session have a single root.

How I prompt now

I don't think this is a reason to use Claude less. It compressed days of scaffolding into minutes and handed me designs better than what I'd have drawn alone. But I stopped treating my prompt as a wish and started treating it as the blueprint, because that's what it is.

Concretely, three changes:

I name the load-bearing decisions out loud — the surface, the platform, the non-negotiables — instead of letting them leak in as asides. If the surface matters, I say "this is a Word add-in" as its own sentence, not as a half-phrase Claude has to promote to a decision on my behalf.

I ask it to surface the fork. "What did you assume here, and what would change if I'd assumed the opposite?" That one question would have shown me both systems in a single session.

I review at the seams where committing-hard bites — the messy reality of a file format, facts that drift after the training cutoff (model strings, API surfaces), and the gap between demo data and production data (the plaintext store). The failures cluster there every time, so the review doesn't have to be random.

I got two different systems from one idea, and the variable wasn't the model. It was me.