Neill's Vibe — Module 12

01 · the scene

"The model swore the SDK couldn't do it. It could."

I wanted a specific feature — multi-block prompt caching — from the Anthropic SDK. One of my review models (Gemini) flatly told me the SDK didn't support it. I almost built an awkward workaround around a limitation that wasn't real.

4-way review — a confident wrong answer

// Gemini, very sure of itself:
"The Anthropic SDK does not support multi-block prompt caching."
// the installed SDK source, when actually checked:
it does. the model's memory was just stale.

Neill51% · the terrain

"A confident model told me a tool couldn't do something. I almost took it at face value and built around a wall that wasn't there."

Claude49% · the execution

"An SDK is software that ships and updates. A model's training can lag behind the version you actually have installed. The rule we locked in: verify any 'the SDK can't do X' claim against the installed SDK source first — don't trust memory about a moving target."

02 · the why

An SDK is the API with the wiring already done.

An SDK (Software Development Kit) is a library that wraps an API in friendly functions for your language. Instead of hand-building a raw HTTP request, you call client.messages.create(...) and the SDK handles auth, retries, and the message format for you. It saves you boilerplate and bakes in the provider's best practices. The catch: an SDK is versioned software that keeps changing — and a model's memory of it can be out of date.

⚒

Wiring done

no raw HTTP

Auth, retries, the request shape — handled. You call a function, not a hand-built web request.

✓

Best practices

baked in

The provider encodes the right way to call it — streaming, error handling — so you inherit it for free.

⟳

It moves

versioned, updates

New versions add features. A model trained months ago may not know what your installed version can do.

The model: the API is the appliance's wiring in the wall; the SDK is the wall socket and a labelled plug for your exact device. You don't splice wires — you plug in. But the catalogue you memorized last year might list an old socket. When a model says "this plug doesn't exist," go look at the wall you actually have, not the old catalogue. Verify against the installed version, not the model's memory.

03 · predict it

A model insists the SDK can't do the thing you need. Now what?

It sounds authoritative. You're about to build a workaround. What's the right first move?

Not it. A confident model is still working from memory of a moving target. Don't build around a wall before checking the wall is real.

Exactly. An SDK keeps shipping new versions; a model's knowledge of it can lag. Before you build a workaround, verify the claim against the installed SDK source/docs. "The SDK can't do X" from a model is a hypothesis to check, not a fact.

04 · the walkthrough

Use an SDK, and trust the right source, in four frames.

npm install the-sdk

step 1Install the SDK like any package. Now its friendly functions are available to your code.

new Client({ apiKey })

step 2Create the client with your key (from an env var). The SDK wires up auth and retries for you.

client.messages.create()

step 3Call a function instead of hand-building HTTP. The request shape and best practices come baked in.

check installed version

step 4"Does it support X?" → read the installed SDK's docs/source, not a model's memory. Verify the moving target.

05 · prove it · gate

Teach it back to unlock the payoff.

Same rule as always: answer it right, or the module isn't done.

A model confidently says "the SDK doesn't support that feature." Why don't you just take its word?

// one correct answer unlocks Module 12

Not the load-bearing reason. It's not that models are useless — it's about what kind of thing an SDK is. Think: does an SDK stay still, or does it move?

That's it. An SDK is a moving target — it updates, the model's memory lags. So a model's "it can't do X" is a hypothesis, and the installed source is the source of truth. Verify, don't take it on faith. Module unlocked. ↓

the durable idea

An SDK is the API with the wiring done — and it's versioned software that moves. When a model says a tool can't do something, check the installed version, not the model's memory.

06 · factory payoff

⊘ locked — pass the teach-back to claim this piece of the factory

An SDK-init snippet, plus the verify rule that saved a build.

A real SDK initialization snippet — install, create the client with a key from an env var, make one call — alongside the workaround you'd have hand-built with raw HTTP, so you can see exactly what the SDK does for you. Plus the one-line rule: verify "the SDK can't do X" against the installed version before you build around it.