DWIM

A system-design stance: treat user input as evidence of probable intent, infer and correct the most likely error or omission, and act on the inferred form rather than the literal one.

Also known as: Do What I Mean; Do The Right Thing (Emacs Lisp idiom); Intent Inference. And, from the original critics: Do What Teitelman Means; Damn Warren’s Infernal Machine.

Understand This First

• Brief – DWIM is the system’s response to what the brief left out.
• Judgment – every DWIM act is a judgment call about what the user meant.
• Blast Radius – the calibration dial for how aggressive DWIM should be.

Context

At the heuristic level, DWIM names a design stance that has been argued about since 1966. Warren Teitelman was a BBN Lisp programmer fed up with FORTRAN rejecting DIMENSOIN as unknown. He built a spelling corrector into BBN Lisp (later Interlisp) that caught undefined-variable errors, guessed the probable intended name (transpositions, doubled characters, case mistakes), and ran the corrected form. The stance spread: autocomplete, autocorrect, IDE refactorings, Perl’s syntactic forgiveness, Ruby’s duck typing, Emacs Lisp’s “do the right thing” idiom, and, most aggressively, every commercial LLM coding agent shipped since 2022.

DWIM sits alongside KISS and YAGNI as a named design stance with real partisans and real critics. It differs from them in scope: KISS and YAGNI are about what you build; DWIM is about how your system responds to input. In agentic coding, that makes DWIM the operational mode of the entire stack. A prompt is the input. An agent is the DWIM engine. The question is how much it should infer and how visibly.

Problem

Rigid literalism produces brittle tools. A system that accepts only perfectly-formed input wastes the user’s time on trivial mistakes the system could have fixed. A missing comma, a transposed letter, a file path with an obvious typo: treating these as hard stops is bad design. The user knows what they meant; the system should too.

But aggressive inference produces opaque tools. A system that silently does what it thought you meant, when you meant something else, has now spent your time on unasked work, in a form you can’t easily audit. The harm scales with the gap between what the user said and what the system did, and with the cost of undoing the wrong move.

So: how much intent-inference should the system do, on what kinds of input, with what visibility, and under what constraints?

Forces

• The cost of literal execution. Small on a typo; catastrophic on a malformed rm argument; recoverable on a misspelled variable. Literal execution is only fine when the error it produces is cheap.
• The cost of wrong inference. Low for a spelling fix on an unused variable. High for a silent rewrite of a function signature that ten callers depend on. Unbounded for an agent that “cleans up” a file you hadn’t asked it to touch.
• Training distribution pull. LLM agents learned DWIM on the public internet, which rewards confident completion over careful asking. The default setting is biased toward acting.
• Visibility. A DWIM that shows its work (“I assumed you meant X; here’s the diff”) is very different from a DWIM that hides it. The critique across six decades has targeted the hidden version, not the visible one.
• Reversibility. Some DWIM moves are trivial to undo (reject a suggested edit). Some are not (a deployed migration, a force-push, a deleted row).

Solution

Commit to DWIM where the cost of being wrong is low and the cost of literal execution is high. Refuse it where either inequality flips. The discipline isn’t “DWIM everywhere” or “never DWIM.” It’s drawing the line on purpose, and then showing the user where you drew it.

A few preconditions turn DWIM from a hazard into a feature:

Surface the correction. Teitelman’s original DWIM printed what it was doing: “undefined function FOOBR; did you mean FOOBAR? using FOOBAR.” That visibility is the difference between DWIM-with-consent and DWIM-in-the-dark. An agent that shows its diff before applying it is doing the first. An agent that silently expands scope is doing the second. The critique survives because it’s always been aimed at the silent kind.

Know where DWIM stops. Mechanical error-correction on unambiguous input (typos, path inference, obvious completions) is classic productive territory. Resolving ambiguity in high-stakes intent (which feature did you want? which database? what style?) is not. The skill is recognizing the line in real time. When you catch yourself guessing about what the user wanted rather than what they typed, DWIM has wandered off its home ground.

Prefer asking over assuming on genuine ambiguity. This is where Question Generation meets DWIM. The right response to a genuinely ambiguous request is not to guess; it’s to ask. Reserve DWIM for cases where the probable interpretation is clearly dominant. Below that, ask.

Calibrate to the cost of undo. On trivially reversible input (an unreviewed edit in a branch), be aggressive. On input whose effects compound or can’t be undone (a destructive command, a public post, a schema migration), prefer literal execution plus explicit confirmation. The appropriate confidence threshold rises with Blast Radius.

How It Plays Out

1970, Teitelman’s DWIM. A user types (FOOBR X) and means FOOBAR. The Interlisp interpreter hits an undefined function, consults DWIM, finds that FOOBAR is defined and is a one-character-off match, prints “using FOOBAR instead,” and proceeds. The correction is mechanical, the fix is unambiguous, and the substitution is surfaced. Productive DWIM in its original, cleanest form.

2015, IDE refactoring. A developer renames a class in IntelliJ. DWIM propagates the rename across imports, configuration files, and templated strings. Mostly helpful: the IDE is doing what the developer meant, across a hundred files they’d rather not edit by hand. The failure mode shows up on the edges. A string that happens to match the old name but isn’t a reference to it gets renamed too. Diff review catches it. The invariant that survives the era is DWIM must be reviewable.

2025, agent coding. A developer writes: “Clean up the auth module.” The agent reads the file and makes four moves: normalizes a comment style, renames one unclear variable, shortens a nested if chain, and (here is where the stance slips) extracts three helper functions it decides are getting long. The first three are mechanical DWIM, reviewable in a diff, defensible on their face. The fourth is a structural judgment the user didn’t ask for and may not want. Without scope-conscious review, the developer merges it. Six weeks later a teammate asks why those helpers exist, and the answer is that the model guessed. That is the 2025 form of Do What Teitelman Means: the agent is doing what it thought you meant, not what you meant.

Consequences

When DWIM fits (low cost of wrong, high cost of literal, visible corrections, reversible effects), it is one of the strongest usability moves in system design. It takes the tedium out of working with a strict tool. Teitelman’s spelling corrector saved a generation of Lisp programmers hours per day. Good autocomplete does the same. A good agent, operated with DWIM calibrated correctly, compresses what used to be a morning of scaffolding into a ten-minute review.

When DWIM overreaches, or when it hides, the damage is specific and recurring:

• Silent scope creep. The agent expands a request without surfacing the expansion. The user finds out in code review, or worse, in production. Teitelman’s original critics (hence “tuned to the particular typing mistakes to which Teitelman was prone”) would recognize this instantly; today the tuning is toward the training distribution, not the user.
• Confident misreads. The agent DWIMs with high confidence a case that warranted asking. It “knew” the user meant Feature A; they meant Feature B. A high-confidence misread is more costly than a low-confidence ask, because the user trusted the output and didn’t think to double-check.
• Domain-tuned DWIM. The agent infers toward the idioms of its training corpus, not the idioms of this codebase. Context Engineering and the project’s Instruction File are how you re-center DWIM on the user’s actual code rather than on the average of the public internet.
• Cascade DWIM. Step 1 infers. Step 2 infers, on the assumption that step 1’s inference was right. By step 5, the agent is executing a task no human asked for and no human can easily reverse. Connects to Delegation Chain failures; the error compounds with the chain.
• DWIM-by-default on destructive operations. The agent “just goes ahead and does” a file deletion, a force-push, or a schema migration whose undo is expensive. DWIM is wrong here. The cost of asking is seconds; the cost of guessing wrong is hours or days.

A sharp reusable test, applicable on every agent interaction:

Related Patterns

• Contrasts with: KISS – KISS is about what you build; DWIM is about how your system responds to input.
• Contrasts with: YAGNI – YAGNI refuses speculative features; DWIM enables (or overreaches into) speculative interpretations.
• Depends on: Judgment – every DWIM act is a judgment call with a cost of being wrong.
• Depends on: Brief – DWIM inferences fill the gaps the brief left unspecified.
• Uses: Local Reasoning – a reviewable DWIM move is one whose effect you can understand from the diff alone.
• Tempered by: Question Generation – the right response to genuine ambiguity is to ask, not to DWIM.
• Configured by: Context Engineering – re-centers the agent’s DWIM on this codebase rather than its training corpus.
• Configured by: Instruction File – declares the project-specific limits on DWIM aggressiveness.
• Calibrated by: Blast Radius – the appropriate confidence threshold rises with the cost of undo.
• Gated by: Approval Policy – the governance layer that catches DWIM moves before they ship.
• Bounded by: Bounded Agency – scope limits on what the agent is allowed to DWIM over.
• Related: Vibe Coding – shipping the output of unreviewed DWIM without reading it.
• Related: Footgun – a destructive operation that DWIMs by default is the clearest footgun family in agent tooling.
• Manifests as: Silent Failure – invisible DWIM moves are the silent-failure variety of the stance.

Sources

• Warren Teitelman developed DWIM for BBN Lisp around 1966, implementing it by 1970. The system grew out of his frustration with FORTRAN’s treatment of typos like DIMENSOIN; its spelling corrector handled transpositions, doubled characters, and case mismatches, printed its inferred correction to the user, and re-executed the corrected form. The history is documented in his retrospective, History of Interlisp (reprint via interlisp.org).
• The Wikipedia entry on DWIM records the critics’ aliases (Do What Teitelman Means and Damn Warren’s Infernal Machine), which have outlasted many of their targets because they named a real design hazard the proponents preferred to minimize.
• Eric S. Raymond’s New Hacker’s Dictionary entry tracks how the term propagated from Interlisp into the wider Lisp community and then into Unix and web-era tool design, becoming a general label for any system that treats input as evidence of intent.
• The Emacs Lisp tradition’s do-the-right-thing idiom (especially in commands like capitalize-dwim, downcase-dwim, upcase-dwim, and comment-dwim) carries the DWIM lineage directly. The GNU Emacs manual documents the convention of commands that operate on the region if active and on the word-at-point otherwise.
• Larry Wall’s design writing for Perl treated DWIM as an explicit principle: the language should accept many idiomatic forms of the same intent rather than demand one canonical shape. The stance is embedded throughout Programming Perl (O’Reilly, 1991 and later editions) and in the wider Perl community’s cultural docs.
• The agentic-era reframing (that every LLM coding agent is a DWIM engine operating at scale, and that the Teitelman-era critique maps onto contemporary failure modes more precisely than any newer vocabulary) emerged from practitioner discussion and product framing in 2024 and 2025 as agents began shipping production code. The reasoning is not yet reduced to a single canonical essay; the lineage is older than the application.

Further Reading

• Paul Graham, The Hundred-Year Language – argues that languages trend toward accepting more forms of intent over time. A useful frame for where DWIM is going.
• The Hacker News thread on DWIM and agent tools is a recurring venue for practitioner argument about where DWIM should stop; search for “DWIM” at news.ycombinator.com for current debate.