5 ms·
Our intern uses copilot extensively and its code is riddled with errors. What a pain to review, a lot of time wasted. This is really concerning for newer genera
by shinycode 2y ago
Our intern uses copilot extensively and its code is riddled with errors. What a pain to review, a lot of time wasted.
This is really concerning for newer generations that are not professionals yet but they trust it because the code looks better than what they are able to do. Worse, they outsource their brain and don’t sharpen their senses. How will they become professionals this way ? As a help it’s okay, as a cheating tool that make them faster …
- zamadatix 2y agoAn intern using LLMs to generate bad untested code is no different than an intern using Stack Overflow to generate bad untested code in that the problem isn't Stack Overflow or the LLM or whatever tool the intern is using rather the lack of application of quality control and code review by the intern on their own code. Making them write everything from scratch isn't an instant cure either, you can write some really badly designed stuff right from scratch and push it immediately on up too. This doesn't make you mentally sharper along the way, it makes you confidently sloppy. A better path is to ensure they are spending significantly more time reviewing, testing, and incrementally improving their code than they are typing/generating it. That's where you really sharpen your brain/senses... and also where you keep from driving everyone else nuts with your PRs. Be it LLM or senior dev if you just say "one shot this functionality so I can push it to main" you're going to have a bad day.
- robryan 2y agoAt least with stack overflow you can be fairly confident the code at least works correctly in the context it was provided in if it has a lot of votes.
- chrisjj 2y agoAbsolutely. Yet where's the "AI" that can do such voting?
- shinycode 2y agoThe main difference with SO is that the code from SO cannot always be c/p, the context is different so we had to rethink it. With copilot you have the sense that it’s contextualized and it’s the right fit. With pair programming I saw him accept multiple times the autocompleted code without reading it, he just said « wow it got it fast ». That for me is even worse than SO in that regard. For the rest I agree
- ssl-3 2y agoIn all cases (using examples gleaned from Stack Overflow, or seemingly-complete code from the bot, or code crafted/hacked-together from scratch with Knuth as reference material): The intern is at the end of this toolchain, whatever that chain is. And when the intern is using that chain to produce code that they won't bother trying to understand before submitting it, then the problem is the intern. It is a poor craftsman who blames their tools. And what I mean by that is this: Suppose an apprentice is tasked with using a saw to cut some 2x4s to a specified length. It doesn't matter what kind of saw it is: It could be a handsaw, a chop saw, a handheld circular saw, a radial arm saw, a table saw, a FrameRipper 9000 Pushbutton CNC SawSaw saw, or any other manner of wood-cutting saw. Maybe they're even using an LLM bot to create the G-code to run that FrameRipper 9000. Whatever it is they're using, suppose they produce cuts that are consistently and uselessly wrong -- that are unfit for the purpose. And maybe a lot of that is OK -- after all, they're there to learn, right? Certainly, a big part of learning means making mistakes. It's going to happen, and to varying extents it's absolutely expected to happen. It can be blameless -- especially early on. But suppose the apprentice won't ever bother with even looking at the cut-up boards that they've produced to see if they're even in the same ballpark of what was requested, and just blindly submits their work (however right or wrong it may be) as a finished task. This is no longer blameless. Now, at this point: Do you blame the tool, or the person who is using that tool? (Choose exactly one.)
- shinycode 2y agoThe person. That’s when I say that when it’s as a help it’s ok, when it’s as a cheating out, aka outsourcing brain, it’s not. « I don’t want to think it through but still appear to having worked on it » is not acceptable. I agree with all other comments that says that we don’t trust the output and always control it. Imagine the horror to trying to read, understand and fix million lines of unsupervised code generated in a production environment …
- chrisjj 2y ago> An intern using LLMs to generate bad untested code is no different than an intern using Stack Overflow to generate bad untested code Very different. An LLM lets him generate /far more/ bad untested code per unit of effort. And SO encourages other humans to test it. Often an SO answer comes with evaluative comments and ratings that are all I need to reject it. If the LMM was "AI", it would at least provide the same, right? > A better path is to ensure they are spending significantly more time reviewing, testing, and incrementally improving their code than they are typing/generating it Then let's see the LLM-based workflow that achieves that...
- JTyQZSnP3cQGa8B 2y agoWhy aren’t you banning the use of such tools all over the company? I think I would do that with the only reason being the fear that it might leak private source code to random companies.
- shinycode 2y agoBecause it’s not in my power to decide but I’ve proposed it