AI made me doubt everything about programming by Felienne Hermans - DDD Europe 2026

Overview

Felienne Hermans explains how AI has pushed her into a broader “identity crisis” about computer science—questioning not just tools, but what the field values, how knowledge gets produced, and whether software practice is actually building anything beneficial for society.

1) Her personal break with “mainstream” programming

• Hermans says she once loved programming as a form of making—similar to drawing or knitting—motivated by creativity and building useful things.
• Over time, she became disillusioned, especially after work on spreadsheets was dismissed by other programmers as “not real programming,” despite her argument that spreadsheets can be Turing-complete.
• She then turned to education: creating Hedy, a localized, easier-to-use programming language (similar to Python but designed for accessibility through translation and simpler syntax), including support for:
  • Arabic keywords
  • Arabic numeral variants
• Her experience trying to validate “Arabic numerals” across mainstream languages showed that many major languages/toolchains reject non-standard numeral characters, while Hedy handled them—highlighting how “accessibility” is often ignored in default engineering assumptions.

2) Programming language localization is political (inclusion beats “English-only”)

• At academic conferences, she encountered repeated questions about why she didn’t just teach in English.
• She argues inclusion matters even when people can speak English, noting that many choose not to because of historical and ongoing harm from colonization and conflict.
• Example: partners in Botswana use Hedy to demonstrate that local language (e.g., Setswana) belongs in technology, not only in languages imposed by colonial histories.

3) Why it’s hard: “complexity is valued” more than “helpfulness”

• Hermans challenges the programming community’s mindset that difficult topics are inherently more prestigious.
• Drawing on a “feminist epistemology” lens and a glaciers study, she argues science/knowledge collection skews toward what’s easier to study and what researchers want to be celebrated for—affecting what gets known and valued.
• She connects that pattern to programming:
  • The community favors “hard/close-to-the-metal” tools (e.g., C++, Haskell)
  • It downplays “easy” tools (e.g., spreadsheets, JavaScript, PHP)
• She suggests that making things easier can be interpreted (within the community) as removing “value,” which helps explain resistance she received toward her work.

4) Programming isn’t treated like helping people—more like satisfying the field

• She criticizes how conferences (including DDD events) often translate human problem-understanding (“talk to customers/users”) into formal “systems” and jargon that are marketed as a technology/discipline.
• She argues that—through community preferences—programming becomes a place where people who love complexity feel at home, while people motivated by social change are less represented (she cites research suggesting caring about social change predicts not studying CS).
• This leads her to a broader conclusion: the culture of programming frequently optimizes for programmer pride and internal technical goals, not for building better outcomes for the world.

5) The field’s history is morally compromised, and AI hype continues the same “neutral tech” mistake

• Hermans claims computer science is not neutral: its knowledge and applications have historically been intertwined with war and harm.
• She recounts controversial figures and institutions:
  • John von Neumann and his role in early nuclear weapons planning and targeting.
  • IBM’s collaboration with Nazi Germany, including punch-card systems used to administer Jewish identity. She notes how this history was publicly documented but later forgotten.
• She argues that talk about AI warfare is not a surprise—it reflects longstanding trajectories where technology is shaped by social forces rather than “neutral science.”
• She frames AI hype as repeating a pattern: benchmark-style evaluation and narrow, testable goals (like “chess” for AI) get exported to domains where that methodology doesn’t fit well (art, language, writing).

6) Chess/Watson as cautionary history for how AI is evaluated

• She uses chess as the “Drosophila” of AI (via historian Nathan Ensmenger): chess was attractive because it maps cleanly onto logic and yes/no states, producing a preferred research methodology (benchmarking, measurable victory conditions).
• She argues LLM development inherited that mentality—leading to overconfidence in general intelligence claims and “solutionism” about using AI everywhere.
• She contrasts this with real human competitions and social contexts: even if tools can “solve” chess privately, we don’t want them to dominate human settings.
• Likewise, programming/writing/art should involve human interpretation and justification, not only machine output.

7) LLMs don’t provide the kind of “intellectual activity” that builds knowledge

• She invokes Peter Naur: intellectual activity involves building theories that can explain, justify, and defend decisions.
• Her claim is that LLMs typically can’t supply coherent, accountable explanations for “why” a design choice was made—so they may produce artifacts but not genuine knowledge.

8) Closing moral argument: programming should be for people, not for programmer satisfaction

• Hermans quotes thinkers (Ada Lovelace, Martin Luther King Jr., and David Graeber) to argue that technology should serve moral ends rather than displacing them.
• She challenges the audience to consider whether their software contributes to a better world; she implies belief is often low, meaning “faster/better” production (even if AI helps) can still serve harmful or trivial ends.
• Her proposed “barred from competition” analogy suggests some technological interventions should not be allowed to replace human responsibility in human domains.
• She ends hopeful: the world is something people make, so programming practices can be redesigned rather than treated as inevitable.

Presenters or contributors

• Felienne Hermans (speaker)
• Nathan Ensmenger (quoted via discussion; historian of computer science)
• Herbert Simon (quoted)
• Peter Naur (quoted)
• Martin Luther King Jr. (quoted)
• Ada Lovelace (quoted)
• David Graeber (quoted)
• John von Neumann (historical subject)
• Thomas J. Watson / IBM leadership (historical subject)
• IBM (institution discussed)
• Kasparov and IBM Deep Blue (mentioned in AI/chess context)
• David Graeber (credited as author of Bullshit Jobs and later works)