[mrbnprck]

I've recently started experimenting with grounding LLM driven implementation/verification on RFC based normative specifications, to avoid having to manually steer the LLM during implementation and dealing with reviewing sloppy pull requests.

It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.

[Lindby]

But do you actually gain anything if you need to write detailed specifications? That seems just as time consuming as writing code, but less gratifying.

Code is just detailed specifications on how things should operate.

[Balooga]

> Code is just detailed specifications on how things should operate.

The spec defines how things should operate. Code defines how things operate.

The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.

Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.

[mrbnprck]

Yes, actually that's what I'd had argued a few years ago as well.

It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.

As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.

Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.

[boredtofears]

I'm curious how that works - are you actually hand writing specs with RFC level detail yourself completely or is it more of an LLM assisted effort? It seems like writing a comprehensive spec manually would almost be as much (if not more) work than the implementation.

[mrbnprck]

I'm writing the specs by hand.

The LLM solely helps with research and retaining the normative document layout (RFC 7322).

Since the spec grounds the underlying implementation I have to fully understand it, writing the spec manually prevents infecting the spec with the typical LLM specification slop.

When writing the specs, the goal is to systematically keep the right balance between scope and depth:

- Scope takes the most effort because it's the only thing preventing the model from escaping an intended boundary, that includes things like stable constraints/interfaces/data models

- Depth is something where I can tolerate "non-normative" interpretations by the LLM. Unless I need a stable implementation, I can decide how much I manually invest into depth vs. letting the model figure the "good enough" solution.

Since the scope/boundaries are explicitly set, the internals are pretty encapsulated and the model comparing an implementation with the spec can identify the "non-normative" pieces and communicate those to me. Then I can decide between "good enough" or to refine these non-normative implementations and make them normative.

From my various experiments the spec vs. code ratio is roughly 1/8.

[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?