First, I love this analogy. At the end of the day someone is still analyzing and decomposing problems, and whether you use AI primarily to search and summarize, to recommend, or to write some goofy starter unit tests, it should still be the human writing the code.
… and now I can’t unsee this rule of three crap. Ever since I heard about an author getting busted for using AI, and all the talk about how AI generates in “rule of three”, I keep looking at my own writing and saying “wait, I do this too. People are going to think my posts are by an AI.” Every part of this post was written by a human software developer on a cell phone while I should be getting ready for work instead.
Also I feel like pointing out: assembler is the human-accessible version, where you break code into files and procedures, give things useful names, you have a symbol table that gives you the addresses where your names ended up. You can insert things and edit things and all the addresses shift around to accommodate your changes automatically. You add comments, even block comments. You “inline” methods with assembler macros.
I would say assembler is more accessible than people think, and complex programs don’t require as much of the “hold everything in your brain at once” horsepower as people think.
assembler is the human-accessible version, where you break code into files and procedures, give things useful names,
I had an interesting “debate” with an LLM a few months back about what makes a useful mnemonic. The LLM persistently advocated for “big-unique-label-with-embedded-meaning-is-best” and I was advocating for “R014 - labels shall carry a short unique mnemonic prefix”. The LLM argued that the short mnemonic label was redundant, duplicative and a waste of symbol space. I persisted, because mnemonics are for people, not LLMs - but I can see how LLMs might “work better” with big bowls of word salad instead of short mnemonics.
In the ensuing project, reference by the mnemonics was highly useful in creating short and effective prompts - behind the scenes the LLM had to decode them - and occasionally would pick up something like R23’s meaning when R32 was specified, but that was fairly rare.
First, I love this analogy. At the end of the day someone is still analyzing and decomposing problems, and whether you use AI primarily to search and summarize, to recommend, or to write some goofy starter unit tests, it should still be the human writing the code.
… and now I can’t unsee this rule of three crap. Ever since I heard about an author getting busted for using AI, and all the talk about how AI generates in “rule of three”, I keep looking at my own writing and saying “wait, I do this too. People are going to think my posts are by an AI.” Every part of this post was written by a human software developer on a cell phone while I should be getting ready for work instead.
Also I feel like pointing out: assembler is the human-accessible version, where you break code into files and procedures, give things useful names, you have a symbol table that gives you the addresses where your names ended up. You can insert things and edit things and all the addresses shift around to accommodate your changes automatically. You add comments, even block comments. You “inline” methods with assembler macros.
I would say assembler is more accessible than people think, and complex programs don’t require as much of the “hold everything in your brain at once” horsepower as people think.
99%? We can get these numbers lower :-)
I had an interesting “debate” with an LLM a few months back about what makes a useful mnemonic. The LLM persistently advocated for “big-unique-label-with-embedded-meaning-is-best” and I was advocating for “R014 - labels shall carry a short unique mnemonic prefix”. The LLM argued that the short mnemonic label was redundant, duplicative and a waste of symbol space. I persisted, because mnemonics are for people, not LLMs - but I can see how LLMs might “work better” with big bowls of word salad instead of short mnemonics.
In the ensuing project, reference by the mnemonics was highly useful in creating short and effective prompts - behind the scenes the LLM had to decode them - and occasionally would pick up something like R23’s meaning when R32 was specified, but that was fairly rare.