AI Assumes Your Domain Knowledge

Claude gets better at code every few months. Better at planning, better at debugging, better at reading a repo and figuring out what's going on. What hasn't changed is the assumption baked into many responses: that you already know what it's talking about.

The Tech Stack Problem

Say you ask Claude to plan out a new project. It comes back with a stack. Maybe it's Next.js on Vercel with Postgres and Redis, maybe it's a Go service behind Nginx in a Docker container.

That's a reasonable recommendation. It's also possible you've never touched half of it.

The person running the prompts isn't always the person who knows the stack. This applies to programming languages, infrastructure, architecture patterns, deployment targets, all of it. Claude picks what fits the problem. It doesn't stop to ask whether you can maintain it after it's built.

Troubleshooting Is Where It Bites

Planning is the easy part. Things break later on in the process.

When something goes wrong, Claude explains the issue at its own level. You get a response about connection pooling or a race condition in your build step, and it assumes you can follow along. Sometimes you can. Sometimes you're three concepts behind and now you're debugging the explanation instead of the actual problem.

One team had specs in place after weeks of planning. Weeks into development, they hit an issue in a technology Claude had recommended and built with. Claude kept suggesting fixes that assumed experience they didn't have.

Make It Declare the Stack First

When you're using Claude to build out a plan, tell it to call out the full tech stack explicitly before any code gets written. Every language, every service, every piece of infrastructure it intends to use.

Now you have a list you can actually react to. If something on it is unfamiliar, you know that going in instead of finding out during your first outage.

Then Tell It What You Know

Once the stack is settled, add a section to your project's CLAUDE.md with an honest assessment of where you stand on each piece.

## My Experience Level

- Docker: Expert
- C#/.NET: Expert
- Angular: Intermediate
- Terraform: Beginner
- Snowflake: Beginner

Then add the instruction that makes it useful:

When explaining problems or walking through troubleshooting,
match your explanation to my listed experience level for that
technology. For Beginner topics, explain the underlying concept
before the fix. For Expert topics, skip the background.

That's the whole trick. Claude reads your background instead of guessing at it.

Why This Is Worth the Five Minutes

It gets you clearer explanations, and it keeps you from shipping things you can't support.

If you're a beginner in Snowflake and Claude knows it, you get context with your answers instead of a one-line fix you'll paste in without understanding. Six months later when it breaks again, you'll have some idea why.

The honest part matters too. Marking yourself as intermediate in something you've touched twice just gets you explanations you'll have to look up anyway.

After You Ship

After you ship, ask it to teach you about the technology you had it build with. Use the 80/20 rule: "Tell me the 20% about X that gives me 80% of the understanding." From there expand the topics until you at least have a high-level understanding.