Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A sufficiently detailed spec is code

haskellforall.com

Post reply on HN
Print view View original

311–320 of 376 posts

Re: A sufficiently detailed spec is code

#311

Post by bigfishrunning »

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.

What does "better" mean here? i suspect that "better" would be defined...in a spec

Re: A sufficiently detailed spec is code

#312

Post by bigfishrunning »

charcircuit wrote: post #158
ozozozd wrote: post #70

Earlier quoted context omitted.

Here is an easy example: Say you and I both wrote the same spec that under-specifies the same parts. But we both expect different behavior, and trust that LLM will make the _reasonable_ choices. Hint: “The choice that I would have made.” Btw, by definition, when we under-specify we leave some decisions to the LLM unknowingly. And absent our looks or age as input, the LLM will make some _reasonable_ choices based on o…

And I'll say it doesn't matter. If it goes with your approach then I'll say that the approach works too. And if goes with my approach I hope you would recognize that my approach also is good enough for what we need. As long as the software meets the requirements, its okay if it isn't implemented the exact way it would have been if it was done by hand.

> As long as the software meets the requirements

"Requirements" are a spec. If your requirements lack detail, you probably won't get what you expected -- vague "requirements" can be met without solving your problem in many cases.

Re: A sufficiently detailed spec is code

#313

Post by marcosdumay »

ithkuil wrote: post #235
svara wrote: post #159

The vibe coding maximalist position can be stated in information theory terms: That there exists a decoder that can decode the space of useful programs from a much smaller prompt space. The compression ratio is the vibe coding gain. I think that way of phrasing it makes it easier to think about boundaries of vibe coding. "A class that represents (A) concept, using the (B) data structure and (C) algorithms for methods…

It's not necessarily just the terseness. Terseness might be a selling point for people who have already invested in training themselves to be fluent with programming languages and the associated ecosystem of tooling. But there is an entire cohort of people who can think about specifying systems but lack the training to sdo so so using the current methods and see a lower barrier to entry in the natural language. That…

> But there is an entire cohort of people who can think about specifying systems but lack the training to sdo so so using the current methods

Nah, it will be extremely surprising if even 1 such a person exists.

On the other hand, there are lots of people that can write code, but still can't specify a system. In fact, if you keep increasing the size of the system, you will eventually fit every single programmer in that category.

Re: A sufficiently detailed spec is code

#314

Post by observationist »

bad_username wrote: post #145

> There is no world where you input a document lacking clarity and detail and get a coding agent to reliably fill in that missing clarity and detail That is not true, and the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions. Code is the detail being filled in. Furthermore, LLMs are the ultimate detail fillers, because they are language interpolat…

ChatGPT 5.4 pro has surprised me several times; when asking a "can such and such be done" type question, intending to have a discussion about whether a thing can be done in principle, and what it might look like, it's actually produced a working example in response, in addition to answering the questions.

Some of the missing pieces come from memory, knowing which topics I like to explore, some from the model itself, either baked in knowledge or what it picks up searching, but they can definitely take a vague, handwavy half baked idea and whip up a full app or game or whitepaper. Sometimes it's "exactly what I wanted!", other times it's "exactly the kind of thing I was talking about!"

Semantics and context and nuance are part and parcel of LLM capabilities. Superhuman in some areas, definitely subhuman in others.

AI is getting pretty competent and clever.

Re: A sufficiently detailed spec is code

#315

Post by [deleted] »

bad_username wrote: post #145

> There is no world where you input a document lacking clarity and detail and get a coding agent to reliably fill in that missing clarity and detail That is not true, and the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions. Code is the detail being filled in. Furthermore, LLMs are the ultimate detail fillers, because they are language interpolat…

[deleted]

Re: A sufficiently detailed spec is code

#316

Post by charcircuit »

bigfishrunning wrote: post #312
charcircuit wrote: post #158

Earlier quoted context omitted.

And I'll say it doesn't matter. If it goes with your approach then I'll say that the approach works too. And if goes with my approach I hope you would recognize that my approach also is good enough for what we need. As long as the software meets the requirements, its okay if it isn't implemented the exact way it would have been if it was done by hand.

> As long as the software meets the requirements "Requirements" are a spec. If your requirements lack detail, you probably won't get what you expected -- vague "requirements" can be met without solving your problem in many cases.

It's okay if you don't get what you expect as long as it works. That's the point. There's a ton of different valid permutations and letting a LLM pick a good one ends up working in practice.

Re: A sufficiently detailed spec is code

#317

Post by riteshkew1001 »

angry_octet wrote: post #162

A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program. Since every invocation of an LLM may create a different program, just like people, we will see that the spec will leave much room for good and bad implementations, and highlight the imprecision in the spec. Once we start using a particular implementation it often become…

[flagged]

Re: A sufficiently detailed spec is code

#318

Post by jmcqk6 »

svara wrote: post #159

The vibe coding maximalist position can be stated in information theory terms: That there exists a decoder that can decode the space of useful programs from a much smaller prompt space. The compression ratio is the vibe coding gain. I think that way of phrasing it makes it easier to think about boundaries of vibe coding. "A class that represents (A) concept, using the (B) data structure and (C) algorithms for methods…

> That there exists a decoder that can decode the space of useful programs from a much smaller prompt space.

I love this. I've been circling this idea for a while and you put into words what I've struggled to describe.

> "A commercially successful team communication app built around the concept of channels, like in IRC." > Without already knowing Slack, that's not decodable.

I would like to suggest that implicit shared context matters here. Or rather, humans tend to assume more shared context than LLM's actually have, and that misleads us when it comes assessing the aforementioned decoder.

But I think it also suggests that there is a system that could be built with strong constraints and saliency that could really explode the compression ratio of vibe coding.

Re: A sufficiently detailed spec is code

#319

Post by skydhash »

abainbridge wrote: post #309
skydhash wrote: post #254

Earlier quoted context omitted.

> But code is just a spec as far as, say, a C compiler is concerned. The compiler is free to implement the assembly however it likes. Not at all. Code is formal, and going from C to assembly os deterministic. While the rules may be complex, they are still rules, and the compiler can’t stray away from them. Writing C code is easier than writing assembly because it’s an easier notation for thinking. It’s like when hamm…

> Code is formal, and going from C to assembly is deterministic. OK, this is the main thing. Going from C to assembly is not deterministic in a sense because different compilers can produce different output. But the behaviour of the generated assembly is always the same. This isn't true of a spec.

> Going from C to assembly is not deterministic in a sense because different compilers can produce different output.

That’s a weird definition of determinism.

Re: A sufficiently detailed spec is code

#320

Post by jerf »

Frieren wrote: post #148
rytis wrote: post #128

Earlier quoted context omitted.

> if the agent has difficulty generating Haskell code then that suggests agents aren't capable of reliably generalizing beyond their training data. doesn't that apply to flesh-and-bone developers? ask someone who's only working in python to implement their current project in haskell and I'm not so sure you'll get very satisfying results.

> doesn't that apply to flesh-and-bone developers? No, it does not. If you have a developer that knows C++, Java, Haskell, etc. and you ask that developer to re-implement something from one language to another the result will be good. That is because a developer knows how to generalize from one language (e.g. C++) and then write something concrete in the other (e.g. Haskell).

One language in the same category to another in the same category, yes. "Category" here being something roughly like "scripting, compiled imperative, functional". However my experience is that if you want to translate to another category and the target developer has no experience in it, you can expect very bad results. C++ to Haskell is among the most pessimal such translations. You end up with the writing X in Y problem.
Post reply on HN