The last thing this world needs is automation around people calling things toxic or problematic.
Building a no-code toxicity classifier by talking to GitHub Copilot
131–140 of 152 posts
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#132Earlier quoted context omitted.
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.
I think we all cargo-cult our way into programming and then over decades get better and better understanding of what we're doing and why.
I remember being 7 years old and not really understanding the AppleSoft BASIC manual. I memorized the variable names in the code examples, not realizing I could name variables whatever I wanted. A$, B$, LEFT_FOOT$. The latter was there to be obvious that one could name variables whatever one wanted, but 7 year-old me didn't understand. I remember talking to an older kid on the school bus whose father worked for IBM, and the confused look on his face when I started rattling off my list of memorized variable names. I can still picture his face, but I forget his name. I'm pretty sure he was Mike. Thanks for straitening me out, Mike (Schmidt?).
At least we're getting more effective cargo cults.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#133We'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 must suspend disbelief a bit regardless: Any “toxicity classifier” has a limited operational life as people who want to say toxic things will simply adapt their language and walk circles around it.
From simple letter substitution (sh!t) to completely different words/concepts (unalive) to “layer 2 sarcasm” (where someone adopts the persona of someone who supports the word view that’s against what they believe in a non-obvious attempt to rally people against that persona).
People have been getting away with being toxic in public for a long time. ML cannot keep up. Humans can’t even keep up.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#134Earlier quoted context omitted.
You'll be downvoted because that is obvious, irrelevant and has no practical consequences.
If I had to guess, most downvotes GP got were for "predicting" downvotes.
I've found that sometimes, "predicting" downvotes fails, and the comment is upvoted, it seems to correlate more to whether people agree with the sentiment of the rest of the comment, but I agree that the prediction could influence the outcome.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#135This 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.
Is memorization of an API surface competence? This feels very much like a "back in my day" argument.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#136Earlier quoted context omitted.
> 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…
>How do you know it was what you were after? By testing it >but at that point what's the value add for copilot? Not having to look up the docs and writing it yourself.
Right, I don't know why people are so invested in minimizing how powerful this tool is. I have never properly learned Javascript but I can write Javascript using Copilot because copilot doesn't really make syntax errors, and I can recognize correct semantics, e.g. is it probably doing what I mean for it to do. And then I can, as you say, just test it.
It also bears repeating that Copilot will only get better.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#137I would like to see a project adding together capabilities of both Autopilot and Intellicode. Copilot uses GPT-4 and GitHub project for training and is giving suggestions based on few lines, Intellicode is reading the whole project and is giving suggestions based on that.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#138Earlier quoted context omitted.
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…
> 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. But code is not a face: you can't easily judge if it's correct or not, if you could you wouldn't need copilot in the first place, so now you have to trust it's correct and, if it isn't, you need to search fo…
They provided an example situation right under "For example a scenario may be:".
Their experience matches mine in my use of copilot.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#139Earlier quoted context omitted.
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…
This will make you less valuable, unless there’s enough interesting problems coming down the pipe to keep us all employed. And then once they expand copilot to also solve the hard problems then what’s the use for you anymore?
This very much seems like cheering on the destruction of your career.
Re: Building a no-code toxicity classifier by talking to GitHub Copilot
#140What 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…
this is cool! to clarify, it's different than the existing Copilot extension because this lets you edit existing code and uses voice commands?