xrrocha

Thanks for this, Daniel! I've been working on a related piece [1] that arrives at Naur from a different angle.

Your "knowledge debt" framing is valuable, it gives practitioners something concrete. And your emphasis on team practices (reviews assessing understanding, pair programming around AI suggestions) addresses social dimension I neglected.

Where we diverge: I argue Naur's pessimism is narrower than supposed. His critique targets technical documentation that describes artifacts while presupposing the theory needed to understand them. But theory-focused documentation -WHY and WHEN, not just WHAT and HOW- isn't subject to the same critique. The Renaissance transmitted Aristotelian theory across a thousand-year gap via preserved texts.

The key distinction: Naur's argument is epistemological, not economic. He's not saying we lack time to document, he's saying certain knowledge cannot in principle be articulated. If the problem was labor, AI would solve it. If it's epistemological, AI can't.

But AI does change something: forced articulation. The interlocutor effect means reasoning that would have remained implicit gets spoken and preserved. Not a solution: better odds.

I posted this recently [2] without much traction, so I'm glad your piece is reaching people. These ideas deserve discussion.

[1] https://xrrocha.github.io/solo-dev-musings/001-naur-document...

[2] https://news.ycombinator.com/item?id=46378885

Peter Naur argued that programming is theory-building, and that theory cannot be fully captured in documentation. But his pessimism is narrower than supposed. It applies to technical documentation of artifacts, not documentation as a human endeavor. AI doesn't "solve" the problem—but it creates conditions where theory transmission becomes more likely.

This is one of the most insightful thoughts I've read about the role of LLM's in software development. So much so, indeed, its pertinence would remain pristine after removing all references to LLM's

I do

Yeah, Implementing the framework as such in Java with no other dependencies is a sound decision, imho.

Laying out a Kotlin DSL on top of it could be an excellent opt-in feature to leverage the core in a more declarative way

This is reminiscent of JavaFX's original F3 formulation (aka JavaFX Script): object literals reflecting the GUI visual structure.

JavaFX started out as a Java library on top of Swing but the lack of object literals and lambdas led to the creation of the F3 language (code-named foo for "funcional object-oriented").

Despite Java's progress since then its syntax still feels somewhat rigid. Sierra looks very nice indeed. It could benefit from a more fluid, less syntax-encumbered DSL laid on top of it in Kotlin or Scala.