Skip to content
  • Hjem
  • Seneste
  • Etiketter
  • Populære
  • Verden
  • Bruger
  • Grupper
Temaer
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Kollaps
FARVEL BIG TECH
  1. Forside
  2. Ikke-kategoriseret
  3. This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been.

This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been.

Planlagt Fastgjort Låst Flyttet Ikke-kategoriseret
77 Indlæg 49 Posters 0 Visninger
  • Ældste til nyeste
  • Nyeste til ældste
  • Most Votes
Svar
  • Svar som emne
Login for at svare
Denne tråd er blevet slettet. Kun brugere med emne behandlings privilegier kan se den.
  • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

    @TauPan I cringe so much when I see people say 'I use it for repetitive things, like tests!'. Because writing good tests requires understanding which bits in the code are corner cases and writing tests that exercise those. I've seen LLM-generated tests with hundreds of tests for the happy path and none that trigger any of the error-handling.

    I can maybe imagine a loop with an LLM and a coverage tool to get proper coverage, but then you'd need to review the tests generated by the LLMs for the corner cases to make sure you weren't just generating tests that enforce bugs in the implementation.

    cavyherd@wandering.shopC This user is from outside of this forum
    cavyherd@wandering.shopC This user is from outside of this forum
    cavyherd@wandering.shop
    wrote sidst redigeret af
    #63

    @david_chisnall @TauPan

    ...like 3-dimensional survivor bias....

    1 Reply Last reply
    0
    • cavyherd@wandering.shopC This user is from outside of this forum
      cavyherd@wandering.shopC This user is from outside of this forum
      cavyherd@wandering.shop
      wrote sidst redigeret af
      #64

      @ChemicalEyeGuy @david_chisnall

      "Maybe it's more efficient just to burn it all down & start from scratch?"

      "A case could be made...."

      Oh wait—that was DOGE's rationale, too....

      1 Reply Last reply
      0
      • kp@bsd.networkK kp@bsd.network

        @david_chisnall That's (on of) my concern(s) with LLM submissions too.
        It's going to be so much more work to review them than reviewing human submissions, and at the same time the payoff is less valuable. Human submissions, even if they're flawed at first, may result in a new contributor. Reviewing LLM submissions will not grow a new contributor.

        cavyherd@wandering.shopC This user is from outside of this forum
        cavyherd@wandering.shopC This user is from outside of this forum
        cavyherd@wandering.shop
        wrote sidst redigeret af
        #65

        @kp @david_chisnall

        I think one of the major unintentional lessons of this era (both technically & politically) is the value of deep human experience.

        Edit: Value & intrinsically un-automatability.

        1 Reply Last reply
        0
        • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

          This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

          The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

          LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

          Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

          And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

          An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

          I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

          bontchev@infosec.exchangeB This user is from outside of this forum
          bontchev@infosec.exchangeB This user is from outside of this forum
          bontchev@infosec.exchange
          wrote sidst redigeret af
          #66

          @david_chisnall Well, I dunno... I've been using Claude since the beginning of the year and it *is* amazing. It has increased my productivity tremendously. Of course, I never trust it blindly and always verify by hand what it generates. And, yes, I sometimes find bugs in the generated code. Nevertheless, and despite the time I have to spend checking its generated code, it is still an amazing productivity-increasing tool.

          darkuncle@infosec.exchangeD 1 Reply Last reply
          0
          • bontchev@infosec.exchangeB bontchev@infosec.exchange

            @david_chisnall Well, I dunno... I've been using Claude since the beginning of the year and it *is* amazing. It has increased my productivity tremendously. Of course, I never trust it blindly and always verify by hand what it generates. And, yes, I sometimes find bugs in the generated code. Nevertheless, and despite the time I have to spend checking its generated code, it is still an amazing productivity-increasing tool.

            darkuncle@infosec.exchangeD This user is from outside of this forum
            darkuncle@infosec.exchangeD This user is from outside of this forum
            darkuncle@infosec.exchange
            wrote sidst redigeret af
            #67

            @bontchev @david_chisnall OP makes a really subtle point there that I think deserves some more reflection; I'm going to be thinking about that angle for a while.

            1 Reply Last reply
            0
            • dysfun@social.treehouse.systemsD dysfun@social.treehouse.systems

              @david_chisnall do you often brine your supply chain attacks in house? i normally outsource it.

              rupert@mastodon.nzR This user is from outside of this forum
              rupert@mastodon.nzR This user is from outside of this forum
              rupert@mastodon.nz
              wrote sidst redigeret af
              #68

              @dysfun @david_chisnall This is a very salty take.

              1 Reply Last reply
              0
              • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                thibaultdu@mastodon.socialT This user is from outside of this forum
                thibaultdu@mastodon.socialT This user is from outside of this forum
                thibaultdu@mastodon.social
                wrote sidst redigeret af
                #69

                @david_chisnall @briankrebs I also often point out that, with a human colleague, I know what they are good or bad at, I know how they are feeling today, I know how good they understand the context of the task and therefore I know where to look for bugs. LLM-generated code: no idea, just as you wrote.

                rgarner@mastodon.socialR 1 Reply Last reply
                0
                • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                  This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                  The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                  LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                  Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                  And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                  An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                  I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                  littlebobbytables@mstdn.socialL This user is from outside of this forum
                  littlebobbytables@mstdn.socialL This user is from outside of this forum
                  littlebobbytables@mstdn.social
                  wrote sidst redigeret af
                  #70

                  @david_chisnall

                  You forgot the 'pleasing' part.

                  A "statistically plausible pleasing machine." LLMs will give you the answer you want based on your repeated clarification prompts.

                  1 Reply Last reply
                  0
                  • rhelune@todon.euR rhelune@todon.eu

                    @demiurg @david_chisnall Production being down can lose you millions. I know someone who caused that (before slop generators) but suffered no consequences.

                    demiurg@fosstodon.orgD This user is from outside of this forum
                    demiurg@fosstodon.orgD This user is from outside of this forum
                    demiurg@fosstodon.org
                    wrote sidst redigeret af
                    #71

                    @rhelune @david_chisnall I have a lot of stories about bugs in production. Not all are critical. In a non toxic team everybody is in charge about quality and if something goes wrong you work on the cause and don't blame individuals. Also, a lot of companies have external devs. They usually do not care too much about anything (I don't blame them, either). Having defects and regressions is the norm. It is not the exception.

                    1 Reply Last reply
                    0
                    • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                      This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                      The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                      LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                      Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                      And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                      An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                      I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                      europlus@social.europlus.zoneE This user is from outside of this forum
                      europlus@social.europlus.zoneE This user is from outside of this forum
                      europlus@social.europlus.zone
                      wrote sidst redigeret af
                      #72

                      @david_chisnall @briankrebs I went on a mild anti-AI rant this week before a presentation I was giving about strata management finance.

                      Strata management is highly regulated in NSW, has rapidly changing legislation over the last 4 years, and is highly technical, and I made the point that when it came to LLMs providing subtly wrong answers they’re the ones it’s often harder to pin down as wrong.

                      I describe LLM outputs as “answer-shaped”, and “correct-adjacent to varying degrees” – pareidolia unfortunately fills in many gaps between those and “correct answer”.

                      1 Reply Last reply
                      0
                      • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                        This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                        The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                        LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                        Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                        And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                        An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                        I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                        kleisli@mastodon.socialK This user is from outside of this forum
                        kleisli@mastodon.socialK This user is from outside of this forum
                        kleisli@mastodon.social
                        wrote sidst redigeret af
                        #73

                        @david_chisnall "His boss told him that if it happened one more time, he’d be fired." Doesn't sound like a place to work at.

                        1 Reply Last reply
                        0
                        • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                          This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                          The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                          LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                          Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                          And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                          An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                          I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                          lproven@social.vivaldi.netL This user is from outside of this forum
                          lproven@social.vivaldi.netL This user is from outside of this forum
                          lproven@social.vivaldi.net
                          wrote sidst redigeret af
                          #74

                          @david_chisnall :%s/brining/bringing/g

                          david_chisnall@infosec.exchangeD 1 Reply Last reply
                          0
                          • lproven@social.vivaldi.netL lproven@social.vivaldi.net

                            @david_chisnall :%s/brining/bringing/g

                            david_chisnall@infosec.exchangeD This user is from outside of this forum
                            david_chisnall@infosec.exchangeD This user is from outside of this forum
                            david_chisnall@infosec.exchange
                            wrote sidst redigeret af
                            #75

                            @lproven Mmm, salted supply-chain attacks.

                            1 Reply Last reply
                            0
                            • thibaultdu@mastodon.socialT thibaultdu@mastodon.social

                              @david_chisnall @briankrebs I also often point out that, with a human colleague, I know what they are good or bad at, I know how they are feeling today, I know how good they understand the context of the task and therefore I know where to look for bugs. LLM-generated code: no idea, just as you wrote.

                              rgarner@mastodon.socialR This user is from outside of this forum
                              rgarner@mastodon.socialR This user is from outside of this forum
                              rgarner@mastodon.social
                              wrote sidst redigeret af
                              #76

                              @ThibaultDu @david_chisnall @briankrebs team software delivery up to this point has been drive-by anthropology, psychology, and geology, and while we may not have qualifications in any of those things, we at least had footholds. Now we're being asked to climb completely smooth surfaces.

                              1 Reply Last reply
                              0
                              • david_chisnall@infosec.exchangeD david_chisnall@infosec.exchange

                                This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

                                The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

                                LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

                                Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

                                And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

                                An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

                                I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

                                tcatinreality@mastodon.socialT This user is from outside of this forum
                                tcatinreality@mastodon.socialT This user is from outside of this forum
                                tcatinreality@mastodon.social
                                wrote sidst redigeret af
                                #77

                                @david_chisnall

                                AIs are designed to maximise plausibility, not accuracy. Because they can "lie" so convincingly, they are particularly dangerous for anything important.

                                Glad that coder eventually came to realise that. We need less hype and more warnings.

                                LLM AI should never be used for anything but entertainment purposes.
                                #RegulateAI

                                1 Reply Last reply
                                0
                                • jwcph@helvede.netJ jwcph@helvede.net shared this topic
                                Svar
                                • Svar som emne
                                Login for at svare
                                • Ældste til nyeste
                                • Nyeste til ældste
                                • Most Votes


                                • Log ind

                                • Har du ikke en konto? Tilmeld

                                • Login or register to search.
                                Powered by NodeBB Contributors
                                Graciously hosted by data.coop
                                • First post
                                  Last post
                                0
                                • Hjem
                                • Seneste
                                • Etiketter
                                • Populære
                                • Verden
                                • Bruger
                                • Grupper