• zbyte64@awful.systems
    link
    fedilink
    English
    arrow-up
    2
    ·
    7 hours ago

    It’s usually vastly easier to verify an answer than posit one, if you have the patience to do so.

    I usually write 3x the code to test the code itself. Verification is often harder than implementation.

    • jsomae@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      3 hours ago

      It really depends on the context. Sometimes there are domains which require solving problems in NP, but where it turns out that most of these problems are actually not hard to solve by hand with a bit of tinkering. SAT solvers might completely fail, but humans can do it. Often it turns out that this means there’s a better algorithm that can exploit commanalities in the data. But a brute force approach might just be to give it to an LLM and then verify its answer. Verifying NP problems is easy.

      (This is speculation.)

    • MangoCats@feddit.it
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 hours ago

      Yes, but the test code “writes itself” - the path is clear, you just have to fill in the blanks.

      Writing the proper product code in the first place, that’s the valuable challenge.

      • zbyte64@awful.systems
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        9 minutes ago

        Maybe it is because I started out in QA, but I have to strongly disagree. You should assume the code doesn’t work until proven otherwise, AI or not. Then when it doesn’t work I find it is easier to debug you own code than someone else’s and that includes AI.