A sufficiently detailed spec is code • Hacker News Board

Re: A sufficiently detailed spec is code

#301

Post by agentultra » Thu, Mar 19, 2026, 3:42 PM UTC

et1337 wrote: post #297

agentultra wrote: post #276

Earlier quoted context omitted.

We do have such detailed specifications. But they are written in a language with a narrow interface. It’s a technique called, “program synthesis,” and you can find an example of such a language called, Synquid . It might be illuminating to see what a mathematically precise specification can and cannot do when it comes to generating programs. A major challenge in formal methods is proving that the program implements t…

I think the worst case is actually that the LLM faithfully implements your spec, but your spec was flawed. To the extent that you outsource the mechanical details to a machine trained to do exactly what you tell it, you destroy or at least hamper the feedback loop between fuzzy human thoughts and cold hard facts.

Unfortunately even formal specifications have this problem. Nothing can replace thinking. But sycophancy, I agree, is a problem. These tools are designed to be pleasing, to generate plausible output; but they cannot think critically about the tasks they're given.

Nothing will save you from a bad specification. And there's no royal road to knowing how to write good ones.

Re: A sufficiently detailed spec is code

#302

Post by adi_kurian » Thu, Mar 19, 2026, 3:42 PM UTC

ex-aws-dude wrote: post #37

adi_kurian wrote: post #30

This won't age well, or my comment won't age well. We'll see!

It will either be true or not be true That is the great insight I can offer

Mostly, I wrote "this won't age well", then appended the circular comment as I didn't want to sound like an arsehole.

Looks like I would have been better off!

Re: A sufficiently detailed spec is code

#303

Post by antonvs » Thu, Mar 19, 2026, 3:43 PM UTC

Panzerschrek wrote: post #136

antonvs wrote: post #60

Earlier quoted context omitted.

Maybe this is your point, but the source code of any non-toy compiler is not a usable specification for the language it compiles. If you want a specification from source code, you need to reverse engineer it. Although that’s a bit easier now, with LLMs.

What do you mean "usable specification"? Usable to produce another compiler implementation for the same language? This IS possible (like clang was designed to match GCC behavior). Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.

You partly answered your own question by mentioning "implementation". Specification and implementation are two different things, and both are important.

A specification describes the externally observable behavior, constraints, and properties of a system. That's independent of how those properties are implemented.

An implementation is a concrete realization of a specification, that achieves the specified behavior using particular algorithms, data structures, and operational mechanisms.

> Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.

That's a non sequitur, i.e. the part of your sentence after the commas doesn't follow from the first part.

"Pure specification itself" has a purpose, which is to guide implementations. That's the "practical sense".

Re: A sufficiently detailed spec is code

#304

Post by danielam » Thu, Mar 19, 2026, 3:48 PM UTC

gusmd wrote: post #273

dxdm wrote: post #208

Earlier quoted context omitted.

Usually, you don't want your developers to be coding monkeys, for good results. You need the human developer in the loop to even define the spec, maybe contributing ideas, but at the very least asking questions about "what happens when..." and "have you thought about...". In fact, this is a huge chunk of the value a developer brings to the table.

And this is usually one of the defining traits of a senior engineer. They understand the tech and its limitations, and thus are able to look around corners, ask good questions, and, overall, provide quality product input.

In other words, prudential judgement.

Programs are a socially constructed artifact that help communicate and express a model (which is perpetually locked in people's heads with variance across engineers; divergence is addressed as the program develops). Determining what should or should not be done is a matter of not just domain knowledge, but practical reason, which is to say prudence, which is a virtue that can only be acquired by experience. It is an ability to apply universal principles to particular situations.

This is why young devs, even when clever in some local sense, are worse at understanding the right moves to make in context. Code does not stand alone. It exists entirely in the service of something and is bound by constraints that are external to it.

Re: A sufficiently detailed spec is code

#305

Post by et1337 » Thu, Mar 19, 2026, 3:53 PM UTC

agentultra wrote: post #301

et1337 wrote: post #297

Earlier quoted context omitted.

I think the worst case is actually that the LLM faithfully implements your spec, but your spec was flawed. To the extent that you outsource the mechanical details to a machine trained to do exactly what you tell it, you destroy or at least hamper the feedback loop between fuzzy human thoughts and cold hard facts.

Unfortunately even formal specifications have this problem. Nothing can replace thinking. But sycophancy, I agree, is a problem. These tools are designed to be pleasing, to generate plausible output; but they cannot think critically about the tasks they're given. Nothing will save you from a bad specification. And there's no royal road to knowing how to write good ones.

Right, there’s no silver bullet. I think all I can do is increase the feedback bandwidth between my brain and the real world. Regular old stuff like linters, static typing, borrow checkers, e2e tests… all the way to “talking to customers more”

Re: A sufficiently detailed spec is code

#306

Post by bigfishrunning » Thu, Mar 19, 2026, 4:07 PM UTC

vbezhenar wrote: post #237

ModernMech wrote: post #234

Earlier quoted context omitted.

The main thing they cannot do is be held accountable for any decisions, which makes them not trustworthy.

This is not correct. They can say "sorry" which makes them as accountable as ordinary developer.

Ordinary developers get fired for poor performance *all the time*.

Re: A sufficiently detailed spec is code

#307

Post by cush » Thu, Mar 19, 2026, 4:09 PM 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…

Exactly. Any developer working on any project will encounter a decision that wasn’t in the spec, where they use their judgement and taste to fill in gaps. The idea that only code can be a complete spec assumes the code perfectly matches the original intent - which we know it rarely does in a project of meaningful size.

Re: A sufficiently detailed spec is code

#308

Post by bigfishrunning » Thu, Mar 19, 2026, 4:09 PM UTC

pixl97 wrote: post #300

bluefirebrand wrote: post #249

Earlier quoted context omitted.

That's not what accountability is

Accountability: "Something that SWE's run screaming from". Example: "We should have professional accountability in software" SWE: "This would bring about the end of the world!!!1!"

The economics of software development have lowered the bar for software engineers: there simply aren't enough people who are good at it (or even want to be), and the salaries are very high, so plenty of people who shouldn't be SWE's are.

I am a software engineer, and I would absolutely love to see more professional accountability in this field. Unfortunately, it would make the cost of software go up significantly (because many many people writing software would be ejected from the industry)

Re: A sufficiently detailed spec is code

#309

Post by abainbridge » Thu, Mar 19, 2026, 4:12 PM UTC

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…

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

Re: A sufficiently detailed spec is code

#310

Post by bigfishrunning » Thu, Mar 19, 2026, 4:13 PM UTC

jappgar wrote: post #246

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…

As you can see by downvotes and comments, they still don't get it. LLMs make developers more efficient. That much is obvious to anyone who isn't blinded by fear. But people will respond "but you still need developers!" True. You don't need nearly as many, though. In fact, with an LLM in their hands, the poor performers are more of a liability than ever. They'll be let go first. But even the "smart" developers will be…

> LLMs make developers more efficient.

They do not. I review a ton of code, and while the quantity is going up, the quality of that code is getting worse. LLMs only make developers more efficient if they skip the due-diligence required to verify its output; they all say they don't, and almost all of them do.