| --- Log opened Sat Oct 05 00:00:02 2024 |
| 00:58 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| 01:14 | | celticminstrel [celticminst@Nightstar-ip9ut1.cpe.teksavvy.com] has quit [Ping timeout: 121 seconds] |
| 01:41 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has quit [Connection closed] |
| 02:15 | | celticminstrel [celticminst@Nightstar-ip9ut1.cpe.teksavvy.com] has joined #code |
| 02:15 | | mode/#code [+o celticminstrel] by ChanServ |
| 02:45 | | Degi_ [Degi@Nightstar-aokub0.pool.telefonica.de] has joined #code |
| 02:48 | | Degi [Degi@Nightstar-2rs2eh.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 02:48 | | Degi_ is now known as Degi |
| 11:12 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has joined #code |
| 12:46 | | abudhabi [abudhabi@Nightstar-94jos0.supernova.orange.pl] has quit [Ping timeout: 121 seconds] |
| 14:51 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has joined #code |
| 14:51 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 16:13 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has quit [Connection closed] |
| 16:30 | | abudhabi [abudhabi@Nightstar-94jos0.supernova.orange.pl] has joined #code |
| 18:47 | <@gnolam> | https://www.cio.com/article/3540579/devs-gaining-little-if-anything-from-ai-coding-assistants.html |
| 19:50 | <@celticminstrel> | No surprise there. |
| 19:54 | <@celticminstrel> | The idea that a glorified random text generator could write correct code is just ridiculous. |
| 20:19 | <@ErikMesoy> | The glorified random text generator is already at the point where I could feed it pseudocode or half-remembered syntax and say "Fix the syntax on this code, language Foo" and it returns a correct fix. |
| 20:20 | <@ErikMesoy> | I guess basic syntax might not be "code", but then the definition of "code" is going to get some increasingly large asterisks in the years to come. |
| 20:24 | <@macdjord> | I recall Tom Scott's video on the subject, like, 2-3 years ago. He wanted a script that would automatically categorize and tag emails in his gmail account, and he asked an AI for it. The resulting code didn't work - but it turned out that was because Gmail's own API documentations lied. (They claimed that labels applied to a whole email conversation, which is how the UI /presents/ them, but in fact internally each email in a conversation can |
| 20:24 | <@macdjord> | have different labels.) |
| 20:26 | <@celticminstrel> | …why would you expect the entire conversation to share labels? |
| 20:26 | <@celticminstrel> | There's no such thing as a "conversation" in the email protocols. |
| 20:29 | <@macdjord> | Allow me to rephrase: the API documents claimed that when you applied a label, it would be applied to every email in the selected conversation. Which is exactly what the GUI appears to do. In reality, it applies the label to one email in the conversation, and the conversation as a whole is treated as having the union of the labels of all the emails in it. |
| 20:29 | <@macdjord> | (At least I think that's how it worked. Again, this was 2-3 years ago.) |
| 20:41 | <@macdjord> | Point is, the AI /was smart enough/ to produce valid and correct code, but not - at that time - smart enough to reverse engineer and debug incorrect API documentation. |
| 20:45 | <@celticminstrel> | I would beg to differ. |
| 20:45 | <@celticminstrel> | It is not "smart". |
| 20:45 | <@celticminstrel> | What evidence is there that it actually looked at the API documentation? |
| 20:45 | <@celticminstrel> | Tho if said documentation has code samples, maybe it did look at those. |
| 20:46 | <@macdjord> | Well, it produced code which /would have worked/ if the given documentation was correct. I'd say that's fairly solid evidence that it read the documentation. |
| 20:47 | <@celticminstrel> | Nope. |
| 20:47 | <@celticminstrel> | It doesn't prove it read the documentation. |
| 20:47 | <@macdjord> | Now, whether it read the documentation as part of its training set or if it was smart enough to google for and then parse the relevent docs for the specific job it was being asked to do, that I cannot tell you. |
| 20:48 | <@macdjord> | celticminstrel: Okay, so how do you explain it? |
| 20:48 | <@celticminstrel> | I can't. But I doubt "it read the documentation" is the correct answer. |
| 20:48 | <@macdjord> | And note: I didn't say it /proved/ it had read them, I said it was /strong evidence/ that it had. |
| 20:48 | <@celticminstrel> | Alright, fair point. |
| 20:49 | <@macdjord> | celticminstrel: Do you have any evidence whatsoever to suggest it did not read the documentation? |
| 20:49 | <@celticminstrel> | I can't deny that there is some logic in concluding that it read the documentation based on the outcome. |
| 20:49 | <@celticminstrel> | Not really. |
| 20:52 | <@macdjord> | Frankly, if it could produce API-compliant code /without/ reading the API, that would be /more/ impressive, not less. |
| 20:55 | <&McMartin> | junior software engineers do that every day <_< |
| 20:55 | <@celticminstrel> | XD |
| 20:55 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has joined #code |
| 20:55 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 20:58 | <@macdjord> | McMartin: Yes, via trial and error. The AI could /write/ code but had no capacity to run it on its own. (Thus being unable to identify and account for the erroneous documentation.) An AI that /could/ run its code, *and then interpret the results and perform debugging on it*, would be more impressive. |
| 21:02 | | Vornicus is now known as Johnn |
| 21:04 | | macdjord is now known as Mike |
| 21:05 | <@celticminstrel> | … |
| 21:06 | | Kizor is now known as Davee |
| 21:08 | | abudhabi [abudhabi@Nightstar-94jos0.supernova.orange.pl] has quit [Ping timeout: 121 seconds] |
| 21:14 | <@Mike> | (Well, okay, 'an AI that can run its own code' would just be giving the AI access to some sort of 'run this' API, not any great technical achievement. The impressive part would be it effectively using the output to iteratively improve the code. And, uh, giving an AI the ability to run code without it being checked by a human first seems like a Very Unwise Idea at this stage of AI development.) |
| 21:15 | <&McMartin> | The people afraid of that are afraid of it managing to write code so good that it is beyond human comprehension and which then decides to exterminate humanity for inscrutable reasons |
| 21:15 | <&McMartin> | I have snide comments about that~ |
| 21:18 | <@Mike> | McMartin: I'm not worried about /that/, I'm worried about it accidentally producing `exec("rm", "-rm", "/")`. We /are/ still at the stage where advisor AIs sometimes say things like 'yes, chlorine gas in breathable'. |
| 21:18 | <&McMartin> | That is the *correct* reason to not hand it off with no oversight. |
| 21:18 | <@celticminstrel> | -rf not -rm |
| 21:19 | <@celticminstrel> | That said, if it's sandboxed so there's nothing important in / then that would be okay, right? |
| 21:21 | <~Johnn> | there's a special flag you have to pass to actually delete / |
| 21:22 | | abudhabi [abudhabi@Nightstar-prgf7c.supernova.orange.pl] has joined #code |
| 21:37 | <@celticminstrel> | On new enough systems, sure. |
| 21:40 | <@Tamber> | --footgun |
| 21:40 | <@Tamber> | (:p) |
| 21:40 | <@Mike> | celticminstrel: Sure, but that depends on it being properly and safely sandboxed. That's reasonably simple if the user just wants a program written in some reasonably common language which processes some fixed input into some static output; just spin up a VM with the relevant compiler or interpreter, copy in a suitable test input, and copy out the output. But as soon as you start throwing in external systems that the code needs to interact with - |
| 21:40 | <@Mike> | such as the Gmail API in Tom Scott's example - things get a lot harder. I'm not confident that the AI devs will always get it right. And if you want to support anything but the biggest, most common APIs, you'll need facitilites for users to provide their own access to test systems - and I do not trust them to get it right at all. |
| 21:41 | <@Mike> | Johnn: Yes, but `rm -rf /*/` isn't much better. |
| 22:09 | | abudhabi [abudhabi@Nightstar-prgf7c.supernova.orange.pl] has quit [Ping timeout: 121 seconds] |
| 23:55 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| --- Log closed Sun Oct 06 00:00:03 2024 |