A sufficiently detailed spec is code • Hacker News Board

Re: A sufficiently detailed spec is code

#151

Post by Frieren » Thu, Mar 19, 2026, 7:58 AM UTC

kstenerud wrote: post #144

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…

I've been working with coding LLMs for almost a year. Here's what I've found works best: - Do a brainstorming session with the LLM about your idea. Flesh out the major points of the product, who the stakeholders are, what their motivations and goals are, what their pain points are. Research potential competitors. Find out what people are saying about them, especially the complaints. - Build a high level design docume…

You are basically discovered working in a team. Even that it is an inferior version of that.

I have always done that steps with my team and the results are great.

If you are a solo developer I understand that the LLM can help somewhat but not replace a real team of developers.

Re: A sufficiently detailed spec is code

#152

Post by debugnik » Thu, Mar 19, 2026, 7:59 AM UTC

Archer6621 wrote: post #141

mfabbri77 wrote: post #117

Earlier quoted context omitted.

The point was to answer the question: "Can every piece of software be viewed as a permutation of software that has already been developed?" In my opinion, an email client is a more favorable example than a 3D engine. In fields where it is necessary to differentiate, improve, or innovate at the algorithmic level, where research and development play a fundamental role, it is not simply a matter of permuting software or…

Actually, in the specific case of a 3D program it's the current generation of LLM's complete lack of ability in spatial reasoning that prevents them from "understanding" what you want when you ask it to e.g. "make a camera that flies in the direction you are looking at". It necessarily has to derive it from examples of cameras that fly forward that it knows about, without understanding the exact mathematical underpin…

> "make a camera that flies in the direction you are looking at"

That's not the task of a renderer though, but its client, so you're talking past your parent comment. And given that I've seen peers one-shot tiny Unity prototypes with agents, I don't really believe they're that bad at taking an educated guess at such a simple prompt, as much as I wish it were true.

Re: A sufficiently detailed spec is code

#153

Post by midasz » Thu, Mar 19, 2026, 8:00 AM UTC

rahulj51 wrote: post #71

For this to be true, we should be able to - Delete code and start all over with the spec. I don't think anyone's ready to do that. - Buy a software product / business and be content with just getting markdown files in a folder.

This and the idea of creating some sort of english-adjacent programming language for LLM's is fun, I guess, but what problem is it solving. Do we really need to go an abstraction higher?

Re: A sufficiently detailed spec is code

#154

Post by charcircuit » Thu, Mar 19, 2026, 8:01 AM UTC

abcde666777 wrote: post #16

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.

These algorithms don't have intelligence, they just regurgitate human intelligence that was in their training data. That also goes the other way - they can't produce intelligence that wasn't represented in their training input.

Firstly, it doesn't really matter if they can produce novel designs or not. 99% of what is being done is not novel. It is manipulating data in ways computers have been manipulating data for decades. The design of what is implemented is also going to be derivative of what already exists in the world too. Being too novel makes for a bad product since users will not easily understand how to use it and adapt their existing knowledge of how other things work.

Secondly, they are able to produce intelligence that wasn't represented in their training input. As a simple example take a look at chess AI. The top chess engines have more intelligence over the game of chess than the top humans. They have surpassed humans understanding of chess. Similar with LLMs. They train on synthetic data that other LLMs have made and are able to find ways to get better and better on their own. Humans learn off the knowledge of other humans and it compounds. The same thing applies to AI. It is able to generated information and try things and then later reference what it tried when doing something else.

Re: A sufficiently detailed spec is code

#155

Post by loveparade » Thu, Mar 19, 2026, 8:02 AM UTC

lynx97 wrote: post #134

loveparade wrote: post #93

Earlier quoted context omitted.

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?

I read this attitude very often on HN. "If someone else has already built it before, your effort is a waste of time." To me, it has this "Someone else already makes money from it, go somewhere else where you dont have competition." Well, I get the drift... But... Not everyone is into getting rich. You know, some of us just have fun building things and learning while doing so. It really doesn't matter if the path has…

If you do it for fun then why do you care whether an LLM can do it well or not, which was the original argument? Shouldn't matter to you in that case.

Re: A sufficiently detailed spec is code

#156

Post by ozlikethewizard » Thu, Mar 19, 2026, 8:03 AM UTC

rytis wrote: post #128

Gabriel439 wrote: post #109

Earlier quoted context omitted.

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.

The hard bit of programming has never been knowing the symbols to tell the computer what to do. It is more difficult to use a completely unknown language, sure, but the paradigms and problem solving approaches are identical and thats the actual work, not writing the correct words.

Re: A sufficiently detailed spec is code

#157

Post by Someone » Thu, Mar 19, 2026, 8:03 AM UTC

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…

> That is not true, and the proof is that LLMs _can_ reliably generate (relatively small amounts of) working code from relatively terse descriptions.

LLMs can generate (relatively small amounts of) working code from relatively terse descriptions, but I don’t think they can do so _reliably_.

They’re more reliable the shorter the code fragment and the more common the code, but they do break down for complex descriptions. For example, try tweaking the description of a widely-known algorithm just a little bit and see how good the generated code follows the spec.

> Sometimes the interpolated detail is wrong (and indeterministic), so, if reliable result is to be achieved

Seems you agree they _cannot_ reliably generate (relatively small amounts of) working code from relatively terse descriptions

Re: A sufficiently detailed spec is code

#158

Post by charcircuit » Thu, Mar 19, 2026, 8:03 AM UTC

ozozozd wrote: post #70

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.

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.

Re: A sufficiently detailed spec is code

#159

Post by svara » Thu, Mar 19, 2026, 8:07 AM UTC

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 (D), in programming language (E)."

That's decodeable, at least to a narrow enough distribution.

"A commercially successful team communication app built around the concept of channels, like in IRC."

Without already knowing Slack, that's not decodable.

Thinking about what is missing is very helpful. Obviously, the business strategic positioning, non technical stakeholder inputs, UX design.

But I think it goes beyond that: In sufficiently complex apps, even purely technical "software engineering" decisions are to some degree learnt from experiment.

This also makes it more clear how to use AI coding effectively:

* Prompt in increments of components that can be encoded in a short prompt.

* If possible, add pre-existing information to the prompt (documentation, prior attempts at implementation).

Re: A sufficiently detailed spec is code

#160

Post by jumploops » Thu, Mar 19, 2026, 8:08 AM UTC

In my experience with “agentic engineering” the spec docs are often longer than the code itself.

Natural language is imperfect, code is exact.

The goal of specs is largely to maintain desired functionality over many iterations, something that pure code handles poorly.

I’ve tried inline comments, tests, etc. but what works best is waterfall-style design docs that act as a second source of truth to the running code.

Using this approach, I’ve been able to seamlessly iterate on “fully vibecoded” projects, refactor existing codebases, transform repositories from one language to another, etc.

Obviously ymmv, but it feels like we’re back in the 70s-80s in terms of dev flow.