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

351–360 of 376 posts

Re: A sufficiently detailed spec is code

#351

Post by [deleted] »

otabdeveloper4 wrote: post #23
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…

> optimizes their token usage and LLM spend Context pollution is a bigger problem. E.g., those SKILL.md files that are tens of kilobytes long, as if being exhaustively verbose and rambling will somehow make the LLM smarter. (It won't, it will just dilute the context with irrelevant stuff.)

[deleted]

Re: A sufficiently detailed spec is code

#352

Post by strix_varius »

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…

> the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions

> Sometimes the interpolated detail is wrong (and indeterministic)

... You consider incorrect, non deterministic results to be "reliable"?

Re: A sufficiently detailed spec is code

#353

Post by gck1 »

It seems like everyone has a very different idea of what spec means in agentic coding.

To me, spec answers the what, the plan answers the how, and in what order, build packets answer the how but with more granularity.

In most cases, you should only care about the what. How it gets done (plan) is simply an implementation detail that you should not care about the same way automated tests should not care about them.

What you prescribe in spec is that data must pass from A to B through C, preserved in D and presented in E in shape of F. It's much easier to write (and change) this in spec than in say, Rust.

Re: A sufficiently detailed spec is code

#354

Post by nitwit005 »

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?

There's this weird schizophrenia around this in the software world.

In the past I have had people here suggest they're just writing boilerplate CRUD software, and I've suggested that means they could just use low code tools instead. They then suggest it's too complex for that to work.

I think we tend to view ourselves as just hooking together basic operations, which might be technically true, but that becomes complex very quickly. A product can be built off of straight forward REST and database operations, but take you months of learning to get up to speed on.

Re: A sufficiently detailed spec is code

#355

Post by gck1 »

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…

SQL - somewhat, python - no. LLMs that write code only work well with proper guardrails. Dynamic languages like Python lack essential guardrails.

Once the project can't fit in model's usable context window (~150k tokens even for 1M models), you need code fighting back and leaving breadcrumbs for model to follow.

Re: A sufficiently detailed spec is code

#356

Post by skydhash »

derrak wrote: post #343
skydhash wrote: post #339

Earlier quoted context omitted.

Determinism implies that the same input will result in the same output. I agree with you that for a single C program there’s a set of assembly code that satisfies it. But by choosing a compiler, an architecture and a set of flags,… you will always get the same assembly code. If you decide to randomize them, then you can no longer guarantee a specific result, but you can still guarantee sets of result. Which is the de…

I see. Then we’re on the same page. My follow up question is: why do we care if the LLM is deterministic? Hypothetically, if we could guarantee a semantic relationship between the input and output we wouldn’t care if the LLM was deterministic. For instance, if I give the LLM a lean theorem and it instantiates a program and a mechanical proof that the program conforms to the lean theorem, I just don’t care about deter…

Non-determinism is not what people really care about.

If you remove randomness (temperature) from an LLM, It's going to be deterministic. But the relation between inputs and outputs is inscrutable (too many parameters) and there's no practical way prove the relation between a certain prompt and the output unless you run it.

Then you add randomness on top of that and the whole thing is a chaotic mess. Due to being formal, I believe generated code has a high probability of being correct (syntax) and generic patterns can be replicated easily. But the higher level concerns (the domain) and the nebulous concepts like maintainability, security,... is harder to replicate. Also correctness (logic) is hard to prove as you're unfamiliar with the code.

Re: A sufficiently detailed spec is code

#357

Post by zelphirkalt »

bluGill wrote: post #245
zabzonk wrote: post #215

Earlier quoted context omitted.

Isn't "not being upsidedown" just one of the default properties of a button in whatever GUI toolkit you are using? I'd be worried if an LLM _did_ start setting all the possible button properties.

If you ask for increase and decrease buttons they will put the right icons on it (not words) and lay them out right.

I cannot confirm that to work reliably and properly from experience of asking various LLMs about reducing button size in tkinter to a minimum for a button's label.

Re: A sufficiently detailed spec is code

#358

Post by derrak »

skydhash wrote: post #254
abainbridge wrote: post #226

Earlier quoted context omitted.

> 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. This perfectly explains the feeling I had when, 20 years into my career, I had to start writing specs. I could never quite put my finger on why it was harder than coding. My greater familiarity with coding didn't seem a sufficient explanation. When writing a line of s…

> 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…

So do you disagree with the parent that “code is just a spec as far as the C compiler is concerned”?

Maybe it’s important to agree on what a spec is. For instance, do you agree that a spec can be just as formal as code implementing the spec? For instance, if the spec is written in a machine parseable logic do you take that to be a spec? Or are you taking a spec to be written in natural language?

I suspect some of your disagreement with the parent is about this definition. I’m just trying to understand because for me it’s uncontroversial to claim C code is a spec for assembly code, but maybe the issue is that I am not thinking of specs in the colloquial way.

Re: A sufficiently detailed spec is code

#359

Post by roysting »

otikik wrote: post #212
roysting wrote: post #205

Earlier quoted context omitted.

In get the sense that what you are responding to and even many comments to yours are expressing a kind of coping with the current dynamic, only exacerbated by the rather elitist and egoistic mentality that people in tech have had for a very long time now; i.e., they are falling…being pushed from Mt Olympus and there is A LOT of anxious rationalization going on. Not a mere 5 years ago even tech people were chortling d…

I use AI for my work every single day - and during some weekends too. Claude Code, with Opus. It is far from being able to reliably produce the code that we need for production. It produces code that looks ok most of the time, but I have seen it lose track of key details, misinterpret requisites and even ignore them sometimes - "on purpose", as in it writing something like "let's not do that requirement, it's not nec…

I think we are in a bit of a trough of people trying to use methods and processes of irrelevant practices, when what is needed for a whole new dynamic, is an adapted and novel set of methods and processes. I suspect we may not get out of it for a number of years until a distinct AI-native generation can start emerging. I have had great effect and know others who have done even and far better than me, and all of them have totally reworked and revised everything about software development processes. Being able to adapt things form first principles seems to be the differentiating factor. I don't like it, but we are probably going to see a whole generation of the past software devs unable or unwilling to adapt to the revolution in the industry that is simply not going to go away.

Unfortunately we will lose things precisely because all that experience and expertise will not be captured and implemented, just like we have lost so man things from the past, like the many different proprietary and secret methods and practices that were jealously guarded by artisans, craftsmen, and artists. But now I've gotten off track a bit. Cheers.

Re: A sufficiently detailed spec is code

#360

Post by bluefirebrand »

adrian_b wrote: post #248
mike_hearn wrote: post #190

Earlier quoted context omitted.

Neither can humans, but the industry has decades of experience with how to instruct and guide human developer teams using specs.

When LLMs generate an appropriate program from ambiguous requirements, they do this because the requirements happen to match something similar that has been done previously elsewhere. There is a huge amount of programming work that consists in reinventing the wheel, i.e. in redoing something very similar to programs that have been written thousands of times before. For this kind of work LLMs can greatly improve produ…

> and even more than this, the removal of the copyrights from the original programs

This seems really strange to me. Can you explain how this is different than just stealing code from other sources, or copying it wholly from open source repos?

Post reply on HN