Felienne Hermans: Making Programming Accessible and the Cost of Understanding (Series #AI4SDLC)

If AI removes syntactic barriers while a person retains an understanding of the problem and control over the solution, isn't that a continuation of the same idea of accessibility that Felienne Hermans champions through Hedy?

I want to begin with this contradiction in my review of her DDD Europe 2026 talk, “AI made me doubt everything about programming.” I have already written about Hedy and her book “The Programmer’s Brain.” Hermans works on programming education, and her criticism of the profession is quite specific: we too often mistake complexity for value and technical possibility for a sufficient reason to do something.

1️⃣ Complexity as a mark of quality According to Hermans, research into spreadsheets met with objections: is that really programming? Hedy prompted a similar question: what is there to research in a language that makes programming easier? Meanwhile, Hedy lets people learn in their native language and introduces syntax gradually. That offers a very tangible benefit to a beginner.

She finds an explanation in an unexpected place—a paper on feminist glaciology. Its authors examine how the image of the heroic conqueror of glaciers affects which researchers receive recognition and whose knowledge remains out of view. Hermans sees a similar mechanism in our profession: difficult and impressive work receives more respect than accessible and useful work. This kind of snobbery deserves to be challenged, but the analogy does not prove that all of programming works this way. Complexity can also be the price of simplicity for the user. A good compiler is not simple on the inside either.

2️⃣ Understanding the program Here she turns to Peter Naur and Programming as Theory Building. In his view, a developer builds a coherent model of how a program solves a problem. They can explain the decisions, their limitations, and how the system should be changed. To me, this is the strongest part of the talk. A working result does not guarantee that anyone understands why it works. But that does not mean using AI necessarily destroys understanding. You can ask a model to compare alternatives, find a counterexample, or help test an assumption. Whether you actually came to understand the problem is a separate question, one that cannot be settled by the model's own elegant explanation.

3️⃣ Tools can be chosen Drawing on Nathan Ensmenger's work, Hermans discusses chess as a model problem for AI. A convenient, testable objective shapes our idea of progress, but we need to be careful when transferring that progress to human tasks. And a chess engine's superiority does not oblige us to allow its help in a tournament. I agree about the right to choose. But in a chess tournament, the player's independent performance is part of the task. In software development, automation may well help achieve the desired result. One analogy is not enough to make the choice for us.

The person retains understanding Now let us return to the opening question. It hides the hardest condition: “the person retains understanding.” Hedy deliberately constructs a path for learning. AI can produce a ready-made solution while skipping that path. It would therefore be too convenient to treat them as equivalent tools. But if working with AI helps someone formulate the problem, understand the constraints, and verify the solution, it is entirely compatible with Hermans's idea of accessibility. Her arguments give us grounds to demand such a process. Rejecting it requires showing exactly where it stops working.

I would test this by changing the requirements: can the person explain what now has to change and why? It is especially interesting to ask this of someone who wrote all the code themselves :)

#AI4SDLC #AI #Engineering #Learning #Conference