A sufficiently detailed spec is code • Hacker News Board

Re: A sufficiently detailed spec is code

#91

Post by retsibsi » Thu, Mar 19, 2026, 6:53 AM UTC

noosphr wrote: post #74

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…

Or they could look at the past few centuries of language theory and start crafting better tokenizers with inductive biases. We literally have proof that an iron age ontology of meaning as represented in Chinese characters is 40% more efficient than naive statistical analysis over a semi phonetic language and we still are acting like more compute will solve all our problems.

> We literally have proof that an iron age ontology of meaning as represented in Chinese characters is 40% more efficient than naive statistical analysis over a semi phonetic language

Can you elaborate? I think you're talking about https://github.com/PastaPastaPasta/llm-chinese-english , but I read those findings as far more nuanced and ambiguous than what you seem to be claiming here.

Re: A sufficiently detailed spec is code

#92

Post by layer8 » Thu, Mar 19, 2026, 6:53 AM UTC

mfabbri77 wrote: post #81

baxtr wrote: post #69

Earlier quoted context omitted.

Isn’t most standard software these days a permutation of things already done before?

In my experience, the further you move away from the user and toward the hardware and fundamental theoretical algorithms, the less true this becomes. This is very true for an email client, but very untrue for an innovative 3D rendering engine technology (just an example).

An email client is highly nontrivial, due to the complexities of the underlying standards, and how the real implementations you have to be compatible with don’t strictly follow them. Making an email client that doesn’t suck and is fully interoperable is quite an ambitious endeavor.

Re: A sufficiently detailed spec is code

#93

Post by loveparade » Thu, Mar 19, 2026, 6:54 AM UTC

baxtr wrote: post #69

mfabbri77 wrote: post #51

Earlier quoted context omitted.

Yes. This happens because the training data contains countless SotA "to-do" apps. This argument does not scale well to other types of software.

Isn’t most standard software these days a permutation of things already done before?

But what's the point of re-building "standard software" if it is so standard that it already exists 100 times in the training data with slight variations?

Re: A sufficiently detailed spec is code

#94

Post by layer8 » Thu, Mar 19, 2026, 6:56 AM UTC

baxtr wrote: post #69

mfabbri77 wrote: post #51

Earlier quoted context omitted.

Yes. This happens because the training data contains countless SotA "to-do" apps. This argument does not scale well to other types of software.

Isn’t most standard software these days a permutation of things already done before?

That isn’t saying much. Every software is a permutation of zeros and ones. The novelty or ingenuity, or just quality and fitness for purpose, can lie in the permutation you come up with. And an LLM is limited by its training in the permutations it is likely to come up with, unless you give it heaps of specific guidance on what to do.

Re: A sufficiently detailed spec is code

#95

Post by quotemstr » Thu, Mar 19, 2026, 6:56 AM UTC

9rx wrote: post #82

quotemstr wrote: post #68

No, a spec is not code. It's possible to describe simple behavior that's nevertheless difficult to implement. Consider, say, fn sin(x: f16) -> f16 There are only 64k different f16s. Easy enough to test them all. A given sin() is either correct or it's not. Yet sin() here can have a large number of different implementations. The spec alone under-determines the actual code.

It says a sufficiently detailed spec is code. Your spec lacks details that could be added.

If you're defining "spec" that way, the word is meaningless. The point of a spec is what it doesn't say.

Re: A sufficiently detailed spec is code

#96

Post by bob1029 » Thu, Mar 19, 2026, 6:56 AM UTC

It helps to decouple the business requirements from the technical ones. It's often not possible to completely separate these areas, but I've been on countless calls where the extra technical detail completely drowns out the central value proposition or customer concern. The specification should say who, what, where, when, why. The code should say how.

The code will always be an imperfect projection of the specification, and that is a feature. It must be decoupled to some extent or everything would become incredibly brittle. You do not need your business analysts worrying about which SQLite provider is to be used in the final shipped product. Forcing code to be isomorphic with spec means everyone needs to know everything all the time. It can work in small tech startups, but it doesn't work anywhere else.

Re: A sufficiently detailed spec is code

#97

Post by codebje » Thu, Mar 19, 2026, 6:57 AM UTC

catlifeonmars wrote: post #44

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.

A thorough specification might even include the acceptable precision on the sine wave; a thorough engineer might ask the author what the acceptable precision is if it's omitted.

Re: A sufficiently detailed spec is code

#98

Post by trane_project » Thu, Mar 19, 2026, 6:58 AM UTC

I've been trying codex and claude code for the past month or so. Here's the workflow that I've ended up with for making significant changes.

- Define the data structures in the code yourself. Add comments on what each struct/enum/field does.

- Write the definitions of any classes/traits/functions/interfaces that you will add or change. Either leave the implementations empty or write them yourself if they end up being small or important enough to write by hand (or with AI/IDE autocompletion).

- Write the signatures of the tests with a comment on what it's verifying. Ideally you would write the tests yourself, specially if they are short, but you can leave them empty.

- Then at this point you involve the agent and tell it to plan how to complete the changes without barely having to specify anything in the prompt. Then execute the plan and ask the agent to iterate until all tests and lints are green.

- Go through the agent's changes and perform clean up. Usually it's just nitpicks and changes to conform to my specific style.

If the change is small enough, I find that I can complete this with just copilot in about the same amount of time it would take to write an ambiguous prompt. If the change is bigger, I can either have the agent do it all or do the fun stuff myself and task the agent with finishing the boring stuff.

So I would agree with the title and the gist of the post but for different reasons.

Example of a large change using that strategy: https://github.com/trane-project/trane/commit/d5d95cfd331c30...

Re: A sufficiently detailed spec is code

#99

Post by wazHFsRy » Thu, Mar 19, 2026, 6:59 AM UTC

Maybe an argument can be made that this definitely holds for some areas of the feature one is building. But in ever task there might be areas where the spec, even less descriptive than code, is enough, because many solutions are just „good enough“? One example for me are integration tests in our production application. I can spec them with single lines, way less dense than code, and the llms code is good enough. It may decide to assert one way or another, but I do not care as long as the essence is there.

Could be that the truth is somewhere in between?

Re: A sufficiently detailed spec is code

#100

Post by fmbb » Thu, Mar 19, 2026, 7:00 AM UTC

mfabbri77 wrote: post #81

baxtr wrote: post #69

Earlier quoted context omitted.

Isn’t most standard software these days a permutation of things already done before?

In my experience, the further you move away from the user and toward the hardware and fundamental theoretical algorithms, the less true this becomes. This is very true for an email client, but very untrue for an innovative 3D rendering engine technology (just an example).

I would be surprised if there are more working email clients out there than working 3D engines. The gaming market is huge, most people do not pay to use email, hobbyists love creating game engines.