Does the Programming Language You Use Shape How You Think?

A standalone literature-review essay synthesizing the research note: Linguistics, embodiment & how code syntax shapes thinking. Thesis: The programming language you use — chiefly through the conceptual metaphors and paradigms it commits you to, less through raw syntax — exerts a weak but real bias on which problem-solving strategies feel natural.

1. Introduction

Few questions sit as squarely at the intersection of linguistics, cognitive science, and software engineering as this one: does the language in which we write code shape the way we think about the problems we are trying to solve? The question has obvious intuitive pull. Anyone who has switched between a procedural language and a functional one, or who has watched a beginner struggle to “see” a problem the way an expert does, suspects that the medium is doing some of the cognitive work. Yet intuition is a poor guide here, because the same surface observation is compatible with several very different underlying claims, ranging from the grandiose (”the language you use determines the thoughts you can have”) to the deflationary (”you simply get better at whatever you practise”).

Photo by Leon Wu on Unsplash

This essay defends a deliberately modest middle position. The claim is that programming languages — primarily through the conceptual metaphors and paradigms they commit you to, and only secondarily through raw syntax — exert a weak but real bias on which problem-solving strategies feel natural to a programmer. The qualifier “weak but real” is load-bearing, and it is sustained throughout. The strong, deterministic reading is rejected, just as it is rejected for natural language. What survives scrutiny is a softer influence: a channelling effect, in which the metaphor system a language hands you highlights some solution shapes and quietly hides others.

To build that case, the essay traces a causal chain from the body to the screen. It begins with embodied cognition and conceptual metaphor (§2), then turns to the linguistic-relativity debate that frames the strong-versus-weak distinction (§3). It carries that distinction into the explicit “Sapir–Whorf for programming languages” argument (§4) and tests it against the neuroscience of code comprehension (§5). From there it locates the thesis’s most defensible form in the conceptual metaphors that saturate computing itself (§6). A case study of “making illegal states unrepresentable” (§7) shows the channelling claim caught in the act, before a closing assessment (§8) weighs the evidence and names the central unresolved question.

This was my entrance to the rabbit hole

2. Embodied cognition and conceptual metaphor

The first link in the chain runs from bodily experience to meaning. The tradition of embodied cognition and cognitive linguistics holds that meaning and reason are grounded in the body: so-called higher cognition is continuous with perception and motor action rather than floating free of it. The canonical statement is Lakoff and Johnson’s Metaphors We Live By, whose central move is to treat metaphor not as poetic decoration but as a conceptual mechanism. When we say argument is war, time is money, more is up, or understanding is grasping, we are not merely speaking colourfully; we are reasoning about an abstract target domain by importing the inferential structure — the built-in pattern of what follows from what — of a concrete source domain. The later Philosophy in the Flesh (Lakoff & Johnson) develops this into a full account of the embodied mind, in which even our most abstract philosophical concepts bear the fingerprints of sensorimotor experience.

Johnson (The Body in the Mind) supplies the connective tissue with the notion of image schemas: recurring sensorimotor patterns such as CONTAINER, PATH, SOURCE–PATH–GOAL, BALANCE, UP/DOWN, LINK, and FORCE. These schemas are abstracted from repeated bodily encounters — putting things into and out of containers, moving from a starting point toward a goal, being pushed and resisting — and are then metaphorically extended to structure abstract thought. The schema is the reusable skeleton; the metaphor is the projection of that skeleton onto a new, non-physical domain.

The most consequential extension of this programme for present purposes is Lakoff and Núñez’s Where Mathematics Comes From, which applies conceptual metaphor to mathematics itself. Their argument matters here precisely because mathematics is abstract and formal yet, on their account, still built from embodied metaphors — arithmetic as object collection (adding as gathering objects into one pile), as object construction (building a number out of smaller parts), as the use of a measuring stick (laying lengths end to end), as motion along a path (counting as stepping forward along a line). Programming sits between natural language and mathematics, so a framework that successfully bridges body and number is the natural candidate for bridging body and code. The key reusable insight is that the source domain’s inferential structure is imported wholesale: once numbers are conceived as points on a line, notions like “between,” “distance,” and “direction” arrive for free — and so do the corresponding blind spots.

3. Linguistic relativity: strong rejected, weak supported

If embodiment supplies the “body → language → thought” half of the chain, linguistic relativity supplies the “language → thought” half, and it is here that the strong-versus-weak distinction must be made explicit. The strong form, linguistic determinism, holds that language determines thought and limits what is thinkable. This claim is rejected by modern linguistics; there is little convincing evidence that language constrains reasoning at a societal or deep-cognitive level. The weak form holds only that language influences habitual cognition — that the categories your language makes salient bias what you tend to notice and discriminate, not what you are capable of conceiving.

The weak form has genuine empirical support, though the effects are characteristically small and perceptual rather than sweeping. The clearest demonstration is Winawer et al. (Russian blues reveal effects of language on color discrimination), who exploited the fact that Russian obligatorily distinguishes lighter blue (goluboy) from darker blue (siniy) with separate basic colour terms, whereas English does not. Russian speakers were faster to discriminate two shades when they fell on opposite sides of the goluboy/siniy boundary than when they fell within a single category, an advantage that disappeared under verbal interference — when a simultaneous word task tied up the speaker’s language faculties. The lexical distinction biases perceptual discrimination — a real effect, but a narrow one, and one that says nothing about whether Russian speakers can think about blue in ways English speakers cannot. This is the template for “weak but real” that the rest of the essay carries forward: language tilts habitual processing without gating the space of possible thoughts.

4. From natural language to code: Sapir–Whorf for programming languages

Carrying that distinction into software gives rise to an active and explicitly named debate over whether anything like Sapir–Whorf applies to programming languages. The affinity case begins from the observation that different paradigms make different solution shapes feel natural. The stock illustration is the task of summing the even numbers in a list. A procedural programmer — one who writes step-by-step instructions — reaches for an explicit loop with an accumulator, iterating along the list and updating a running total — a solution that wears the PATH/motion schema on its sleeve. A functional programmer — one who builds a result by chaining small data-transforming operations — composes a filter and a fold (keep the even numbers, then collapse them into a single sum), describing a transformation of data rather than a sequence of steps — a pipeline schema. An array-language programmer — working in a language where one operation applies to a whole array at once — writes a single whole-array expression in which no loop is “seen” at all, while a logic programmer — who states facts and rules and lets the system search for what satisfies them — declares the relations that define the answer rather than the procedure that computes it. The same arithmetic result is reached by visibly different cognitive routes, and design-and-comprehension studies reinforce the point: experts trained in different paradigms produce differently shaped designs, and the first language a novice learns measurably influences how they later decompose problems. Practitioner reports add colour — learning a formal-methods language is said to make people “see race conditions everywhere,” even away from the keyboard.

Against this stands a deflationary reading, argued most forcefully by Wayne (Sapir-Whorf does not apply to programming languages). His point is that human language is special in ways code is not: we think and dream in natural language and it recruits dedicated neural machinery, whereas we do not engage code with those same faculties. The cognitive reshaping that paradigm-strict languages produce is therefore better explained by the mundane Tetris Effect — the fact that anysustained skill, from juggling to profiling, reshapes what one notices — than by anything specifically linguistic. A language like Haskell feels Whorfian only because it forces concentrated practice in one style.

Crucially, the strong form fails for code just as it fails for natural language: a programmer working without higher-order functions can still articulate, in plain English, the wish for one (”I wish I could factor out this repeated loop”), so the concept is plainly not gated by the language. Plant (Inverse Sapir-Whorf and programming languages) offers a useful refinement, suggesting that an “inverse” Whorf effect may be truer of programming than of human language: some languages make particular things genuinely hard to express — reasoning about memory in a garbage-collected language, for instance — which shapes what one habitually thinks about, even though “hard to express” never amounts to “impossible to conceive.” The debate thus converges on the same boundary drawn in §3: a habitual bias, not a hard limit.

5. What the neuroscience says

If code were processed by the brain as a kind of natural language, the Whorfian reading would gain considerable ground; if it patterns instead with logic and mathematics, the affinity case weakens and the deflationary reading gains. The evidence points, on balance, toward the latter. Siegmund et al. (Understanding understanding source code with fMRI) provided an early and widely cited result: functional magnetic resonance imaging of source-code comprehension lit up classic language-related regions (Brodmann areas 21, 44, and 47 — regions long tied to language processing) alongside working-memory and attention areas, a finding naturally read as “programming recruits language faculties.”

Subsequent work complicates that picture. Ivanova et al. (Comprehension of computer code relies on domain-general regions) found that comprehension of computer code relies primarily on the domain-general multiple-demand network — the system implicated in general executive control and problem-solving — while the language network is not consistently engaged. On this account code overlaps more with formal logic and mathematics than with natural language, a position Fedorenko et al. (The language of programming: a cognitive perspective) frame explicitly in arguing for a cognitive perspective on programming. The net reading is that code is processed more like math, logic, and general reasoning than like natural language. This cuts against the strong “code is a language, therefore Whorf applies” claim and supports the weaker view that programming is domain-general problem-solving, biased by habit and practice — which is exactly the “weak but real” pattern the essay has tracked from the start. (The fMRI literature remains young and its localisation claims are contested in detail; the safest summary is directional rather than settled, a point to which §8 returns.)

6. Metaphor inside computing

The neuroscience pushes the strong linguistic claim aside, but it does not touch the metaphor claim — and that is where the thesis finds its firmest footing. Independently of whether syntax rewires cognition, computing is demonstrably saturated with conceptual metaphor, and that metaphor system does shape how practitioners reason. Blackwell (Metaphors we program by), analysing how programmers talk about Java, identifies systematic metaphor families: data as a physical object, a program as an agent that acts, memory as space or place or container, computation as motion or flow. Type systems, object orientation (”objects,” “inheritance,” “is-a”), and architecture (”pipelines,” “trees,” “streams”) are metaphor scaffolds that enable some reasoning paths while hiding others — the classic Lakoff highlight-and-hide effect. The defensible version of the hypothesis is therefore not that syntactic characters rewire the brain, but that the metaphor system a language commits you to channels which solutions feel natural.

Type systems are the richest vein, because they are simultaneously formal and described almost entirely through embodied metaphor. A type, roughly, is the label a language attaches to a value to say what kind of thing it is and what may be done with it — number, string, “a list of users.” The vocabulary programmers use for these labels is not neutral notation; almost every word for it is borrowed from physical experience.

Start with the most basic move: treating a type as a set or container of values — the collection of all the things that count as that type. That imports the CONTAINER schema, and with it the ideas of membership (a value is in the type or it is not), subtyping-as-containment (one type nested inside a larger one), and empty versus inhabited types (a type that nothing can ever satisfy versus one that has actual values). What the container image hides is everything dynamic — computation and effects.

Two ways of bundling data lean on related object metaphors. Product and record types — a single value that packs several fields together, like a struct or an object with named slots — rest on OBJECT COLLECTION. Algebraic data types — types built from a fixed menu of named cases, where each case is produced by a constructor (the small named function that stamps out a value of that case) — lean on Lakoff and Núñez’s OBJECT CONSTRUCTION, so that building a value and pattern-matching it apart feel like assembling and disassembling a physical whole.

A function type — the type of something that takes an input and returns an output — reads as a machine with an input slot and an output chute. That is a SOURCE–PATH–GOAL framing, in which the input travels along a path to become the output; it highlights flow and composition while hiding cost, time, and state.

Other type vocabulary borrows from social life rather than from physical objects. A type seen as a contract or capability— an interface, a protocol, a typeclass, all names for a promise that a value supports certain operations — invokes FORCE (compulsion) and social obligation: it “must be satisfied,” it “guarantees,” it is “honoured.” And subtyping — the relation that lets a more specific type stand in wherever a more general one is expected — when read as an is-a hierarchy stacks UP/DOWN, CONTAINER, and LINK.

The same embodied schemas Lakoff and Núñez found in arithmetic are, in other words, exactly the schemas that structure how programmers talk and reason about types; types are embodied metaphors wearing formal clothing.

The Curry–Howard correspondence, popularised for a broad audience by Wadler (Propositions as types), is the cleanest example of what Lakoff and Núñez call a linking metaphor — a mapping between two domains that are both already formal. Under “propositions as types, proofs as programs,” a type is a claim, an inhabited type is a provable proposition, and writing a well-typed term is constructing a proof. Each logical connective has a matching type constructor. Logical AND (conjunction) becomes a product type that bundles two values together; logical OR (disjunction) becomes a sum type — a value that is either an A or a B; if-then (implication) becomes a function type that turns a proof of one claim into a proof of another; and “for all” (universal quantification) becomes parametric polymorphism, the generics that let a single definition serve every type. The cognitive consequence is decisive for the thesis: a programmer who internalises “types are propositions” inherits the inferential structure of logic and begins to reason about programs as proofs, whereas a programmer equipped only with “type as container” cannot reach those moves. Same code substrate, different metaphor, different reachable thoughts.

Colburn and Shute supply the twist that keeps the computing case from collapsing into a mere reapplication of Lakoff and Núñez. In their analyses of abstraction and metaphor in computer science (Colburn & Shute, Abstraction in computer science, Metaphor in computer science), they observe that mathematics and computing pursue opposite abstraction objectives. Mathematics aims at information neglect — stripping away particulars to expose inferential structure — and its metaphors accordingly run from concrete to abstract, reasoning about the abstract by way of the concrete, exactly as Lakoff and Núñez describe. Computing aims instead at information hiding — deliberately concealing a complex mechanism behind a simple interface — so many of its metaphors run the other way, from a simple, familiar source to a genuinely complex target, as when we reason about an intricate runtime control-stack mechanism through the homely image of “throwing” and “catching” exceptions. A type signature, on this view, is an information-hiding membrane: the metaphor of contract or box or proposition is chosen precisely so that one need not think about the machinery beneath. That is Lakoff’s highlight-and-hide recast as an explicit engineering objective, and it explains why type systems feel like thinking tools rather than mere descriptions.

Colburn and Shute press this further for type specifically (Colburn & Shute, Type and metaphor for computer programmers): because computing invents its own subject matter, type metaphors trade on both pre-existing and newly minted similarities, and they let programmers encode their intentions into code and reconstruct others’ from it.

7. Case study: making illegal states unrepresentable

Everything so far has concerned how metaphors tilt reasoning in general. One small, well-known technique lets us watch the tilt happen on a single concrete decision, which is what makes it a useful test case. The technique has an unfriendly name — making illegal states unrepresentable — but the idea behind it is plain. An illegal state is simply a combination of data that a program is able to store even though it should never logically occur. Picture a user record with a boolean isLoggedOut flag and a separate sessionToken field: nothing stops the program from holding a record that is marked logged-out yet still carries a live session token, and that nonsensical pairing is an illegal state. The usual response is to allow the bad combination to exist and then write runtime checks, assertions, and defensive comments promising it will never really happen. This technique responds differently: it redesigns the shape of the data so that the bad combination cannot be written down in the first place. If it cannot be expressed, it cannot occur, and the checks guarding against it become unnecessary.

The slogan itself comes from practice rather than from a textbook. It is usually traced to a 2010 talk by Yaron Minsky (Effective ML), a working engineer at a finance firm, who urged programmers to lean on the type system — the part of a language that classifies and constrains what kind of value is allowed where — to rule out bad data by construction. The phrase caught on because it names a payoff every programmer wants: fewer bugs you have to remember to guard against.

The canonical worked example comes from Scott Wlaschin (Designing with types). Suppose a business rule says a contact must have an email address, or a postal address, or both — but never neither. The naive design gives the contact two optional fields, one for email and one for postal address. “Optional” means each field may be either present or absent, so the two fields together permit four combinations: email only, postal only, both, and — the forbidden one — neither. That fourth combination is the illegal state, and in the naive design the only thing standing between it and a corrupted record is a validation check the programmer has to remember to run. The redesign replaces the two optional fields with a single field that can take exactly one of three shapes: “email only,” “postal only,” or “both.” There is no fourth shape to choose, so “neither” becomes impossible to express. The business rule has moved out of a comment and a runtime check and into the structure of the data itself, where the compiler now enforces it for free.

Why exactly three shapes and not four? Here the research literature’s algebra of algebraic data types helps, and despite the forbidding name it is really just counting. Every type has a number of possible values it can hold: a boolean has two, a three-colour traffic-light type has three, and so on. When you combine fields with and — a record holding a boolean anda traffic light — you multiply the counts (2 × 3 = 6 possible combinations). When you offer a choice between alternatives with or — this shape or that shape — you add them. A type that can hold nothing, with no possible values at all, counts as zero; a type with exactly one possible value counts as one. The design heuristic then fits on a single line: choose a data shape whose number of possible values equals the number of states that are actually legal, and no more. Every extra value the shape allows is, by definition, a representable illegal state — a latent bug. In the contact example three legal states call for a shape with exactly three possible values; the naive two-optional-fields design allowed four, and that surplus of one was precisely the “neither” bug.

This counting view connects back to the propositions-as-types idea from §6 — the correspondence, popularised by Wadler (Propositions as types), under which a type behaves like a logical statement and a program that produces a value of that type behaves like a proof of the statement. Pushed to its extremes, the correspondence says a type with exactly one possible value plays the role of “true” (trivially satisfiable), while a type with no possible values at all plays the role of “false,” a claim no value can ever satisfy. Designing away an illegal state is the everyday use of that extreme: you give the impossible combination a shape that has zero possible values, so no value of it can ever be built.

The same instinct has a dynamic, boundary-crossing form, captured by Alexis King in the slogan parse, don’t validate. Most programs receive raw, untrusted data at their edges — input from a form, a file, a network request. Validating that data means checking it against the rules, returning a yes-or-no answer, and then throwing the evidence away; the raw data flows onward unchanged, so every later part of the program must re-check the same property or simply trust that someone already did. Parsing means converting the raw data, once, at the boundary, into a new value whose very type guarantees the rules are met — turning an untrusted string into a trusted “valid email,” say. From that point the guarantee travels with the data, and downstream code cannot even be handed something invalid. Validation keeps peeking inside a container to re-confirm what it holds; parsing proves the property once and lets the type carry the proof forward.

This is where the case study earns its place in the argument. A programmer holding the subtractive metaphor — start from everything the data could be and carve away the bad cases with checks — sees illegal states as things that exist but are forbidden. A programmer holding the constructive metaphor — build the data up only out of legal pieces — sees illegal states as things that simply do not exist. Same language, same compiler, same data: the only thing that differs is which metaphor the programmer holds, and that alone decides whether “delete this entire class of bug” is even on the menu of options. Unlike the broad paradigm comparisons earlier in the essay, this is cleanly testable, because one can hold the language fixed and vary only which metaphor developers are primed with.

Honesty requires one caveat, and for the thesis it is a strength rather than an embarrassment. The tidy “types are logic” correspondence holds perfectly only in an idealised language in which every program is guaranteed to finish running. Real languages such as Haskell, Rust, and TypeScript allow programs that loop forever, and a never-finishing computation can technically masquerade as a value of any type — even the supposedly impossible, zero-value one — so the underlying logic is not strictly airtight. In practice this rarely bites, and working programmers borrow the discipline and intuition of the correspondence without depending on it as a formal proof. That is exactly the point: what the technique delivers is a strong cognitive and metaphorical channel — a way of seeing that makes whole categories of bug easy to design away — not an ironclad mathematical guarantee. The influence is real, and it is a bias rather than a law, which is precisely the weak-but-real claim the rest of the essay defends.

8. Assessment and open questions

Laying the links side by side yields a consistent gradient of evidential strength — a measure of how firmly the available research backs each step, running from well-established through moderate down to rejected. The grounding of meaning in bodily and sensory experience is strongly supported as established theory with some neural support. The weak relativity claim that language influences habitual thought is moderately supported, with effects that are real but small (Winawer et al., Russian blues reveal effects of language on color discrimination). The strong determinist claim is rejected. The claim that programming paradigm shapes problem-decomposition style is weak-to-moderate and badly confounded by training and self-selection — the likelihood that people already disposed to think in a paradigm’s style are the ones who gravitate to it. The claim that syntax alone — surface form isolated from semantics and paradigm — shapes thinking is weak and underexplored, since almost no study separates the two. And the Tetris-Effect confound, that it is skill and practice rather than language that reshapes cognition, competes hard with any Whorfian reading.

Two findings do the most to keep the thesis modest. The neuroscience places code with mathematics, logic, and general reasoning rather than with natural language (Ivanova et al., Comprehension of computer code relies on domain-general regions; Fedorenko et al., The language of programming: a cognitive perspective), undercutting any claim that code is processed as a language. And the Tetris-Effect argument (Wayne, Sapir-Whorf does not apply to programming languages) offers a deflationary explanation for the same reshaping the affinity case points to. What remains, and what the evidence genuinely supports, is the metaphor-channelling claim of §6 and §7: a language commits you to a system of conceptual metaphors, and that system biases which solution shapes feel natural without ever gating which are conceivable.

The central open question is methodological. Almost every existing study confounds surface syntax with semantics and paradigm, so the specific claim about syntax remains untested. The cleanest experiment would hold the language fixed and vary only the metaphor — priming one group with “type as container” and another with “type as proposition,” then measuring which solutions each reaches, exactly as the illegal-states case study invites. Until such isolating work is done, the honest verdict is the one stated at the outset: programming languages exert a weak but real bias on problem-solving, carried chiefly by metaphor and paradigm rather than by syntax — an influence that tilts the habitual without ever fixing the possible.

9. Postscript: when the code is written by prompt

The argument so far has assumed a programmer typing code. Large-language-model assistance changes the authoring surface, and in doing so it puts the essay’s central distinction under a revealing new light. Section 5 placed code comprehension with the analytical multiple-demand network rather than the language network. LLM-assisted engineering partly inverts the authoring channel: intent is now expressed in ordinary prose, which is precisely the stimulus that drives the language network — Tuckute et al. (Driving and suppressing the human language network with LLMs) show that GPT-style models can predict, and even deliberately drive or suppress, that network’s activity. The multiple-demand reasoning does not disappear; it relocates downstream, into specifying the problem and evaluating the result. The hazard is subtle: the fluency of the language channel can make it feel as though the work is finished while the analytical work quietly goes undone.

There is now direct neural evidence for that hazard. Kosmyna et al. (Your brain on ChatGPT), an MIT Media Lab EEG study, found that brain connectivity scaled down systematically with the amount of AI support — weakest in the group that leaned hardest on the assistant. The most instructive result was an order effect: participants who struggled unaided first and only then reached for the model re-engaged their networks, whereas those who started with the model and later worked alone showed weaker, less coordinated activity. (The study concerns essay-writing and is preprint-stage, so it transfers to programming only by analogy.) The complementary survey of knowledge workers by Lee et al. (The impact of generative AI on critical thinking) describes the same shift in different terms: critical thinking does not vanish so much as migrate from generating answers toward verifying and stewarding them — effort that remains available to be spent, but only if the user chooses to spend it.

Software-specific findings sharpen the better-versus-worse question, and a single distinction organises them. Some of the effort a task demands is merely incidental — recalling exact syntax, typing boilerplate — work that stands between the programmer and the problem without being the problem; call this extraneous load. The rest is the effort that constitutes the thinking itself — breaking the task down, choosing abstractions, holding the design in mind; call this germane load. The gains from AI are real when the tool strips away only the extraneous kind, leaving working memory free for the germane kind. They are largest under two further conditions: when the developer verifies actively, which in one controlled study was the strongest behavioural predictor of whether comprehension survived at all (Code comprehension with GitHub Copilot); and when the user is a relative novice or the task unfamiliar, where Cui et al. (The effects of generative AI on high-skilled work), pooling three field experiments across nearly five thousand developers, found the largest productivity gains accruing to less-experienced engineers.

The losses are equally real when the tool removes the germane load too — when the analysis itself is offloaded in the accept-and-move-on habit. That habit produces automation bias, an illusion of competence, and measurable deskilling in code reading and debugging (Anthropic, How AI assistance impacts the formation of coding skills). The pattern can even invert for experts: METR (Measuring the impact of early-2025 AI on developer productivity) found seasoned developers on familiar code were slowed by AI while believing themselves faster, a perception gap that should caution anyone confident the trade is obviously favourable.

One mechanism unifies these results. Bjork & Bjork’s (Making things hard on yourself) desirable difficulties — together with cognitive-load theory — distinguish the difficulty that merely obstructs from the difficulty that is the learning. Removing extraneous difficulty is pure gain; removing the reasoning difficulty is exactly what erodes problem-solving and skill formation. The decisive point is that the tool cannot tell the two apart, so the human must.

What, then, can a programmer do to keep the analytical channel engaged? Attempt the problem unaided before reaching for the model, since that struggle-first order re-engaged the brain networks passive prompting leaves idle (Kosmyna et al., Your brain on ChatGPT). Treat whatever the model returns as something to verify actively — read it, test it, challenge it — because active verification was the strongest predictor of preserved comprehension (Code comprehension with GitHub Copilot). Favour explanatory or learning modes, accepting that getting productively stuck is how mastery forms (Anthropic, How AI assistance impacts the formation of coding skills). Spend the freed effort on judgement — questioning, integrating, and stewarding the output — so the model serves as a tool for thought, not an answer machine (Lee et al., The impact of generative AI on critical thinking). The unifying frame is to preserve the desirable difficulty of reasoning while offloading only syntax (Bjork & Bjork, Making things hard on yourself). Other habits suggest themselves — periodically solving problems with no AI, treating review of generated code as deliberate practice, alternating assisted and unaided sessions — though these remain speculative and untested for software work.

This returns the essay to its thesis on new ground. The body argued that paradigm and metaphor tilt the habitual without fixing the possible — they bias which solution shapes feel natural, never gating which are conceivable. The prompting interface does the same thing one level up. Its affordances make the language-network mode feel natural and the analytical mode feel optional, defaulting the user toward under-engaged analysis unless they deliberately resist. The medium has not removed the multiple-demand work; it has merely made it skippable, and made skipping it feel like progress. That is the weak-Whorf claim again, transposed from the language of code to the language we now use to summon it: a channelling effect on which cognitive mode feels natural, leaving the harder mode available to whoever still elects to use it.

10. References

Anthropic. (2025). How AI assistance impacts the formation of coding skills. [research report]. <https://www.anthropic.com/research/AI-assistance-coding-skills>

Bjork, E. L., & Bjork, R. A. (2011). Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning. In M. A. Gernsbacher, R. W. Pew, L. M. Hough, & J. R. Pomerantz (Eds.), Psychology and the Real World: Essays Illustrating Fundamental Contributions to Society (pp. 56–64). Worth Publishers. <https://bjorklab.psych.ucla.edu/wp-content/uploads/sites/13/2016/11/Making-Things-Hard-on-Yourself-but-in-a-Good-Way-20111.pdf>

Blackwell, A. F. (2006). Metaphors we Program By: Space, Action and Society in Java. PPIG 2006 (18th Workshop of the Psychology of Programming Interest Group), University of Sussex. <https://ppig.org/papers/2006-ppig-18th-blackwell/>

Code Comprehension with GitHub Copilot: Performance Gains, Comprehension Trade-offs, and Behavioral Predictors in Brownfield Programming. (2025). arXiv:2511.02922. <https://arxiv.org/abs/2511.02922>

Colburn, T. R., & Shute, G. M. (2007). Abstraction in Computer Science. Minds and Machines, 17(2), 169–184. <https://doi.org/10.1007/s11023-007-9061-7>

Colburn, T. R., & Shute, G. M. (2008). Metaphor in Computer Science. Journal of Applied Logic, 6(4), 526–533. <https://doi.org/10.1016/j.jal.2008.09.005>

Colburn, T. R., & Shute, G. M. (2017). Type and Metaphor for Computer Programmers. Techné: Research in Philosophy and Technology, 21(1), 71–105. <https://doi.org/10.5840/techne20174662>

Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. [working paper]. <https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566>

Fedorenko, E., Ivanova, A., Dhamala, R., & Bers, M. U. (2019). The Language of Programming: A Cognitive Perspective. Trends in Cognitive Sciences, 23(7), 525–528. <https://doi.org/10.1016/j.tics.2019.04.010>

Ivanova, A. A., Srikant, S., Sueoka, Y., Kean, H. H., Dhamala, R., O’Reilly, U.-M., Bers, M. U., & Fedorenko, E. (2020). Comprehension of computer code relies primarily on domain-general executive brain regions. eLife, 9, e58906. <https://doi.org/10.7554/eLife.58906>

Johnson, M. (1987). The Body in the Mind: The Bodily Basis of Meaning, Imagination, and Reason. University of Chicago Press. <https://books.google.com/books/about/The_Body_in_the_Mind.html?id=Y0RSuKxtn1YC>

King, A. (2019). Parse, don’t validate. [blog post]. <https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/>

Kosmyna, N., Hauptmann, E., Yuan, Y. T., Situ, J., Liao, X.-H., Beresnitzky, A. V., Braunstein, I., & Maes, P. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv:2506.08872. <https://arxiv.org/abs/2506.08872>

Lakoff, G., & Johnson, M. (1980). Metaphors We Live By. University of Chicago Press. <https://doi.org/10.7208/chicago/9780226470993.001.0001>

Lakoff, G., & Johnson, M. (1999). Philosophy in the Flesh. Basic Books. <https://www.hachettebookgroup.com/titles/george-lakoff/philosophy-in-the-flesh/9780465056743/>

Lakoff, G., & Núñez, R. (2000). Where Mathematics Comes From. Basic Books. <https://www.hachettebookgroup.com/titles/george-lakoff/where-mathematics-come-from/9780465037711/>

Lee, H.-P. (H.), Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., & Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI ‘25 (Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems). <https://doi.org/10.1145/3706598.3713778>

METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. <https://arxiv.org/abs/2507.09089>

Minsky, Y. (2010). Effective ML (talk/lecture) — origin of “make illegal states unrepresentable”. <https://blog.janestreet.com/effective-ml-video/>

Plant, L. (n.d.). Inverse Sapir-Whorf and programming languages. [blog post]. <https://lukeplant.me.uk/blog/posts/inverse-sapir-whorf-and-programming-languages/>

Siegmund, J., Kästner, C., Apel, S., Parnin, C., Bethmann, A., Leich, T., Saake, G., & Brechmann, A. (2014). Understanding understanding source code with functional magnetic resonance imaging. ICSE ‘14, 378–389. <https://doi.org/10.1145/2568225.2568252>

The algebra of algebraic data types. (n.d.). Codewords / Recurse Center [web]. <https://codewords.recurse.com/issues/three/algebra-and-calculus-of-algebraic-data-types>

Tuckute, G., Sathe, A., Srikant, S., Taliaferro, M., Wang, M., Schrimpf, M., Kay, K., & Fedorenko, E. (2024). Driving and suppressing the human language network using large language models. Nature Human Behaviour, 8(3), 544–561. <https://doi.org/10.1038/s41562-023-01783-7>

Wadler, P. (2015). Propositions as Types. Communications of the ACM, 58(12), 75–84. <https://doi.org/10.1145/2699407>

Wayne, H. (2025). Sapir-Whorf does not apply to Programming Languages. [blog post, non-peer-reviewed]. <https://buttondown.com/hillelwayne/archive/sapir-whorf-does-not-apply-to-programming/>

Winawer, J., Witthoft, N., Frank, M. C., Wu, L., Wade, A. R., & Boroditsky, L. (2007). Russian blues reveal effects of language on color discrimination. PNAS, 104(19), 7780–7785. <https://doi.org/10.1073/pnas.0701644104>

Wlaschin, S. (n.d.). Designing with types: Making illegal states unrepresentable. F# for Fun and Profit [web]. <https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/>