Footguns and gerunds the developer slang shaping AI-assisted code

Smoke testing is the kind of phrase that sounds almost stupid until you have watched a build fail in the first 10 seconds and save everyone an hour of pointless clicking. In a real team, that is not a theory exercise. It is the thing that decides whether QA starts testing, whether a deploy gets blocked, and whether a broken feature gets dragged through three more meetings before someone admits the build was dead on arrival.

AI tools have added another layer to that old software vocabulary. A Claude-assisted workspace can sound like normal engineering one minute, then throw out words that feel half technical term, half private joke. If you work in web development, automation, or SEO scripting in South Africa, that mix matters. You need to know the old words well enough to spot a broken workflow, and the new slang well enough to tell when an AI has wandered into its own little theatre.

Smoke testing is the first decent lie detector

Smoke testing, also called build verification testing, is the quickest way to answer a blunt question: does this build even deserve more attention? It is broad, shallow, and deliberately unsentimental. You are not checking every corner of the application. You are checking the core path that tells you whether the thing is alive.

The term comes from hardware. Engineers used to power up a new circuit board and look for smoke, because smoke meant something had gone badly wrong. Software borrowed the same logic. If an app crashes on launch, breaks login, or fails a basic transaction, it has failed the smoke test and should be thrown straight back over the wall.

For web work, the usual smoke-test list is boring in exactly the right way. Open the homepage. Load the app. Log in. Add something to the cart. Hit checkout. Submit the contact form. If those basics fail, no one should be wasting time on deeper checks. The build is not ready, full stop.

That is why smoke testing fits CI/CD so well. The same handful of checks can run after each build without drama. It is repeatable, cheap, and brutally efficient. If you are shipping web code, automation scripts, or SEO tooling that touches live systems, this is one of the few habits that actually prevents chaos instead of merely documenting it.

Smoke testing and sanity testing are cousins, not twins

People often use smoke testing and sanity testing as if they mean the same thing. They do not.

Smoke testing is the wide check. It looks across the application after a new build or a major change and asks whether the whole thing still stands up.

Sanity testing is narrower. It comes after a bug fix and checks the specific module that was touched, plus the nearby features that might have been damaged in the process. It is more focused, more local, and less interested in the rest of the system.

If smoke testing is the building inspector walking through the whole structure and checking whether the lights come on, sanity testing is the plumber coming back after a repair to see whether the pipe still leaks. Teams that collapse the two into one usually end up with sloppy test habits and confusion about what failed.

The classic developer words still do the heavy lifting

Claude and other LLMs rely on ordinary software terms because those terms do real work. If you understand them, you can read an AI suggestion without treating it like mystical output from the machine god.

Refactoring is the clean-up job where code gets reorganised without changing what it does. Good refactoring makes the next developer faster. Bad refactoring just moves the mess into a different folder and adds confidence with no payoff.

Technical debt is the future bill you create when you ship the easy version now and promise yourself you will fix it later. That promise is often fiction. In practice, debt accumulates in login systems, script shortcuts, messy integrations, and the “temporary” patch nobody wants to touch before a client demo.

Boilerplate is the copy-paste material every project seems to collect. It is the startup code, wrapper code, and repeated glue that nobody loves but everybody needs. Idiosyncratic code is the opposite end of the spectrum, code written in a style so personal that the next developer has to decode someone else’s habits before they can fix the bug.

The standards language is where AI starts sounding polished

LLMs use the vocabulary of quality and style because it lets them talk about code in a way that sounds precise. Sometimes that is useful. Sometimes it sounds like a consultant who has never deployed anything.

Best practices are the methods people have settled on after enough failures to make the point obvious. Idiomatic code is code written in a way that feels native to the language it lives in. A Python solution should feel like Python, not like Java dressed in a fake moustache. Syntactic sugar is the convenient syntax that makes an expression easier to read or write. An antipattern is the wrong answer that keeps showing up because teams like shortcuts more than consequences.

Those terms matter when you are building real workflows. If you are generating SEO scripts, WordPress helpers, or automation around client reporting, the difference between idiomatic and merely functional code is the difference between something maintainable and something future-you will curse at 7am.

Deterministic and idempotent are the words that save you from weird bugs

When AI is helping with code, it will often talk about system behaviour in very precise language because those words describe whether a workflow can be trusted.

Deterministic behaviour means the same input gives the same output every time. That sounds obvious until a script behaves differently depending on timing, environment, or some hidden state in a global variable.

Idempotent operations are the ones you can run more than once without changing the result beyond the first pass. That matters in deployment scripts, API calls, and automation jobs. If you can press the button twice without wrecking the system, you are in better shape than most teams.

Bottlenecks are the points where everything slows down because one piece cannot keep up. Edge cases are the odd conditions that only show up when a user does something unexpected, like uploading a weird file, using a broken browser setting, or entering data in a format the happy-path mockups never considered.

Those terms are not decorative. They are how serious developers talk about why a stack falls apart under pressure.

Greenfield, brownfield, CI/CD, and LGTM are process words with real consequences

Greenfield means you are starting from scratch. No legacy baggage, no old database shape, no inherited WordPress plugin from 2019 that nobody dares uninstall.

Brownfield means you are working inside an existing system, which is most real jobs. That includes the messy website inherited from a predecessor, the SEO tracker built by someone who left the company, and the custom script that only one person knows how to run.

CI/CD, short for continuous integration and continuous deployment, is the automation layer that turns code changes into a repeatable build, test, and deploy flow. It is where smoke tests earn their keep.

LGTM means “Looks Good To Me”. It is the approval phrase in a code review when the reviewer is satisfied enough to let the code move. It sounds casual because it is casual, but in practice it is one of the few words standing between a clean merge and a future incident.

Claude has its own little language, and developers keep repeating it

The new slang around Claude is not a formal taxonomy. It is the kind of language that grows around tools when people spend too much time watching them think.

Claude Code, Anthropic’s command-line tool, swapped a plain loading spinner for 57 random bizarre words while terminal commands run. That is the sort of design choice that sounds like a prank until a team starts using it as a vocabulary source. The result is “gerunding”, a word developers use when the AI appears to be stuck thinking and spraying odd words at the screen.

There is also “honking”, used when the AI is clearly working hard. “Schlepping” describes Claude hauling a huge file or dependency tree into its context window, which is one of those beautifully specific developer insults that somehow becomes useful. “Claoding” is the self-referential verb for Claude doing Claude things. “Moseying” describes slow, low-priority background work. “Purring” showed up when developers asked Claude to read markdown files, such as `cat pr.md`, and noticed a distinct vibe around that action.

These are not formal terms in any standard manual. They are social markers. They tell the room that an AI is in the loop, and they do it with humour instead of corporate beige.

Vibe coding is real, and it is messier than the hype makes it sound

Vibe coding is the most honest piece of slang in the bunch because it names a real behaviour before anyone bothered to make it sound respectable. It means coding by talking to an LLM in plain English, without reading much code, writing much code, or fully understanding every line the machine produces. The human steers the mood. The AI drives the keyboard.

That sounds reckless because it often is. It can still be useful for quick prototypes, disposable scripts, or rough automation where the goal is to get to a working draft quickly. It becomes a problem when the team mistakes a generated draft for a system they actually understand.

The danger is not that the code exists. The danger is that nobody can explain what it does once it starts failing at 2pm on a Friday.

Claude-isms are the tell in the review comments

Claude’s style leaves fingerprints. It is polite, precise, and a little too academic when it is overconfident. That is why teams joke about phrases like “a rich tapestry of data” or “a testament to robust engineering” when they see them in PR comments or generated docs.

There is a broader pattern here. ChatGPT has its own text tell, often exposed by the word “delve”. Claude’s version tends to lean into careful framing, phrases like “Let’s ground our understanding…” or “It’s crucial to ensure…”. On a bad day, it takes an ordinary engineering idea and inflates it into something that sounds like a conference paper written by a polite robot.

You can spot this in coding advice too. A simple point about bundling items can come out dressed as a grand theory with unnecessary abstraction. The wording is neat. The substance may be plain. That mismatch is exactly why experienced developers keep their scepticism switched on.

Footguns are what happen when the software helps you hurt yourself

A footgun is a feature, API, or language choice that makes it easy to damage your own project by accident. The point of the word is not just insult. It is diagnosis. The tool is shaped in a way that invites mistakes.

JavaScript has long been the poster child for this kind of trap. `[] + {}` and `{ } + []` do not behave the way a new developer expects, because implicit type conversion turns simple expressions into nonsense. That is a footgun. It looks harmless until the language quietly changes the meaning of your code.

`rm -rf` is another classic. One typo, one empty variable name, and a command meant to clean up a directory can wipe an entire system. That is not edge-case drama. That is a direct line from convenience to disaster.

Global variables are another familiar trap. They seem simple when a script is small. Then one feature on Page 10 breaks a feature on Page 1 because both pieces touched the same shared state.

Overpowered APIs belong in the same category. If a developer only needs to read a user profile name, they should not be handed a token with full database deletion rights. That is not efficient design. It is an invitation to disaster with a nice interface.

The practical habit is to name the trap before it bites you

For South African teams building websites, running SEO automation, or wiring AI into client workflows, the useful habit is simple. Learn the language well enough to describe what is happening without fake certainty.

If a build is unstable, smoke test it before anyone sinks time into deeper QA. If a fix only needs a local confirmation, call it sanity testing and keep the scope tight. If the code smells like generated fluff, check whether it has been over-polite by Claude. If a function can ruin your day with one wrong input, call it a footgun and design around it.

The best AI-assisted developers are not the ones who worship the model. They are the ones who can read the output, name the failure mode, and keep the system from embarrassing them in front of a client.