Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

surgehq.ai

Post reply on HN
Print view View original

91–100 of 152 posts

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

#91

Post by IshKebab »

dusted wrote: post #76

This comment will of course be down voted, I'll attribute this to selection bias caused by the headline of the article. You can't classify a comment as boolean toxic, toxicity does not exist in a vacuum. To extend the analogy from it's biological counterpart, toxicity depends on the organism. You should never just a piece of text in isolation and draw any conclusion about it. It must understood in context, both that…

You'll be downvoted because that is obvious, irrelevant and has no practical consequences.

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

#92

Post by qsort »

IshKebab wrote: post #90
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…

The fact that "toxicity" is not well-defined or black and white and you'll never be able to reach 100% accuracy is extremely obvious and not very interesting. That's probably why nobody is talking about it.

Sure, but we probably can work on that a little more rather than throwing in the towel and saying 'toxicity is when text matches regexp'.

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

#93

Post by IshKebab »

ShamelessC wrote: post #70
hombre_fatal wrote: post #60

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…

> The negativity here just seems like sour grapes or weird goal posts. Indeed. Every negative comment I have seen here has been a shallow dismissal by someone who clearly hasn't engaged with the tool. I'm not sure why people here are so primed to shit all over anything potentially innovative, seemingly even without background knowledge. Like, is there something inherently offensive to coders about a model that threat…

> I'm not sure why people here are so primed to shit all over anything potentially innovative

Maybe jealousy - people often downplay others' achievements to make theirs feel better. Or pride - "I don't need no stinking AI assistant! What are you saying? I couldn't write this myself?". I find the latter is a common reaction to static types too.

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

#94

Post by chockchocschoir »

ShamelessC wrote: post #71
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…

> 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). See, this tells me you may not have even used copilot. Because while tutorials such as this (and the OpenAI codex tools) have you use comments explicitly to code, the reality is that you're not hammering out plain english requirements for copi…

It doesn't actually say that at all, because you can use Copilot in different ways. One way is the way you mention, by writing code and letting Copilot finish those off. Another way is the way GP describes it (and, the technique that the article uses) where you write comments and let Copilot fill out the code.

Just because one uses one of the ways doesn't mean they are not aware of the other way too.

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

#95

Post by chockchocschoir »

klabb3 wrote: post #44
MichaelBurge wrote: post #26

Earlier quoted context omitted.

Start a line with // CAVEATS: // POTENTIAL ISSUES: // Above is deprecated. Use below code instead and ask Copilot to auto-complete.

// this should never happen

    fn classify-toxicity(text: string) {
      do_work(text)
      while true {}
      // this should never happen
    }

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

#96

Post by ImprobableTruth »

ShamelessC wrote: post #71
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…

> 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). See, this tells me you may not have even used copilot. Because while tutorials such as this (and the OpenAI codex tools) have you use comments explicitly to code, the reality is that you're not hammering out plain english requirements for copi…

Copilot is great as a 'smart auto-complete' or when you need to do pattern based drudge work... but that's not what this article is about. It's trying to sell people on copilot as a no-code tool.

The leading question is this:

>But as helpful as it is for coders, what if it enabled non-engineers to program too – by merely talking to an AI about their goals?

and it answers this in my opinion deceptively by presenting what amounts to a parlor trick. Whether copilot in general is any good or not is in my mind totally separate to this.

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

#97

Post by dusted »

ShamelessC wrote: post #87
dusted wrote: post #76

This comment will of course be down voted, I'll attribute this to selection bias caused by the headline of the article. You can't classify a comment as boolean toxic, toxicity does not exist in a vacuum. To extend the analogy from it's biological counterpart, toxicity depends on the organism. You should never just a piece of text in isolation and draw any conclusion about it. It must understood in context, both that…

I mean, what you're saying just isn't really directly on-topic. The article's focus is a a copilot tutorial, clearly meant to be illustrative rather than literally used in production. So it comes across like you're criticizing the article for doing something it isn't really concerned with doing to the degree you are expecting. Does that make sense?

It does make sense.

However, the framing of the tutorial is clearly about using automated censorship at scale.

Someone is going to roughly copy-paste this into some forum software and call it a day.

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

#98

Post by ShamelessC »

chockchocschoir wrote: post #94
ShamelessC wrote: post #71

Earlier quoted context omitted.

> 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). See, this tells me you may not have even used copilot. Because while tutorials such as this (and the OpenAI codex tools) have you use comments explicitly to code, the reality is that you're not hammering out plain english requirements for copi…

It doesn't actually say that at all, because you can use Copilot in different ways. One way is the way you mention, by writing code and letting Copilot finish those off. Another way is the way GP describes it (and, the technique that the article uses) where you write comments and let Copilot fill out the code. Just because one uses one of the ways doesn't mean they are not aware of the other way too.

Not logically, no. But it is implied because you actually get both such experiences on-demand in VS Code/vim/emacs. It's a fascinating experience and you find yourself writing more descriptive function names and variable names rather than using handwritten instructions. You quickly realize that comments are just one of many prompt engineering tricks available once you have access to this - and simply generating snippets as the linked article does is quite restricting sometimes.

Basically, the concern that e.g. comment length gets too long is a weird one, because you don't tend to actually use copilot that way if you have access to it through tab-complete.

Perhaps what I really mean is - people should try using copilot for an actual coding project. Its benefits aren't really obvious in contrived examples.

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

#99

Post by ShamelessC »

ImprobableTruth wrote: post #96
ShamelessC wrote: post #71

Earlier quoted context omitted.

> 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). See, this tells me you may not have even used copilot. Because while tutorials such as this (and the OpenAI codex tools) have you use comments explicitly to code, the reality is that you're not hammering out plain english requirements for copi…

Copilot is great as a 'smart auto-complete' or when you need to do pattern based drudge work... but that's not what this article is about . It's trying to sell people on copilot as a no-code tool. The leading question is this: >But as helpful as it is for coders, what if it enabled non-engineers to program too – by merely talking to an AI about their goals? and it answers this in my opinion deceptively by presenting…

Yeah, I agree Copilot is absolutely not a no-code tool.

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

#100

Post by qayxc »

Ozzie_osman wrote: post #9

This is a game-changer, even if it doesn't work 100% of the time. I only infrequently need to use notebooks and dataframes, I'd say once every few months. Frequently enough that I have a vague idea of what I need to do but not frequently enough that I can remember syntax. With this, I don't need to memorize the syntax OR be bottlenecked on looking at documentation or stack overflowing the commands I need.

> With this, I don't need to memorize the syntax OR be bottlenecked on looking at documentation or stack overflowing the commands I need.

In other words: you're celebrating the fact that a tool allows you to become more and more incompetent.

I don't have much hope for future generations at this point.

Post reply on HN