• Modern_medicine_isnt@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    5 months ago

    I am old enough to remember ms frontpage. It could take a 50 line html page and make it 500 lines or more without changing the external appearance. Didn’t make it better.

    And how do you even explain the requirements of somethingvthat took that much code to implement to an AI. The context window is only so big.

  • ozymandias117@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 months ago

    I can certainly understand why one of your libraries was bothering you if you’re merging 250,000 lines of AI generated code in a month.

    • temmink@feddit.org
      link
      fedilink
      Deutsch
      arrow-up
      1
      ·
      5 months ago

      As an AI native he knows how to prompt, for example to always include “don’t make errors” and “make sure to follow security best practices”. It’s really easy once you know.

  • Malix@sopuli.xyz
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    now ask them to maintain the 250k lines, probably fine for rew more commits, but after that? Oh look, they left the company for the next ai-nonsense-startup.

      • Alexstarfire@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        5 months ago

        You made me wonder how many lines our product contains. Looks to be around 600k total right now. Granted, that’s just the front end. It includes comments, blank lines, and lines that are just brackets and such. Also includes some dev only code. So, far more bloated than the actual code. Excludes code from any external libraries we use though.

        I don’t have an easy way to see how many lines our backend is. A large portion of the files aren’t for our front-end and I don’t feel like figuring it out. Couldn’t even tell you if it’s more or less code than the frontend.

        I’d be extremely worried if someone added or re-wrote 250k lines of code in our code base in one month. We actually have regulations to follow.

  • comfy@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    Programming is one of those skills and industries that is accessible enough that basically anyone can do it, but you will run into trouble later if you’re doing anything serious without learning how to do it well. There are hundreds or thousands of ways to make something work, but if it’s an unmaintainable mess or you don’t even understand how it works, then we end up with our financial institutions running COBOL in 2025. Good luck when regulations change. Have fun when your operating system becomes unsupported and you have to replace the underlying dependencies. Hope your boss doesn’t sue when they have to hire people to rewrite your hackjob.

    And these were all already problems before AI code came onto the scene. We had the programming equivalent of script kiddies, people who would blindly copy and paste code from web searches without even reading the date or the comments saying “this is bad and this is why”. But this probably makes it even easier to do, and possibly harder to spot. Combine this with how many universities don’t even focus on lower-level languages so you get plenty of people who can’t understand how to fix any of the trickier errors in their code. And that’s not to say everyone has to be able to, but it’s a problem when so few are able to. So these programmers are unlikely to know if the code has problems so long as it passes their tests, and unlikely to know how to fix those problems when they become clear.

    Automation tools are good ideas for assisting and detecting possible mistakes. They’re not good at generating that much code. In fact, that amount of code in that amount of time is suspicious, hinting that it’s unlikely to be well-designed, maintainable or efficient.

    • Gumby@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 months ago

      I agree with your main point, although I think your example of COBOL being used to this day in financial institutions is actually the opposite problem. The guys that originally developed that shit were damn good programmers, but they were severely constrained by the available hardware, limitations of the language, etc. So they had to get really clever in order to make these massive, complicated systems work. In my experience, those really old legacy systems tend to be rock solid with near 100% uptime and almost no errors. They’ve never been rewritten because doing so would be a multi-year effort costing millions of dollars, and the end result would be a system that is most likely slower, buggier, and has less functionality.

      TLDR: The old COBOL systems are unmaintainable messes not because of incompetent developers, but because the limitations of the available technology when they were originally developed forced a bunch of really good devs to have to get extremely creative and hacky with their solutions.

  • hello_hello [comrade/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    5 months ago

    Notice the most cracked developer “Arno” is a white guy with very expensive equipment who was raised in that environment for more than a decade?

    CS not beating the white supremacy allegations any time soon in the West.