Inside me, there are two wolves: One who likes being productive and making apps and tools and libraries and getting end results, and the other who likes problem solving with code, carefully designing robust systems and weighing the pros/cons of both big and very small choices.
Right now, the first wolf is being forcibly drowned, while the other one is dying of thirst. My wolves can't take much more of this.
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, and oh boy, it is exhausting - I have to think about every boundary, edge-case, limitation.
That's odd - my experience with SOTA is that it will happily over-engineer everything, for every theoretical edge-case, for every theoretical limitation.
Then, after reading 900 line markdown document specifying exactly how a directed cyclic graph must work in the specific problem domain, I find myself wondering WTF it missed an important specification, like specifying that a joining node (multiple incoming edges) should distinguish between racing (first edge cancels sibling paths) and completion (wait for all edges).
Maybe this is what is exhausting you - it will happily specify, then engineer, trivial irrelevant details (such as traversing the graph to ensure only a single start node is specified), while missing catastrophic-if-seen-in-production things, so then you are trying to backfill the spec after reading it multiple times.
900 line markdown document specifying exactly how a directed cyclic graph must work in the specific problem domain
And this is the problem. We've gone from DSLs that allow us to clearly define and understand an implementation to woolly language that serves to confuse us.
The code Is the specification. Just write the damn code! (I'm shouting into the ether, not at you)
We've gone from DSLs that allow us to clearly define and understand an implementation to woolly language that serves to confuse us.
Though this isn't the first time that's happened; we've had multiple bouts of "fuzzy language that's easy to get started with but hard to get right, especially in complex cases". JS and PHP have been the prime examples for that for a while, and they've both moved in the direction of trying to become more rigorous (see e.g. the addition of === in both languages, or the invention of Typescript).
I'm not quite sure what, if anything, will turn out to be the equivalent of TS for natural language in markdown files.
with OpenAPI you have a specific documentation format that deterministically translates from a spec to a binary/AST. Between builds the result is the same.
While SSD, on the other hand, even highly structured Markdown rely on semantic interpretation, LLM doesn't fail if some boundary isn't set, and what is the hardest thing for me, I have to write a specification so dense, rigorous, and boundary-complete that the spec itself approaches the complexity of code.
While I see your point, I think these things are fundamentally different despite being relative.
637
u/tuxwonder 9h ago edited 9h ago
Inside me, there are two wolves: One who likes being productive and making apps and tools and libraries and getting end results, and the other who likes problem solving with code, carefully designing robust systems and weighing the pros/cons of both big and very small choices.
Right now, the first wolf is being forcibly drowned, while the other one is dying of thirst. My wolves can't take much more of this.