[HN Gopher] I worry our Copilot is leaving some passengers behind
___________________________________________________________________
I worry our Copilot is leaving some passengers behind
Author : headalgorithm
Score : 173 points
Date : 2024-02-17 18:21 UTC (4 hours ago)
(HTM) web link (joshcollinsworth.com)
(TXT) w3m dump (joshcollinsworth.com)
| jeffbee wrote:
| I work with a guy who is absolutely dedicated to using LLMs to
| generate C++ code. If I ask him for a specific small thing I'll
| get back a PR with hundreds of lines of irrelevant crap and when
| I ask why it has this move constructor or whatever, they won't
| have a good reason. Even though my colleague is an industry
| veteran, their new habit has made it feel like they are
| delegating all their work to the stupidest teammate I've ever
| had.
|
| I feel like we are going to need to work out some norms and
| customs in this industry for using code-generating systems in a
| way that respects the time and attention of coworkers.
| stouset wrote:
| Request changes on the PR with the exact same reasoning you
| would use with any other developer who works like that?
| halfmatthalfcat wrote:
| > absolutely dedicated
|
| Hard to reason with developers like this, especially if
| they're more senior than you.
| convolvatron wrote:
| it really doesn't matter how many years they have been
| working, or how old they are, or how long they have been at
| the organization. we should all agree that someone who
| offloads the error correction of llms to their teammates
| isn't someone that's really 'senior'
| bluefirebrand wrote:
| Offloading all of the actual code reasoning onto your team
| because you cannot be bothered to write the code yourself and
| are trusting an LLM should get you fired on the spot.
|
| I cannot imagine a worse teammate or a worse developer.
| lpapez wrote:
| I had one such coworker until recently, and he was actually
| fired because nobody on the team felt he was pulling his
| own weight.
|
| He produced massive amounts of code which did not fit the
| style of the codebase at all, and when questioned point-
| blank if it was LLM-generated he denied it (even thought it
| was undeniable).
|
| I'm all for using tools to boost your productivity, but IMO
| when you offload generated junk to be reviewed by your team
| it's a sign of disrespect.
| rvnx wrote:
| Ask the PR to be reviewed by an LLM. Enjoy your new life with
| lot of free time.
| johnny22 wrote:
| until you get tasked with fixing the buggy code
| ptero wrote:
| This. Good code is clean and has a well thought through
| internal architecture. LLM-ifying the code and treating it as a
| black box (if it passes the tests, it is acceptable) is
| tempting, but it works until it does not and the "does not"
| might come pretty quickly: once a human cannot easily untangle
| the logic the only fix is a rewrite.
|
| I think there is a way to extend the useful life of such an
| approach by setting up a good architecture with lean, strict
| interfaces and thorough tests. Then one can treat any module
| that is compliant as a black box and give a computer the power
| to insert as much crap as it can generate. You then should be
| ready and willing to rewrite any box that has become so
| convoluted that LLM can no longer fix, likely by splitting it
| into smaller externally observable and testable elements.
|
| I doubt that this is a long-term viable approach, but this is
| just a personal hunch. It would be interesting to see how such
| approaches develop. My 2c.
| flappyeagle wrote:
| Maybe he needs to get a stern talking to by his manager? Has
| that happened?
| timeon wrote:
| Hope manager won't be like: "According to chatGPT..."
| blibble wrote:
| if he's doing that the company might as well save his salary
| and get an intern with a ChatGPT subscription
| halfmatthalfcat wrote:
| Copilot is a decent tool for experienced developers (though,
| hasn't replaced Google-foo by any stretch) and a trap for
| inexperienced ones. Sure it may be able to speed things up in the
| beginning but it's a crutch for long-term sustainability in the
| industry. You inevitably have to understand the paradigms and
| patterns that LLMs regurgitate; taking them at face value (which
| I suspect is what most LLM users do), is a recipe for disaster
| and unfounded confidence.
| skissane wrote:
| > Copilot loves suggesting about 25 nested divs as a starting
| point.
|
| > I assume this is because of a flaw in how LLMs work.
|
| I know with some LLM implementations, you can configure the
| sampling to penalise repetitions - this is making me wonder if
| Copilot might benefit from that?
|
| > What does it say about Copilot's knowledge of accessibility
| when it will hand us code even basic checking tools would flag?
|
| Maybe it could do with some fine-tuning based on those checking
| tools? e.g. sample many answers to same prompt, run them through
| checking tool, and then fine-tune it to prefer the answers which
| caused the least warnings?
|
| Or: run the suggestion through checking tools, and if it triggers
| warnings, sample a new suggestion, and see if the new one
| doesn't. This could be done on the client side in a loop - run
| suggestion through checks, if it fails, ask the LLM for a new and
| different suggestion, repeat until we get one which passes
| checks, or we give up.
| teaearlgraycold wrote:
| The issue is that often you do want heavy repetition when
| programming. Think about a list of strings where they mostly
| have a common prefix. Or JSON, or a bunch of imports and
| exports. Good code often has these low entropy sections.
| skissane wrote:
| > The issue is that often you do want heavy repetition when
| programming.
|
| Up to a certain number of tokens, yes. But, I doubt any high
| quality code would have the exact same sequence of N tokens
| repeated 25 times consecutively. There's a certain heaviness
| of repetition at which it is unlikely to be genuinely useful.
|
| > Or JSON, or a bunch of imports and exports
|
| A human programmer, when evaluating whether code is
| repetitive, doesn't treat all tokens as equal - they ignore
| "expected"/"necessary" repetitions, and focus on the
| "unexpected"/"unnecessary" ones. So, penalising repetitions
| in sampling doesn't have to treat all tokens equally either.
| For example, in a JSON document, one might choose to ignore
| the tokens required by JSON syntax. In Java, one might
| penalise repetitions less in the import block than in a
| method body.
|
| Of course, this means the sampling actually has to be aware
| of the syntax of the language being generated - which is
| possible, and can have some other advantages (e.g. if
| sampling only samples tokens which are allowed by the
| language grammar, you can eliminate many possibilities of
| generating syntactically invalid code.)
| teaearlgraycold wrote:
| All true. The raw transformer architecture isn't enough to
| write sane code. I'd love to see changes made to have them
| guided by the compiler, customer linter rules, etc.
|
| I still like them as is. I don't let them write too much
| code for me. They're really good translators (JSON to
| TypeScript interface definitions, shell command to Python
| string list) and quick documentation lookups (I like to
| write quick one-line comments for something short that I
| need that I would previously have looked up).
| pclmulqdq wrote:
| If you look at the code for many sites with high "production
| value" today, 25 nested divs is about right. As a non-web-dev,
| I have always been surprised at how often you need to throw in
| a new layer of divs to get some simple visual thing to work
| across device sizes.
| Doches wrote:
| This is one of the more thoughtful, nuanced criticisms of the
| current LLM fad that I've read, and I'm delighted to see it make
| it show up on HN. The author starts off with a series of well-
| thought experiments that show Github Copilot generating _pretty
| valid_ frontend code, code that works and fulfills the prompt:
| but code that ignores every web accessibility rule of thumb in
| the most egregious ways. Sure, yes, bad web devs write bad code,
| and Copilot is -- on its best day -- a perfectly cromulent bad
| developer. Yawn, news at 11, etc.
|
| But where he takes those examples and where his thoughts end up
| is where this essay really hit home for me:
|
| > As more and more of the internet is generated by LLMs, more and
| more of it will reinforce biases. Then more and more LLMs will
| consume that biased content, use it for their own training, and
| the cycle will accelerate exponentially.
|
| And 'biases' here isn't the usual "models are woke-lobotomized!"
| yammering, but rather a thoughtful take on how the use of LLMs
| for code generation may, at least for the current state of LLMs,
| slowly normalize _writing worse code_.
| rebolek wrote:
| So that's nothing new. Code is getting worse for decades.
| Moore's law is making worse code acceptable.
|
| In the meantime, some people write better code and do care
| about it and LLMs aren't going to change that.
|
| So there will be worse code and there will be better code as
| always. LLM is just a tool.
| timeon wrote:
| This is true but let's not forger that it is race to the
| bottom.
|
| Even this blog did reshaped itself while I was reading it.
| Moore's law is lagging here.
| here4U wrote:
| It is clear that despite these tools having flaws on the whole
| they save a lot of time. It is not clear what the tradeoff with
| introducing poorly understood or faulty code will bring, but
| given the utility we're never going back.
| callamdelaney wrote:
| Half the time copilot doesn't even return a solution
| Smaug123 wrote:
| This is a _good_ thing in the context of the article (it even
| explicitly says "They're not made to give you verifiable facts
| or to say 'I don't know'" in a context which suggests this is
| in fact a bad trait). Better to return no code than to return
| crap code.
| timeon wrote:
| Better no-solution than cognitive overload with bad solutions.
| plondon514 wrote:
| Is it just me or has copilot gotten progressively worse lately?
| It used to feel like it was making well informed guesses, now
| they feel like literal guesses with no context at all. For
| example in my phoenix live view (elixir) app it guesses
| "xxx@xxxxx" for _any_ attribute I pass in to a component.
| stanleydrew wrote:
| > Shouldn't the results I get from a paid service at least be
| better than a bad StackOverflow suggestion that got down-voted to
| the bottom of the page (and which would probably come with
| additional comments and suggestions letting me know why it was
| ranked lower)?
|
| I don't know why you would expect this, when the model is likely
| trained on StackOverflow material (or similar publicly available
| code examples).
| godelski wrote:
| I think the problem is that any tool like this (even one
| theoretically much more powerful) is most beneficial to those
| that need it the least and least beneficial to those that need it
| the most. If you're an expert you can identify the mistakes and
| they are not generally a roadblock. But if you're a novice you
| can't and you'll simply be unaware of any hallucinations. The
| benefit SO has over this is just the extra friction of needing to
| copy paste or retype because it slows you down and forces an
| opportunity to think.
|
| My worry is that we become too reliant on tools and outsource our
| thinking to them before they are ready to take on that task. This
| will only accelerate the shitification of things we have. More
| apps that use far too many resources. Things that are security
| nightmares. Interfaces with more friction. All of it.
|
| The problem is pareto efficiency. 80% of your code is written in
| 20% of your time but 80% of your time is is required for 20% of
| your code. The problem is that the devil is in the details. So
| even a 95% or 99% accurate code generator is going to make for
| hard work. That's 1 in every hundred lines of code. I hope the
| compilers people are writing good error messages.
| jimbob45 wrote:
| _My worry is that we become too reliant on tools and outsource
| our thinking to them before they are ready to take on that
| task._
|
| Industry greats like Spolsky have been beating this drum for
| decades [0] with no success. Those with natural curiosity will
| gravitate towards understanding the low-level mechanisms of
| things, just as they always have. Others won't.
|
| [0] https://www.joelonsoftware.com/2001/12/11/back-to-basics/
| heisenbit wrote:
| The key issue is not the power of the tool but the tool
| powerfully amplifying practices that ought to be resisted but
| exist in the majority of the code in the wild.
| godelski wrote:
| The problem with move fast and break things is that you need
| to at some point slow down and fix things. But we've
| developed systems that incentivize never stopping and so just
| enshitify everything. You win by not having no shit, but by
| being ankle deep in shit rather than waist deep. By being
| less shitty.
| beau_g wrote:
| Enshitification doesn't happen because of the tools, it happens
| because the market will bear it.
|
| "More apps that use far too many resources", "Interfaces with
| more friction" Let's extend this to just performance/latency/ux
| at large for web based tools/sites/resources. The market has
| shown in some cases people will tolerate a lot of this, like
| phone support, can take >30 mins, but in other cases/scales,
| like search, every millisecond matters. The garbage apps I
| encounter like this now I feel are on the wrong side of this
| line are generally are enterprise apps that deal with payroll,
| HR training, etc. These apps are allowed to be bad because
| their users are generally captive/don't choose the apps and
| their developers aren't likely to care much because nobody is
| passionate about making sexual harassment quizzes. I actually
| like the chances of a 2-3 person team using LLM coding tools
| being able to upset these entrenched garbage piles. The
| likelihood of a tool/site with good UX and performance now
| degrading because junior engineers are using LLM code seems to
| be about zero, if you've built these tools you know how hard it
| is to drive the culture/ethos on shipping the code that powers
| these projects before copilot/chatGPT was around, and that
| isn't going to change. So ultimately, I think
|
| -Garbage apps that exist now will become slightly worse -The
| chances of slightly better, cheaper apps replacing those apps
| will grow -Good apps that exist now won't regress
| godelski wrote:
| Because of the tools? No, of course not. Do the tools make
| enshitification easier and does the current incentive
| structures create an environment where I expect these types
| of tools to accelerate enshitification? Certainly. These are
| two very different things. I hope we can understand the
| difference because these types of details are important to
| prevent enshitification.
| ctoth wrote:
| I am pretty sure enshitification is a specific process with
| a specific meaning, what you're talking about, quality
| going down for whatever reason you can just call "going to
| shit."
|
| Let's not lose the useful concept enshitification is a
| pointer to by overloading the word :)
| c0pium wrote:
| The inevitable enshitification of enshitification.
| godelski wrote:
| I don't think I'm really pushing the bounds here. The
| fast pace does help make things sticky. We love shiny new
| features. Even if it is just a polished turd. My worry is
| about more polished turds, which I think is pretty in
| line with enshitification since the de facto tech is
| reliant upon network effects. But I guess the thought is
| more general.
|
| Words shift meanings and once you have coined something
| you lose control over it. Bitter sweet.
| BerislavLopac wrote:
| > 80% of your code is written in 20% of your time but 80% of
| your time is is required for 20% of your code
|
| This is not correct. It is well known that the first 90% of the
| code takes the first 90% of the time, and the remaining 10% of
| the code takes the other 90% of the time. [0]
|
| [0] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
| godelski wrote:
| Good catch, I fell victim to one of the classic 4 problems in
| CS: off by integer overflow, segfault. I'm sorry I can't
| complete this task, I'm a model trained by OpenAI and my
| knowledge cutoff date is Sept 2021.
| seabass-labrax wrote:
| This is a bit suspect... you're not patronizing enough to
| have been trained by OpenAI!
| bayindirh wrote:
| This is one of the golden rules of the software development,
| yet many people still thinks this one-liner meant to be for
| fun only.
| godelski wrote:
| I think a better definition of a clique ends up being
| "something everyone can recite but don't know." I think it
| tells us something about intelligence too, because you can
| know things but that doesn't mean the information is
| actually useful.
| Jensson wrote:
| I always wondered if that meant the first 90% takes 50% of
| the time or 10% of the time.
|
| You could see it as the last 10% taking 90% which is the same
| as the first and total work was actually 180%, so the first
| took 50% of total.
|
| Or you can see it as the last taking 90% of the time for
| real, so the first 90% took 10%.
|
| It is a factor 5 difference between the two interpretations,
| so it really matters a ton.
| iefbr14 wrote:
| In practice they both turn out to take 90%
| skybrian wrote:
| In my experience, it's the opposite. Asking GPT4 for help is
| most helpful when I don't know how to do something. Once I know
| what I'm doing, the mistakes become more obvious and annoying.
| I've learned something, but the chatbot makes the same mistakes
| as before, and it will keep making them.
|
| Ironically, it's because people can learn and chatbots don't.
| (In the short term, that is; new releases will be better.)
| nogridbag wrote:
| _My worry is that we become too reliant on tools and outsource
| our thinking to them before they are ready to take on that
| task_
|
| Personally I have never tried any of the AI assistants, but I
| have noticed a large uptick in developers attempting to
| secretly use them in remote coding interviews. I'm curious how
| the larger companies are dealing with this.
| mrweasel wrote:
| > attempting to secretly use them in remote coding
| interviews.
|
| We have from time to time simply asked people to write
| pseudo-code in something like Etherpad or Google Doc. I'm
| sure that you can get an AI to type in your answer, but I
| feel it going to be pretty obvious what's happening.
| ljm wrote:
| I see it fairly often when doing code review, because
| sometimes a line of code or a function stands out that just
| doesn't seem in line with the rest of the PR. So I add a
| comment like "what is this doing exactly?" because it's
| usually something that's difficult to understand, and the
| answer is usually "It's what GPT/Copilot suggested _shrug_ ".
| It's not really something I approve of because it's actively
| defying codebase standards that are intended to help the
| team. At least make the effort to clean it up so it meets
| basic expectations.
|
| I imagine it's quite easy to ask the same question during a
| code test because you shouldn't have to stop and think about
| code you consciously wrote, and you wouldn't have to wait for
| GPT to feed you an answer.
| esafak wrote:
| I ask them to share their whole screen.
| nogridbag wrote:
| Yeah I thought about that too. I suppose it could still be
| a problem if they have a second monitor.
|
| I guess there's the opposite perspective. By not actively
| trying to prevent it, we can weed out people who would
| choose to cheat in a remote coding interview. Those same
| candidates would likely do fine if they were physically not
| able to cheat, but may have ultimately be a net negative
| for the team.
| godelski wrote:
| Hopefully by less lazy interviewing tactics and trying to
| hire via nuanced understanding of candidates instead of
| hackable metrics like memorizing leet code.
|
| The traditional engineering interview is more fuzzy and is
| basically an engineer asking you about how you'd solve a
| problem they are currently working on or recently did. The
| interest is to see how you think and problem solve. It's
| inheritably unmeasurable but I think it is better than using
| a metric that ends up not meaning much. If it is explicit
| fuzziness vs implicit, I'll choose explicit every time
| because it is far harder to trick myself into thinking I'm
| doing the right thing when I'm not.
| simonsarris wrote:
| > The benefit SO has over this is just the extra friction of
| needing to copy paste or retype because it slows you down and
| forces an opportunity to think.
|
| The benefit of SO is the opportunity for both learning and
| doubt: There are multiple answers and comments on answers. It's
| not at all a site with nothing but code blocks to copy.
|
| Certainly _some_ people copy-paste without reading any more,
| but you don 't have to use it that way if you want to learn.
| LLMs treat every user closer to the laziest user, which seems
| like a problem.
| make3 wrote:
| I wonder if these issues will still exist in 5 years. The power
| of NLP models has improved by so much these past 5 years, it's
| really insane.
| bluefirebrand wrote:
| I agree with most of the stuff in this article but I'm a bit
| puzzled by some of the attitudes of the author. They seem to care
| more about the LLM delivering code with poor accessibility than
| they care about the LLM delivering completely wrong answers.
|
| The "any good developer would realize this is bad code" rings
| strongly as "no true developer would think the LLM's bad answer
| was correct". Seems like a short sighted opinion to me.
|
| I also think you can replace "accessibility" with any number of
| programming meta concepts and find problems too.
|
| How about "internationalization"? Are LLMs any good at producing
| code that is nicely internationalized?
|
| Or more importantly "security". Are LLMs going to produce
| millions of lines of poorly secured code that people never double
| check? Almost assuredly.
|
| The fact is that LLMs are prediction engines. They run off of
| probabilities based on the prompt and the training model. Thus,
| unless the training model is weighted towards cherry picked
| examples of excellent code, it's going to follow the masses.
|
| And the masses write bad-to-average code mostly.
| wlesieutre wrote:
| _> They seem to care more about the LLM delivering code with
| poor accessibility than they care about the LLM delivering
| completely wrong answers._
|
| I think the idea with this is that if it gives you completely
| wrong answers and the code doesn't work, it will obviously not
| work and have to figure out how to fix it.
|
| Meanwhile when it gives you code that appears to do what you
| wanted except the accessibility is broken, you'll ship it
| because you don't realize there's anything wrong with it.
| bluefirebrand wrote:
| The problem is that often it will give answers that are only
| subtly wrong, and those will get shipped too.
|
| I think my puzzlement is with the focus on accessibility as
| though it was a high priority item. In my experience it's
| usually an afterthought, if it's a thought at all. Personally
| I've never worked on a codebase where accessibility was in
| the top 5 priorities. No one would ever block a prod release
| for an accessibility mistake.
|
| But like I said, you could take this whole argument,
| find+replace "accessibility" with "security" and you would
| have a much more compelling argument imo. Given time
| constraints, code should prioritize security over
| accessibility basically always.
| runarberg wrote:
| I don't think you are a minority in web development, but if
| you are shipping to a wide user base on the open web, you
| are definitely on the wrong, and you may be doing something
| illegal.
|
| As far as web development goes, accessibility is actually
| something you must screw up, rather then something you have
| to build up. In most cases what you do is accessible _by
| default_ (as is talked about in this article) and you have
| to do something weird to brake it. What you build by not
| thinking about accessibility might not have the best
| _usability_ for assistive technology, but it should at
| least work.
|
| That said, throughout my 10+ years as a web developer, I
| have consistently been reminded about accessibility. It is
| all over the literature, if you go to a random page on MDN
| there is probably a bullet point about accessibility
| implications. As a student, accessibility was at the
| forefront.
|
| In fact, as an expert front end developer, it is my
| responsibility to make sure what I build is accessible. In
| fact, project managers often don't know this, and I have to
| explain to them. A good project manager would know to take
| an expert advice.
|
| > you could take this whole argument, find+replace
| "accessibility" with "security" and you would have a much
| more compelling argument imo. Given time constraints, code
| should prioritize security over accessibility basically
| always.
|
| I'm sorry, but this mentality demonstrates a massive
| disrespect for a portion of your user base (given you are
| targeting a general audience; as opposed to internal
| tools). If your work can't be used by somebody with a
| disability (or because their touchpad stopped working), you
| are not only being rather rude, but you may be braking the
| law. Everybody deserves the possibility to use your work
| equally.
| wesleyyue wrote:
| I think a lot of these are actually solvable problems today,
| Copilot just hasn't prioritized actually improving the product
| (don't need to improve the product for breakneck growth when you
| have github.com as a distribution channel!)
|
| It feels like there are a lot of well-intended AI coding products
| that just don't pay attention to getting the details right. I
| actually started building my own extension recently, with an
| emphasis on getting all the little things right, because I got so
| frustrated at Copilot. Things like closing brackets properly, not
| interrupting me and destroying my train of thought when writing
| comments, not suggesting imports unless it's highly certain (or
| verified with intellisense), etc. Like why am I wasting my
| precious time talking to copilot chat with gpt3 when gpt4 exists?
|
| It's still a pretty early version, and ultimately we're using the
| same underlying model for completion, but I think getting these
| details right make a huge difference (at least to my biased
| self).
|
| If you want to try it:
| https://marketplace.visualstudio.com/items?itemName=doublebo...
|
| You'll need to install the pre-release version for auto-complete.
| throwanem wrote:
| I'll use a locally hosted Llama 2 or CodeLlama instance as a
| 'consultant', via a chat window. These models can be great for
| that! A well-formulated question often elicits a precise and
| accurate answer, even from the unspecialized model.
|
| I _won 't_ use Copilot or anything else that integrates that
| tightly into my workflow, even though it is now possible to do so
| without losing the incremental-cost and customizability benefits
| of selfhosting.
|
| The context switch is important. To a very good first
| approximation, our task as engineers is to think _before_ we
| assume, and I have found Copilot recklessly encourages the latter
| at the expense of the former.
| _flux wrote:
| I wonder though if Copilot had fared better here had it been told
| to pay attention to accessibility.
|
| I mean, maybe it should do it by default (and maybe it could be
| part of its system prompt or otherwise in its material), but it's
| still a tool that needs some expertise for using, even if it's
| trying its best to trick people into believing otherwise.
| Ultimately I don't think there's a solution to people misusing
| tools.
|
| Paraphrasing sentiment I don't quite recall exactly: "If anyone
| can do it, then anyone will."
| rafram wrote:
| > In a lot of ways, in fact, "AI" is just the newest iteration of
| a very old form of colonial capitalism; build a wall around
| something you didn't create, call it yours, and charge for
| access. (And when the natives complain, call them primitive and
| argue they're blocking inevitable progress.)
|
| This is pithy, but the dynamic between OSS devs and
| Microsoft/OpenAI is not exactly comparable to the dynamic between
| a colonial government and an indigenous population. I don't think
| it really needs to be said, but open-source maintainers are not
| colonized natives.
|
| Even overlooking the very questionable metaphor, they're not
| building a wall around existing repositories of code and selling
| them back to us. They spent a lot of money training an AI model
| on that code, and now they're selling access to that model. You
| don't need to pay Microsoft for access to the GitHub repos or
| Stack Overflow answers that they trained on.
| g-b-r wrote:
| These code generation systems should probably prepend a hidden
| "Generate accessible, secure, maintainable etc code" prompt
|
| Of course that doesn't provide any guarantee, and no developer
| should rely on it, but the average results would probably be a
| little better
| joenot443 wrote:
| I've come to largely agree with the author. These days, I keep it
| off by default, but is a Cmd+' away from being flipped on and
| filling in what I _know_ to be boilerplate that's well suited. If
| I was younger with less money, I probably couldn't justify the
| price, but these days if it can save me a half hour of busywork
| per month on my personal projects the $10 is more than worth it.
|
| Leaving it on while doing any thoughtful or challenging coding is
| super distracting for me.
| input_sh wrote:
| As someone younger with less money... well, I'm "lucky" enough
| to get it for free (fun fact: GitHub just gives it away in
| perpetuity to accounts above certain threshold of "karma"), so
| I use it.
|
| If I didn't get it for free... well I'd be lying if I said I
| don't get any value out of it, but you're spot on, definitely
| not enough to justify its perpetual subscription.
| samatman wrote:
| The vacuum cleaner analogy didn't land for me. I've bought that
| vacuum cleaner, and I didn't return it.
|
| I'm referring to one of the countless models of robot vacuum, of
| course. They clean the floor, most of it, most of the time, but
| they miss spots, they get stuck on things, and they don't have
| the suction of a full-size vacuum.
|
| I wish none of those things were true, but _it saves me labor
| nonetheless_ , so I kept it. I can detail corners and pull the
| thing off the corner of the rug, and still get a mostly-clean
| floor, automatically. Sure, it doesn't get all the schmutz out of
| carpets, but it gets enough that I can go over them monthly
| instead of weekly.
|
| Yes, I'm talking about LLM code assistants. They have
| embarrassing failure modes, but experienced developers get a
| sense of what they can and can't do, and the result is something
| which saves time. I've found they're particularly good at "dumb
| debugging", where there's some fat-fingered error in the code and
| I can't spot it just by looking. I can copypasta the function
| into ChatGPT in seconds, and it gives a step-by-step description
| of what the code does, which routinely points out exactly where
| the bug is.
|
| I have my concerns about what these tools will do to the up-and-
| coming generation of developers, it's easy to imagine them as a
| crutch, training wheels which never come off. But that's a
| separate matter, and I trust that the more natively talented
| juniors will recognize the hazard there, and understand that a
| chatbot can't substitute for becoming a skilled programmer.
| coffeebeqn wrote:
| I use them quite a bit. Write these tests for this function in
| format x, transform this struct with lots of fields in the
| manner y or just good old rubber ducking about a problem I'm
| having trouble debugging
| throwawaysleep wrote:
| > but it saves me labor nonetheless, so I kept it.
|
| Yep. Trading accessibility and usefulness to the people who
| disable JavaScript for 20% more productivity is a bargain. Most
| companies make that trade for far less every day.
|
| I've never worked in a place that gave much thought to those.
| At most there was a contracted dev in some low cost country to
| slap aria tags around.
| throwuxiytayq wrote:
| I am somewhat amused by all of the "copeelot bad" articles, and I
| dearly hope they keep proliferating, so that those of us who
| enjoy its frankly insane productivity boost get to stay ahead of
| the competition. I perceive no quality/reliability drawbacks in
| my own code. If anything, the ability to iterate more quickly
| makes my code better than ever.
|
| It's a skill issue. (You had it coming.)
| Karellen wrote:
| > I perceive no quality/reliability drawbacks in my own code.
|
| How can you be sure that doesn't say more about you than it
| does about copilot?
| throwuxiytayq wrote:
| I'm pretty sure, as I constantly judge and monitor the
| quality of my code. But thanks for immediately disregarding
| my personal experience and inserting your own uninformed
| prejudged assessment, random internet guy.
| notpachet wrote:
| > thanks for immediately disregarding my personal
| experience and inserting your own uninformed prejudged
| assessment
|
| Isn't that exactly what your toplevel post is doing?
| Physician, heal thyself!
| throwuxiytayq wrote:
| I hesitate to engage in this hopelessly fruitless
| discussion, but the answer is no. I don't even express my
| opinion of the article, arguably barring one humorous
| phrase that refers to the currently-fashionable wave of
| Copilot criticism. _I don 't mind the article_. It's
| actually pretty well-written. None of this is
| incompatible with my statement that in my experience,
| Copilot lets me do my job better. Time to get off the
| internet, physician.
| Ologn wrote:
| Redmonk says Kotlin is the 17th most popular programming language
| ( https://redmonk.com/sogrady/2023/05/16/language-rankings-1-2...
| ). So can any of these LLMs and whatnot, even the ones supposedly
| geared toward programming do something like this:
|
| "Write a function in Kotlin that take a Long as a parameter, and
| sends back a List containing Long types. The parameter is a
| number, and the return is a list of prime numbers less than that
| number. All in one function."
|
| It seems it should be pretty simple, in fact I have written this
| program a number of times. If you think a list of prime numbers
| might take up too much memory, I have also done prompts only
| asking it to just give the largest prime under the input
| parameter.
|
| It is not a difficult task, and Kotlin is between Objective-C and
| Rust in popularity. Have any neural network programming tools
| been able to complete this? No. Some can, if the number input is
| 18L or the like. None have been able to handle 600851475143L
| (taken from the third Project Euler). If the program runs at all
| I get "java.lang.OutOfMemoryError: Java heap space". Even if I
| warn it to watch heap memory, it still is the same result.
|
| As I said, this is a prompt for a list, but even if I ask for
| only the largest prime number before 600851475143L, or any long
| such as that number, I have not seen any LLM or the like that can
| write that function. Especially ChatGPT 4, which I have tried it
| on extensively.
|
| I'm not saying LLMs will not get there, but this part of the
| third question on the Project Euler site, from a fairly popular
| language. It's a pretty simple question - a straightforward
| function to write. They can't do it yet.
|
| I see people worrying about AI being on the verge of taking
| programmers jobs. Until it can do something incredibly specified
| and simple as this, I am not worried at all.
| Smaug123 wrote:
| The list of primes below 600851475143 contains 23038900221
| elements. If each element is a long, that takes a little over
| 184GB (decimal) of storage. May I ask how you managed it
| _without_ running out of memory?
|
| (Project Euler 3 asks for a _factorisation_ , which using the
| most memory-hungry but reasonable algorithm would require a
| list of merely sqrt=775146 in length, which is much more
| manageable.)
| pavlov wrote:
| Personally I think of LLM code helpers as a warning smell.
|
| If I'm working on something where I'm tempted to generate a bunch
| of boilerplate from a bot that knows very little about the
| context of the project, am I really spending my time on the right
| thing? Either I should be working on something higher level, or
| the amount of boilerplate should be so low that I can write it
| myself. Anything else suggests that there's a problem and the LLM
| bloat band-aid isn't the solution.
| coffeebeqn wrote:
| Depends. We have a large CRUDv service - lots of endpoints that
| has a lot of boilerplate and not much business logic but it
| doesn't change often. It's annoying to add a new endpoint but
| it's not common enough that I want someone to spend a month+
| refactoring it
| dexwiz wrote:
| Copilot is a competent coder. If I tell it to generate a function
| with certain parameters, a class that follows a Gang of Four
| pattern, mass rename variables, or refactor loops into maps, then
| it does a pretty good job.
|
| Copilot is a bad engineer. If I tell it to build something,
| unless exceedingly simple, it usually fails. The ability for it
| to create something seems correlated to how many 5 minute
| tutorials for that exist on the internet. Which given its
| training, makes perfect sense. So if I think I could find an
| answer on Stack Overflow, then I will just ask Copilot instead.
|
| 10 Years ago everyone was afraid of the Stack Overflow developer,
| now its the GPT developer. I think its a combination of actual
| worry and hurt pride that your job can be accomplished by someone
| copy/pasting. But like usual, good engineers will learn to think
| for themselves when leveraging tools. And an exceedingly amount
| of code produced works but is bad by some arbitrary metric.
|
| I think the footer example is hilarious, because its exactly
| inline with web development trends of the last decade. Why use
| native elements when I can script my own behavior in Javascript
| on a div? And in a rush to "not use tables for formatting," I bet
| there are some 25 nested div websites out there. Even on Google
| sites, I have see grids built using absolutely positioned boxes
| with Javascript layout logic. The web is a wild place once you
| start looking past the tutorials and best practices.
| rikafurude21 wrote:
| ultimately these are the kind of things programmers care about.
| code debt is real and anyone who has any experience having to
| pay the debt off usually learns their lesson and does a better
| job on the next try
| robocat wrote:
| > Even on Google sites, I have see grids built using absolutely
| positioned boxes with Javascript layout logic
|
| Possibly a side-effect of the framework used. Some frameworks
| used HTML like a CANVAS and drew/layout everything in HTML
| using absolute positioning. Ugggh.
| CarefreeCrayon wrote:
| One concern that I have is that copilot is inherently additive in
| nature. It is unable to suggest that blocks of code be deleted
| which creates a bias that adding more code is always the solution
| and a lot of code that shouldn't be written ends up in the
| codebase.
|
| I believe this is a problem works against less experienced
| engineers because more senior engineers are better at recognizing
| that problem. In my experience the most senior engineers respond
| to that by just turning the tool off.
| idempotent_ wrote:
| Would be very cool to be able to highlight sections or even an
| entire file and then have a right-click option to "Refactor
| Code" which, rather than being additive, would clean up and
| condense the code according to the idioms of the language.
| runarberg wrote:
| > In a lot of ways, in fact, "AI" is just the newest iteration of
| a very old form of colonial capitalism; build a wall around
| something you didn't create, call it yours, and charge for
| access. (And when the natives complain, call them primitive and
| argue they're blocking inevitable progress.)
|
| What a wonderful analogy. LLMs also feel very pythagoran, where a
| secret cult (of capital owners; the bourgeoisie) guards the
| secrets of forbidden math, using it for their own benefits, and
| denying it to the masses. The amount of data and computing power
| needed to train a good model means it is pretty much inaccessible
| to the masses, the public can only ever hope to use an already
| trained model which is provided to us by this secret cult.
| cwkoss wrote:
| Does anyone who has found a good workflow with copilot have a
| good resource to share that demonstrates how to get the most out
| of it?
|
| I really want it to be more useful, but rarely find that it's
| helpful for completing more than a single line or two.
|
| Do you write out comments for everything you're going to do and
| then just write it yourself if the suggestion isn't useful?
|
| Is there a trick to getting it to read your code itself across
| files?
| layer8 wrote:
| It's appalling that most website/app developers even have to deal
| with those kinds of low-level considerations, after decades of
| web-tech evolution, instead of using a UI builder tool (or a
| better UI modeling language) that provides all the building
| blocks for the most common 97% of use cases, and where you would
| need to go out of your way to create a non-accessible link.
|
| TFA is right about LLMs, but it's also an indictment of the web
| UI stack.
| taway_6PplYu5 wrote:
| By a UI modelling language, do you mean HTML or Javascript or
| CSS?
| layer8 wrote:
| I mean something more suitable than the HTML+JS+CSS
| combination. HTML is a document markup language, not a UI
| definition language. CSS mixes layout with styling, which are
| largely orthogonal. (One should be able to specify a UI
| independently from styling/theming.) A programming language
| like Javascript shouldn't be needed for building a UI, in the
| majority of cases. Most UI components and behaviors should be
| standard (built into browsers, or whatever is used as the UI
| runtime) and declarative.
| simonw wrote:
| Copilot is bad at accessibility because web engineers are bad at
| accessibility. All of the bad habits in this post were learned
| from its training data.
|
| That's not to say this can't be fixed: a recurring lesson of LLMs
| is that the quality of the training data is /everything/. OpenAI
| made their models better at chess by feeding in higher quality
| chess data - they could absolutely make it better at accessible
| frontend code by curating and boosting better code examples.
|
| I doubt they'll do that any time soon, purely because there are
| so many other training data projects they could take on.
|
| Thankfully we aren't nearly as dependent on a few closed research
| labs as we used to be.
|
| It would be very exciting to see fine-tuned openly licensed
| models that target exactly this kind of improvement.
| d_sem wrote:
| I don't know if its mindset or my owner ignorance, but I find
| myself using Copilot and other language model tools as a teacher,
| a debugger, a reviewer, and and idea brainstormer. I find each
| use case to enhance my ability to think more deeply about my code
| and helps keep me more engaged in problem solving.
|
| For some reason I find a inference from a compressed model which
| contains almost every notable open source program written in the
| history of humanity to be a decent sidekick.
|
| My experience tells me no software engineer is an expert at
| everything. Having a tool which allows us to try new things
| faster is a good thing.
| skybrian wrote:
| No mention of testing in the article. It seems odd how often
| accessibility advocates talk about following rules rather than
| testing. Shouldn't we be testing with screen readers or
| something?
|
| If a website doesn't work in Firefox, we fault the developer for
| not testing it in Firefox. Similarly for mobile browsers.
|
| If testing is in place, LLM's are much safer to use. You'll
| notice when they give you code that doesn't work.
| tydunn wrote:
| > Copilot is encouraging us to block users unnecessarily, by
| suggesting obviously flawed code, which is wrong on every level:
| wrong ethically, wrong legally, and the wrong way to build
| software.
|
| I share many of the same worries as the author. This is why I
| think teams need to build and run their own Copilot-like systems,
| so that they can guide the suggestions they receive. Each
| developer and team has their own way of building software, and
| they need to be able to shape and evolve the suggestions they
| receive to fit their definition of the "right" way:
| https://blog.continue.dev/its-time-to-collect-data-on-how-yo...
| htfu wrote:
| It's a very powerful autocomplete. "It doesn't generate all the
| code I need in full and if it does I have to poke at it" is just
| poor criticism. You don't have to press tab and insert everything
| it suggests. It will usually generate me half a line after typing
| the first half - that's pretty awesome in my opinion.
|
| If you stick to using it to merely speed-spell out what you were
| in fact already in the process of writing, and ignore 90% of the
| terrible crap it proposes, it's a nice productivity boost and has
| no way to make code worse by itself.
|
| Basically, instead of writing a big comment and then a function
| signature and expect it to do the rest, just start writing out
| the function, tab when it gets it, don't when it doesn't, or
| (most of the time) tab then delete half of it and keep the lines
| you intended, likely with some small tweak.
|
| Surely LLMs will be able to go so much more and without constant
| supervision in the future, but we're not there. That doesn't mean
| they're bad. Especially copilot since it's just there with its
| suggestions and doesn't require breaking flow to start spelling
| out in regular text what you're doing.
| Qwero wrote:
| What we will see is that llms become so good in writing code that
| LLM first will emerge.
|
| LLM first means we will test it against our libraries, best
| practices and potentially even create a new language for it.
|
| Then programming in the classical sense won't exist anymore.
|
| The ara of code will end when we will deploy the first code
| written with LLM to write new code.
|
| Javallm or #llm.
|
| It might be full of examples for a LLM, it might focus on
| analyzing logic and fixing it on a higher level, until the AI is
| good enough to self write, evaluate and deploy it.
|
| After that it will become no longer understandable by us and
| researchers will start analyzing it after it was written.
|
| Historians will start tracking when ai started to create more
| efficient abstractions etc.
| Barrin92 wrote:
| The biggest problem with Copilot/LLMs is that they effectively
| operate against anything that programming languages were designed
| for. What makes programming languages special is that they're
| well defined, semantically and syntactically rigorous and
| intended for machine execution. They give us the capacity to
| formally reason.
|
| Instead what we've got now is _tools that literally argue with
| us_ , rather than anything that actually augments my capacity to
| reason about, inspect and understand the real performance and
| hardware of a system my code runs on. What I need is more Coq
| (this is truly an odd name for a language btw) and less of
| something that just makes natural language suggestions.
|
| What makes a good _engineering_ tool is something that can look
| at the code right there as it is, use the formal guarantees that
| programming languages were designed for and give me some
| verifiably correct suggestions. Not average out 90% of
| Stackoverflow answers and then hallucinate up some statistical
| answer.
___________________________________________________________________
(page generated 2024-02-17 23:01 UTC)