Why I will not be using LLMs in my coding

This sounds like, “I’m not going to buy any food at the store at all; I’m going to toil the soil for any nutrient I put in my mouth.” Cool story bro, but it sounds like you are trying to convince yourself. See you back here in a month, or so.

• mathgeek · 17 hours ago

  That's because the history of new technologies, new tools, etc. is one of resistance from those who knew how to manually do what the technology enables for more folks. Sometimes it works out well for humanity, other times the technology fades into obscurity or is quickly replaced by something else, but at the time the pushback on both eventualities looks the same. We'll see the same for automatic freight movement in the next few years, as just one example.

I was a competitive programmer, coded non-stop in many languages for 15+ years. I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever. Not sure how I feel about it

• xyzsparetimexyz · 17 hours ago

  If you don't look at the code, how do you know it's higher quality than ever?

  • eulgro · 17 hours ago

    Competitive programmers don't usually produce quality code, I'm guessing it could hardly be worse even without looking at it.

    • XCSme · 17 hours ago

      That's true, code is usually shit but the result/outcome really good and performant.

    • sabas123 · 17 hours ago

      They do produce code optimizing for a different goal. But readability is often not one of them yeah.

  • shmoil · 17 hours ago

    He must have been a really bad coder.

  • rvz · 17 hours ago

    Claude told him so.

  • XCSme · 17 hours ago

    I simply test the final result,manual tests, automated tests, benchmarks, people using the apps and giving feedback, increased number of sales, etc.

    • mzhaase · 16 hours ago

      Here is something I found this week: copies the entire db to memory, inserts a single row into in-memory db, deletes everything from real db, writes everything back. Sentence that caused this is "do XXX in one transaction". All tests pass, everything seemed to work. Would not have noticed of I didn't read through the code. Amount of other stupid shit I found is crazy.

      • ricardobeat · 16 hours ago

        These anecdotes mean little without knowing context, model, harness, prompt. The technology has moved a lot in the past year, and does require some adjustment. My very first experience with OpenCode led to a `rm -rf /` within minutes, which I caught by chance watching the output stream in. Yet 99% of my code is currently written through an agent.

        • xigoi · 14 hours ago

          Ah yes, the favorite response to any criticism of LLMs – you are using the wrong model.

      • XCSme · 16 hours ago

        A performance benchmark would have easily caught this though, ask the LLM to create and run benchmarks and see how those change after each new feature/major change.

        • verdverm · 16 hours ago

          I have found test coverage reports to be really helpful as well.

  • XCSme · 17 hours ago

    Also to make it clear, I am not saying the code itself is better, but the end-product and what the user sees and gets. Like that saying "if it's stupid, but it works, then it's not stupid"

    • sixtram · 15 hours ago

      for you, "if it's stupid, but it works, then it's not stupid." for me, if it's stupid, but it works, then it's a coincidence.

      • XCSme · 14 hours ago

        I think LLMs themselves are a good example of "it's stupid but it works"

  • noosphr · 17 hours ago

    A programmer's output was never code. It's was just what we had to do to get computers to work for us. Now I just ask a genie to do what I did and check the results.

    • xigoi · 14 hours ago

      Good for you. I prefer to communicate with computers using an unambiguous language that describes exactly what I want them to do.

      • noosphr · 10 hours ago

        Ah, a connoisseur of machine code.

  • jstanley · 17 hours ago

    How do you know it's high quality if you do look at the code?

  • Someone1234 · 17 hours ago

    Because the exact same processes that create it faster, are also now generating large comprehensive test suites, and data-validation suites based around the actual business requirements and data/edge cases. In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation). So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."

    • bakugo · 17 hours ago

      How do you know those large comprehensive test and validation suites you've never looked at actually reflect real user experiences at all?

      • Someone1234 · 15 hours ago

        You must have replied to the wrong comment, since the one you did replied to never claimed that the test and validation suites were "never looked at." They are reviewed, and the test/data results are reviewed. It said verbatim: "Don't trust. Verify."

    • verdverm · 16 hours ago

      > Because we have test result data that PROVES it to be the case. pgrust thought this too, but then another human discovered claude had hardcoded benchmark query plans. Now pgrust has a "test" [1] to make sure the Ai doesn't do this again (unless it decides this test is bad for the current goal) I have a growing list of these, another notable one is OpenCode having a security regression [2] because the Ai redesigned configuration loading for v2. Real verification seems beyond transformer capabilities. [1] https://github.com/malisper/pgrust/blob/38634b408dea373f3944... [2] https://github.com/anomalyco/opencode/pull/54921

    • mzhaase · 16 hours ago

      Yeah but you don't test for stuff you don't know you have to test for. All tests can pass and internally its still done in a braindead way that will explode at some point.

      • Someone1234 · 15 hours ago

        Absolutely, and this is exactly why humans are weaker than LLMs. We consider what is likely, they consider what the data/logic shows is possible. So you get edge cases tests/flagged, that wouldn't even be something a real person would know to look for.

    • springtimesun · 16 hours ago

      This is my observation as well. I thought I was good at testing (I wanted to be good at testing), but the models are just better at it. Testing in particular rewards a tireless cataloging of the tiny and the tedious and in this respect LLMs are unmatched. Single data point, my Sentry notifications across more than a half dozen client projects when from 2-4 a month to basically 0. That's while shipping 20x _more_ code.

  • weego · 16 hours ago

    Very little code written in the world day to day ever has to justify its 'quality' or long term value. A lot it is just one off tools, bits and bobs to make a teams life easier or whatever. I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are. Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown. The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.

• npsomaratna · 17 hours ago

  International Olympiad in Informatics (IOI) Gold Medalist here. I too did competitive programming for years. I pride myself on writing beautiful code that is succinct, effective, and efficient. Yet I find myself using AI coding agents more and more. In this day and age, your choice is to either use them, or be stomped into the ground by programmers who do. AI still can't write code at my level of quality, but it can do so at adequate quality now; and sadly, that is "good enough" for the real world.

  • alfiedotwtf · 16 hours ago

    > or be stomped into the ground by EXPERIENCED programmers who do FIFY. I've found experienced devs with AI is a force multiplier, but AI in the hands of juniors however is my hovercraft is full of eels.

  • glimshe · 16 hours ago

    I've made many friends and acquaintances over the years who are top notch, some world class, programmers. I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already). I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it. Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases. This is purely anecdotal but I'm starting to notice this pattern everywhere I look.

    • sdiupIGPWEfh · 15 hours ago

      All I want is an explanation of how you're all reliably getting good enough (or better) results from LLMs. Surely us AI critics are doing something wrong, something much more specific than needing to "prompt harder", if we accept the framing that 90% of world class programmings are achieving that, while the rest of us are not. There simply has to be some specific, repeatable, and yes, teachable thing we're missing. So what is it?

      • koonsolo · 15 hours ago

        Most senior developers that steered juniors or interns in the past, are able to work with LLM's. Sure, LLM's are unreliable. So are juniors. Sure, LLM's code quality is not always great. Well, so is the juniors code. The benefit of LLM's is that they can work super fast and have a vast amount of knowledge. The benefit of juniors is that they actually learn from their mistakes and get better over time. LLM's stay at intern/junior level, even with the correct context. So for me, I see each LLM session as a new intern coming in. You hand them the right context, give them the correct instruction, and off they go. Then they come back, and you will have to judge how detailed you want to review what they produced. Or in other words, can you get away with some bad code? And for the next session, it's a new intern that starts from 0. But it is also highly dependent on the project you are working on. If it's a big complex codebase, LLM's will struggle, and they can only do simple tasks (however, they can help with testing a lot!) So the teachable thing is unfortunately experience: - Know where quality matters, and where it doesn't - Know what kind of mistakes could be made and should be checked for - Know which things can be duck-taped together, because they live at the edge, and which things need a proper foundation, because the rest builts on it. So in the end, I think it all comes down to making the right trade-offs and the right decisions (which LLM's are terrible at, by the way). And unfortunately that is gained by the slow process of experience. I think it's very tough for junior developers right now, because they either go fast by letting the LLM's do the work, but then they learn nothing. Or they go slow by asking the LLM's what's going on, and then do learn. A senior developer never understood the full code-base, and never reviewed every line of code. That's just impossible. And now every developer needs to be a senior developer that is able to steer these new "interns". And just like with juniors and interns, you have to put a lot of effort into it, and it's not always clear in the end if you gained or lost time :D.

        • em-bee · 14 hours ago

          LLMs and juniors are not the same. i made this argument on a previous discussion of the same topic: https://news.ycombinator.com/item?id=48212898

          • koonsolo · 14 hours ago

            I don't claim LLM's and juniors are the same. I claim that working with LLM's and juniors are similar. If you are able to work with juniors, you are probably able to work with LLM's. To comment on the post you linked: I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist). Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing. Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.

            • em-bee · 10 hours ago

              I don't claim LLM's and juniors are the same. I claim that working with LLM's and juniors are similar. i meant "working with" as i explained in the linked comment. the feedback and response i get from juniors is very different from an LLM. and yes, sure every junior dev is different from the others too, but i simply enjoy working with people so i can handle that but i can't stand working with machines in the same way. what bothers me about LLMs is that they are not deterministic. that just drives me nuts. i do enjoy learning the ins and outs of a language or compiler to figure out how to write the code to get the results i need. but LLMs just don't work like that. the same instruction that produced good working code today could produce nonsense tomorrow. this is not about quality. this is about trust. i can't trust LLMs and that makes it very uncomfortable for me to work with them.

          • unethical_ban · 12 hours ago

            One thing that stood out in that comment: You said "you like" the act of programming elegantly and understanding the problem. There's nothing wrong with that. Many of us do (or did) like programming and the problem-solving itch it scratched for us. But getting work done for pay is more than what we like. If an LLM can reliably solve a problem for me in a day that would have taken a project, a team of several people, and close to a month of work to build out manually, then I go with the tool that works. And that "if" is the reality I live in. About a decade ago, I wrote a program to do analysis of config files for a product our team uses. It took me weeks of side-work to implement the idea of passing boolean python functions as checks for the configuration. Such an elegant way of creating new checks on our system! It was company work, and when I left to a new place, I didn't have that code, just the idea. Fast forward five years and I want to write the same thing at a new place. I asked an LLM to do the same task, and it wrote exactly my solution immediately. It just worked. It shocked me. In the last few months, I've had it write analysis tools against this product that would have taken me days or weeks. I am admittedly not a comp-sci level programmer. There is no denying that LLMs are powerful coding tools. That can be true at the same time that we lament the end of manual-coding-for-pay, the death of programming education as we know it, and the worries about employment and society.

        • popkkksidhd · 11 hours ago

          > A senior developer never understood the full code-base, and never reviewed every line of code. No, but when a junior puts up a PR I do. They aren’t trustworthy enough yet. One of the biggest parts of being senior is ownership of your code and knowing you’re putting your trustworthiness behind every PR you make. If you’re making bad PRs, you can’t say it’s Claude’s fault because you didn’t think a certain area was worth reviewing. > That's just impossible. Somewhat, but this is directionally bad advice. There’s huge payoffs for taking time to thoroughly understand areas you’re working in. It greatly amplifies your ability to prompt and overall execute in a codebase.

        • sdiupIGPWEfh · 4 hours ago

          If I was told that, as a senior, writing code was now a waste of my time and I could only contribute by telling juniors what to do and reviewing their code, I think I'd have lost my mind years ago. Just like you say, at least any junior worth retaining will learn, maybe even excel beyond me in some particular niche or other, and establish trust and rapport. Claude, on the other hand, may behave like an expert on some matter one day and act like an idiot in the same area the next, so how can I give in to trusting it. Unless I'm doing something wrong and it's on me. The mandate is no more hand-written code. The claim is that if I'm any good, I should know how to squeeze consistent quality results from LLMs. The reality is that I find continuously arguing with and correcting a chat bot all to be mentally intolerable. I'd very earnestly like to understand if the problem is me and what I can do to change.

          • koonsolo · 12 minutes ago

            > Claude, on the other hand, may behave like an expert on some matter one day and act like an idiot in the same area the next, so how can I give in to trusting it. That's why I say: every session is a new intern. That's how I look at it. > The claim is that if I'm any good, I should know how to squeeze consistent quality results from LLMs. Claude Opus 5.5 can write decent code, better than most juniors I came across, and definitely codes faster than me. But is that quality high enough for your standards? It sounds like no. So then the next question is, does your project really require your high standards?

      • sadilek · 13 hours ago

        Try requesting a feature from Opus 5.5 high that would take you a day or two to implement and test well. It'll work for 20-30 minutes or so. Then ask it to review the changes with a sub agent of itself and with Codex Sol 6.1 high. Then let it address the findings and iterate the review/fix cycle until the reviewers are happy.

        • sdiupIGPWEfh · 5 hours ago

          I will at least acknowledge that having full freedom to mix models according to which balance of strengths / speeds is appropriate to the task does help, both in terms ultimate quality and reduced review iteration. I won't go so far as to say it eliminates all headaches, but I'll take what wins I can get. All too regrettably, that's no longer an option at the day job, with managers wanting to move to a single standardized vendor.

      • unethical_ban · 12 hours ago

        Anecdotally, for small tools and projects, it can crank out functional tools that would take me days or weeks to remember how to do manually. Every time I ask LLM to write something, it also writes tests and validates its code against known values. I additionally spot-check the LLM's code against my own known values in prod, and have had to correct it on some functions. The code I write is mainly analysis of logs and configurations, and they seem well trained on the products that I am using. Testing. It's all about having unit tests, and known outcomes that the LLM can check against every time it makes changes. For my work, that is good enough. For safety-critical systems I would demand more rigor in the testing and the human review and creation of tests.

        • sdiupIGPWEfh · 4 hours ago

          Do you write the tests yourself? Or at least thoroughly read and understand the tests?

      • ObiKenobi · 12 hours ago

        There are Addons for IDEs like "AI-Autocomplete". When you don't want the AI to write whole features at once, you can prompt it to write the functions one by one and work like that. Still a lot faster then writing all functions by yourself and granular enough that it is easy to describe and easy to review.

      • baggy_trough · 12 hours ago

        My best explanation is that AI coding critics have a kind of willful blindness or fall prey to motivated reasoning.

      • Garlef · 3 hours ago

        Don't ask for the result that you want but ask for the code that you want.

  • swat535 · 15 hours ago

    I feel like code quality is important when humans have to reason about. However if the future is machines managing the code then all that matters is AI understanding it. The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans. I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..

• raincole · 17 hours ago

  I insist on reviewing every line of code. But in the last few weeks I realized that LLMs are simply better than me at reviewing code too and I'm just finding excuses to not do the real work, which is to write more prompts.

  • 0c3ca83 · 16 hours ago

    Have you considered asking them to write the prompts?

    • raincole · 16 hours ago

      I have been asking LLMs to review/edit prompts since GPT4o era, so I really don't know what the point of this snarky comment is. Since GPT4o, I have been convinced that most of the digital work would be done by AI and humans' job is to "move the chairs around to not block AI's way." It's a given to me. I'm just debating whether reading the code makes me a better chair-remover.

      • cudgy · 15 hours ago

        Don’t think it was snarky. My guess is op is just suggesting that you could automate further, but you are ratcheting toward it one step at a time while op is suggesting to allow the ai more autonomy.

  • apothegm · 3 hours ago

    I find LLMs are better than humans at finding bugs in code review. But humans are bad at finding bugs in code review in general. That’s not what a good human code review accomplishes. A good human code review takes into account the broader business context and the structure of the codebase. It finds instances of poor design or readability. It suggests patterns or existing utilities that the author didn’t make use of, and points out antipatterns. LLM reviews are a great first line of defense against certain classes of bugs. But I consistently find major issues in code review that the review bots miss — and some that they couldn’t have caught under any circumstances. Just last week: 800 lines of unnecessary (and clearly LLM-written) code with high cyclomatic complexity that could be easily replaced by 50 lines of mostly declarative code by using existing patterns and utilities; several missed opportunities for converting incoming data to native types up front upon receipt and enforce stricter typing, rather than passing around things like dates or UUIDs (or even basic numeric types) as strings and trying to parse them over and over; and a case where the author had misunderstood which of two possible sources certain data should be derived from, resulting in subtly incorrect data being saved to the system of record.

• verdverm · 16 hours ago

  > Not sure how I feel about it A phrase I've been toying with is eyes free vs hands free coding. The distinction is important. While I too hardly write code these days, I do continue to make smaller changes and look at what's being done. This is as opposed to the group who has decided vibing mega commits is a good idea.

  • XCSme · 16 hours ago

    I am not doing small changes though, I add large features or refactors daily, which involve changing hundreds of files and thousands of lines, even if I wanted I couldn't review everything by hand.

    • verdverm · 16 hours ago

      I have done this too, for side projects, but I see the limits. Discovering what happens when we do this was one of my intentions and why I hold my opinions. For these projects I make regular time to look through the code and do cleanup phases.

    • nvme0n1p1 · 15 hours ago

      So you're saying simultaneously, the code is "higher quality than ever", but you also haven't even looked at the code to see its quality. Classic. I think you're mistaking quantity for quality.

      • verdverm · 15 hours ago

        I think they are saying they are using proxies for project quality, like features and test coverage

      • XCSme · 14 hours ago

        I mentioned before, code is definitely worse, but end product is better. High quality code doesn't always lead to a high quality product. And bad code doesn't always lead to a bad product.

      • munksbeer · 11 hours ago

        If a product functions correct and performance is good, and AI agents write and maintain all the code, no-one has to care about human level code quality. The concept of "code quality" was only invented to make it easier for humans to understand and change code.

        • XCSme · 8 hours ago

          That's a really good point. Most good or bad code, and all the best practices came usually from the perspective of having the code be readable and maintainable by humans long-term. And performance is easy to test automatically by having performance benchmarks automatically ran on deployment.

• 0c3ca83 · 16 hours ago

  I hear this all the time, but the software I use is becoming obviously buggier and less pleasant. It seems most people are bad at evaluating the quality of their work, especially if they purchased it from Anthropic.

  • koonsolo · 15 hours ago

    I think there is a big industry push on "use AI to deliver features faster". It could have also been a "use AI to test our product more", but I don't see that anywhere. I hope you agree LLM's can actually help with quality, if used for that purpose?

    • 0c3ca83 · 13 hours ago

      Who cares about the theory? The fact is that the world is now worse due to LLM use. And it's not just restricted to software. Everything I care about is getting worse. Dribbling about how it could theoretically be better doesn't help undo the damage. "Imagine how much fun we could have playing baseball", says the man with the baseball bat, as he kneecaps you.

      • koonsolo · 25 minutes ago

        For your own projects you could make use of AI to increase the quality.

  • munksbeer · 12 hours ago

    We use AI to write almost all our code in a fintech - trading applications. If the quality is low, bugs cause monetary loss. Degradation in performance causes monetary loss. And so on. It doesn't happen. We have very good functional and non-functional testing and the coding agents are able to iteratively add functionally correct features and improve performance. I don't understand what other people are doing differently to get worse results. We cannot ever go back to humans writing this code, because our competitors will eat our lunch if we do.

• rvz · 16 hours ago

  > I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever. Well that doesn't make sense if you are writing code that is going to be used on critical infrastructure. Imagine a disaster were to happen and you said to the auditors that "I don't know what I am doing nor did I look at the code" and you cost the company tens of millions of dollars. Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality? Don't you see the contraction you just did there?

  • cameronh90 · 16 hours ago

    There’s a huge gulf between toys and critical infrastructure.

  • MichaelRo · 16 hours ago

    "didn't even look at it" is a giveaway of the OP being a liability on top of a boaster and the company who employs him deserves to go out in flames Wonder if he tells his boss to "I pushed critical code to production without even taking a look at it" or is it just for show on HN

  • XCSme · 16 hours ago

    Indeed, I am just building apps people use, they are not "critical infrastructure" and the world won't end if there's a small bug, I don't vibe code self driving cars, defense systems or medical devices. A If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time. Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.

  • bluecalm · 16 hours ago

    LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing. Tests are written faster too so not only you have more time for testing but also you can use it better. >>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality? >>Don't you see the contraction you just did there? I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it. That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.

    • rvz · 14 hours ago

      > LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing. So does that mean you should never look at its code? If a fault in the software occurs even after testing and there was an investigation, will you admit in the postmortem report that you did not look at the code at all and blame the agent for the error? > I wouldn't trust anyone who refuse to use LLMs for programming. Did I say I refuse to use LLMs for programming? I am telling you to check the agent's work. I would not trust anyone who DOES NOT check the changes of an agent's code when using them for programming in highly regulated industries or in critical systems. For most companies in the Fortune 500, it is irresponsible to not check. > That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago. No-one argued against that and it does not mean that you do not check with the agent at all even if the agent believes that they "fixed it".

• fps-hero · 16 hours ago

  AI is a hammer, problems are the nails. At the end of the day, you still need someone to swing the hammer. Aside from the occasional overstretch of scope and “reining it in”, the real bottleneck is humans. We have more freedom than ever to build whatever we dream of, you still need a dreamer. And that’s why the profession of coding isn’t going away, you still need people to turn ideas into reality. I find AI soulless, it’s great at mimicking but is incapable of coming up with an original idea that wasn’t yours regurgitated.

  • cudgy · 15 hours ago

    But will we need fewer people is the question.

• pleasethinkforo · 15 hours ago

  When am I (as a user of a lot of software) going to start seeing any results of this unprecedented productivity gain? This thread is full of 100x supercharged programmers, so why is it that I can't name a single useful feature added in the last 5 years in e.g. macOS, Windows, Firefox, Chrome, YouTube, VS Code, YouTube, Slack, Photoshop, Word or any of the other 5 programs currently on my taskbar?

  • patrakov · 15 hours ago

    The productivity gain is invisible using your metric. What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.

  • XCSme · 14 hours ago

    Because the code is and almost never was the problem. Product design and business involves a lot more than code. Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.

  • scruple · 11 hours ago

    The productivity gains will go where they always go when a mature industry undergoes automation. We'll reduce headcount, ramp up the output expectations of anyone lucky enough to keep their job, and expand the operating margins for shareholders. None of this capital has ever been earmarked to build better consumer utilities.

I have the personal rules regarding LLM coding: - Try to prove the concept early on. When you start spinning in circles, then it might be time for a different approach - I’ve had a lot of success with projects that have not started out as LLM codebases. And adding features one by one and testing really carefully by hand - UI generated by LLMs are overly verbose. The key lies in the iteration. What you can cut, move or approach differently. But you have to have taste.

That's kind of audacious, for a php programmer

• phoronixrly · 17 hours ago

  I can say the same about any opinion of an LLM 'programmer'

• hoppp · 17 hours ago

  Yeah, when I saw PHP it made me question everything. It's the language I hate to write the most.

LLMs and generative AI took what means to be a human away for many, not just programmers. The upcoming unrest will be fascinating.

• hoppp · 17 hours ago

  If they can take away your feelings of what being human is so easily then you should have taken care to develop it better.

  • alexpadula · 17 hours ago

    Oh I'm fine but people around me aren't and that's from accountants, to writers, to artists(music, drawing, animating), look around you. I'm the kind of person who doesn't buy bread, I bake everything from scratch, AI won't take a lot away from me, I'm a lover and creator. I do worry though, it may take everything in a way eventually, that's the sad part if you think far enough into the future.

    • evanelias · 14 hours ago

      I'm curious, is your database work all hand-coded? Tidesdb is extremely impressive in any case, and I just saw Turborel which looks interesting. Your commit rate is pretty intense -- speaking as a hand-coding dinosaur myself, if this is all by hand too I'm now even more impressed (and a bit jealous for your level of productivity!)

      • alexpadula · 11 hours ago

        Thank you, also less and less which is what scares me. I use LLMs like everyone else on things I've been wanting to build for years, Turborel is that, TidesDB is that baby you started pre-llms and don't want to effect but PRs coming in are good and you're like WELL.

  • ZnerflBerp · 17 hours ago

    Lots of people define themselves by their work. Might be able to indict that. Or that society made that a viable or indeed encouraged option.

    • hoppp · 16 hours ago

      I would blame society, yes. People need to reflect and find themselves instead of relying to their own automaticity to get them through life, stop and smell the flowers a little.

• ricardobeat · 17 hours ago

  I have a hard time understanding that position when it comes to programming. What is "human" about typing instructions for the computer into a terminal? Was perforating paper more human? And I say this as a programmer with 20 years of experience. The human part is the thinking and intention behind it, not the typing. When it comes to generative art, yes, that's a much more significant issue.

  • alexpadula · 17 hours ago

    Have you ever solved a problem with code? If you have, you will know why it hurts so bad to lose that ah-ha moment at that level. It's something special spending a long time on something, learning as you do it. I do understand you can get this through possibly an LLM, just different. Take a mathematician spending years on a problem. Seeing a computer do it in a matter of a second or "11 days", is devastating in a way.

    • ricardobeat · 16 hours ago

      Yeah, I used to get a kick out of building a perfect, performant, keyboard-accessible, a11y compliant and well-designed dropdown menu. Building my own rendering libraries. Making things run at 60fps. Optimizing server code, HTTP performance. Watch a full fleet of servers running my code in action. It was great. Now I get the same feeling out of building an entire component library in an afternoon, running my code in a Nintendo Wii with twenty minutes of effort, hacking a LED display that I bought for €5, writing a tool to update my keyboard that only supported Windows, or building projects that would take a team of twenty engineers in the past. We just got a power upgrade, the magic is still there.

      • 0c3ca83 · 16 hours ago

        This reads like "I used to enjoy making a home cooked meal for my family, but now I can buy ten off doordash in the same time". in the end it's just sad.

        • ricardobeat · 16 hours ago

          If we're going with cooking analogies - I really enjoy it, yet a good rice cooker was one of the best purchases I've ever made. That's a better parallel to me.

          • alexpadula · 16 hours ago

            A rice cooker? Is this a joke? Making white rice takes 10 minutes with a pot. Very confusing.

            • ricardobeat · 15 hours ago

              I know right? Yet, what I said is true, and you can ask anyone who owns one for japanese/korean/chinese cooking. It reduces effort to near zero while giving 100% consistent results. The point though, is that I don’t feel “sad” about not having controlled the temperature and time myself. It’s a tool.

            • dw_arthur · 15 hours ago

              I thought the same thing until I got a rice cooker. It makes cooking a little less stressful while you make the rest of your meal. I eat rice once every 1-2 weeks and I still love it.

          • 0c3ca83 · 13 hours ago

            Ah, yes, because just like a rice cooker, the work takes the same amount of time, it's just using less space on the stove, and is more reliable. Wait, no, a rice cooker doesn't seem to fit.

        • _aavaa_ · 15 hours ago

          Nobody is stopping you from home cooking however you want. Working in a commercial kitchen however is a different matter. But there again, nobody is forcing you to use LLMs. Cook however you want.

          • sdiupIGPWEfh · 15 hours ago

            > But there again, nobody is forcing you to use LLMs. In the sense that I can quit my job at any time, sure. But my employer certainly requires LLM use, and even if I found another position that doesn't, I have no reason to believe that will last.

            • _aavaa_ · 15 hours ago

              This is the commercial kitchen part of the analogy. Either you work in someone else kitchen based on their rules. Or start your own kitchen and you set the rules. I am not denying the lack of freedom when working for someone else, or that it sucks when they impose rules on you. But that’s always been the way it goes. The comment I replied to was about home projects and home cooking. Nothing there has to change.

  • trial3 · 16 hours ago

    assuming you yourself had programmed pre-LLM i completely fail to relate to your lived experience. what a devastatingly sad way of viewing the world setting aside the craft and mastery or satisfaction in goal accomplishment: to me the main thing is a sense of actualization, of the codebase or thing you were working on being better because you were there. have you ever put up a shelf? did it feel good after?

    • alexpadula · 16 hours ago

      Putting a shelf up is not fun. Designing, building the shelf from scratch with my own vision feels way better ;). It's a lot more of a hassle but you will always look at it and be like I did that, heck you might have even learn a whole bunch doing that as well. It's easy to go to the store, buy something and assemble it (automation).

    • ricardobeat · 16 hours ago

      I think this perspective comes from assuming that the LLM is doing the thinking for you. And that is not the right approach IMO. The code is still mine - I chose how to write it, reviewed changes, suggested improvements, picked the architecture, directed refactoring and benchmarking efforts, tooling, scope of tests, and so on. It feels quite similar to being a project lead.

  • SvenL · 16 hours ago

    Code can be art too. There are many ways to solve problems but finding this easy and elegant way which is just beautiful is marvelous.

  • twobitshifter · 16 hours ago

    Not OP, but all the choices made along the way are the human part. The understanding and creativity to solve the complex challenges that arise in an efficient way that fits into the structure of the greater program. Programming never has had one right way to accomplish a task, and that is disappearing with agents. Why would pick Ruby for a project because it’s nice for the programmer, when the agent is the one coding? In fact, Why would anyone ask an LLM to write a new program in almost anything other than JavaScript and Rust?

  • vbezhenar · 16 hours ago

    Downgrading programming to typing instructions is like downgrading mathematics to writing characters. This is not an issue. Nobody cares about typing instructions. If someone can click instructions or voice them, it all the same. Programming is about finding the right instructions. Not about typing.

• noosphr · 17 hours ago

  I'd say they took the inhumane parts of being a programmer away and people who spend 30 years turning themselves into robots don't know what to do with themselves now.

  • alexpadula · 17 hours ago

    That's a pretty funny take but you need to zoom out and look at other white collar occupations and then blue collar that will be cheaper to automate.

  • twobitshifter · 16 hours ago

    Programmers were just the first shoe to drop. The same is now coming for the entry-level engineers as agents learn cad programming which has the same complexity barrier to entry. We will soon trade that complexity barrier over to the agents and we won’t know how it is done, because the agents always did it for us.

• nickorlow · 17 hours ago

  I feel like LLMs are akin to a performance enhancing drug that's gained mainstream acceptance. Everyone can run a 5 minute mile now without training. I used to like training to be able to do that, but now that it's accepted everyone can do it for free (and people don't care if you did it the hard way) the joy has been sucked out of it a bit.

  • alexpadula · 17 hours ago

    Very much so. I feel like LLMs are even greater force than something like "steroids" which in the end are deadly if abused.

  • FeteCommuniste · 16 hours ago

    It's more like they are being carried in the arms of a big robot who is doing the running for them, but everyone has somehow agreed to say that the human "ran" a five-minute mile because they ordered the robot where to run.

  • _aavaa_ · 15 hours ago

    Except performance enhancing drugs are banned from sports because that’s how they want it to be played (it has nothing to do with safety, look at non drugs like the LZR Racer swim suit). If you wish to make software engineering your job then it stops being a game where we ban things simply because they provide an “unfair” advantage. If you wish to play at programming “the way it used to be done” then by all means go ahead. But mixing methapors between sports and work is not helpful.

    • nickorlow · 13 hours ago

      I think you grossly misunderstood my point. Just saying the hobby side of it is less fun because the effort part of it feels more pointless.

      • _aavaa_ · 13 hours ago

        I guess I don’t understand the motivation you have for perusing your hobbies. To me, the effort part only feels pointless if you want to accept LLM-derived code as comparable. Any marathon run is pointless, you go in a loop and we have cars. The point is to do the run yourself unaided. That a computer can play a virtual instrument better than me (and continuously better than anyone) has little bearing on whether or not I continue practicing on my piano.

        • nickorlow · 12 hours ago

          The world at large does accept LLM-derived code as comparable. The same cannot be said for driving v. running 26 miles.

          • _aavaa_ · 12 hours ago

            I think the analogies are not helping us. This started by comparing LLMs to performance enhancing drug being used within the same sport. But software engineer, as a job rather than a hobby, has always been about results. Hence my original point. Hence my confusion. I am not perusing my hobbies for “the world at large” I’m perusing them for myself; being able to drive 26 miles makes no difference to me nor to the others who wish to run it.

            • nickorlow · 11 hours ago

              I think many people derive joy from hobbies because they get a unique skill as a result of time invested. If the Philadelphia marathon started giving out medals to people who drive the course in a car, I think less people would want to run it.

              • _aavaa_ · 10 hours ago

                I agree, but they would move on to another marathon that didn’t hand out prizes to drivers. People who continue to do the hobby without LLMs will still get unique skills, like woodworkers who don’t use power tools. I understand that this is a loss for those who were pursuing programming as a hobby only as long as it gave them a unique skill and made them feel superior to others. However, for better or worse, I can’t bring myself to care about that.

                • nickorlow · 10 hours ago

                  Not sure how you got the 'made them feel superior' part.

                  • _aavaa_ · 10 hours ago

                    I’m not sure what other implication there is. Hobby programming without LLMs and you gain unique skills (you can do the work without power tools). Hobby program with LLMs, you gain unique skills again (you learn how to properly use these models and get to quickly iterate on your design skills). Regardless of what the big labs are saying, there is still a lot of skill involved in creating with them; if only because they don’t read minds so you have the get good at describing your taste and requirements.

                    • nickorlow · 9 hours ago

                      My point is in the former case, if the skill feels less useful, it just feels less fun. It's not a 'better than' thing.

                      • _aavaa_ · 8 hours ago

                        I guess I fundamentally disagree with that being a good metric by which to pick hobbies. I am not picking mine based on some economic expected value calculation, it's whether or not I enjoy doing the activity for its own sake.

                        • nickorlow · 7 hours ago

                          I guess it's hard to express over text, it's not an economic value thing, it's about being able to cultivate a unique and useful skill.

• nanapipirara · 16 hours ago

  As an illustrator/animator who codes as a hobby and to produce games that are mostly just making that art interactive. I feel like AI is taking over my humanity when it’s doing any visual art or design work. But when it does code. I care much less and am just happy that I reach my goals faster. This is very personal and I completely understand that if coding is your main thing , code by genAI feels worse. I do fear for the future… At least coders have been able to save some money. Visual artists are mostly broke.

  • alexpadula · 16 hours ago

    If you were good with money hah!! What will be the purpose of a graphic designer when Google can generate you a logo, endless combinations. Devastating to me. I've seen it first hand, it's pretty mind blowing and rather scary. You can't not feel that way after some time. The hype disappears.

> I feel that LLMs and their overtly verbose output trick less knowledgeable programmers of the quality of their output. When Claude spits out refactored code with tons of comments, documenting each method and variable, and tests for everything as well, it looks impressive, at a first glance. But if you dig deeper, it's sometimes just complete bullshit. This is pretty spot on. But it's important to note that the resulting code, is still often significantly better than what those developers used to produce. Especially under tight deadlines and pressure to complete CRUD like interfaces. We simply can't afford spending a whole day tweaking a sortable table on the web anymore.

• mortalapeman · 17 hours ago

  I agree that it produces code that is better than many of my colleagues. I have spent the last 14 years honing my ability to build code in a scalable way that works for basically any domain. I still produce better output than the LLM. But the incentive to encourage my colleagues to reach that kind of level is just gone, and that's what frustrates me. As humans, we could have been so much more efficient, but instead LLMs came in and are steering us towards the median of slop code. Slop by my standards anyways.

  • sgt · 16 hours ago

    Exactly! It's a bit of a tragedy. But then again, LLMs do offer benefits that are impossible not to want to harness.

So I have some questions for agentic dev aficionados: - Why should I even start vibing up my desired tools and projects when I can just wait it out so a better clanker emerges 6 months down the line? - What guarantee is there that Rust is the best programming language for vibe coding when the models could improve to directly output assembly? What incentive do you have in vibing up something?

• Grombobulous · 17 hours ago

  I can answer question #1 from the perspective of an employee who trades time for money: I don’t get immense joy [1] from writing code to do whatever dumb corporate thing my employer needs this week. An agentic workflow lets me literally sit on my hands (or play Star Wars: Galactic Racer, or play my musical instrument, or work on my CAD hobby, etc) while the agent machine does my work for me. The best part is that this is how my employer wants me to work. They literally want me to be lazy. Works for me! Where is my incentive structure to not use AI? [1] coding manually brings me a non-zero amount of joy and mental satisfaction and stimulation but I am still trading time for money.

  • spacechild1 · 16 hours ago

    How long it will it take your employer to figure out that your hours are really only worth a fraction of your current rate?

    • noosphr · 16 hours ago

      You're not being paid to be busy, you're paid to be useful. A man with a tea spoon digging a ditch is worth a lot less than one with a excavator.

      • spacechild1 · 14 hours ago

        Yes, but if I only use the excavator for 5 minutes and coast the remaining 55 minutes, I'm less useful than someone who uses the excavator the whole hour. Now, if I'm particularly skilled at using the excavator compared to my peers, I might get away with working less. If not, working 5 minutes while charging for 60 minutes will eventually get me fired. Generally, automation does not make us work less because the expectations rise equivalently.

        • noosphr · 9 hours ago

          The work is redefined to be something rather different and easier. If you disagree try digging a trench with a shovel vs an excavator.

          • spacechild1 · 8 hours ago

            I think you completely missed the point. If the work becomes faster, you need to get more work done per hour than before. The work has been redefined, but so have the expectations.

    • Grombobulous · 15 hours ago

      1. At my company I am basically a regulatory requirement. 2. I’m paid to be a warm body who is available. That’s I am paid salaried instead of hourly. 3. I don’t really care if this situation changes in the future. If AI takes my job there’s nothing I can personally do to stop that from happening. I’m just saving my money and planning to retire as early as possible. I view work as a necessary evil.

      • spacechild1 · 14 hours ago

        Seems like you make best out of it :)

• ricardobeat · 17 hours ago

  Good software comes from good ideas, design, and a deep understanding of why it does things. A better LLM will not give you much of that. To answer your question: 1) do you want it now, or in six months? and 2) it will still take the same amount of human effort.

• Paradigma11 · 6 hours ago

  "What incentive do you have in vibing up something?" I can use it.

Maybe an LLM would help him avoid the 418 error I am getting?

you can do that for personal/passion projects, but you will just get fired if you don't use LLMs at your job

I'm not writing a blog post just for this, but the man is right. For me, the only thing I expecte from a LLM is a StackOverflow/Google that actually works and maybe some static code analysis.

This is a totally fine position to take - if you have no intention of staying in the field as a professional. The environmental aspects can be solved. Quality is a measure of the person driving the process, models can write code better than the average engineer. The impact on learning, seniority etc is the one big unknown - but I believe can/will also be solved.

• incrudible · 16 hours ago

  > models can write code better than the average engineer If you're not interested in "average", volume isn't going to make up for quality. I'm certainly not perfectly satisfied with LLM output quality, but even the best programmer in the world will undeniably be helped by LLM tooling, even if only for having it write tests, benchmarks, run experiments, create research summaries, and so on.

• OlivOnTech · 16 hours ago

  > The environmental aspects can be solved. I don't think that matters. What matters is that they ARE solved. Which is not the case today.

• xigoi · 14 hours ago

  > The environmental aspects can be solved. I’m sure the people dying to air pollution and high temperatures feel good knowing that it can hypothetically be solved.

I guess nobody cares about, if some one use LLM or hand written code. They all care if you are hired and deliver the output comparable to others with all their requirement fulfilled. I still remember how wordpress developers were against elementor during its early days and look how pagebuilders became default choice now for wordpress.

You don't need to use LLMs for coding to stay "competitive" with your colleagues. I work for a FAANG, we have unlimited AI credits to be used on any model we want, with basically any tooling we want. My whole team massively uses AI, I barely do. I use not even 10% of the tokens that they do. Yet I have not only the highest rate of PRs raised, but also the highest rate of PRs I reviewed, and the second lowest number of revisions per PR. AI is all about fake productivity. You feel productive while you're achieving the same, if not less (or even often, nothing at all). Long term it's pretty obvious that people heavily using AI will become a lot less productive, if not simply unable to work as software engineers. My colleagues are already scared. In fact, as a challenge to anyone who says they "haven't written a line of code by hand in X amount of time", go do a test. Try to write any code without any LLM use for just 30 minutes.

• jvidalv · 17 hours ago

  Im sorry but nope.

• ricardobeat · 17 hours ago

  All that tells me is that your org hasn't learned how to use AI effectively yet. There is no way a human programmer can keep up with a computer doing the work of four programmers at once. You might not see this for every problem of course - in product development the bottleneck is often the design/product work, feedback cycles, not the coding.

  • iLoveOncall · 17 hours ago

    Yeah of course, it's always "you're not prompting it correctly", right? I understand though, it's hard to feel your skills atrophy in real time while at the same time realizing that the data shows your productivity has in fact not increased at all.

  • coffeefirst · 16 hours ago

    Nah. It sounds like OP is using the tools where they help him instead of for everything regardless of utility. Which seems like the right way to use tools?

• blocked_againnn · 17 hours ago

  Okay. My knee jerk reaction to this is 1. OP probably works on a team that does not ship much. It's a dead end team on maintenance mode. 2. OPs colleagues were not good engineers even before LLMS 3. OP is lying. 4. OP is delusional and is actually left behind. And is measuring wrong metrics. Which one did I get correct and wrong? Does you manager also agree you are the most productive engineer in team?

  • iLoveOncall · 16 hours ago

    We're a greenfield team working on a new piece of software. My colleagues are all also FAANG software engineers. > Does you manager also agree you are the most productive engineer in team? It would seem so. Additionally, in my mid-year performance review a couple of months ago he specifically mentioned how every metric also looks great. It seems the only option left is that I'm lying. In reality, your knee jerk reaction was to be scared and deny that what you have taken as productivity increase was just an illusion, and that you've actively been losing your skills for literally nothing.

    • blocked_againnn · 16 hours ago

      Hmm. I don't know to be honest. I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be. And all the engineers in my team are full on AI. Even the best ones. For me I see the opposite of what you are saying. I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized. So me personally I am liking how the industry is going. Never really enjoyed writing thousands of lines of code to be honest. Though always like programming when I was young.

      • iLoveOncall · 16 hours ago

        > I actually ship way more features in my side projects. Even work wise I have seen projects delivery speed going half or 1/4th of what it used to be. Again, you are conflating appearance of productivity, with actual productivity. Are you shipping more features in your side projects because AI is allowing you to ship more features faster (let's assume at the same level of quality), or are you investing more time in shipping features in your side projects, because you FEEL like AI is a productivity booster and therefore you get more out of your time, even if it's not real? Are projects at work estimated to be a lower cost because of AI productivity increases, or because estimates were too high previously, and you could always deliver at that speed? For the second point, I'd add that any launch announcement I see at work touting AI gains of 50-75-90% NEVER hold to any sort of scrutiny, so it's also simply, lies? Employees currently are desperate to look good in the eyes of the CEOs pushing for higher AI adoption. You're entitled to feeling more productive, I'm just saying you likely aren't, or not by very much. Add to that the fact that you didn't like writing code to begin with, it's easy to fall into this sort of falacy. To be clear, I do use AI, and I do see some productivity gains, but they're not in writing production code (issue management, automation that was too expensive before, generation of code or artifacts that I don't actually care much about, etc.).

      • lilerjee · 14 hours ago

        > I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized. It's impossible. You are lying. If you developed software, you should know "the tech specs and all" is never finalized, the requirements are always changed, when you are developing it, the specs or details are changed or improved.

        • blocked_againnn · 14 hours ago

          Hmm. None of us in our team has written hand written code for almost an year now. We don't really find the need anymore. Pretty much defining tech spec and getting it implemented by breaking through tickets are more than enough. There might be bugs. Wbut we catch it through testing and get it merged while building.

• sublinear · 15 hours ago

  This is extremely accurate, but HN doesn't like it when you burst their bubble. A good software engineer has always been able to write a ton of code all by themselves in a short period of time without any oversight. There's nothing romantic or intelligent about that. It's just reckless. Teamwork is more important than ever, and yes of course that slows things down. That's the point. The decision making is the slowest part. 5 hours of meetings today can completely change the trajectory of the next 5 years. This isn't a revelation for anyone but the most naive.

I agree with most points made by the author, however the cognitive impact depends on how you use LLMs. Here's an example: I build so many Phoenix / Elixir applications and one of the things I really hate is the amount of boilerplate code I need to write for every project. It is exactly the same (eg. Setting up vite, removing existing mix based node integrations) and modifying scaffolded code to adhere to my design. I already know CSS inside out and Tailwind CSS too. So, by offloading the task of rewiring existing scaffolded CRUD templates, I would argue the opposite - I am saving precious cognitive load from doing repetitive data entry work. That's why I have a very clear personal policy of always being the architect and instructing LLMs what AND how a task must be done as opposed to blindly just trusting them with everything - that is how you lose your ability to think.

I'm using it for Rust, easily handle 1mil/sec connections and I'm okay with this.

This is a roundabout way of saying you're leaving the profession. We now have people commonly running multiple concurrent programming tasks, while automatically and interactively testing them, reviewing them, and validating them. They're then handed for human review, where little is found because the quality regime is now set so high. We're talking weeks of development + testing/validating time brought down into the realm of days . So this is pure "my horse & cart are just as good as the motorcar"-levels of argument. If I bury my head in the sand long enough, and deep enough, this will all just blow over, and we'll go back to doing stuff significantly slower/worse any day now... The quality of stuff I am shipping today is the highest it has ever been, and tested/validated significantly more comprehensively. Why? Because time/resources was the limitation, not willingness or skill. I always wanted to test for every single possible edge case/scenario, but it wasn't in the time-budget (and diminish returns). Now I don't need to make that trade-off.

That's an extremely privileged take.

• 72deluxe · 17 hours ago

  How? Cognitive skills and enjoyment of coding is not something exclusive to the privileged.

  • bitwize · 16 hours ago

    Most of us in the field have to produce software for money, and the economics of that have shifted to the point where LLM use is table stakes. Programming by hand is now an idle curiosity, a leisure-time activity.

  • RockRobotRock · 15 hours ago

    I can’t find a job at all. Hundreds of applications sent, all thrown in the trash. To not use an LLM at all for software engineering? That’s just a joke. You can also deliver food with a bicycle. Good luck making a living doing that.

• unleaded · 16 hours ago

  In what way? I see it as the opposite if anything, the rise of LLMs marks the first time programmers have been expected to spend money on tools since around the 2000s.

I've struck the balance of using it at work but not at home. At work I still read through every line in the diff (unless it's a personal util/non-production facing/critical etc). Even with this I feel less 'in touch' with my work code than I do with my home code.

Reminds me of Oscar, the accountant from The Office who would refuse using a calculator.

The comparison with heroin frankly is bizarre, as if using LLMs was purely hedonistic activity. LLMs are tools like motor vehicles. They allow you to get somewhere, quickly but brutishly. You won't be able to appreciate the beautiful scenery much, as it rushes by. You're going to have to compensate for the exercise you would have gotten, had you walked, or it's going to be unhealthy. It's undeniably bad for the environment (electric or not) and has other negative externalities. The politics of many of the countries supplying most motor vehicle fuel to the world are beyond fascist by modern leftist standards. Yet, we depend on them, we have constructed a lot of the infrastructure we need to live around their existence, and even if every city became walkable over night, the last mile for most transport would be covered by some motor vehicle. There are many "what ifs" surrounding motor vehicles where the answer boils down to: "Well, then we're fucked". But we're not fucked today, and so on it goes. Of course you can try not to partake in motor vehicles, and insofar as you don't make a moral grandstand about it, that's totally fine with me. But the rest of the world is in it for the ride. The first cars weren't very good either.

> Before anyone calls me a luddite or a AI-skeptic If you're afraid of being called a luddite, you've already lost. You shouldn't value the opinion of those who would insult you for not wanting to offload something you find intellectually fulfilling to a machine.

I've been suggesting my junior colleagues recently the following mindset: for the last 5 years you have been milking cows, that was your job, and you were great at it. But this job ceased to exist [somewhere around August this year when Opus 5 appeared] You have a new job: you are a barista now [and you are going to serve oat milk] You can still manually type code, it can be a great hobby, but it is unlikely that someone will pay you a full time salary for doing it

• iLoveOncall · 16 hours ago

  Except your job as a software engineer has never been to write code, it has always been to produce software. Whether you do this by using AI or by rolling your head on the keyboard doesn't matter, and nobody cares.

  • fullstackwife · 16 hours ago

    Except usage of AI is not only about writing code, it produces software very often from very small intent, shallow context and few bread crumbs. And you don't need to play Planning Poker with it

  • bitwize · 13 hours ago

    Yes, people care. Part of the job of management is not just to define what is to be done, but how it is to be done. Let's put to bed this notion of "nobody cares how you do the job as long as it gets done" because it's hogwash. In the early 20th century, Frederick Winslow Taylor came up with scientific management, a set of principles for determining the most efficient way to perform work tasks using systematic observation and measurement rather than tradition and "rule of thumb". The problem Taylor was trying to solve was that of soldiering, or as we call it more euphemistically today, "quiet quitting"—doing the bare minimum of work necessary to keep your job. If the best way of performing a particular task were known to management, soldiering workers could be held to account for not performing as much work as they could, effectively stealing from their employers. So since that time, business has had a vested interest in understanding the best way to perform all business tasks and making that the institutional standard. You might think "But that doesn't apply to us in software engineering/IT. We use our smarts to solve problems." You couldn't be more wrong. Milt Bryce's insight was that the exact same management principles that applied to the manufacturing and construction industries applied to information systems as well, and treating a software shop like an industrial factory would save the company time, money, and effort. Today, it is known that, when properly prompted, LLMs write better code than humans, much faster than humans can, and test it much more thoroughly as well. So yes, your employer absolutely cares whether you use an LLM or not. What rational person wouldn't, especially if they don't want to waste time or money? Furthermore, now that LLM use has been standardized as best practice because they are vastly more efficient, if you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.

    • iLoveOncall · 11 hours ago

      > Today, it is known that, when properly prompted, LLMs write better code than humans Funniest shit I read all day.

      • bitwize · 6 hours ago

        Have you actually used frontier models? It's a different world now. AI is better than ~90% of practicing software engineers.

    • sdiupIGPWEfh · 4 hours ago

      I kind of love this analogy, actually, because Taylorism and scientific management also had serious downsides for the employees involved. That kind of micromanagement leads directly to burnout, and the elimination of supposed "wasted movement", in search of repeated optimized motions, leads directly to RSI and workplace injury. But if the workers are just replaceable cogs in the machine, who cares? Certainly it boosted productivity. > If you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so. So now it's our chance to be abused to improve the bottom line.

      • bitwize · 4 hours ago

        Before Taylorism, line workers were worked to the bone. Taylor was one of the first to identify that 8-hour workdays and frequent, short breaks actually boosted productivity. Although one of Taylor's quotes has special resonance in the AI era: "In the past the man has been first; in the future the system must come first." Programming was a job where the man has long been first. That era is coming to a close.

        • sdiupIGPWEfh · 3 hours ago

          It's possible I've accidentally swallowed some labor union propaganda during my education, but that's a much too rosy interpretation of Taylorism. Line workers have always been up against pressure to be worked to the bone, before and after Taylor. As you've already pointed out, workers were getting away with soldiering pre-Taylor, and then weren't immediately post-Taylor. I recall something about subsequent labor strikes. The very working conditions he helped impose would have made the ideal scenario for him to identify just how much a shorter work day and short breaks were now needed. But then, at least in the US, we didn't get the Fair Labor Standards Act for nearly three decades later. Also, Robert Owen had Frederick Taylor beat on the 8 hour workday front by like a century. Maybe Taylorism was, in practice, one of the last straws. Or maybe it was Taylor's scientific support that helped convince the legislature an 8 hour workday was needed. Personally, I have my interpretation based on the evidence, and I don't see it boding well for software engineering as a profession in our immediate future.

Genuine question: Will you also reject the results and fixes regarding the current PHP CVEs until there are handcrafted versions? And - a question from another perspective - would you be open to using Mistral in a self hosted environment?

I’m not disagreeing with the author, but if you look at his dealbreakers: most of them will be resolved over time (quality, maintainability, environmental impact & even politics), they are not so much against LLMs as they are against the current versions of them. The only arguments against AI itself are about cognitive decline and “I like coding” While there is nothing wrong with those preferences, it’s akin to saying “I like building furniture with only hand tools, and not doing it by hand leads to decline in your ability.”

• jasperry · 16 hours ago

  It could be the case that the environmental and ethical issues with LLMs are resolved, but that's about a projected future, not the present reality. Wouldn't you say that until such a time, the only ethical choice is to refuse to use LLMs?

I see LLM usage as more of a spectrum than a binary decision. For the most critical parts of my day job, I still don't commit anything from an LLM that I haven't checked myself. My brain has never felt busier and more engaged on that stuff. But then I also produce absolute mountains of code (side projects, internal tooling) that I don't have time to review and frankly it doesn't really matter what the code looks like. You can choose how much to engage your brain. Every project is different.

> Entrepreneur at heart The post sounds more like a programmer at heart, and that's totally fine. To me, being an entrepreneur is more about building products, solving problems, and creating business value. LLMs help to deliver bug fixes, new features, and entirely new products faster.

It's not all black and white. Do I write less and less code myself? Yes. Do I read less and less code? Maybe. Does it always matter? No. Sometimes, the agent writes code in a project or section of code that is sensitive and deserves a thorough review. Sometimes, it's in a tool that you would never have had the time to write if you didn't have an agent. Or it can be in a project that is so well covered by TDD that you can be confident that it won't break. There could be performance regressions or duplication / code creep, but once you realize it, you can ask an agent to simplify the code and find ways to prevent that from happening again. There are cleanup / technical-debt-reduction tasks that I thought would never be done in my lifetime due to lack of time and other priorities. But now, I'm blasting through them with Claude. I cannot imagine the lack of productivity I would suffer if deprived from an agent. That said, I agree with most points the author makes. It becomes harder to grok the code, just as it becomes hard to navigate without GPS navigation once you are used to it. It is maybe necessary to force oneself to do a development task once in a while without the help of an agent in order to stay sharp. But stop using LLMs? that sounds counterproductive.

This is akin to sticking to hand tools after the development of the electric motor. There is no going back to writing code the old way. I don't see that happening in the industry, ever. The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.

• incrudible · 16 hours ago

  I guess it's because throughout the lifetime of this profession, we have not witnessed a development like this. We went from punchcards to assembly to compilers to javascript, but at no point was it a process that would just "keep going" until you turned it off, much like a motorized machine. I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.

  • bbor · 15 hours ago

    Which is why none of us have or want job titles with "programmer" in them; even juniors are junior software engineers . As long as a human is needed to design and implement good software, they will be software engineers. The temporal affordances aren't nearly as unique as you imply, either: generated code and unit test results are two good examples of things that "keep going... much like a motorized machine". That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it. This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...

    • ffsm8 · 11 hours ago

      Eh, the industries went pretty long with the title being programmer? Didn't it only start with faang that things kept getting sillier? Tbf, I wasn't yet in the job market before the dotcom bubble, so maybe it only seems like it to me who started in the 2010s

• _aavaa_ · 16 hours ago

  > If you let it write the code, it does become a management job more than an engineering job. I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site. Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.

  • archagon · 14 hours ago

    Writing high-level code was never as mechanical as “cutting piping.” That’s absurd. If that’s how you thought about writing code, you were simply a bad programmer. (Or working on some incredibly boring code.)

    • Jare · 13 hours ago

      The typing absolutely was mechanical. The thinking what you need to type is what's never been mechanical, and there's plenty of that to do LLM or not. We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.

    • _aavaa_ · 12 hours ago

      Writing the code absolutely was. Every character we had to type was accidental complexity You are conflating designing the system and instantiating it with code. This is exactly what I’m talking about. Typing characters absolutely is cutting pipe and pouring concrete. It is not where the engineer was or is.

      • archagon · 12 hours ago

        You are conflating system design with high-level programming (with typing, which is trivial and takes almost no time).

        • _aavaa_ · 12 hours ago

          What exactly is the distinction you’re making between system design and high-level programming?