A sufficiently detailed spec is code • Hacker News Board

Re: A sufficiently detailed spec is code

#41

Post by catlifeonmars » Thu, Mar 19, 2026, 5:27 AM UTC

macinjosh wrote: post #24

IMHO, LLMs are better at Python and SQL than Haskell because Python and SQL syntax mirrors more aspects of human language. Whereas Haskell syntax reads more like a math equation. These are Large _Language_ Models so naturally intelligence learned from non-code sources transfers better to more human like programming languages. Math equations assume the reader has context not included in the written down part for what…

I suspect your probably right, but just for completeness, one could also make the argument that LLMs are better at writing Haskell because they are overfit to natural language and Haskell would avoid a lot of the overfit spaces and thus would generalize better. In other words, less baggage.

Re: A sufficiently detailed spec is code

#42

Post by manmal » Thu, Mar 19, 2026, 5:30 AM UTC

rdevilla wrote: post #7

I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…

Codex already has such a language. The specs it’s been writing for me are full of “dedupe”, “catch-up”, and I often need to feedback that it should use more verbose language. Some of that has been creeping into my lingo already. A colleague of mine suddenly says the word “today” all the time, and I suspect that’s because he uses Claude a lot. Today, as in, current state of the code.

Re: A sufficiently detailed spec is code

#43

Post by anonzzzies » Thu, Mar 19, 2026, 5:30 AM UTC

rdevilla wrote: post #7

I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…

It was mentioned somewhere else on hn today, but why do I care about token usage? I prompt AI day and night for coding and other stuff via claude code max 200 and mistral; haven't had issues for many months now.

Re: A sufficiently detailed spec is code

#44

Post by catlifeonmars » Thu, Mar 19, 2026, 5:31 AM UTC

measurablefunc wrote: post #2

I agree with the overall structure of the argument but I like to think of specifications like polynomial equations defining some set of zeroes. Specifications are not really code but a good specification will cut out a definable subset of expected behaviors that can then be further refined with an executable implementation. For example, if a specification calls for a lock-free queue then there are any number of poten…

I kind of feel like the specification would call for an idealized lock free queue. Whereas the code would generate a good enough approximation of one that can be run on real hardware.

To invert your polynomial analogy, the specification might call for a sine wave, your code will generate a Taylor series approximation that is computable.

Re: A sufficiently detailed spec is code

#45

Post by ulrikrasmussen » Thu, Mar 19, 2026, 5:40 AM UTC

A corollary of this statement is that code without a spec is not code. No /s, I think that is true - code without a spec certainly does something, but it is, by the absence of a detailed spec, undefined behavior.

Re: A sufficiently detailed spec is code

#46

Post by ChrisMarshallNY » Thu, Mar 19, 2026, 5:42 AM UTC

hintymad wrote: post #28

> A sufficiently detailed spec is code This is exactly the argument in Brooks' No Silver Bullet. I still believe that it holds. However, my observation is that many people don't really need that level of details. When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.

But if you’re selling that to-do list app, then the rules are different, and that spec is required.

I guess it depends on whether or not we want to make money, or otherwise, compete against others.

Re: A sufficiently detailed spec is code

#47

Post by sjeiuhvdiidi » Thu, Mar 19, 2026, 5:44 AM UTC

Absolute nonsense. A sufficiently detailed "spec" is the code. What is wrong with you people ? Pure nonsense, all they have to offer.

Re: A sufficiently detailed spec is code

#48

Post by lmm » Thu, Mar 19, 2026, 5:45 AM UTC

hintymad wrote: post #28

> A sufficiently detailed spec is code This is exactly the argument in Brooks' No Silver Bullet. I still believe that it holds. However, my observation is that many people don't really need that level of details. When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.

> When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.

If someone was making a serious request for a to-do list app, they presumably want it to do something different from or better than the dozens of to-do list apps that are already out there. Which would require them to somehow explain what that something was, assuming it's even possible.

Re: A sufficiently detailed spec is code

#49

Post by [deleted] » Thu, Mar 19, 2026, 5:49 AM UTC

[deleted]

Re: A sufficiently detailed spec is code

#50

Post by bigstrat2003 » Thu, Mar 19, 2026, 5:51 AM UTC

systemsweird wrote: post #10

charcircuit wrote: post #6

This articles ignores that AI agents have intelligence which means that they can figure out unspecified parts of the spec on their own. There is a lot of the design of software that I don't care about and I'm fine letting AI pick a reasonable approach.

Exactly. The real speed up from AI will come when we can under specify a system and the AI uses its intelligence to make good choices on the parts we left out. If you have to spec something out with zero ambiguity you’re basically just coding in English. I suspect current ideas around formal/detailed spec driven development will be abandoned in a couple years when models are significantly better.

> in a couple years when models are significantly better.

They aren't significantly better now than a couple of years ago. So it doesn't seem likely they will be significantly better in a couple of years than they are now.