Hacker News Reader

Comment by tomerv | Hacker News Reader

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 Copilot to write code for a classifier for chemical compounds, but it just spits out code for classifying text.

View on HN

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.

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

You can ask copilot to do it for you!

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.

This maps to my experience as well. Think many senior engineers forget what it's like to learn programming. It is, in fact, incredibly hard.

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.

Copilot can already write your boilerplate for you once it has a single example of how to do it.

The boilerplate problem has been solved decades ago. You can use macros or code generation. Letting Copilot do that for you seems a bit like an ugly workaround. We sometimes need those, but at some point we should be taking a step back and design a program instead of hacking away.

I am eagerly waiting the day an AI will collaborate with me like that. You want one for writing the tedious bits of code, I want one for managing information in a research project, others want one to automate tasks RPA-style.

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.

Just bill yourself as an artisanal developer and 5x your rates

> In few years if Copilot deliver its promise ...

That's ages ago in AI time.

> I'm now imagining a very frustrated junior developer a few years from now trying to argue with Copilot to write code for a classifier for chemical compounds, but it just spits out code for classifying text.

So just the future version of a junior developer not knowing how to use their tools? Yeah, that scans. Still sounds incredibly useful however. The alternative is, of course, a junior developer fumbling as they try to write said program entirely from their learned skills and experience.

That’s a very important thing to experience.

There’s not always a quick fix or easy path. You can’t always patch existing stuff together or just wait until the problem goes away.

And when a tool helps you too much, then is there really a point in what you’re doing? It’s not even a learning experience anymore.

> And when a tool helps you too much, then is there really a point in what you’re doing? It’s not even a learning experience anymore.

Have you seen the documentary about AlphaGo? After watching it, and seeing Lee Sedol just utterly devastated by losing to a computer, I felt like I too would surely feel the same thing in my life. I mean, surely Lee Sedol is a far more skilled Go player than I am a skilled programmer.

Anyway, sorry for the rambling. I agree - it's deeply important to _actually_ learn how things work. That's why I wouldn't recommend copilot to a junior dev. Unfortunately, the way things are going - those junior developers are going to use it anyways and I tend to be more of a realist than an idealist.

That’s what computers and copilot are good for. Finding solutions for well defined problems based on data we feed them. They can’t for example design a novel and interesting video game, or build a bespoke tool for an SME.

Reply on news.ycombinator.com