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.
A sufficiently detailed spec is code
71–80 of 376 posts
Re: A sufficiently detailed spec is code
#72I am developing my own programming language, but I have no specification written for it. When people tell me that I need a specification, I reply that I already have one - the source code of the language compiler.
The source code does what it does, including bugs.
So unless you want bugs to be your specification, you actually need to specify what you want.
Re: A sufficiently detailed spec is code
#73This 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.
How does post-training via reinforcement learning factor in? Does every evaluated judgement count as 'the training data' ?
Re: A sufficiently detailed spec is code
#74I think it's only a matter of time before people start trying to optimize model performance and token usage by creating their own more technical dialect of English (LLMSpeak or something). It will reduce both ambiguity and token usage by using a highly compressed vocabulary, where very precise concepts are packed into single words (monads are just monoids in the category of endofunctors, what's the problem?). Grammat…
Or they could look at the past few centuries of language theory and start crafting better tokenizers with inductive biases.
We literally have proof that an iron age ontology of meaning as represented in Chinese characters is 40% more efficient than naive statistical analysis over a semi phonetic language and we still are acting like more compute will solve all our problems.
Re: A sufficiently detailed spec is code
#75I recently left this comment on another thread. At the time I was focused on planning mode, but it applies here.
Plan mode is a trap. It makes you feel like you're actually engineering a solution. Like you're making measured choices about implementation details. You're not, your just vibe coding with extra steps. I come from an electrical engineering background originally, and I've worked in aerospace most of my career. Most software devs don't know what planning is. The mechanical, electrical, and aerospace engineering teams plan for literal years. Countless reviews and re-reviews, trade studies, down selects, requirement derivations, MBSE diagrams, and God knows what else before anything that will end up in the final product is built. It's meticulous, detailed, time consuming work, and bloody expensive.
That's the world software engineering has been trying to leave behind for at least two decades, and now with LLMs people think they can move back to it with a weekend of "planning", answering a handful of questions, and a task list.
Even if LLMs could actually execute on a spec to the degree people claim (they can't), it would take as long to properly define as it would to just write it with AI assistance in the first place.
Re: A sufficiently detailed spec is code
#76This is laid out in “the code is the design” - https://www.developerdotstar.com/mag/articles/reeves_design_... by jack reeves.
Like they say “everything comes round again”
Re: A sufficiently detailed spec is code
#77> A sufficiently detailed spec is code This is exactly the argument in Brooks' No Silver Bullet. I still believe that it holds. However, my observation is that many people don't really need that level of details. When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.
Yes. This happens because the training data contains countless SotA "to-do" apps. This argument does not scale well to other types of software.
Most software written today (or 10 years ago, or 50 years ago) is not particularly unique. And even in that software that is unusual you usually find a lot of run-of-the-mill code for the more mundane aspects
Re: A sufficiently detailed spec is code
#78For 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.
I've heard of people _experimenting_ with deleting their code every day.
I haven't heard of being content paying for a product consisting of markdown files. Though I could imagine people paying for agent skill files. But yet, the skills are not the same product as say, linear.
Re: A sufficiently detailed spec is code
#79> A sufficiently detailed spec is code This is exactly the argument in Brooks' No Silver Bullet. I still believe that it holds. However, my observation is that many people don't really need that level of details. When one prompts an AI to "write me a to-do list app", what they really mean is that "write me a to-do list app that is better that I have imagined so far", which does not really require detailed spec.
Everyone at least heard stories of people who just want that button 5px to the right or to the left and next meeting they want it in bottom corner - whereas it doesn’t make functionally any difference.
But that’s most of the time is not that they want it from objective technical reasons.
They want it because they want to see if they can push you. They do it „because they can”. They do it because later they can renegotiate or just nag and maybe pay less. Multiple reasons that are not technical.
Re: A sufficiently detailed spec is code
#80No, a spec is not code. It's possible to describe simple behavior that's nevertheless difficult to implement. Consider, say, fn sin(x: f16) -> f16 There are only 64k different f16s. Easy enough to test them all. A given sin() is either correct or it's not. Yet sin() here can have a large number of different implementations. The spec alone under-determines the actual code.
Well, the spec can of course define constraints of how the function is implemented.