> Code is just detailed specifications on how things should operate.
The spec defines how things should operate. Code defines how things operate.
The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.
Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.
When "using an LLM", means the human has to substantially alter the output of the LLM for the work to be eligible for copyright. Agreed.
But this makes the LLM tool different to other tools. If I author a novel using a word processor I don't then in addition have to substantially alter that output in order for the work to qualify for copyright.
[edit]
It's like, how substantive would changes to J.K. Rowling's Harry Potter need to to be in order for a derivative work to qualify for copyright? Now apply that to the output of an LLM.
In aerospace related industries there is a culture of writing and reading of requirements.
I system engineered for a major US satellite TV provider, and just the specification that defined the protocol for transmitting guide data over the satellite was about 640 US letter pages when printed.
I used to work in Burbank and lived approximately 34 miles away, across Los Angeles. It could take almost three hours for me to drive home on a Friday afternoon on the freeway. This was before Covid, and traffic has only gotten worse.
That way of teaching got us to the moon, created transistors, produced the internet, smartphones, quantum computers, the very AI that everyone is talking about, vaccines, sent probes into space, cured diseases, fed millions, jumbo jets, basically every single thing that society has come to depend on.
My Dad could never build the metal model to understand that common concepts like copy/paste would work almost identically across different native Windows applications; "How do I copy/paste in an email?", "How do I copy/paste in a Word document?", "How do I open a file in Excel?", "How do I open a file in Word?".
The lightbulb just never went on in his head. And this was in the 90s and early 2000s when developers at least used MFC - probably the period of peak UX design.
Things have now gotten so much worse since then. Now, I struggle to remember how to add an attachment in MS Teams, which I use every day.
Keep in mind that Fielding used his "REST" principles to drive work on the release of HTTP 1.1 in 1999. He subsequently codified these RESTful principles in his dissertation in 2000. The first JSON message was sent in 2001. The reason RESTful is perfectly suited to the WWW is because REST drove HTTP 1.1, not the other way around.
Now days there are just so many use cases where an architecture is more suited to RPC (and POST). And trying to bend the architecture to be "more RESTful" just serves to complicate.
> You describe how web pages work, web pages are intended for human interactions
Exactly, yes! The first few sentences from Wikipedia...
"REST (Representational State Transfer) is a software architectural style that was created to describe the design and guide the development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave." -- [1]
If you are desiging a system for the Web, use REST. If you are designing a system where a native app (that you create) talks to a set of services on a back end (that you also create), then why conform to REST principles?
Then that does not conform to the HTTP spec. GET endpoints must be safe, idempotent, cachable. Opening up a site to cases were web crawlers/scrapers may wreak havoc.
The spec defines how things should operate. Code defines how things operate.
The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.
Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.