Immune

Podcast 2 — In conversation

Speaker A: I was reading something about diplomatic immunity the other day, and it struck me that the word immune is doing very different work there from what it does when we talk about the immune system.

Speaker B: Yes, and yet the two uses are remarkably coherent once you know the word's history. Both come from the same original idea — exemption from a burden or a harm that everyone else is subject to. In the diplomatic context, it is exemption from the jurisdiction of the host country's law. In the biological context, it is exemption from the harm a pathogen would cause to an unprotected body. The logic is identical; only the domain changes.

Speaker A: That makes it easier to remember. So when someone says "I seem to be immune to his charm," they are drawing on that same idea?

Speaker B: Exactly. The metaphorical use is where immune gets its most interesting everyday life. "I'm immune to his excuses by now." "She seems completely immune to stress." In each case, the speaker means: something that would affect most people has simply lost its power over me. There is often a slight sense of hardening through experience — as if the speaker has been exposed often enough that the effect no longer registers.

Speaker A: Is there a difference between saying you're immune to something and saying you're resistant to it?

Speaker B: A significant one. Resistant implies partial or active defence — you are holding something back, but it still has some effect or could eventually break through given enough force or time. Immune implies complete protection — the threat simply cannot gain entry. In medicine, a resistant strain of bacteria can still be fought; an organism that is immune to a virus cannot be infected by it at all. In everyday use, you might say you're resistant to a bad habit and immune to a former obsession — the levels of defence are genuinely different.

Speaker A: What about invulnerable? That seems even stronger.

Speaker B: Invulnerable is total and absolute — it implies no vulnerability at all, in any direction. Immune is specific: you are protected against a particular threat, not necessarily all threats. A person can be immune to one disease and entirely susceptible to another. Invulnerable suggests a kind of comprehensive armour; immune is a targeted shield. In practice, immune is also much more natural in everyday speech — invulnerable tends to belong to mythology, gaming, and very dramatic rhetoric.

Speaker A: One last thing — is it "immune to" or "immune from"?

Speaker B: Both are correct, but they carry different nuances. "Immune to" tends to be used for threats, influences, or effects — immune to disease, immune to criticism, immune to flattery. "Immune from" tends to be used for legal obligations, penalties, or formal duties — immune from prosecution, immune from liability, immune from taxation. The distinction mirrors the word's two main streams: the biological and the legal. When in doubt: if the thing you cannot be reached by is an institution or a law, use from; if it is an influence or substance, use to.

Podcast 3 — Prompt engineering

Speaker B: Immune is a word that carries real precision in software engineering contexts. Systems, components, and users can all be immune — or dangerously not immune — to various classes of failure. In a prompt, immune tells the AI that you want absolute protection, not just mitigation. Five prompts.

Speaker A: I see that immediately — "make the endpoint immune to SQL injection" is a much stronger requirement than "sanitise the inputs."

Speaker B: The word raises the bar from hygiene to architecture. First prompt — JWT middleware immunity:

Prompt: Write a Node.js Express middleware function that makes all protected API routes immune to JWT bypass attacks. The middleware must reject tokens with the none algorithm, tokens with an expired or missing exp claim, tokens signed with an unexpected algorithm, and tokens where the payload has been modified after signing. Log every rejection with the reason and request IP. No route should be accessible if the token fails any of these checks.

Speaker B: The word immune here establishes the security requirement as absolute — not "handle some JWT attacks" but make the routes immune, meaning no bypass should be possible. Listing the specific bypass vectors — none algorithm, missing exp, wrong algorithm, tampered payload — turns this from a vague security requirement into an explicit specification. The AI will produce middleware that addresses each vector individually rather than writing generic token verification.

Speaker A: The none algorithm attack is the one that trips up so many JWT implementations — listing it explicitly is the difference between a secure and an insecure library choice.

Speaker B: Second prompt — React component immune to missing data:

Prompt: Build a React UserProfileCard component that is immune to breaking when any combination of its props is null, undefined, missing, or an unexpected type. The component should render gracefully in every degenerate state — no avatar, no name, no bio, all three missing, or receiving an object instead of a string. Use PropTypes or TypeScript for documentation. Write a test file that verifies immunity for each missing-data combination.

Speaker B: Immune to breaking on missing data is a precise architectural requirement. The phrase every combination pushes the AI toward exhaustive defensive rendering rather than just handling the obvious cases. The test file requirement — verifying immunity for each combination — means the specification is self-verifying. The component isn't declared immune until the tests pass.

Speaker A: Every combination is the key phrase there — most defensive coding handles the obvious missing cases but misses the combinations.

Speaker B: Third prompt — database foreign keys immune to cascade deletion:

Prompt: Design a PostgreSQL schema for a financial transactions system where the transactions table is immune to accidental cascade deletion. Parent records in the accounts table must never cause transaction records to be deleted. Enforce this with RESTRICT on the foreign key constraint, and add a database trigger that raises an exception if any operation attempts to delete an account that has associated transactions. Include an audit log table that records all attempted account deletions.

Speaker B: Making transactions immune to cascade deletion is a data integrity requirement with legal and financial implications. RESTRICT instead of CASCADE is the first line of defence, but the trigger is what makes the table genuinely immune — it intercepts even administrative attempts that bypass the application layer. The audit log adds accountability. Together, these three measures create a schema that is architecturally immune rather than merely policy-compliant.

Speaker A: The trigger is the critical addition — without it, a DBA with direct database access could still bypass the application's protections.

Speaker B: Fourth prompt — global handler immune to unhandled rejections:

Prompt: Write a Node.js application bootstrap module that makes the process immune to silent crashes from unhandled promise rejections and uncaught exceptions. Intercept both process events, log the full error with stack trace and timestamp to a file, attempt a graceful shutdown by closing active database connections and HTTP servers, and exit with a non-zero code so a process manager like PM2 can restart the service. The handler must never itself throw.

Speaker B: The handler must never itself throw is the self-referential immunity requirement that separates a robust error handler from a brittle one. An error handler that throws on unexpected errors is not immune — it is just moving the crash. The graceful shutdown sequence — close database, close HTTP server, exit with non-zero — is the standard production pattern. PM2 restart on non-zero exit ensures the process recovers automatically.

Speaker A: The "must never itself throw" constraint is easy to overlook but absolutely critical. I've seen error handlers crash the process they were supposed to protect.

Speaker B: Final prompt — endpoint security audit for middleware immunity:

Prompt: Write a Django management command that audits all registered URL patterns and identifies any endpoints that are immune from authentication middleware — either through the login_not_required decorator, explicit exemption in middleware settings, or missing inclusion in the protected URL namespace. Output a report listing each immune endpoint, the view it maps to, and whether the exemption is intentional based on a whitelist configuration file.

Speaker B: Immune from authentication middleware is here used in its legal sense — exempted from an obligation that all others bear. The audit command finds every such exemption and forces it to be classified as intentional or unintentional. The whitelist configuration file is the key mechanism: if an endpoint is immune but not on the whitelist, it is a potential vulnerability. This prompt produces a genuine security audit tool in one specification.

Speaker A: Five prompts — JWT bypass immunity, null-safe React components, cascade-proof schemas, unhandled rejection handlers, and endpoint security audits. Immune turned every one into an absolute protection requirement rather than a best-effort defence.

Speaker B: That is the word's engineering value. It raises the standard from "reduce risk" to "eliminate the vulnerability entirely." When you use immune in a prompt, you are telling the AI: partial protection is not enough. The system must be placed beyond reach.