925 karma · joined January 8, 2011
[ my public key: https://keybase.io/indutny; my proof: https://keybase.io/indutny/sigs/xZ05hlJI5Q7vq0EGv-3GVxlxW3TIsoV5PL6lbA9zl74 ]
Precisely! Because the code is made to believable the risk of accepting it without understanding full implications is very high.
> If the answer is "the same review process we've always had" then the problem isn't AI, it's whether that process is rigorous enough for the stakes involved.
True, but there is also a reputational component to how changes are reviewed (whether we like it or not). The longer the tenure and the deeper the understanding of the changed code is - the chance of careless Pull Request gets lower.
It is great to have a legal perspective on compliance of LLM generated code with DCO terms, and I feel safer knowing that at least it doesn't expose Node.js to legal risk. However it doesn't address the well known unresolved ethical concerns over the sourcing of the code produced by LLM tooling.
If submitter picks (a) they assert that they wrote the code themselves and have right to submit it under project's license. If (b) the code was taken from another place with clear license terms compatible with the project's license. If (c) contribution was written by someone else who asserted (a) or (b) and is submitted without changes.
Since LLM generated output is based on public code, but lacks attribution and the license of the original it is not possible to pick (b). (a) and (c) cannot be picked based on the submitter disclaimer in the PR body.
* https://www.susanjfowler.com/blog/2016/8/13/so-you-want-to-l...
There are plenty of textbooks and lecture notes available online and that article links to most of the popular choices. Make sure to choose correct order of topics to avoid getting stuck!
As a shameless plug: https://derivepass.com/
The light comes from bottom left, then gets into Beam Splitter (BS) and splits in two. The top-left detector has a pre-selected filter and a measurement device after a delay line. As far as I understand, this device gives binary output: either light received or not. The top-right detector captures whole image of the light ray, but does so only if the left detector has seen light.
The result is that the image from the top-right detector is highly correlated with the pre-selected filter of the top-left detector, even though they're placed in different arms of Beam Splitter! https://advances.sciencemag.org/content/advances/5/7/eaaw256...
I'll check server logs to identify the problem. Sorry again!
It is trained using (almost) a triplet-loss: http://openaccess.thecvf.com/content_cvpr_2016/papers/Cheng_...
While it might sound like this should make your samples very different from others, it could actually act the other way and confuse the network. Hopefully, this will be improved in the next version of it, which I'll start training right after this data collection sprint.