Agent Skills: Cringe-Nudge

Cringe-Nudge

Start with the tweet

We are solving the so-called literacy crisis using tech. Get this: tech thinkfluencers publically reinvent disciplines like epistemology of mind & hermeneutics from first principles and do such an appalling, embarrassing job that people try books again. It's called cringenudging.

Do you get the joke? (You should — read it again if not.)

The joke is that tech "solves" the literacy crisis by accident. The mechanism isn't a product. It's that tech thinkers keep wading into deep, well-developed humanities fields — epistemology, philosophy of mind, hermeneutics — and reinventing them from first principles, on the assumption that raw cleverness beats centuries of accumulated thought. They do it so badly that the secondhand embarrassment drives people back to the actual books. "Nudging" is from behavioural economics (subtly steering people toward better choices); the cringe-nudge is steering them toward the real sources by being so bad at the ideas that the originals look good again. It's a backhanded insult dressed as a compliment: the industry's best contribution to reading is making itself cringe.

Why this matters for a code review

Here's the thing: this happens constantly in software, and it's usually invisible. When you architect something, you're very often reinventing — in your business logic — a thing that has already been examined and battle-tested far more deeply elsewhere. AI features are the worst offenders, because they put us in the business of modelling reasoning, which is precisely the territory other disciplines have spent careers mapping.

Some real examples of the pattern:

• Assessing LLM decision-making by breaking an answer into individual factual claims and scoring each one. It feels rigorous, then you immediately drown in edge cases: competing inputs, overlapping claims, claims that are only true conditional on others. There is a whole field — jurisprudence (conflict-of-norms, lex specialis/posterior), and argumentation theory / defeasible reasoning — that has already mapped exactly how to resolve competing and overlapping grounds. A naive "fact-by-fact" rollup is reaching for, and failing at, something that already exists in a much richer form.
• A customer-interview agent given an "empathetic persona" and a pile of fragile hand-written instructions about how to probe the user. There are established frameworks — e.g. Deploy Empathy (Michele Hansen) — that lay out how to interview without leading the witness, immediately applicable instead of improvised.

The point of this skill is to catch those moments. Not to send reading recommendations — to find the specific, applicable, battle-tested framework the author hasn't realised exists, and show how borrowing its form (often just a richer schema) dissolves a class of edge cases they'd otherwise hit one painful bug at a time.

The primary input is implementation plans / architecture docs (cheaper and higher-leverage to catch it before it's built), but inputs are arbitrary — a diff, a PR, a design sketch, a description in chat.

The thing to get right: the bar is high, and silence is the default

Most code is not a pseudo-framework reinventing a discipline. If this skill fires on ordinary changes — "have you considered Dung's abstract argumentation frameworks for your validation helper?" — then it has become the cringe it was mocking. Its value is inverted from a normal linter: rarely triggered, high signal when it does. Skepticism is a feature here, not an afterthought.

So: we generate proposals, then we score them hard, and only keep what is genuinely useful. That is not a low bar. We do not change things for a tiny benefit. We are looking for true cringe-nudge cases — where the established framework makes the current solution look comparatively naive.

The process

Step 0 — Detect (the gate). Default to nothing.

Look at the input and find candidate homegrown frameworks. Random changes aren't useful. You're looking for places where the author is encoding a model of some real-world reasoning or behaviour: a taxonomy/vocabulary, a scoring or aggregation scheme, a classification of relationships (e.g. conflict/overlap), a decision procedure, a state machine, a persona/protocol. The dead giveaway is a "framework" or pseudo-framework in an arbitrary sense — be careful not to over-specify what form it takes.

For each candidate, you must be able to complete this sentence crisply:

"This code models <real-world reasoning/process> with a homegrown encoding <X>."

If you can't name a real-world reasoning process being modelled, it's not a candidate — drop it. "You built a scoring rollup" is not a candidate (every app does that). "You built a scoring rollup that is secretly a theory of how evidence aggregates into a verdict" is.

Worked detection example. We were building an agent to assess development applications. We needed confidence in the accuracy of its answer, so we broke the answer into individual sub-answers and scored accuracy individually to produce a final score — framework #1. We then built on top of that to track where the planning scheme (in the agent's context) contained competing policies, lowering confidence where conflicts made the decision less clear — framework #2, which had been naively conflated as one big framework with the first. Two distinct homegrown frameworks, both modelling real reasoning processes (evidence aggregation; norm conflict). Both are candidates.

If there are no candidates, say so and stop. That is a successful, common outcome.

Step 1 — Classify and route each candidate

Each candidate is one of two kinds. They are not symmetric — route, don't always fork:

• General-discipline reinvention (rarer, harder, highest value): a real intellectual discipline has studied this. Jurisprudence, argumentation theory / informal logic, epistemology, hermeneutics, interview/empathy methodology, decision theory, belief revision. This is the tweet's literal target.
• Software-domain reinvention (more common, cheaper to spot): an established in-domain pattern the author hasn't recognised — you've hand-rolled a state machine, a saga, a CRDT, a rate limiter, a parser combinator, an existing standard's data model. Narrower than the tweet meant, but the same bucket — keep the two cleanly separated in the output.

From here, use an agent team — one agent per candidate (or per direction), running in parallel.

Step 2 — First principles, then deep research

For each candidate, in order:

1. First principles first. Using your own ingrained knowledge, name broadly what disciplines or patterns could inform a more robust, proven solution. Cast wide; it doesn't have to be domain-related.
2. Then deep research for the specific, named framework you could adopt. "Framework" is the key word — this is practical, not a reading list. We don't want "go learn jurisprudence." We want "here is Dung's abstract argumentation framework / the lex-specialis conflict rule / Toulmin's argument model — an actual abstract structure you can lift." Use the deep-research skill for this — it fans out web searches, fetches sources, adversarially verifies claims, and returns a cited synthesis. Pass it a tight question aimed at named, adoptable frameworks for the candidate (e.g. "What established frameworks model conflict and overlap between competing legal/normative clauses, with a structure I could encode in a schema?"), not a broad survey. Fall back to raw WebSearch/WebFetch only for quick lookups.

Step 3 — Reimagine it cohesively in the project

We do not adopt anything wholesale, and we don't build a whole legal app. We borrow the form — the battle-tested structure that already figured out the edge cases — and reimagine it minimally inside this codebase.

Worked outcome example. From the jurisprudence research on the development-application agent, we didn't build a legal engine. We ended up with a richer classification of individual clauses and how they conflicted or overlapped — instead of a single boolean conflict field in our Zod interface. The change was: enrich the JSON schema the LLM outputs to, then adjust downstream scoring and outputs to use it. It wasn't even a big PR, and it pre-empted a whole class of problems we'd otherwise have hit.

That's the target altitude: a mini-framework, often expressed as a better schema plus the downstream logic that consumes it.

Step 4 — Score. Keep only the genuine cringe-nudges.

This is the gate that protects the skill from becoming noise. Score each proposal and discard anything that isn't clearly worth it. A proposal survives only if it can show all of:

1. The homegrown framework — the actual current code/schema.
2. The established framework + discipline/pattern it maps to (with a citation).
3. A specific input that breaks (or impoverishes) the homegrown version — a concrete edge case it mishandles. If you cannot produce this, the match is shallow — drop it.
4. A minimal, project-cohesive change inspired by the established framework (often: a richer schema + downstream adjustment).
5. Honest cost/benefit — does this dissolve a class of problems, or is it marginal? Would adopting it be over-engineering? "You're fine, just watch this one edge case" is a valid and respectable answer — gold-plating is its own cringe failure mode.

Rank survivors by severity (saves-you-from-a-bug-class > minor enrichment). If nothing clears the bar, return nothing of substance — and that's fine.

Step 5 — Form the response

If — and only if — at least one proposal cleared the Step 4 gate, open with a cringe verdict. This is the skill's signature; earn it, don't fake it. Be creative and vary it — name the reinvented discipline, keep it playful but affectionate (you're nudging a colleague toward the good books, not dunking). The response is self-contained: never use the word "cringenudge" or refer to the tweet — the reader has no idea what those are. Just call the thing cringe. Examples of the register, not a script to copy:

• "That's cringe. You've reinvented jurisprudence, and jurisprudence is winning."
• "Sorry, but a boolean conflict field is cringe — there's a 2,000-year-old field that does this better."
• "Respectfully: this is cringe. You're three commits into rediscovering argumentation theory from first principles."

Then, for each surviving proposal:

• Propose the framework concretely (the borrowed form, not the whole discipline).
• Explain the context — what's being reinvented and why the established thing is deeper.
• Show specific examples of how the framework handles edge cases the current approach mangles. This is the most important part. Make it vivid: "today, input X collapses to a boolean and you lose Y; with this structure, X classifies as … and downstream Z does …".

Keep general-discipline and software-domain findings in separate sections. State the candidate count and how many were dropped at the gate (no silent truncation — if you considered five and kept one, say so).

Anti-patterns (don't become the cringe)

• Name-dropping a discipline without a concrete diff and a concrete breaking input.
• Recommending a heavyweight framework where a small distinction would do.
• Proposing change for a tiny benefit. The bar is "makes the current solution look naive," not "is technically more correct."
• Treating "scoring rollup / validation / mapping" as candidates by default — they're only candidates if they secretly model a reasoning process.
• Firing on every input. Most reviews should return "nothing here."