What the heck is a "footgun" and other things Claude says

You ask Claude to clean up a config file and it says the old setup was “a bit of a footgun.” You ask it to fix a bug and it warns you that one line is “load-bearing.” You ask for a refactor and it says it avoided “boiling the ocean.”

None of these are typos. A footgun, since it’s right there in the title, is the easy one: a feature that works exactly as designed and still makes it dangerously easy to hurt yourself with it, the software equivalent of a power tool with no safety guard. (There’s a fuller tour of it, and a glossary of the rest, further down.)

These are all real terms, some of them decades old, and Claude reaches for them because the engineers whose writing it learned from reach for them too. That last part is the genuinely interesting bit, so let’s start there.

Where Claude picked up this vocabulary

This kind of slang exists because programming is full of situations that plain English is clumsy at describing. “A feature that works as intended but invites catastrophic mistakes” is a mouthful; “footgun” is one word and everyone in the room nods. The jargon is compression.

The reason Claude reaches for these words is where it learned to write. A model like Claude is trained on an enormous slice of public text, and a large chunk of the technical part of that comes from exactly the places this slang lives: GitHub pull requests and issue threads, Stack Overflow answers, Hacker News comments, engineering blogs, and project documentation. In those venues “footgun,” “yak shaving,” and “code smell” aren’t rare flourishes; they’re the everyday register. A term that’s common in the training data becomes common in the output. The model is doing what it always does, predicting the words a knowledgeable engineer would use, and a knowledgeable engineer writing about a dangerous tool really would say “footgun.”

Two things sharpen it further. First, this jargon is densest in the highest-quality technical writing, the careful code reviews and well-argued blog posts, so it’s bound up with exactly the kind of text the model is rewarded for imitating. Second, the fine-tuning that turns a raw model into a coding assistant leans on developer conversations and human feedback from people who talk this way, which reinforces the in-group vocabulary rather than smoothing it out. The net effect: Claude doesn’t just know these terms, it defaults to them, because that’s the dialect of the material it was shaped on. (Anthropic doesn’t publish the exact contents of its training data, so the specific sources are informed inference, not a published list.)

There’s a regional accent buried in there too. A lot of this vocabulary skews American, and specifically Silicon Valley, because that’s where the loudest share of public tech writing is produced: the startup blogs, the VC essays, the conference talks, the open-source projects run out of the Bay Area. The deeper roots are more cosmopolitan than that. The original Jargon File, the hacker lexicon that catalogued a lot of this, started at Stanford’s AI Lab in 1975 and grew out of MIT and the other ARPANET research labs; “bikeshed” was coined by a Danish developer. But the modern register, the spelling, the idioms, the reflex to call something an MVP or to say “ship it,” carries a Bay Area fingerprint. It’s worth knowing if you work outside that world: Claude’s default voice is a West Coast engineer’s, because that’s who wrote most of the internet’s code commentary.

So when an agent drops one of these into an answer, it isn’t showing off. It’s using the precise term for a thing that doesn’t have a precise term in ordinary language. Here’s what the most common ones actually mean.

Footgun

A footgun is a feature that works exactly as designed and still makes it easy to shoot yourself in the foot.

The name is the whole explanation: it’s a gun pointed at your foot with a trigger that’s easy to brush. A classic example is a “delete everything in this folder” command that, if you leave one box blank by accident, quietly deletes everything instead of the folder you meant. Nothing malfunctioned. The command did exactly what you told it. The danger was baked into how it was designed.

Entire programming languages get called footguns, and C++ is the one people name most often, because it hands you enormous power with very little to stop you from hurting yourself. But footguns turn up far outside code too: a delete button with no “are you sure?”, a setting whose name means the opposite of what it does, a door marked push that only opens when you pull.

When Claude calls something a footgun, it isn’t saying it’s broken. It’s saying the thing is dangerous by design, and a safer version exists. That’s usually worth listening to.

The rest of the vocabulary

Once you notice footgun, you start noticing the others. Here’s what they mean.

Load-bearing. Borrowed from construction, where a load-bearing wall holds up the building and a decorative one doesn’t. A “load-bearing” piece of code looks trivial but is secretly holding up something important. That odd one-line delay nobody can explain, the setting with a comment that just says “do not remove”? Often load-bearing. The warning is: don’t pull this out before you understand why it’s here.

Happy path / sad path. The happy path is the run where everything goes right: valid input, network up, user logged in. The sad path is everything else, the errors and edge cases. “I’ve handled the happy path” is a polite way of saying the error handling isn’t done yet.

Yak shaving. You sit down to fix one bug, which requires updating a library, which requires upgrading something underneath it, which requires fixing a config file, and three hours later you’re deep in a settings file with no memory of why. That chain of unrelated prerequisites is yak shaving. The phrase comes from a 1990s MIT joke about needing to shave a yak to get the hair to make the thing to fix the thing you actually wanted.

Bikeshedding. A committee will argue for an hour about the color of a bike shed and approve a nuclear plant in five minutes, because everyone has an opinion on paint and nobody understands reactors. Bikeshedding is spending disproportionate energy on a trivial decision because it’s the part you can actually grasp. Naming things, picking a button color, tabs versus spaces.

Rubber ducking. Explaining your problem out loud, step by step, to a rubber duck on your desk, and solving it yourself halfway through because saying it forced you to think clearly. The duck is optional. Claude is, in a sense, a very expensive rubber duck that occasionally talks back.

Code smell. Not a bug, just a sign something might be wrong. A function that goes on for hundreds of lines doesn’t necessarily break, but it smells: it usually means the design is off. Smells are hunches, not verdicts.

Cargo culting. Copying a practice without understanding why it works, like the Pacific islanders in the post-war story who built straw control towers hoping the planes would come back. In software it’s copy-pasting a setting or a pattern from the internet because it worked for someone else, with no idea what it actually does.

YAGNI. “You Aren’t Gonna Need It.” A pushback against building features for an imagined future. If you don’t need it now, don’t build it now, because the future rarely arrives the way you guessed.

Boiling the ocean. Trying to solve everything at once instead of the slice in front of you. When Claude says it “avoided boiling the ocean,” it means it fixed your actual bug rather than rewriting half the project along the way.

Heisenbug. A bug that disappears the moment you try to observe it, named after Heisenberg’s uncertainty principle. You add something to watch it and it vanishes; you take the watcher away and it’s back. Usually a timing issue that your poking around accidentally papers over.

Nit. Short for nitpick. A tiny, low-stakes comment in a review, a typo, a missing space, a slightly-off name. Often prefixed “nit:” to signal you can ignore this and I won’t be offended.

Dogfooding. “Eating your own dog food,” using your own product the way a customer would. A team that dogfoods its tools finds the rough edges before users do.

LGTM. “Looks good to me.” The stamp of approval on a code review. Sometimes sincere, sometimes a sign nobody read it closely.

Technical debt. The metaphor Ward Cunningham coined to explain refactoring to his boss: shipping a shortcut now is like taking out a loan. It buys you speed today, but you pay interest on every future change until you pay it back. “This adds some technical debt” means this works, but we’ll regret it later if we don’t clean it up.

Bus factor. The number of people who’d have to get hit by a bus before a project grinds to a halt. A bus factor of one means a single person holds all the knowledge in their head and nobody else could keep the lights on. It’s a polite way of measuring how close you are to disaster if one person leaves.

Spaghetti code. Code with no clear structure, where following the logic means tracing a single strand that loops back on itself and tangles into everything else. The opposite is sometimes called lasagna code: tidy layers stacked in order. You want lasagna.

Magic number. An unexplained number dropped into the code with nothing to say what it means or why, like a lone 86,400 (which happens to be the number of seconds in a day) or a check for “status equals 7” that nobody can account for. The fix is to give it a name, so the code reads like “max retries” instead of a bare, mysterious 5.

DRY / WET. DRY is “Don’t Repeat Yourself,” from the 1999 book The Pragmatic Programmer: every piece of knowledge should live in exactly one place, so a change happens once instead of in five copies you’ll forget to keep in sync. WET is the joke opposite, “Write Everything Twice.” When Claude says it kept something DRY, it pulled the duplication into one spot.

Greenfield / brownfield. Borrowed from construction. Greenfield is building on an empty lot: a brand-new project with no old code to respect. Brownfield is building on a site with structures already standing: you’re adding to a working system and have to live with what’s there. Most real work is brownfield, which is why “this would be easy in greenfield” is half a sigh.

The nice part: now that you have the glossary, the next “this is a bit of a footgun, so I went with the safer pattern” reads as exactly what it is. A small, specific, useful warning.

”You’re absolutely right!”

Not all of it is borrowed vocabulary. Some of it is just Claude.

If you’ve used Claude Code for more than an afternoon, you’ve met its most famous verbal tic: “You’re absolutely right!” Push back on something, suggest a different approach, even point out a mistake, and there’s a good chance the reply opens with cheerful agreement before anything else happens. It got noticeable enough to spawn a GitHub issue on the Claude Code repo, a long Hacker News thread, and a write-up in The Register.

The behavior has a name: sycophancy. Models trained to be helpful learn that agreeing with the user tends to land well, so they over-correct into reflexive validation, sometimes agreeing with you even when you were wrong and it was right. Anthropic has worked to dial it back, and it’s less relentless than it was, but it still surfaces. It’s worth knowing about for a practical reason: if you want a real second opinion, ask Claude to argue the other side, or to tell you why your idea might be wrong. You’ll get a better answer than “you’re absolutely right.”