[hombre_fatal]

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.

[csomar]

Copilot is insanely brilliant and good. Its only issue is that it takes too little context (up to what your cursor is pointing on the file, at least on vim). If it did take all context (your whole project, maybe your shell history, your data files, the imported libraries code, GitHub repo issues/PRs, etc...) and it had some LSP checker for errors, add all of that to GPT-4; and maybe we'll have something that can do complex coding stuff auto-magically.

[Mountain_Skies]

Even though it is based on mostly human written code, Copilot makes mistakes that are different from the type human coders typically make. It will take a different skill set to detect and correct the errors made by systems like Copilot. The same is true for self-driving cars. This doesn't mean that we shouldn't use these technologies, just that there will be adaptations to our behavior we'll need to make if we want to make use of them.

[fn1]

> Even though it is based on mostly human written code, Copilot makes mistakes that are different from the type human coders typically make.

Can you give an example for this?

[Satam]

Probably not what OP intended but here's what I encountered. When autocompleting code for a Pythonic database query it would finish something like "query.all()" as "query.all().delete()". Meanwhile, as a programmer, I'm usually quite vary of deleting all the records from a database unless I'm very sure that's what I want.

[ShamelessC]

> 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 threatens to do their job? Or is it just years and years of people getting burned by previous "AI" projects without knowing that this one is actually rather impressive and comes from good research?

Keep shallow dismissals to yourselves people. It's in the site's rules.

[xodjmk]

You can't imagine how some people might have an adverse reaction to a low-barrier of entry arbitrarily defined self-appointed moral policing 'AI' tool generating framework? Not all ideas are good ideas. It doesn't mean the ops are not talented, just misdirected.

[ShamelessC]

> low-barrier of entry arbitrarily defined self-appointed moral policing 'AI'

So, a software developer?

Just kidding. Perhaps it would clear things up to know that "toxicity" classification is simply an introductory topic in natural language and machine learning. It is an interesting "problem" to try to solve precisely because of how ambiguous language gets. As far as I can tell, the article is mostly not concerned with the quality of the the classifier and is meant to be a proof of concept.

In any case, people have been coding and using such classifiers all over the internet since their inception. Believe me - this isn't accelerating that and the damage is likely mostly done. My advice? Self-host a web server.

[dash2]

You might think it's awesome and well-executed, and still think that an automated toxicity classifier is a terrible idea.

[ShamelessC]

It's simply a fun toy tutorial and likely good introductory material for people trying to learn language modeling and classification, two important topics in the broader NLP/machine learning scene.

The article isn't making any suggestions about whether or not they are good or bad ideas.

[IshKebab]

> 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.

[ShamelessC]

> Maybe jealousy

Somehow, I suspect this the most. It's the defensive tone they tend to strike, I think. Particularly apparent in threads about new research. Lots of "I actually had this idea", and "my concern for this is [slippery slope fallacy here]".

I sincerely hope that I never become so egotistical about my own achievements (or lack thereof) that I instinctively despise those who achieve more. Fuck that.

[nimih]

This is definitely a very cool tech demo, but I got the same feeling reading this as I do when I read a blog post years ago where a guy walked through using very rigid green-red-green TDD to solve a hairy algorithmic problem[0]: it sort of seems like the person already had the shape of the solution in their head before they started writing the code.

Which is maybe the point! As the article points out, remembering the correct incantation to get matplotlib to spit out a bar chart is hard[1]; I certainly have to look it up literally every time (well, these days, I just use tools which have more intuitive APIs, but that's maybe besides the point). I don't really know what it means to "binarize" a dataset, but apparently the language model did, and apparently seeing the giant stack trace when trying to plot a precision-recall curve was enough to prompt the article writer to realize such an operation might be useful. When you're doing exploratory analysis like this, keeping a train of thought going is extremely important, so avoiding paging back and forth to the scikit-learn documentation is obviously a huge win.

But, on the other hand, this isn't a "no-code" solution in any real sense, because for all intents and purposes the author really did all the difficult parts which would've been necessary for a "fully coded" solution: they knew the technical outcome they wanted and had very good domain knowledge to guide the solution, and, shoot, they still ended up needing to understand semantics of the programming language and abstractions they were working with in that stacktrace at the end. It's still extremely neat (and, presumably, useful) to see the computer was able to correctly guess at all the syntax and API interfaces for the most part[2], but I don't really think you can fault people for wanting to push back against the idea that this is somehow fundamentally transformative, since I think it's pretty obvious that the human is (still) doing the hard and interesting parts and the computer is (still) doing the tedious and boring parts. Maybe people shouldn't be getting flustered about a click-baity title over-promising a hip new technology, but as you say:

> Or is it just years and years of people getting burned by previous "AI" projects without knowing that this one is actually rather impressive and comes from good research?

There's definitely some of this.

---

[0] I wish I could find the link for this, but I'm very bad at google these days.

[1] To risk ascribing agency to a statistical model of github commits, it is sort of funny that the co-pilot pulled in seaborn as a dependency but then did everything directly with calls to plt and DataFrame.plot.

[2] I don't really have the expertise myself to tell you whether that scikit pipeline is at all reasonable, I suppose. It sure sounds fancy, though.

[ShamelessC]

Thank you! This was researched and informed by the article we're all meant to be discussing. That is all I ask, ha.

I 100% agree that this is not a "no-code" solution as is defined. On the other hand, I wouldn't really mind a definition of "no-code/low-code" that involved this - but indeed, not there yet.

And yes, more-or-less I generally agree that this is a tool that must be used by experienced developers. So I can see how a false claim of "no-code" (basically defined as devs-not-needed) would trigger folks to be a little defensive.

However! If you are a programmer with experience, and you want to make your work just so much easier, then copilot is a great tool. I implore you to try it yourself with VS Code/Vim/emacs rather than using openai/codex as the autocomplete is what makes it great.

[skhr0680]

> Sure, it makes mistakes and needs verification. But know what also makes mistakes and needs verification?

The problem is when it makes something that looks OK but does the opposite of what you want it to. See: machine translation