A developer named Building Better Tech did what more of us should probably do: they read the source code of the tool they use every day. In this case, Claude Code, Anthropic’s AI coding assistant.

What they found was a bunch of configuration options that don’t appear in the official documentation. Settings for customizing keyboard shortcuts beyond the basics. Ways to tweak the agent behavior. Hooks that let you run shell commands in response to tool events. The kind of stuff power users love and product managers agonize over.

The post hit Hacker News yesterday and sparked the usual debate about documentation completeness. But the more interesting question is why these features exist in the code but not in the docs.

The Documentation Problem Nobody Talks About

Here’s the thing about AI coding tools: they’re already overwhelming for most users. You’ve got context windows, model selection, permission systems, agent modes, tool calling, and half a dozen other concepts that didn’t exist in developer tools two years ago.

Every feature you document is another thing users need to understand. Another decision point. Another place where someone can get confused and blame the tool for being complicated.

So you end up with this tension. Power users want configurability. They want to customize keybindings, set up complex workflows, wire tools together in ways you never imagined. But documenting all that makes the tool look intimidating to the person who just wants to ask Claude to fix a bug.

The compromise is often what we see here: ship the features but keep them quiet. Let the people who care enough to dig into the source code find them. Everyone else gets a simpler mental model.

Permission Fatigue Is Real

Speaking of overwhelming UX, someone built a game called “Continue? Y/N” that’s just 60 seconds of approving AI agent permission requests. It’s clever satire, but it’s also pointing at a real problem.

AI coding tools constantly need permission. Can I read this file? Can I write that file? Can I run this command? Can I install this dependency? The permission model exists for good reason, obviously. You don’t want an AI agent recursively deleting your filesystem or pushing broken code to production.

But the UX is exhausting. Every context switch to approve a permission request pulls you out of flow. After the twentieth approval in a row, you stop reading what you’re approving. Which defeats the entire point of having a permission system.

This is the same problem browser security warnings ran into a decade ago. When you train users to click “OK” reflexively, the security theater doesn’t make anyone safer. It just makes the experience worse.

The Real Solution Isn’t Better Docs

The Claude Code configuration situation and the permission fatigue problem are related. They’re both symptoms of tools that are still figuring out their interaction model.

Should AI coding tools expose every possible configuration option, or hide complexity behind smart defaults? Should they ask permission for every action, or trust you to set high-level boundaries and get out of the way?

The answer is probably different for different users. Someone maintaining a production codebase needs different guardrails than someone experimenting with a side project. A developer learning a new language wants different behavior than someone working in their primary stack.

But right now, most AI coding tools give you one interaction model and expect it to work for everyone. That’s why you end up with undocumented power user features hidden in the source code, and permission dialogs that train users to stop paying attention.

The tools that figure out how to adapt to different users and use cases will win. The ones that just add more configuration options and hope users read the docs won’t.

What Developers Actually Want

If you’re building AI coding tools, here’s what matters: developers want tools that get out of the way. They want smart defaults that work for their context. They want to grant high-level permission (“you can modify test files”) rather than approving every individual file write.

And when they need configurability, they want to find it easily. Either document the advanced features clearly, or don’t ship them at all. Hiding functionality in the source code helps nobody. It just creates two tiers of users: the ones who know the secret handshake and everyone else.

The good news is we’re still early enough that these UX patterns aren’t set in stone. The bad news is most AI labs are so focused on model capabilities that they’re not spending enough time on the interaction design that actually determines whether developers will use these tools.

Someone building a 60-second game about permission fatigue shouldn’t be notable. But it is, because it’s one of the few examples of people actually critiquing the UX rather than just debating context window sizes and benchmark scores.

Read the source code of your tools. Build satirical games about bad UX patterns. Complain when the documentation doesn’t match reality. That’s how we get better tools.