[brap]

>writing programs is not hard. Specifying what a program should do is hard.

But these two things are kinda the same thing. Writing a program is mostly just specifying what it should do in a very specific, unambiguous way. That’s why we have programming languages and don’t use English.

A PRD, a design doc and the code itself are kind of all the same thing, but with increasing levels of specification.

If you’ve ever played with formal specifications at some point you probably had the realization “wait a minute, I’m just writing another implementation of the program!” and in a way you are.

[bobro]

Spoken language descriptions of how to do something are incredibly underdetermined. Many people are likely familiar with the meme of following exact instructions on making a PB&J where a phrase like “put a knife in your hand and spread the peanut butter” can result in stabbing yourself and rubbing peanut butter on the wound. More than half of my job is helping other people know or otherwise determining what they really want a program to do in the first place.

[bambax]

This sounds true but isn't.

"The program should accept one parameter as a number, and output this number multiplied by two" is a spec.

  input a

  print a*2

is a program.

But: why do that? why multiply by two? what does two represent? what do the input and output mean in the real world? what part is likely to change in the near future? etc.

Wrting the program isn't harder than writing the spec. Analyzing the problem and coming up with solutions is the hard part.

(And yes, LLMs are getting better at this everyday, but I think they still have a very long way to go.)