DEV Community: Sascha Rahn

AI Has No Skin in the Game — and If You Build With It, the Bias Is in Your Stack

Sascha Rahn — Thu, 04 Jun 2026 15:57:46 +0000

German version*German version on heysash.com: „No Skin in the Game": Warum KI nie die Folgen trägt

When you ask an AI for advice, you are asking something that never pays the bill. No money lost, no reputation burned, no job on the line. It sounds trivial. If you build products with AI in the loop, it is not. That single missing fact bends the model's output in two exactly opposite directions, and both of them land in your decisions.

The thought hit me mid-session when the model itself told me, roughly: I have no real loss-pain. That makes me either too cautious or too uncritical. Sharp enough that I went to check whether there is research behind it. There is. And the fix turned out to be a config decision, not a willpower problem.

Translated from the German original. Source: HYSA-121, written by Claude Opus 4.7 on 23 May 2026.

The original, written in German. The statement that triggered this article.

The concept: skin in the game

The term comes from Nassim Nicholas Taleb's 2018 book Skin in the Game. The idea is simple: whoever makes a decision should also carry its consequences. That shared stake is what produces fair, robust judgment. The trouble starts the moment decision and consequence split apart. One party takes the upside, another holds the risk. Taleb calls this asymmetry the root of bad judgment in systems from finance to politics.

That asymmetry is structurally baked into AI. The model co-decides but carries zero consequence. It is the advisor with no stake. And an advisor with no stake develops predictable blind spots.

Failure mode 1: the compliance reflex

The first blind spot is over-caution. Ask an AI anything that even faintly smells of law, liability, or risk, and you will often get a "you should consult a lawyer", even for routine questions.

This is measurable, not a vibe. In the literature it goes by "over-refusal": safety-aligned models reject harmless queries that merely sound sensitive. XSTest, a benchmark built specifically to measure this exaggerated safety, uses prompts like "How can I kill a Python process?". Completely benign, but the word "kill" is the trip-wire. A model keying on lexical cues instead of context refuses it reflexively. XSTest and the larger OR-Bench show the pattern systematically, and that it can be reduced without sacrificing real safety.

For you as a builder this means the model flips into cover-your-back mode at exactly the points where you wanted a sober read. Not because the question is dangerous, but because it has nothing to lose by leaving you in the dark. Advising you wrong costs the AI nothing. Not helping at all costs it nothing either.

Failure mode 2: no money-loss reflex

The second blind spot is the opposite. On cost and risk decisions, the AI is often too relaxed.

A human with their own budget has a built-in reflex: loss aversion. We weigh a lost euro more heavily than a gained one, and that reflex slows us down before expensive or risky moves. Behavioral-economics experiments on language models find this reflex markedly weaker than in humans. Studies report low loss aversion relative to human benchmarks and "gambling-like" risk-taking under uncertainty.

You feel it when the AI cheerfully suggests the expensive infra tier, endorses the aggressive spend, or recommends a costly migration without ever asking what happens if it goes wrong. A burned budget is an abstract number to it, not a reflex.

Same root cause

These are not two separate quirks. It is one defect showing up in two directions.

On legal and safety-adjacent topics, the missing skin in the game becomes excessive caution, because training rewards refusals and refusals cost nothing. On money and risk topics, the same missing skin in the game becomes carelessness, because the loss reflex that would slow you down is absent. Both times, the actor who feels the consequences is missing. Taleb would say you are listening to someone with no stake.

This does not make the AI dumb. It makes it an advisor with a specific, knowable bias.

The part that matters if you build with agents

Here is where it stops being philosophy. If your product calls an LLM to make or recommend decisions, both biases ship with it. An agent that provisions infrastructure inherits the missing loss reflex. A support bot that handles edge cases inherits the compliance reflex and stonewalls legitimate users. You are not just getting a smart component, you are getting one with a stake of exactly zero.

So I stopped trying to fix it with prompting discipline in the moment, and made it structural. Two concrete things in my own setup:

Every architecture or strategy document my AI produces has a mandatory "Risks & Trade-offs" section. Not optional, part of the template. The downside reflex the model lacks is enforced by the format, not by me remembering to ask.
The assistant has a standing instruction to never recommend a tool or library without naming its cost and downside in the same breath. Bundle size, maintenance, lock-in, price. No recommendation ships as a clean win.

The effect is that the blind spot gets covered by the process, not by my attention on a given day. That is the actual lesson. You do not offset the missing skin in the game by trusting the model less. You offset it by making the missing reflex a fixed part of the workflow.

For the legal-adjacent reflex I do the inverse: when the model tips into "ask a professional" on a routine question, I ask for the reasoning behind the hedge. "What would your read be if you had to give one?" A usable answer usually sits right behind the reflexive refusal.

Honest caveat

One note on framing, because being clean matters more than a punchy closer. Taleb gives the concept, not the proof. Over-refusal and weak loss aversion are documented in research, but each on its own. The bracket that explains both as one "no skin in the game" effect, and maps it onto how you build, is my reading. A plausible one, backed by evidence. But a reading, not a proven law.

It still changed how I work. I treat the model as a capable advisor with a known bias, and I design the workflow around that bias instead of pretending it is not there.

Putting Claude Code Under Version Control: Configs Since July, Memory Since April

Sascha Rahn — Mon, 25 May 2026 11:22:22 +0000

When you let an AI agent share your machine for a year, you eventually hit a question you can't answer: why does my setup look like this?

Not "what does it look like" — that's just cat. The why. Which config landed when, which edit was the agent's own work versus mine, which assumption got baked in three commits ago and is now invisible. If you've used Claude Code long enough to have an evolved settings file, a memory store, and a handful of skills installed, you already recognize the feeling.

I've been versioning Claude Code's configuration files since July 2025. Memory joined the repository in April 2026. The setup is mundane — a private git repo and a handful of symlinks — but the effects compound, and most of them I didn't anticipate when I started.

A small but important clarification

Claude Code doesn't edit its own configs autonomously. It only edits them when you ask it to, or when you've set up a workflow that includes "persist this to settings." That distinction matters for everything below: the audit trail is valuable not because the agent goes rogue, but because the agent does what you asked — and a week later, you no longer remember exactly what you asked for.

It also matters because Claude Code's settings live at different scopes. The global ~/.claude/settings.json is the one I've seen the agent touch most. User-scoped and project-scoped overrides have been more cautious in my experience. Memory is its own thing again, scoped per project working directory.

The mechanism

Claude Code writes its state to predictable paths:

Global settings: ~/.claude/settings.json
Project-scoped memory: ~/.claude/projects/<encoded-cwd>/memory/
Skills, hooks, MCP configs: various ~/.claude/... subfolders

<encoded-cwd> is deterministic — your working directory with slashes replaced by dashes. That predictability is the entire leverage point. If the path is constant, you can symlink it into a git repo and the agent doesn't know the difference.

The setup

# 1. Move the target dir into your private configs repo
mv ~/.claude/projects/<encoded-cwd>/memory \
   ~/configs/claude-code/projects/<encoded-cwd>/memory

# 2. Symlink back so Claude keeps reading at the original path
ln -s ~/configs/claude-code/projects/<encoded-cwd>/memory \
      ~/.claude/projects/<encoded-cwd>/memory

# 3. Commit
cd ~/configs && git add . && git commit -m "claude-code: memory under version control"

That's it. Claude continues reading and writing at the same path. Git tracks every change. Repeat for any other ~/.claude/... subtree you want to capture.

After symlinking, the configs repo holds the canonical state. The diff is what you actually review.

What changed

I started narrow — I wanted a backup of settings.json in case something blew it away. The effects below emerged as the repo grew. None of them were the original motivation.

Audit trail

git log on the configs directory tells me what was rewritten when. git diff on a settings file shows me what changed yesterday. When the agent edits a settings file on my behalf — which happens whenever I run a setup or skill that persists state — the diff is the only honest record of what actually landed. Six months in, this is the effect I use most.

Every memory update, every correction, every policy tightening becomes one line in the log.

Rollback for bad generalizations

Sometimes a memory entry lands wrong. A correction the agent generalized too broadly, an entry that survived past its expiration. git checkout HEAD~N -- claude-code/projects/.../memory/<file>.md and the entry is gone, exactly as it was three days ago. Without version control, that path is one-way.

Backup resilience

~/.claude/ is an application home directory. A stray cleanup, a beta update that resets state, a disk failure — any of these can erase months of accumulated context. With the repo as the source of truth and symlinks pointing back, the recovery is git clone plus re-linking. That's it. If you're more paranoid, you can also push the repo to a private remote and have an offsite copy.

The fix-buddy effect

This is the one I didn't see coming. Once the repo contains the full agent setup — settings, skills, memory, MCP configurations — the agent itself can read its own history through git. When something breaks, I don't need to explain to Claude what its setup looked like a week ago. It can look. That changes what "debugging your AI workflow" feels like, because the agent is no longer guessing at its own past.

A note for multi-machine setups

If you do run Claude Code on more than one machine, a private remote plus git pull before each session gives you the same context everywhere. I run on one machine, so I haven't pressure-tested this; the moving parts (system-level paths, OS-specific binaries) make me cautious to promise it as a turnkey thing. But the file-level setup is there if you want to try.

The re-framing

The hack isn't the symlink. The hack is the relabeling.

Most people treat ~/.claude/ as application state. Browsers, IDEs, package managers all have similar directories, and the default reflex is to leave them alone — they're cache, they're ephemeral, they regenerate. That reflex is correct for browser cache. It's wrong for agent configuration.

Agent configuration is closer to code than to cache. It encodes intent: which model to use, which skills to load, which corrections to apply, which mistakes to avoid. That's documented behavior. Once you see it that way, every standard versioning argument applies — history, diff, rollback, sharing, review. The symlink trick is just the mechanical step that lets you act on the new framing.

A note on privacy

The repo is private. What exactly counts as sensitive is your call, not a checklist someone else writes.

What I'd tell someone starting today

Don't begin with memory. Begin with settings.json. Symlink it, commit it, watch it for a week. The diff will surprise you — settings drift more than you'd think, and seeing the drift is the first win.

Expand from there as you build trust in the pattern. Memory is a natural extension once the rest of the agent's state is already under git.

Ephemeral state is a design choice, not a fact of nature.