[dhorthy]

normative specifications can help, but the thesis here is that specs that define behavior of the product or even architecture are helpful but there's MORE that can be done and even though "program design" feels too in the weeds it's still essential if you care about maintainability

[mrbnprck]

Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?

Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.

[dhorthy]

> Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.

yes exactly - this is what I'm advocating for - that you can't skip the system design, and that actually good system design goes down to the typedefs and object graph at the code level, not just mermaid charts and db schemas and service contracts.

I will highlight what a few others have said along the lines of "a sufficiently detailed spec IS code" - that is, to make the spec guaranteed to produce the code you want, the spec will look a lot like code (and will be roughly the same effort to review as the code itself anyway, saving you no time)

what I'm proposing is "how can you maximized the odds that the code WILL be good or close enough to good that its easy to get there, with the LEAST amount of human effort/attention" - how can you move fast without skipping what matters

https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...

[human807]

Hey, I’ve watched some of your talks on YouTube and they have generally felt right and influenced my thinking as to how to navigate software engineering in this era. I appreciate you engaging here!

I read your piece here and again I appreciate and agree with your main points. You have a section here titled “30 minutes of planning saves hours of review” — but I find it hard to believe that you are doing all this pre-work of creating specs (ai-assisted) at various levels, down to the level of function signatures and such, and this whole thing only takes you 30 minutes. Is that what you meant? Can you talk a bit about how long this process actually takes, or if it is really only 30 minutes, how you pull that off?