> This is also why PICK can usefully fail. Sometimes none of the model’s candidates is right, and PICK ends with zero survivors. Under the spec-elucidation reading, that outcome means: the commitments you made through classification could not be satisfied by anything the model produced. Better to know than to ship the regex anyway.
Zooming out (but only a little) from the impetus to formalize a commitment to a particular class of result candidate (what the author here is calling "spec elucidation"), we can also imagine this same evolution of concerns being applied in order to cause what we currently term "AI safety" into something more like "AI ethics".
For example, if we can elucidate the specifications for things like peace and justice to ensure that the class of results is formally verified as non-participation in war (or perhaps, further in the future, non-participation in state activities whatsoever), we may be able to throw cold water on all the vitriolic arguments about model capabilities and which need to be banned or delayed lest we accelerate the apocalypse (or whatever is actually on the mind of the ban-this-model constituency).
I like how the author ends tersely with:
> If you have a formal language with the closure properties above — we suspect you would be surprised how many do — we would very much like to hear from you.
That's certainly not me, but I bet it's true that it's somebody.
this is the type of thing you need to build a foundation sturdy enough to let you operate higher up the stack and ratchet to design-by-metaphor and then design-by-philosophy. those design skills are taught in humanities departments, not engineering departments, so this is a weird feeling place for those of us that wandered over from a technical field.
> Telling people “you must read all the code generated by an LLM” is definitely meaningful—but it is not at all moderate (so most people won’t do it).
I am honestly heartbroken to live in a world where reading the code is seen as an unreasonable ask by either students or by professional working programmers.
What is heart breaking about it? Code reviews were always being the most sucky part of the job.
They are also among more recent inventions, they are not "the traditional" programming at all. It is not like code review was the thing that attracted people to the profession or something that would be ore rewarding part of it.
No one is complaining about having to read code. The complaints usually fall in one of these buckets:
- having your job responsibilities being reduced to ONLY reviewing code.
- having to review code unnecessarily high scrutiny because it can hallucinate randomly and you as a human are responsible for the code even though you didn’t write it. In a traditional context when I review code, there’s a shared responsibility. Someone writes the code and another person reviews it. Now it’s entirely on the person who reviews it.
There may be other buckets, these are the ones that I hear often from other engineers.
6 comments
[ 5.2 ms ] story [ 30.6 ms ] threadZooming out (but only a little) from the impetus to formalize a commitment to a particular class of result candidate (what the author here is calling "spec elucidation"), we can also imagine this same evolution of concerns being applied in order to cause what we currently term "AI safety" into something more like "AI ethics".
For example, if we can elucidate the specifications for things like peace and justice to ensure that the class of results is formally verified as non-participation in war (or perhaps, further in the future, non-participation in state activities whatsoever), we may be able to throw cold water on all the vitriolic arguments about model capabilities and which need to be banned or delayed lest we accelerate the apocalypse (or whatever is actually on the mind of the ban-this-model constituency).
I like how the author ends tersely with:
> If you have a formal language with the closure properties above — we suspect you would be surprised how many do — we would very much like to hear from you.
That's certainly not me, but I bet it's true that it's somebody.
But they should! The code is the best source of truth on what the software is doing after all.
Instead of giving up on that, we should make it easier to read generated code, e.g. by generating less code in a higher level language.
On the flip side, forcing myself to read all the code also resulted in a smaller, higher quality code base.
I am honestly heartbroken to live in a world where reading the code is seen as an unreasonable ask by either students or by professional working programmers.
They are also among more recent inventions, they are not "the traditional" programming at all. It is not like code review was the thing that attracted people to the profession or something that would be ore rewarding part of it.
- having your job responsibilities being reduced to ONLY reviewing code.
- having to review code unnecessarily high scrutiny because it can hallucinate randomly and you as a human are responsible for the code even though you didn’t write it. In a traditional context when I review code, there’s a shared responsibility. Someone writes the code and another person reviews it. Now it’s entirely on the person who reviews it.
There may be other buckets, these are the ones that I hear often from other engineers.