Building a no-code toxicity classifier by talking to GitHub Copilot • Hacker News Board

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#51

Post by kcorbitt » Fri, Mar 25, 2022, 5:44 AM UTC

What funny timing! Just this week I've actually been working on an open source VS Code extension that uses OpenAI's new code edit API[1] to let you write or edit code in your IDE by typing instructions.

And as a bonus related to the article title, it literally lets you talk to your editor (ie you can press the keyboard shortcut and then give edit commands by voice[2]). I've been leaning on it heavily for the last few days and the setup feels really productive!

If you want to try it out you can install it here: https://marketplace.visualstudio.com/items?itemName=clippy-a...

You can also find the full source code here: https://github.com/corbt/clippy-ai/tree/main/vs-code-extensi...

I'd love feedback!

[1]: https://openai.com/blog/gpt-3-edit-insert/

[2]: I just wrote the voice command interface yesterday and it's still highly experimental. Relies on having ffmpeg installed on MacOS and doesn't work with all audio setups yet. But there's a clear path to making it more robust.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#52

Post by ripper1138 » Fri, Mar 25, 2022, 6:02 AM UTC

blackoil wrote: post #43

tomerv wrote: post #34

The first comment asks Copilot to import all the libraries needed for a toxicity classifier, and it imports libraries such as re (regex engine) and nltk (natural language toolkit). But what if I wanted a classifier for toxic chemicals and not toxic speech? That was my first thought when I saw "toxicity" in the title. I'm now imagining a very frustrated junior developer a few years from now trying to argue with Copilo…

Like googling is an essential skill for developers. In few years if Copilot deliver its promise, navigating it would be treated the same. You may also have an interview round wherein optimization would be how quickly can you get Copilot to write the expected code.

Funny you point that out. In this specific example, what if I just googled “Python comment toxicity classifier” and looked for a complete solution that way? It’s like a semi-smart googler in your IDE.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#53

Post by junon » Fri, Mar 25, 2022, 6:11 AM UTC

blackoil wrote: post #43

tomerv wrote: post #34

The first comment asks Copilot to import all the libraries needed for a toxicity classifier, and it imports libraries such as re (regex engine) and nltk (natural language toolkit). But what if I wanted a classifier for toxic chemicals and not toxic speech? That was my first thought when I saw "toxicity" in the title. I'm now imagining a very frustrated junior developer a few years from now trying to argue with Copilo…

Like googling is an essential skill for developers. In few years if Copilot deliver its promise, navigating it would be treated the same. You may also have an interview round wherein optimization would be how quickly can you get Copilot to write the expected code.

If this is what software engineering turns into, put a bullet through my head please.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#54

Post by junon » Fri, Mar 25, 2022, 6:14 AM UTC

As with most harmful speech classifiers (even classic models) this most likely won't catch the more passive aggressive remarks. Those worded innocently but imply something terrible. I've had a 100% success rate getting these sorts of models to tell me asking someone to "kindly end their own life" is not rude, toxic or harmful.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#55

Post by injidup » Fri, Mar 25, 2022, 6:17 AM UTC

zkldi wrote: post #33

CallMeJim wrote: post #29

Earlier quoted context omitted.

Note that in part of the process, Copilot was the one asking complex questions when the human programmer didn't know how to proceed. Copilot adds tremendous value for someone who knows what they want, but not how to do it. For example, I'm not a great programmer. I'm also a lazy programmer. I had to convert a time to a specific format, in a specific timezone in JS, and I couldn't be bothered looking up documentation…

> I wrote a comment outlining exactly what I wanted, and immediately Copilot generated the code I was after. How do you know it was what you were after? Like you said, it could be .toLocaleTimeString or .toLocaleString (or something else). How do you verify that the AI isn't giving you broken/incorrect code? I guess you could check the docs, or run the code yourself, but at that point what's the value add for copilot…

The negative comments seem to assume an open loop development strategy where if copilot fails to give the 100% correct result it is a fail. Rather, even if it is wrong it can get you close and if not close it can give you ideas. You have to close the loop and use your own intelligence as well.

For example I can't draw faces but I can recognize a badly drawn face. If I ask an AI: Please draw me a 35 year old man with receding hair and crooked teeth I can quickly validate the result is fit for purpose. If it is not what I want I can modify the query. I then learn quickly how to prompt the AI to give me what I want.

In the example you give we can assume that the AI has produced a plausible option even if wrong. For example a scenario may be:

   # User: Write a comment "Convert the date to the current local for printing"
   # Copilot: generates the method 'toLocaleString'
   # User: Mouse hover over the method to get the documentation for the 'toLocaleString' method
   # User: See that the method produces the wrong output. We realize we don't want the date
   # User: Modify the comment to "Convert the date to the current local for printing time only"
   # Copilot: generates the method 'toLocaleTimeString'
   # User: Yes this is the one I want. Moves on

The key point is you have to know what you want and be able to recognize a correct result. Validating a correct result is often easier than coming up with the correct result. You have multiple strategies to validate the result.

Testcases, compilation, code review, documentation, IDE intellisense

This obviously gets harder the larger the amount of code copilot is being asked to generate. But good software engineering practises still stand. Try to keep your functions and modules small and to the point.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#56

Post by sdoering » Fri, Mar 25, 2022, 6:25 AM UTC

BeefWellington wrote: post #45

abeppu wrote: post #35

We're all focusing on the weaknesses of co-pilot (the comments can be longer than the code produced; you need to understand code to know when to elaborate your comment, etc). But also ... what do you need to know to recognize that the concept of a 'toxicity classifier' is likely broken? We can do _profanity_ detection pretty well, and without a huge amount of data. But with 1000 example comments, can you actually get…

A few years ago I did some work with IBM's Watson Twitter integration. One of the fun things you could do was sentiment analysis. It was reasonably accurate for the extremes but anything in the gray area would be wildly off. A politely worded tweet that was scathing would come across high on the positive sides of the scale, whereas a perfectly reasonable sentence that included profanity as used in a quote would immed…

Years ago at pyData Berlin I remember a talk trying to classify comments from three major online newspapers with the question if we. Could detect where a comment was made.

One newspaper was left leaning, the other had the reputation of right wing trolls commenting and one was somewhat in the middle ground with a reputation of the audience being pseudo intellectual neoliberalists.

The 'center' (most typical) comment for these three sites totally was in line with these sentiments. The perfect proof (or confirmation bias).

But the classification didn't work. While there were clear cut cases (one has to love stereotypes) most cases were just neutral. Meaning they could have been made on any of these media sites. Either they were just too short or just not extreme enough.

I feel (used explicitly here) that toxicity is not something that is easily classifiable without deeper understanding of the context. Else, if feeling a comment was toxic was the measure one would need to query all walks of life from extreme left to extreme right and afterwards would probably be left with a lot of toxicity that doesn't tell us much except that different people will find different things toxic.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#57

Post by Aeolun » Fri, Mar 25, 2022, 6:36 AM UTC

junon wrote: post #53

blackoil wrote: post #43

Earlier quoted context omitted.

Like googling is an essential skill for developers. In few years if Copilot deliver its promise, navigating it would be treated the same. You may also have an interview round wherein optimization would be how quickly can you get Copilot to write the expected code.

If this is what software engineering turns into, put a bullet through my head please.

You can ask copilot to do it for you!

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#58

Post by madrox » Fri, Mar 25, 2022, 6:37 AM UTC

junon wrote: post #53

blackoil wrote: post #43

Earlier quoted context omitted.

Like googling is an essential skill for developers. In few years if Copilot deliver its promise, navigating it would be treated the same. You may also have an interview round wherein optimization would be how quickly can you get Copilot to write the expected code.

If this is what software engineering turns into, put a bullet through my head please.

It's not that far off today from how junior engineers treat stack overflow. There's just fewer intermediate steps.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#59

Post by caymanjim » Fri, Mar 25, 2022, 6:46 AM UTC

junon wrote: post #53

blackoil wrote: post #43

Earlier quoted context omitted.

Like googling is an essential skill for developers. In few years if Copilot deliver its promise, navigating it would be treated the same. You may also have an interview round wherein optimization would be how quickly can you get Copilot to write the expected code.

If this is what software engineering turns into, put a bullet through my head please.

I haven't tried Copilot, and based on what I've read, I don't think I'd want to use it in its current form, but I'd love for software development to evolve to the point that I never have to write any boilerplate code again. Even with DSLs, code generation, autocompletion, snippets, and countless libraries and frameworks to draw upon, the bulk of what I do as developer is write the same boring code over and over again. I welcome the day that a predictive IDE allows me to focus on the interesting aspects of problem solving without having to do all the tedious bits, while still allowing me to inspect and modify the tedious bits when needed.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#60

Post by hombre_fatal » Fri, Mar 25, 2022, 6:47 AM UTC

This is absolutely insane. I had no idea Copilot was this good.

The negativity here just seems like sour grapes or weird goal posts.

Sure, it makes mistakes and needs verification. But know what also makes mistakes and needs verification? All the code I already manually write as I tediously ratchet towards a solution. Removing some cycles from that process is a win.

Just stubbing out close-enough boilerplate is a win by itself, like setting up an NLP pipeline or figuring out which menagerie of classes need to be instantiated and hooked up together to do basic things in some verbose libs/langs.