> it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) This applies to natural language, but, interestingly, the opposite is true of code (in my experience and that of other people that I've discussed it with).
See: Kernighan's Law > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? https://www.laws-of-software.com/laws/kernighan/
Using LLMs at Oxide
31–40 of 284 posts
Re: Using LLMs at Oxide
#32He is a long way from Sun.
Re: Using LLMs at Oxide
#33It sets the rule that things must be actually read when there’s a social expectation (code interviews for example) but otherwise… remarks that use of LLMs to assist comprehension has little downside.
I find two problems with this:
- there is incoherence there. If LLMs are flawless in reading and summarization, there is no difference with reading the original. And if they aren’t flawless, then that flaw also extends to non social stuff.
- in practice, I haven’t found LLMs so good as reading assistants. I’ve send them to check a linked doc and they’ve just read the index and inferred the context, for example. Just yesterday I asked for a comparison of three technical books on a similar topic, and it wrongly guessed the third one rather than follow the three links.
There is a significant risk in placing a translation layer between content and reader.
Re: Using LLMs at Oxide
#34As usual with Oxide's RFDs, I found myself vigorously head-nodding while reading. Somewhat rarely, I found a part that I found myself disagreeing with: > Unlike prose, however (which really should be handed in a polished form to an LLM to maximize the LLM’s efficacy), LLMs can be quite effective writing code de novo. Don't the same arguments against using LLMs to write one's prose also apply to code? Was this structu…
Re: Using LLMs at Oxide
#35As usual with Oxide's RFDs, I found myself vigorously head-nodding while reading. Somewhat rarely, I found a part that I found myself disagreeing with: > Unlike prose, however (which really should be handed in a polished form to an LLM to maximize the LLM’s efficacy), LLMs can be quite effective writing code de novo. Don't the same arguments against using LLMs to write one's prose also apply to code? Was this structu…
Re: Using LLMs at Oxide
#36Re: Using LLMs at Oxide
#37As usual with Oxide's RFDs, I found myself vigorously head-nodding while reading. Somewhat rarely, I found a part that I found myself disagreeing with: > Unlike prose, however (which really should be handed in a polished form to an LLM to maximize the LLM’s efficacy), LLMs can be quite effective writing code de novo. Don't the same arguments against using LLMs to write one's prose also apply to code? Was this structu…
One difference is that clichéd prose is bad and clichéd code is generally good.
Re: Using LLMs at Oxide
#38Find it interesting that the section about LLM’s tells when using it for writing is absolutely littered with emdashes
You can stop LLMs from using em-dashes by just telling it to "never use em-dashes". This same type of prompt engineering works to mitigate almost every sign of AI-generated writing, which is one reason why AI writing heuristics/detectors can never be fully reliable.
Re: Using LLMs at Oxide
#39Earlier quoted context omitted.
One difference is that clichéd prose is bad and clichéd code is generally good.
Depends on what your prose is for. If it's for documentation, then prose which matches the expected tone and form of other similar docs would be clichéd in this perspective. I think this is a really good use of LLMs - making docs consistent across a large library / codebase.
Re: Using LLMs at Oxide
#40Earlier quoted context omitted.
One difference is that clichéd prose is bad and clichéd code is generally good.
Depends on what your prose is for. If it's for documentation, then prose which matches the expected tone and form of other similar docs would be clichéd in this perspective. I think this is a really good use of LLMs - making docs consistent across a large library / codebase.