9 ms·

Linus Torvalds regarding the Linux kernel is reasonably similar. He views AI/LLMs as just another tool in the development process. Think about life before and

• bigstrat2003 1mo ago
  Except LLMs actually are making programmers dumber. I personally know people, people whom I know for a fact were good programmers before, who have now completely stopped using their brains. When you ask them why they did something in the code, they say "I don't know, Claude did that and I didn't really question it". There was no such analogous phenomenon with IDEs.
  • winrid 1mo ago
    They're not dumb. They just don't care. They didn't before either. Now they just have an easy excuse.
    • bigstrat2003 1mo ago
      They cared enough to do good work before, so I don't think that your explanation suffices here. From my observation (not just with their programming but in other interactions), it truly is that using an LLM has made these people less intelligent than they were before.
      • fidotron 1mo ago
        There was an increasingly scary mass of people in the industry that viewed the coding as a sort of therapeutic exercise, and would become quite obsessive about it. For those people LLMs are anathema because they take away what was the rewarding part of the job. If you care primarily about the quality of the end result, as opposed to being attached to a particular process of achieving it, then you're happy about how things have gone.
        • Sharlin 1mo ago
          You find it scary that people enjoy what they do? Simply caring about the end result is often not wise, ethical, or sustainable, and the quality thereof is dubious in any case, especially when you consider that the end result of developing software is never just the artifact.
          • fidotron 1mo ago
            Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy. And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site. This is quite distinct from enjoyment.
            • trelbutate 1mo ago
              People who simply enjoy coding (without treating it to be "therapeutic") are still unhappy because working with LLMs is just not the same, and not rewarding in the same way
            • aleph_minus_one 1mo ago
              > Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy. > And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site. I know that experience, but I do have a different opinion on this: Many such people studied computer science (a similar point holds for mathematics, physics and some engineering disciplines) because they love coding. Unluckily, the job that they got does involve barely any clever coding, but rather - tolerating and gluing together shitty code pieces that someone else wrote - tolerating red tape So, such people simply do in their free time what they love. And to come back to my point "similar point holds for mathematics, physics and some engineering disciplines": these people try to use their little free time to prove some novel theorems or put their shed full of machines like 3D printers, CNC mills, CNC lathes, laser cutters, self-built pick-and-place machines, ... to work on their own beloved engineering projects.
      • bodge5000 1mo ago
        A friend of mine, really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money. Not too long about, programming went through a very similar phase. To be clear its not that I think programmers or lawyers shouldn't make good money, they absolutely should and it is deserved, its just it has the unfortunate side effect of attracting people who don't care about the field itself. For those people, they care as little as they can get away with and still be paid big money, and if LLM's allow them to do that at the cost of quality, they absolutely will. I do think LLM's are making some genuine programmers less intelligent, but I think this type of person makes up a decent portion of its users too
        • asveikau 1mo ago
          > really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money. Sorry to say this, but he doesn't sound like a nice guy.
          • bodge5000 1mo ago
            I can say with a great degree of certainty that I know him better than you would from half a paragraph. Would you like to think that someone would judge your character from so little?
            • asveikau 1mo ago
              I would not study law with no interest in justice, being motivated by megabucks. This is sociopathic. People judge me for less all the time and I usually don't care.
              • bodge5000 1mo ago
                I don't think my friend is a sociopath. Perhaps 0 interest in justice is an exaggeration, or a matter of perspective, more like an average interest in it. At the end of the day, he took a career path for the same reason most people do. I can see why if you're deeply passionate about your field that can be annoying, but "sociopath" is really quite an extreme judgement > People judge me for less all the time and I usually don't care. Maybe its a case of "takes one to know one", but isn't this literally what a sociopath is? You act without caring what people think. I don't usually like to say that about a person I don't know but clearly you won't be affected by that.
    • sisyphus15 1mo ago
      Completely wrong generalization. I'm a person who is over-reliant on LLMs, doesn't know how most of the things in the codebase work, and is atrophying both in programming and in general cognition. I used to care, a lot. And I still do.
      • yoyohello13 1mo ago
        If you actually cared. You’d do something about it.
      • collingreen 1mo ago
        Tell us more about how you caring a lot matches up with this self diagnosis. Are you prioritizing other things? Do you think losing your cognition and programming skills won't have a negative effect on your project? Those seem bad but maybe they fit into a bigger picture for you?
        • bodge5000 1mo ago
          I don't want to speak for them, but perhaps this is a very real consequence of the "use ai or get left behind" talking point. Maybe they were effectively scared into it, and now are too far gone. They seem like a very reasonable person if they're admitting to being over reliant on LLMs, so I don't mean this as an insult
      • ashton314 1mo ago
        What are you trying to do to halt that atrophy, then?
      • winrid 1mo ago
        Nope you just don't care to know. Stop making excuses.
    • deleted 1mo ago
      [deleted]
    • ssl-3 1mo ago
      I'm not dumb. I care a great deal and I always have. I've just never been good at programming. When I recently found a small bug in how NTP is implemented in Home Assistant OS that was affecting my use of it, I thought about just reporting that bug. But I set the bot forth to work on corrective measures, instead. The first proposed fixes were overbearing and awful. Maybe they'd have worked but it hurt my soul to look at them. I couldn't accept them -- not for my system at home nor for anyone else's. Through a laborious process (that many here could have skipped entirely), I eventually got what I feel is a cromulent fix down to a few lines of changes in an init script. I didn't write it. All I did was direct (and sometimes brow-beat) the bot, rejecting things over and over while optimizing at a high level until it produced an acceptable result. I now have a fix that is tidy-enough that it can be applied to running systems. It is easy to understand what it does, and why it does it -- even for me. Perhaps I should submit a PR... > They just don't care. They didn't before either. ...but this kind of blanket mentality really puts a damper on my willingness to do so.
  • aceazzameen 1mo ago
    It doesn't apply to everyone, but yes I know people who are over-reliant on LLMs and definitely getting dumber. With devs and non-devs too. I hate seeing this happen.
  • fidotron 1mo ago
    > Except LLMs actually are making programmers dumber. Make that some/a lot, but not all. There is a clear bifurcation. A lot of those that never cared really don't care now, but then you get others that can use it to crank that much harder than ever before. If you put the same brain effort in but leverage LLMs you really can be dramatically more productive.
    • b112 1mo ago
      Right! Exactly! You get it! Just like when Boeing decided that their QA process should be abridged to save wasted time and money! And that worked perfectly. (edit: rereading I think maybe you don't support not reviewing all of LLM code you submit, but the above was written with another impression)
  • vlyan 1mo ago
    IDEs enable us to not bother memorizing the number and order of arguments, long names beyond the first word or two, etc. the impact is comparable, freeing some of the very limited space in our memory for more important things. sure, students and juniors shoot themselves in the dick if they let LLMs do everything, but they're fucked anyway so it doesn't matter,
    • zaneyard 1mo ago
      With AI people aren't reading, writing, or thinking about the code. I would not say something that helps me remember a function name is comparible.
      • brookst 1mo ago
        I’m genuinely curious why it matters to make abstract moral judgments about the differences between remembering function names and deep understanding of the syntax used in a function. Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
        • AlotOfReading 1mo ago
          How do you trust the results of a black box that are hard to verify? Most of us use proxies that are easier to check, like historical competence and maturity. For example, it's difficult to verify my compiler produces a binary that correctly implements the code I wrote. I can partially validate the result with testing, but when I send it out into the world to handle unknown inputs I'm trusting that the compiler has done its job correctly. I can have that trust because I know the compiler people (in aggregate) have thought very hard about correctness, and the project is mature enough that bugs are rare. If the GCC developers tomorrow were to start merging anything that passed the test suite and some other list of objective metrics, my trust would rightly decrease.
        • deleted 1mo ago
          [deleted]
      • 1mo ago
  • rel2thr 1mo ago
    You can just ask Claude why it did something in the code and it will tell you Programmers just moved up a level , not dumber, we are now managers of a team of 'agent' programmers. The deliverable is now a functionality instead of a specific block of code
    • brookst 1mo ago
      Yep. I do so much work with Claude on product requirements and architecture before a single line of code is written, and test coverage is extreme. If I need to understand a specific line of code it means I did something wrong in planning or in requirements for testing.
      • fortzi 1mo ago
        In my experience it’s impossible to foresee all the micro decisions that reality will demand. IMO it’s one reason to not use waterfall, which is very similar to what you described
        • brookst 1mo ago
          No, waterfall is an engineering process. What I’m describing is thorough documentation of requirements (acceptance criteria, if you like), and then encouraging Claude to be agile in execution. As long as the outcome is well-defined, it is expected and normal to iterate on implementation.
    • ButlerianJihad 1mo ago
      > You can just ask Claude why it did something But will Claude give you an authentic rationale and a traceable, verifiable "line of reasoning" for those things? Or will it just construct the next plausible Markov chain built on whatever Reddit thread it ingested at random? You can ask Claude or any LLM for citations, and it will RAG them out ex post facto. Those actually aren't citations, they're just web searches for related articles, and they don't necessarily support the assertions that you're asking to cite. I am sure that Claude and the others can produce intermediate logs of their inference and "reasoning" process while they are processing stuff, but can they really go back within the context window and construct an authentic apologia for a specific thing when you ask for it?
  • hn_submit 1mo ago
    I just means I'm gonna be filthy rich in a couple of years when most programmers have lost their proficiency and me never having used Claude or any other A.I. slop tool.
  • newsomix9xl 1mo ago
    The LLM did not require them to ignore their code. That's a choice they made. They made choices that made them dumber is what I'm saying.
  • createful 1mo ago
    You could also say the same with desktops. Desktops abstracted CLI commands like mv or ls. People who are taught on desktops will get scared when they see a terminal. Yet programmers will still know commands. Abstractions can make things easier but it doesn't require losing skills.
    • inigyou 1mo ago
      Desktops don't abstract CLI commands. Both are different interfaces on the same thing underlying. Both coreutils and Windows Explorer are "abstractions" (as you call them, but they're actually interfaces) on filesystems.
      • createful 1mo ago
        Not CLI commands but system calls. Technically, in that sense, both commands and desktops abstract system calls. It's just that desktops handle a lot more than individual commands, aiming to make it easier for the user to use the computer. I call it an "abstraction" because that's what it is. Instead of you writing commands manually into the terminal, you use a program that calls it for you and does the hard work. That's what an abstraction is, you're abstracting away something by making an interface around it. All interfaces, as a matter of fact, are abstractions.
  • brookst 1mo ago
    There’s certainly an analogue to package managers, which made it easy to pick a random package rather than writing the code. We survived. Some upsides, some downsides, life continues.
  • digitaltrees 1mo ago
    I have had the same experience and feel pressured to adopt it. I had one former colleague say “you really have to stop looking at code” almost incredulous that I was uncertain about whether we should let models write really bad code and architecture that never would have been allowed in the before times. I will say when I let the agents go autonomous I often find I spend more time refactoring than if I had moved slower and forced them to write good code and follow project architecture patterns.
    • lrvick 1mo ago
      I use agents to build exactly what I want like I am pair programming with a jr engineer, and review every line of final output before I make a PR. I would have zero tolerance if anyone that did anything less in my orgs. Owning and understanding the code you submit is the one job that matters most now.
      • b112 1mo ago
        I feel that in a few years, or even less time, we'll see a whole bunch of companies implode, whist others remain fine.
        • deleted 1mo ago
          [deleted]
        • inigyou 1mo ago
          We should have already seen it. Software was slop quality even before AI. But we didn't see it.
          • b112 1mo ago
            The whole point is, it's 10x, 100x more slop now, if no one looks at LLM output. If no one reviews it. Context.
        • lrvick 1mo ago
          We see it every day in the news with hacks that were, in every single case, completely preventable. That is had any competent security engineers been involved, with leadership willing to fund the cycles to do it right. "But we passed SOC2 and that is all our customers care about" they say, right up until they are in the headlines for a data breach directly resulting from them putting all customer data in plain text internet facing databases the whole team can access from their workstations. What did they think was going to happen? Survivors bias is a hell of a drug.
  • lrvick 1mo ago
    > Except LLMs actually are making programmers dumber. And compilers made every software engineer worse at writing Assembly and better at skills higher up the stack. This will be no different.
    • b112 1mo ago
      No. Nada. Wrong. With compilers, you still had to think in depth about the code, write it, develop and maintain muscle memory, understand what you were doing. Many are not doing any of that, and coding is a skill you need to constantly practice.
      • lrvick 1mo ago
        > Many are not doing any of that I do. Most people sucked at programming before AI and they still suck after it. Who cares what "many" do. We as individuals can demand higher bars from ourselves and our teams. AI can increase that bar or lower it depending on how it is used.
        • b112 1mo ago
          And yet, you're in a thread discussing the people who don't look at llm output. And where you tried to claim that assembly -> compiled language, is the same abstraction as coding -> not even looking at LLM output. And then after I replied, edited your comment to change that context a bit. So as for ypur original assertion, in this subthread, no... not even remotely the same.
    • eudamoniac 1mo ago
      I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine. An example: 'read input from CLI, do this specific transform on it, send log with this text to external service, then output transformed data to CLI' is a program. Going up the abstraction levels from assembly to Ruby, you always know the "What" of the program, while you understand less of the "How" at each step. This is not the case with LLMs used in the common way. The problem with LLMs is that you no longer have a grasp of the "What", because you are not reading the code; you may have memorized the ambiguous English "What" that I wrote above, but that is not sufficient to understand the true behavior because English is not sufficient to represent it; it must be represented in a programming language. (What is 'read'? What is 'send'? What happens with errors?) By the time you have sufficiently represented the program in English to be nonambiguous, you've written more text than the code would have been, with just as much rigor. So LLMs represent a fundamental difference to traditional abstractions: the user has lost the understanding of what is actually happening, because they are prompting ambiguously, and thus they cannot possibly have a grasp of the behavior, because the behavior is not defined in their prompt. In other words, they are programming in a new programming language that has a ton of undefined behavior that just randomly happens. No one could understand the What of their program when using such a language, unless they compiled it to a nonambiguous language and then understood that instead. Of course it is possible to read and understand the code output by the LLM. It is even possible to build a whole knowledge graph in your head, as you traditionally would, and have a pretty full understanding of the whole thing. But, you are always doing this with the outputted code, not with the inputted prompts. The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. You don't have to read the assembly to understand your program, but you do have to read the LLM outputs. The other issue is that the above paragraph's process of understanding is discouraged. The time taken to fully understand the outputs approaches the time it would have taken to write them yourself, so is very rarely done, and that increasing rarity of understanding is what we are concerned about. The programmers are moving from an understanding of the program into an understanding of the JIRA tickets that produced the program; they are becoming product managers. The thing is, currently you still need someone who understands the program beyond the level of a product manager in order to retain maintainability and quality. Maybe in the future you won't, but right now you do.
  • hombre_fatal 1mo ago
    That's what delegation looks like, but it needs a better process. They could be committing plan files alongside any nontrivial change to application code, and the plan file can have everything you'd care about, like the invariants it held to and why, the rejected ideas and why, the acceptable risks and why, etc. This is solved by better usage of LLMs, not less. The divide to me isn't engineering skill vs those who lost it, it's people who care vs. those who don't care. It's a higher level thing now that we're working at a higher level (delegation).
    • 1718627440 1mo ago
      Delegation implies a specification and responsibility, both with don't exist for LLMs.
  • surajrmal 1mo ago
    That's a cultural thing. Push back on it and don't make it acceptable behavior. I would argue most people generally are terrible at code review and do this same behavior with their peers as well, but at least their peers are capable of owning some level of responsibility, whereas the LLM is not.
  • greenowl 1mo ago
    I think LLMs make programmers lazy more than anything. And when programmers stop programming for extended periods, they lose their programming skills. No surprise here. Use it or lose it. I think a possible solution on both fronts (maintaining software quality, preventing skill atrophy) may be implementation of strict token budgets. Make the individual programmer choose how they are going to spend their limited tokens for the day/week. Provide just enough to use it as a plan/development/review tool, but nowhere near enough to just go full send AI vibe coding software factory slop mode all day long.
  • a34729t 1mo ago
    It is insiduous how easy it is to stop thinking. When writing complex code it seems like most of the time it would have been faster just to write it myself and build a complete understanding of it. I swear if I asked most engineers at my company to describe their changes recently they would be unable to.
• inquirerGeneral 1mo ago
  [dead]