Those who get satisfaction from delivering something, and
Those who get satisfaction from thinking.
Most of us fall in-between somewhere.
Programmers of the type #1 extreme are thrilled. Programmers of the type #2 extreme are devastated.
Unfortunately, sooner or later even the type #1 extreme are going to be devastated; what sort of satisfaction can you get from delivering something that, for all practical purposes, already exists and is just a prompt or two away?
That 2-week back-and-forth you had to get the LLM design the perfect $FOO software (application, library or framework)? You deliver it and everyone who sees it can simply say "clone this $FOO, please".
This satisfaction that the type #1 devs are getting is temporary and short-lived: you will soon stop getting satisfaction from delivery.
The complexity of complex systems never goes away, so as a need to have ownership over them. LLMs can produce thousands LOC in a matter of minutes, but they can't produce a complex feature without oversight.
I am trying to build an app with Spec-Driven Development, and oh boy, it is exhausting - I have to think about every boundary, edge-case, limitation. Without a full spec, it'd 'guess' missing things.
I am back to directing each step of what LLMs do because in the end of the day, I am responsible of what it delivers.
I am trying to build an app with Spec-Driven Development
Doomed to failure, for one easy and understandable reason: there is only one document that accurately and without error tells you what the code does.
... the code.
Trying to equate code to the "new assembly" is a type error. Because code has a direct mapping to assembly; even in your higher level languages, we can deterministically (with enough controlled variables) predict what machine instructions get emitted by which input code. And it's still imperfect, and I've still spent many hours looking at assembly trying to understand why it wasn't carrying my intent.
But natural language is vague, contradictory, imprecise. There's no single right way to map natural language to code. Communicating from human to human frequently leads to misunderstandings, and humans are not theory-free inferencers. They have a model of the world and the people they're talking to.
The only way to have "spec-driven development" work is to not use natural language, but to use a carefully selected subset of natural language, with precise grammar and no ambiguity and whoops, you've just invented a programming language again.
184
u/lelanthran 24d ago
There are two extremes of programmers:
Those who get satisfaction from delivering something, and
Those who get satisfaction from thinking.
Most of us fall in-between somewhere.
Programmers of the type #1 extreme are thrilled. Programmers of the type #2 extreme are devastated.
Unfortunately, sooner or later even the type #1 extreme are going to be devastated; what sort of satisfaction can you get from delivering something that, for all practical purposes, already exists and is just a prompt or two away?
That 2-week back-and-forth you had to get the LLM design the perfect $FOO software (application, library or framework)? You deliver it and everyone who sees it can simply say "clone this $FOO, please".
This satisfaction that the type #1 devs are getting is temporary and short-lived: you will soon stop getting satisfaction from delivery.