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

121–130 of 376 posts

Re: A sufficiently detailed spec is code

#121

Post by smackeyacky »

wongarsu wrote: post #77
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.

Most software written today (or 10 years ago, or 50 years ago) is not particularly unique. And even in that software that is unusual you usually find a lot of run-of-the-mill code for the more mundane aspects

I don’t think this is true. I’ve been doing this since the 1980s and while you might think code is fairly generic, most people aren’t shipping apps they’re working on quiet little departmental systems, or trying to patch ancient banking systems and getting a greenfield gig is pretty rare in my experience.

So for me the code is mundane but it’s always unique and rarely do you come across the same problems at different organisations.

If you ever got a spec good enough to be the code, I’m sure Claude or whatever could absolutely ace it, but the spec is never good enough. You never get the context of where your code will run, who will deploy it or what the rollback plan is if it fails.

The code isn’t the problem and never was. The problem is the environment where your code is going.

The proof is bit rot. Your code might have been right 5 years ago but isn’t any more because the world shifted around it.

I am using Claude pretty heavily but there are some problems it is awful at, e.g I had a crusty old classic ASP website to resuscitate this week and it would not start. Claude suggested all the things I half remembered from back in the day but the real reason was Microsoft disabled vbscript in windows 11 24H2 but that wasn’t even on its radar.

I have to remind myself that it’s a fancy xerox machine because it does a damn good job of pretending otherwise.

Re: A sufficiently detailed spec is code

#124

Post by trane_project »

jiggawatts wrote: post #104
trane_project wrote: post #98

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…

My twist on this is to first vibe code the solution with the aim of immediately replacing it. I’ve found that two to three iterations with various prompts or different models will often yield a surprising solution or some aspect I hadn’t thought of or didn’t know about. Then I throw away most or all of the code and follow your process, but with care to keep the good ideas from the LLMs, if any.

I mostly work with existing codebases so I didn't really want to vibecode for real.

The only vibecoded thing was an iOS app and I didn't follow this process because I don't know iOS programming nor do I want to learn it. This only works if you know at least how to define functions and data structures in the language, but I think most PMs could learn that if they set their minds to it.

Re: A sufficiently detailed spec is code

#125

Post by ChrisGreenHeur »

Gabriel439 wrote: post #109
baxtr wrote: post #69

Earlier quoted context omitted.

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

Author here: it's not even clear that agents can reliably permute their training data (I'm not saying that it's impossible or never happens but that it's not something we can take for granted as a reliable feature of agentic coding). As I mentioned in one of the footnotes in the post: > People often tell me "you would get better results if you generated code in a more mainstream language rather than Haskell" to which…

It can also mean that the other programming language is above the cognitive abilities of the LLM

Re: A sufficiently detailed spec is code

#126

Post by ChrisGreenHeur »

loveparade wrote: post #93
baxtr wrote: post #69

Earlier quoted context omitted.

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?

The point is the small variations

Re: A sufficiently detailed spec is code

#127

Post by Toutouxc »

philipp-gayret wrote: post #90
nostrademons wrote: post #83

Earlier quoted context omitted.

Most of the economically valuable software written is pretty unique, or at least is one of few competitors in a new and growing niche. This is because software that is not particularly unique is by definition a commodity, with few differentiators. Commodity software gets its margins competed away, because if you try to price high, everybody just uses a competitor. So goes the AI paradox: it's really effective at writ…

Could you give some examples? I can only imagine completely proprietary technology like trading or developing medicine. I have worked in software for many years and was always paid well for it. None of it was particularly unique in any way. Some of it better than others, but if you could show that there exists software people pay well for that AI cannot make I would be really impressed. With my limited view as softwa…

All it takes is a sufficiently big pile of custom features interacting. I work on a legal tech product that automates documents. Coincidentally, I'm just wrapping up a rewrite of the "engine" that evaluates how the documents will come out. The rewrite took many months, the code uses graph algorithms and contains a huge amount of both domain knowledge and specific product knowledge.

Claude Code is having the hardest time making sense of it and not breaking everything every step of the way. It always wants to simplify, handwave, "if we just" and "let's just skip if null", it has zero respect for the amount of knowledge and nuance in the product. (Yes, I do have extensive documentation and my prompts are detailed and rarely shorter than 3 paragraphs.)

Re: A sufficiently detailed spec is code

#128

Post by rytis »

Gabriel439 wrote: post #109
baxtr wrote: post #69

Earlier quoted context omitted.

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

Author here: it's not even clear that agents can reliably permute their training data (I'm not saying that it's impossible or never happens but that it's not something we can take for granted as a reliable feature of agentic coding). As I mentioned in one of the footnotes in the post: > People often tell me "you would get better results if you generated code in a more mainstream language rather than Haskell" to which…

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

Re: A sufficiently detailed spec is code

#129

Post by brunorsini »

A sufficiently detailed spec was actually a small step in the path to functional code.

Then came all sorts of shenanigans, from memory management to syntax hell, which took forever to learn effectively.

This stage was a major barrier to entry, and it's now gone — so yeah, things have indeed changed completely.

Re: A sufficiently detailed spec is code

#130

Post by kstenerud »

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…

Human language is already very efficient for conveying the ideas we have. Some languages are more efficient at conveying certain concepts, but all are able to handle the 90% case. I'd expect any attempts to build a "technical dialect of English" to go about as well as Esperanto.
Post reply on HN