AI made me doubt everything about programming by Felienne Hermans - DDD Europe 2026
A social critique of complexity, benchmark culture, and treating AI adoption as inevitable
Computer science professor and Hedy creator Felienne Hermans argues that programming culture rewards difficult technical work over accessibility and social purpose. Moving from localized numerals to feminist epistemology, computing history, chess-derived AI benchmarks, and Peter Naur’s theory-building account of programming, she asks developers to treat LLM use as a choice rather than an inevitability and to focus on problems worth solving. This is an argumentative keynote, not an empirical evaluation; its broad claims about programmers, AI research, and machine understanding are illustrative rather than systematically demonstrated.
Domain-Driven Design Europe
Computer science professor, secondary-school teacher, and Hedy creator Felienne Hermans argues that programming culture prizes technical difficulty over accessibility and social purpose. She uses that argument to question how the field frames AI progress and why developers treat LLM adoption as inevitable rather than as a choice.
Difficulty is not the same as value
- Accessibility work exposed a conflict in what the field rewards: Hermans describes how spreadsheet research was dismissed as “not real programming,” then recounts adding localized keywords and Arabic numerals to Hedy. She argues that making programming easier can be socially valuable even when technical communities discount work that sounds easy 01:51–12:52(opens in a new tab).
- Ask whose knowledge a field values, and why: Hermans uses feminist epistemology—a way of examining how social position and power shape knowledge—to question what counts as valuable research. Drawing on a paper about glacier research, she argues that researchers can favor difficult, heroic work over accessible work with greater human relevance. She applies that lens to the status attached to complex languages and techniques 13:44–18:49(opens in a new tab).
- Technical vocabulary can legitimize ordinary human work: Hermans uses requirements engineering and domain-driven design to argue that software communities often turn asking people about their needs into specialized systems before treating the activity as valuable. This is her interpretation of the culture, not a claim that those disciplines add no useful method 18:49–20:48(opens in a new tab).
Programming is shaped by social choices
- Who enters the field affects what the field builds: Citing research that associates concern for social change with a lower likelihood of studying computer science, Hermans argues that education and professional culture select for people who enjoy complexity and marginalize other motivations. The talk does not provide the study details needed to assess the size or causes of that association 20:48–23:40(opens in a new tab).
- Computing history challenges claims of technical neutrality: She invokes John von Neumann’s work on nuclear weapons and IBM’s business with Nazi Germany to argue that present-day AI uses cannot be separated from institutional goals and incentives. These examples support a moral warning, not a direct causal history of current LLM systems 23:40–28:29(opens in a new tab).
- A convenient research subject can shape the whole field: Hermans cites Nathan Ensmenger's analogy between chess in AI and fruit flies in genetics: both are manageable subjects for experiments. Chess has clear rules and win-or-lose outcomes. She questions carrying that style of evaluation into language and art, where success is less objectively defined. The analogy challenges assumptions behind benchmarks; it does not evaluate a current benchmark 28:29–32:24(opens in a new tab).
AI capability does not settle how it should be used
- A solved technical problem can still be excluded from human practice: Chess engines have exceeded human players for decades, yet social and professional chess bars their use during play. Hermans presents that norm as evidence that software teams and communities can choose where not to use AI even when it is capable 32:24–35:23(opens in a new tab), 44:23–46:17(opens in a new tab).
- Code generation is narrower than intellectual ownership: Through Peter Naur’s account of programming as theory building, she distinguishes producing code from being able to explain, defend, and revise a coherent understanding of the system. She argues that current LLMs do not sustain that understanding; the talk illustrates this claim but does not test models or agent systems 35:23–36:31(opens in a new tab).
- Faster production does not determine whether the result is worthwhile: Hermans asks whether improved software output matters when developers do not believe the systems they build improve the world. She reframes programming as understanding a problem deeply and making something for people, rather than treating code production as the primary end 36:31–43:18(opens in a new tab).
- Adoption is a responsibility, not an inevitability: The closing argument is that programmers collectively shape technical norms. Hermans asks them to reject passive claims that LLM use will happen regardless and to decide which forms of programming and automation benefit people 43:18–47:11(opens in a new tab).