Forgot your password?
Close
typodupeerror
AI Programming

Will AI Force Source Code to Evolve - Or Make it Extinct? (thenewstack.io) 159

Posted by EditorDavid from the rise-of-the-machine's-language dept.
Will there be an AI-optimized programming language at the expense of human readability? There's now been experiments with minimizing tokens for "LLM efficiency, without any concern for how it would serve human developers."

This new article asks if AI will force source code to evolve — or make it extinct, noting that Stephen Cass, the special projects editor at IEEE Spectrum, has even been asking the ultimate question about our future. "Could we get our AIs to go straight from prompt to an intermediate language that could be fed into the interpreter or compiler of our choice? Do we need high-level languages at all in that future?" Cass acknowledged the obvious downsides. ("True, this would turn programs into inscrutable black boxes, but they could still be divided into modular testable units for sanity and quality checks.") But "instead of trying to read or maintain source code, programmers would just tweak their prompts and generate software afresh." This leads to some mind-boggling hypotheticals, like "What's the role of the programmer in a future without source code?" Cass asked the question and announced "an emergency interactive session" in October to discuss whether AI is signaling the end of distinct programming languages as we know them.

In that webinar, Cass said he believes programmers in this future would still suggest interfaces, select algorithms, and make other architecture design choices. And obviously the resulting code would need to pass tests, Cass said, and "has to be able to explain what it's doing." But what kind of abstractions could go away? And then "What happens when we really let AIs off the hook on this?" Cass asked — when we "stop bothering" to have them code in high-level languages. (Since, after all, high-level languages "are a tool for human beings.") "What if we let the machines go directly into creating intermediate code?" (Cass thinks the machine-language level would be too far down the stack, "because you do want a compile layer too for different architecture....")

In this future, the question might become 'What if you make fewer mistakes, but they're different mistakes?'" Cass said he's keeping an eye out for research papers on designing languages for AI, although he agreed that it's not a "tomorrow" thing — since, after all, we're still digesting "vibe coding" right now. But "I can see this becoming an area of active research."
The article also quotes Andrea Griffiths, a senior developer advocate at GitHub and a writer for the newsletter Main Branch, who's seen the attempts at an "AI-first" languages, but nothing yet with meaningful adoption. So maybe AI coding agents will just make it easier to use our existing languages — especially typed languages with built-in safety advantages.

And Scott Hanselman's podcast recently dubbed Chris Lattner's Mojo "a programming language for an AI world," just in the way it's designed to harness the computing power of today's multi-core chips.

Will AI Force Source Code to Evolve - Or Make it Extinct? More | Reply

Will AI Force Source Code to Evolve - Or Make it Extinct?

Comments Filter:

  • Abstract Syntax Tree (Score:3)

    by zekica ( 1953180 ) on Monday March 23, 2026 @06:51AM (#66055710)
    Any language designed for LLMs will probably be AST based. There is no need to convert tokens to text then back to tokens. Bu since LLMs don't understand code, no one will be able to see the bugs it generates.

    • Re: (Score:2)

      by Viol8 ( 599362 )

      Just generate assembler or even machine code direct. Give the AI the task then ask it to generate for x86, ARM etc.

      • Or, since all microprocessors consist of registers, simple instructions, memory addresses, and push/pull, just create a very simple, generic, "language"based on that, and then compile it to any specific architecture.

        • >>Or, since all microprocessors consist of registers, simple instructions, memory addresses, and push/pull, just create a very simple, generic, "language"based on that, and then compile it to any specific architecture.

          We already have programming languages like that. C-- claims to be a "portable assembly language" (some claim that traditional C also fits that description).

          • That sounds good. I understand webassembly was made for something like this too, but I never got into the nuts and bolts of that.

          • Who needs a language at all?

            Cowboy Neal codes in machine instructions, AI should too.

            Even C gets translated to assembly before the assembler makes the binary that gets modified by the linker.

            Point is: all human-accessible programming languages are _at least_ two degrees of separation from machine language executed by the instruction decoder in the CPU. The only thing that matters is the final binary executable in RAM.

          • C? C would be a poor choice; I don't think your can write a complete BNF description of the langauge. Pascal, or Modula3, on the other hand...
        • Java bytecode? That should be directly translatable into runnable code using existing tools.
      • You cant do that: Agent based LLM code generation actually incorporate the result of compile and test. The same quality checkers are as if not even more needed when the code is node by a LLM which is as error prone as human.

      • Are any of the people making these proposals actually considering the consequences of having generated code that no human being can understand?

    • Re: (Score:2)

      by ceoyoyo ( 59147 )

      In the old(er) days of AI there was a philosophical split between people who believed the way forward was creating larger and larger databases of hand compiled facts and rules for relating them, and people who favoured doing as little as possible hand engineering and letting learning algorithms figure things out for themselves. The latter group is certainly dominant now, but old habits die hard.

      If we dispense with the need for humans to understand programs then we won't have a "language designed for" progra

  • What's the prize? (Score:4, Funny)

    by too2late ( 958532 ) on Monday March 23, 2026 @06:52AM (#66055712) Journal
    Is there a contest I don't know about for who can come up with the dumbfuckest ideas?
    • I'd try the Darwin Awards [darwinawards.com]. But be warned. Applying can be dangerous.
    • Since LLM's are a statistical completion engine, how are they supposed to statistically analyze code for a language that nothing is written in? The only reason that they can do what they do is because humans feed them with solid information. When fed poor quality info, you get Grok. The article's author seems to have a fundamental misunderstanding of how this stuff works.
    • I saw this in the documentary 'Idiocracy'

  • We are having a hard enough time as it is already debugging code generated by LLMs and now someone wants to make it even more obscure??

  • Microsoft basic could be saved in the original text format or a faster loading token format. The token format was not human readable but existed as a language of its own. Any computer language can be translated into another language including human readable language. I had a translator program that would convert token basic into human text readable. I also have a program that converts C programs to pascal.

    Any computer language is just a language and can be translated to most any other language if you know w

    • I think your analysis is starting from a solid point, but i still worry there is a lot of room for things to go wrong. LLM oriented code might not have a 1:1 human readable equivalent. There are likely to be subtle differences and assumptions lost in translation. LLM code might also evolve faster, turning it into an arms race to keep up.

  • Tests are not sufficient (Score:3)

    by cjonslashdot ( 904508 ) on Monday March 23, 2026 @07:14AM (#66055728)
    It is provably impossible to "test" that software is (1) secure and (2) reliable. To demonstrate those properties, there must be an "assurance argument" - a logical explanation of how the security and/or reliability aspects of the design generate those properties. Thus, an AI could author such narratives, but without human-readable source code, there would be no way to verify that the code actually adheres to the claimed explanations.

  • Llms are not magic. They are trained on existing languages, including natural language.

    For an AI only language, someone will have to invent it first, then train the models on it.

    The far more likely outcome will be that the models will code in whichever language has the most code examples, and translate from your natural language input to that language.

    • I have used AI to generate code, and it does a decent job of providing generalized code when I do not want to do it myself. The code never works correctly or even at all, but it looks fine at a first glance. The problem is programming languages have to be precise and AI misses details. Specifically I was generating Python code.

      Obvious problems: 1) Using parentheses "()" to call a value in an array instead of brackets "[]". 2) Not using the correct spacing. Python is very space sensitive. Generated code may

      • ehh, I've had the opposite experience. I've got way too many years writing C for embedded systems, but needed an Android app. So I asked ChatGPT to create an Android app for me that would do MDNS and Bluetooth discovery, pop up a dialog to let me choose from the discovered devices, and then connect over WiFi or Bluetooth as appropriate. And, after spending an hour downloading and installing the Android toolset, the program compiled first time and did what I asked. I did my normal step-through-line-by-lin

      • When was the last time you tried this? 2024? Even last month and current week AI is already a world of difference. Codex 5.3 is a leap up from codex 5.2. Opus 4.6 is much better than 4.5. And don't use generic AI for coding tasks, ChatGPT 5.4 can't code it's way out of a wet bag.

    • DotNet bytecode will work fine. Highly efficient representations of abstract languages, easy to translate, plenty of documentation.

  • LLM are trained on existing programming languages in source code form, so to have an LLM to generate code in a new language a lot of source code has to be present.
    Maybe an LLM could produce directly machine code, or p-code instead of having an intermediate step on a language that has to be compiled or interpreted, but this makes more difficult to check and debug the LLM output, and because the output isn't deterministic this makes very diffcult to debug a program.

  • Considering text generators mostly work for things you'd have "copied of StackOverflow" before, I fear that this might lead to more and more boilerplate code. We already saw this with advanced development systems in languages like Java, where you often have more boilerplate than actual code.

    I mean we keep seeing more and more effort being put into the same trivial code we've written for many decades now. Generative AI will likely only make that problem worse. Probably good programmers, now called 10x engine

    • Why is that a bad thing? A library of validated functions that can be glued together would be more secure and more stable than bespoke programming. Itâ(TM)s not as efficient, but with modern processors why is that important? In the industrial automation world this is what systems like PlantPAX are for.

      • Itâ(TM)s not as efficient, but with modern processors why is that important?

        Why do the terms "640k", "ought", and "everybody" keep popping into my head? ;-)

        More specifically, data centres are increasingly responsible for worsening AGW. Inefficient code wastes more power than it needs to; and that's literal, physical, P=E*I power.

  • I would say from past experience that some concepts are simply not meant for AI.

    For example, the Swift programming language is typically good. But SwiftUI construct made on top of Swift is nearly impossible to debug, both for users and AI. Asking AI to do SwiftUI is an experience in futility. (One could say the entire idea of SwiftUI is a false good idea, but thatâ(TM)d be stretching it).

    C++ is not much better. It has to rely on known constructs to understand what the code is doing. AI will add up asin

  • we already have a term for this (Score:3)

    by usedtobestine ( 7476084 ) on Monday March 23, 2026 @07:57AM (#66055786)

    Can we reuse the term 'binary blob'? I think we can.

  • I love it! (Score:5, Insightful)

    by Gravis Zero ( 934156 ) on Monday March 23, 2026 @08:20AM (#66055822)

    I love everything about this but don't get me wrong, it's not because I think it's a good idea. On the surface this seems like it's the future but really it's the single dumbest proposal to come out about AI-based programming. Assuming you make a language that avoids the possibility of creating syntax/structural flaws, it's the inability to scrutinize the underlying code that will bite you, The result is a lower ability to debug code and will end up obscuring security flaws which will make the jobs of criminals easier.

    I love this idea because I know the second a company using this crap gets bitten it's going to be an extremely expensive problem the fix, more costly than if they had just paid normal programmers to write the code originally and may actually force entire programs to be rewritten. This basically ensures that if it gets off the ground that it's going to self-destruct and every company who invested in this idiocy will suffer financial losses.

    What's not to love about idiots getting their just deserts?

    • My job is not primarily focused around writing code, but I have to write code now and then. One the major challenges around code is dealing with very messy data and corner cases. The code would have worked flawlessly except for that meddlin' data. For example, dealing with division by zero errors because a number that should have never been a zero is a zero in one case out of millions. Or that number is null even though the source system does not allow for null to be in that field. One example in two millio

    • Re: (Score:2)

      by Jeremi ( 14640 )

      I love this idea because I know the second a company using this crap gets bitten it's going to be an extremely expensive problem the fix

      That's my gut reaction too -- this will result in software with obscure bugs that are near-impossible for a human to find or fix because no human even understands how the software works.

      OTOH, maybe no human will need to find or fix the bugs, because they can task an AI to find and fix them instead. I'd say that strains credibility, but last year I would have said it strains credibility that an AI can understand (or, at least, "understand") human-written code as well as a human programmer, and yet here we a

      • >>> this will result in software with obscure bugs that are near-impossible for a human to find or fix because no human even understands how the software works.

        And that's different from the current state of Software Engineering how, exactly?

    • Re: (Score:2)

      by wings ( 27310 )

      I agree this is a dumb proposal.
      Just wait until the AI that generates your code gets compromised.

      After a quick internet search I'll leave this link here:
      https://micahkepe.com/blog/thompson-trojan-horse/ [micahkepe.com]

    • Re: (Score:2)

      by gweihir ( 88907 )

      Problem with that is that this may actually cause a major global crisis.

  • The question is... (Score:3)

    by Junta ( 36770 ) on Monday March 23, 2026 @08:48AM (#66055878)

    Why bother? LLMs doing the job they are supposed to works just fine targeting a human readable language, what do they imagine the gains to be? The whole point is that the LLMs deal in human friendly material.

    This seems to be a pointlessly 'futurist' ambition for showing enthusiasm for LLMs rather than some goal with practical implications.

    Even when I see someone having reasonably 'good' luck with their LLM usage, they end up with something a little wrong that, if they would just go manual for a second would be a super quick tweak. But they are committed to the prompt interaction, they keep trying back and forth with prompting and not getting exactly what they want, or something else changing at the same time. Leaving it human readable means you can do that quick manual change without trying to try to induce an LLM to make a precise change, which LLMs even at their best are prone to not manage.

  • Where would training come from? (Score:4, Insightful)

    by maiden_taiwan ( 516943 ) on Monday March 23, 2026 @08:51AM (#66055896)

    AI learned to code by reading human code examples. Where will the training examples come from if AI codes directly to a human-unreadable language?

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      There will be languages made specifically for AI. Probably something a bit like Rust, with inherently safe typing and the like.

      There will still be some developers too, mostly working in languages like C and assembler, and on building stuff for AI to use.

      But a lot of development of in-house apps will probably get replaced by AI. The quality is already terrible because there is no business case for doing more than the bare minimum to make it work.

    • AI doesn't *only* learn to code by reading human code samples. It also can read documentation and write code based on what it sees in those documents, even if no examples exist.

      Generally speaking, the syntax of a language is straightforward. Even non-AI tools can generate proper syntax. What AI does, is a level of abstraction above syntax, applying a specific solution and expressing it in that syntax. AI generally breaks down a problem into components, then puts the building blocks together. The lack of cod

      • yeah maybe.

        i wonder how much language-independent discussion of software design is out there. can an AI only "think" in a specific language like python or whatever ? i'm assuming the bulk of the code intelligence is coming from scraping SO and all the coding blogs out there, which in my experience are almost always using the context of a specific language.

        otoh, maybe that doesn't matter. it can assume python for "thinking" about design and then drop down to the ai-direct language for implementation.

        and

        • i'm assuming the bulk of the code intelligence is coming from scraping SO and all the coding blogs out there, which in my experience are almost always using the context of a specific language.

          I think this assumption was mostly true a year or so ago, but isn't true any more. Current-generation LLMs do reason quite effectively about code and are perfectly capable of creating entirely new code that isn't regurgitated from anything. They're actually better at debugging than writing code, I think, though they tend to focus on shortest-path solutions even after they've (correctly!) identified the root cause.

          • totally,
            but where does that reasoning ability come from ?
            i'm assuming it comes from the vast body of human discussion about coding.

            • totally, but where does that reasoning ability come from ? i'm assuming it comes from the vast body of human discussion about coding.

              Some of it, sure. But some comes from the generic reasoning overlays, some from self-derived conclusions arrived at through self-talk, and some from training that didn't originate in the corpus of human discussion, i.e. from synthetic training. Your mental model of LLMs as regurgitation machines is no longer accurate.

              • i think you're reading a regurgitation viewpoint into what i'm saying. i put 'think' in quotes because i'm still wary of describing them as thinking, but yeah i totally agree they're way beyond regurgitation at this point. i mean, huge portions of human reasoning are language-based. the entire field of formal mathematics is founded on symbol manipulation, for example. so it makes sense that being good at working with language can result in reasoning.

        • Assuming that LLMs get all their information from human discussions and examples, is oversimplifying what LLMs do.

          One way to visualize it (literally) is to think about what PhotShop does when it "erases" someone or a thing from a photo. When it does this, it doesn't get the idea how to "erase" by scraping discussion forums, and not even necessarily from scraping photo sites. Instead, it "hallucinates" what might be "behind" the thing that is being erased, a lot like auto-complete. It extrapolates from what

    • I've seen similar ideas floated by other idiots that said they'll generate machine code directly. Machine code as training data is easy to come by (just compile the C/C++/Rust/Go source), but good luck doing any kind of QA or debugging on it. Code review decreases the amount of testing needed drastically compared to blackbox testing.

    • Re: (Score:2)

      by gweihir ( 88907 )

      What? A strategic view on things? The get-rich-quick idea people do not do that.

  • What a semantic angel-dancing-on-a pin type of question. The source code will always be there. Maybe its in a readable text file. Maybe its buried across 25 gigabytes of uselessly nested code containers, twisted together like spaghetti so no human could possibly ever parse it. But no code means no program.

  • ... is likely going to be the mid- to further out future of coding. Presumably de-compiling into some human-only language not intended for re-compiling is going to become more and more of a thing. No need to go through all the hoops of countless programming languages and frameworks just because some naked apes like to each turn their own little software world into a stack-religion.

    Some form of containers is going to remain though. Especially to isolate problems and find bugs isolating logical components int

  • becuase doing "divided into modular testable units for sanity and quality checks." costs money.

  • A return to the era of "buggy" compilers (Score:5, Interesting)

    by amp001 ( 948513 ) on Monday March 23, 2026 @09:23AM (#66055974)
    When I learned C++, back in the 1980s, the "compiler" (Cfront) was really just a translator that generated C code. That was a good thing, because it occasionally generated bad code, and being able to keep the intermediate C code around during compilation meant you could figure out what was going wrong at that level instead of having to dig into the assembly code. Code-generation bugs still happen occasionally in compilers, I'm sure, but not like it was in those days. Now, it's rare anyone has to worry about the code that ends up executing being functionally different from what was expressed in the higher level language (at least not due to code generation bugs).

    But that semantic gap (the levels of abstraction between what the programmer considers as an abstract execution model and what the hardware actually executes) was increased by going from C to C++, and Cfront was the tool that enabled that expansion. Newer, even higher level languages have continued to increase that semantic gap, aiding productivity gains. But, they still generate code in a predictable, consistent way. The same code, compiled by the same compiler version, will generate the same executable code every time.

    But here we are again. LLM-generated code is just the new "Cfront", taking very high level language descriptions of what we want, in the form of "prompts", and translating them into code at one (higher) level of semantic gap into another (lower) level of semantic gap. Great. Except now we're back to having to deal with "bugs" in the code generation. Worse yet, it doesn't generate the same code consistently, because the "temperature" parameter is a trade-off between output quality and consistency. Perhaps one day we'll get to where modern compilers and code generators are. Until then, we are still responsible, even liable, for the code we create, either directly or via some LLM-based model. So, we'd better be able to read and understand the code being generated at the layer most prone to bugs, until that layer gets to the same level of reliability as modern compilers are at today.
    • Why not just have the AI write directly in assembly? If you are taking away all these layers of abstraction, why not get rid of them all? I'm sure AI will write efficient and effective machine code.

      • Re: (Score:3)

        by gweihir ( 88907 )

        I'm sure AI will write efficient and effective machine code.

        There is absolutely no reason to expect that. There are a lot of reasons to expect the converse. And, apparently, you have not heard that LLM-generated code needs careful review. Much harder to do that on machine code level.

  • Can we top this click bait article title this week?

  • Raise your hand if you have programming in machine language - entering binary directly into memory. Raise your hand if you have programmed in assembly. Raise your hand if you have programming low-level stuff in C.

    The first question will have the fewest takers, because there is almost no reason to do that anymore. Assembly will have a few more takers, low-level C a few more. Technology has progressed, our compilers, optimizers and linkers have gotten better.

    Historically, there have been numerous attempts

    • Re: (Score:2)

      by timelorde ( 7880 )

      I have. I still have some of the 8085 call/jump/return opcodes memorized. There were times when it was much faster to patch in a fix and continue, rather than stopping to change the assembly source, run the assembler and linker, and re-download the executable into the in-circuit emulator.

      Then again, that was in the early 80's.

    • Re: (Score:2)

      by gweihir ( 88907 )

      The problem is that CPUs, assemblers and compilers all come with a spec and assurances. LLM code may be arbitrary broken. Hence they are the wrong tool for the job.

  • AI has been trained on human data, and is optimized for replicating human behavior. And so far, coding with AI follows the same principals as coding with humans: You need to be clear on what you want to achieve. You need to leave enough room for alternative solutions. You need to be careful to give enough context, but not too much. Therefore I think AI won’t perform that well when you let it work on abstraction levels it’s not trained on. And humans need high level specifications and code th

  • Compilers should adapt too (Score:3)

    by rknop ( 240417 ) on Monday March 23, 2026 @09:38AM (#66056016) Homepage

    If we go this way, then we should also adapt compilers to include random variation in the code that they generate, so that the same source code on the same version of the compiler won't always produce the same output.

    You now, if LLMs are the golden standard for how we want all the world to work, we take the things that are really bad ideas for programming in LLMs and implement them in our compilers too.

  • Question 1: Will AI make some languages evolve? Yes, very likely.
    Question 2: Will AI make some languages go extinct? Yes, very likely.

    These things happen with or without AI.

    Anybody remember ALGOL? It was a C-like language that was used to write the Unisys mainframe operating system. It's pretty much extinct today.
    Simula anyone? It was a big deal in the 1960s.

    The point is, languages go extinct all the time, for many reasons. AI will lead to more extinctions, but this won't be a new phenomenon.

    Languages also

    • These things happen with or without AI.

      If these things happen with or without AI, then how is AI going to cause languages to go extinct or evolve? You've basically nullified your own premise.

      Anybody remember ALGOL? It was a C-like language that was used to write the Unisys mainframe operating system. It's pretty much extinct today. Simula anyone? It was a big deal in the 1960s.

      And? I fail to see how one of the earliest programming languages last made for machines in the 1960s demonstrates your point. Better languages were invented; hardware has changed.

      The point is, languages go extinct all the time, for many reasons. AI will lead to more extinctions, but this won't be a new phenomenon.

      You have yet to demonstrate AI will be the cause. You have made the assertion and then declared it to be true.

      Languages also constantly evolve, at least, if they are being used. Would AI cause this evolution to change in some way, compared to the evolution that would happen without AI? Perhaps. How would we tell the difference?

      Again you keep asserting a premise then declaring it true without any

    • Re: (Score:2)

      by Junta ( 36770 )

      I doubt that AI will particularly drive changes, since the whole point would be that the LLMs don't care and can work with the languages as-is.

      The languages evolve and go away because of human motivations. Maybe a toolchain had a proprietary lock and associated with a business that went south. Maybe the language was a bit overly verbose and people didn't feel like dealing with it. Sometimes it's more like fashion than reason with how they go unpopular and back, maybe because some rabid fan implements a m

  • Some kind of token format could be used for AI which would be converted to human readable text when necessary.

    At the current state of AI I am pretty sure that it would be a bad idea to do away with human readable code. AI just not as reliable as we'd need for that. But I won't rule out that AI could become good enough for that.

  • I can't wait to fly on a plane with AI generated flight control systems. After all, what possibly could go wrong?

    Maybe I'll wait until Elon uses only AI generated code for all SpaceX vehicles first.

  • nonsense (Score:2)

    by Tom ( 822 )

    Will there be an AI-optimized programming language at the expense of human readability?

    Why? We already have machine code. What could an "AI-optimized programming language" do that neither machine code nor current programming languages already do?

    "Could we get our AIs to go straight from prompt to an intermediate language that could be fed into the interpreter or compiler of our choice?

    Uh, you can do that today. That "intermediate language" is any programming language that has enough stuff on the Internet that the LLMs have trained them.

    Now whether or not that's a good idea or a recipe for desaster is an ongoing discussion. As a security professional, my take is simple: Thank you AI, my job is secure until I retire. Just when techni

  • Codex whined a bit about the ARM not being as easy as ELF, but after consulting some online resources it ultimately succeeded. I don't believe it could handle anything with real complexity.
  • Thought just occurred to me that you could hypothetically write code as a sequence of prompts, so the code becomes even more high level. And could be regenerated using the prompts as source Lot's of details as to why it wouldn't work most of the time, but hypothetically source code could become even more high level

  • Then shouldn't they produce clear, self-documenting code?

  • This is a prime example of what I worry about with AI, who owns and controls it. Putting aside the current technical limits AI can already do useful stuff and that will only increase, as this news explores. However the thing most AI solutions have in common is the are owned and run by a large resource rich corporation and the role of average person is to chose to whom they will pay for AI access to and how much they are willing to pay.

    In most of human history people have had the choice to do things the
  • Same with source code. Although the repetition gets worse each time, with a side of spaghetti.

  • Engineers own the code, not the prompt. (Score:3)

    by Hamfist ( 311248 ) on Monday March 23, 2026 @05:27PM (#66057298)

    In our practice we are maintaining the principle that we own the code. While the prompts help us develop the code, the ownership responsibility for the resultant code still rests with the human. Thus our development approach needs to adjust how the agent delivers the code so that it is still comprehensible and auditable.

  • Seriously, what kind of a stupid question is that. But LLMs may make it clearer that you need people that actually can code well or you will be losing money.

Slashdot Top Deals

My idea of roughing it turning the air conditioner too low.

Close