Back in January, I received a note from a senior software engineer in Silicon Valley. He described himself as an AI skeptic who became converted after trying Claude Code for the first time. “Overnight, it changed the way I do my job,” he wrote. “It’s really, really good.”

As he explained, he no longer used a standard development environment. Instead, he “exclusively uses Claude Code” to get the job done, interacting with the tool in a terminal window and allowing it to program on his behalf.

“If I had to guess,” he concluded, “I’d say a task that would have taken me a week now takes me 2 days.”

This past winter, when I surveyed more than 300 software developers to learn how AI was transforming their jobs, the majority told a similar tale of shifting from writing their own code to instructing AI agents. The speed with which this new tool became ubiquitous in this industry was stunning.

This story matters for the rest of us because AI coding tools have emerged as the prime example of the power of AI—the first step of many more soon to come on this technology’s disruptive march through our work and our lives.

But what if the reality here is more complicated?

Last week, I received a new message from that same senior engineer who wanted to share an alarming addendum to his tale…

“I’m writing to give you an update on my current thinking about the state of AI in software engineering,” he began, “because my attitude has shifted quite a bit.”

He told me that features he generated using Claude Code ended up crashing their product on two different occasions. His boss told him that if it happened one more time, he’d be fired. “I’ve never had quality issues like this before in my career.”

The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems. As a result, you should carefully review your agent’s output, but this is difficult. As the engineer told me, it’s “famously hard” to understand code you didn’t write yourself, so this extra step becomes “easy to just blow it off (especially when we are all trying to ‘10x’ our velocity).” Soon, systems start to break.

“The coding harnesses are useful and make life as a developer easier,” he summarized, “but they also encourage laziness.”

In response to these issues, this disillusioned engineer has returned to largely programming by hand. Here’s how he explained his current philosophy:

“Writing your own code, slowly but surely, and using LLMs for narrow or particularly annoying tasks (say like writing tests or throw-away scripts), is the best way to produce the highest quality code, since it’s the only way to properly understand it.”

Here’s the thing: he’s not alone.

I increasingly hear similar rumbles from many other people in the software industry (see, for example, ​this podcast episode​ from May). Tools like Claude Code can feel like magic, but the strategy of outsourcing all code production to AI isn’t currently sustainable.

In addition to reliability issues, it often engenders a mind-numbing workflow and an environment where junior developers will never acquire the expertise to become senior developers capable of designing complex systems.

Meanwhile, as the frontier labs reduce their subsidies on underlying computing costs, the old habit of burning through as many tokens as possible in search of workable results is proving prohibitively expensive.

From the outside, software development seemed like the poster child for AI’s potential. On the inside, it’s a mess.

This doesn’t mean that coders will abandon AI; its facility with programming languages is too valuable to ignore. But I think there’s a lot more work to be done trying to figure out how to integrate AI into this industry in a way that actually works.

This is a key point.

This last year has been exhausting. The PR departments of the frontier labs have done an excellent job convincing us that AI developments are occurring at an astounding, world-changing rate. But if you zoom out, it becomes clear that almost every “breakthrough” since last summer has concerned the narrow domains of computer code and math, which are defined by highly structured languages and come accompanied by massive amounts of specialized training data.

And yet, even in this best-case-scenario setting for AI, we’re still struggling to figure out how to actually use these tools in a way that makes sense in the long run.

This doesn’t mean that AI doesn’t work or is useless. But it does emphasize an important truth: AI is not a magic “infinity machine” that can solve all our problems, and ultimately deliver us a sense of meaning in a cold, confusing world. It’s a normal technology, and perhaps it’s time we start talking about it that way.

  • IchNichtenLichten@lemmy.wtf
    link
    fedilink
    English
    arrow-up
    28
    ·
    4 days ago

    I tend to agree with Cory Doctorow in that LLMs are not the amazing breakthrough tech that AI companies have been gaslighting management into thinking they are. This tech should really be thought of more like plugins are - a useful, albeit limited, aid for speeding up some of the more tedious tasks.

    Of course, only an idiot would look at the vast piles of money burned and resources wasted for a plugin and think that makes any sense.

    • Feyd@programming.dev
      link
      fedilink
      arrow-up
      18
      ·
      edit-2
      4 days ago

      Another aspect is that “some of the more tedious tasks” already had tons of ways to be sped up but the brain-dead LLM pushers had never actually tried to optimize their workflows before and thought LLMs would make them be as good as their much more competent peers without actually learning anything.

      • expr@programming.dev
        link
        fedilink
        arrow-up
        6
        ·
        3 days ago

        Seriously. My argument against “LLMs are good at generating boilerplate” has always been “why are you putting up with needing to write boilerplate in the first place?”

        I really do think that it’s emblematic of a problem that existed long before LLMs: a lot of developers were/are deeply uncomfortable with stepping outside the confines of their IDE, and thus would basically never fix workflow/DX issues unless said fix came packaged as a feature by whichever megacorp was feeding them tooling. Scripting is all but unheard of outside of things like builds or CI.

        I see this divide in my own organization, actually. Our mobile developers aren’t really all that comfortable with stepping outside of what Android Studio/XCode can do and the workflows deined by Google/Apple.

        Our backend team is very different. No one uses IDEa, and we’re all Unix terminal folk for the most part. Lots of scripting and tooling we’ve created over time to streamline our development.

        So when me and few other backend engineers decided to write a small Caddy file to set up a reverse proxy to enable the mobile emulators to talk to our locally-running backend (rather than a shared non-prod backend that the mobile teams always use, in order to facilitate more efficient end-to-end testing for features), we may as well have been talking an entirely different language when describing it. The very idea of creating your own tooling to solve a problem with your job is just entirely alien to them.

      • IchNichtenLichten@lemmy.wtf
        link
        fedilink
        English
        arrow-up
        13
        ·
        4 days ago

        It’s everywhere. Can’t code for shit? Just use a LLM bro. Can’t create art? Just throw your prompt at the latest slop machine. Too lazy to write anything? We can help with that. Women too stuck up and woke to talk to your nasty self? Guess what, our LLMs will tell your just how special you really are.

        Sometimes I just want to go live in a cave.

      • Buddahriffic@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        3 days ago

        Ironically, LLMs are pretty good for helping optimize non-LLM workflows. Brainstorming a list of things that already exist is something they do well. And even if they hallucinate some entries, just move on to the next one. And having them help with one time setup or debugging specific issues is way more efficient than having a workflow that involves them regularly.

  • Solumbran@lemmy.world
    link
    fedilink
    arrow-up
    55
    arrow-down
    12
    ·
    4 days ago

    Coders will abandon AI, one way or another. Either willingly, or by dying like the rest of humanity when summers reach 60°C.

    • boonhet@sopuli.xyz
      link
      fedilink
      arrow-up
      17
      arrow-down
      1
      ·
      4 days ago

      Either willingly, or by dying like the rest of humanity when summers reach 60°C.

      I mean all of us will abandon everything that way, that’s not specific to AI in any way.

        • Dack@programming.dev
          link
          fedilink
          arrow-up
          20
          arrow-down
          1
          ·
          4 days ago

          For localized environmental strain (like heavy water usage or regional grid pressure) it’s entirely true , but certainly not in the big picture of global climate change. Fossil fuels, heavy industry, and agriculture are the actual main drivers. Blaming AI for “60°C summer” completely misses the point.

        • boonhet@sopuli.xyz
          link
          fedilink
          arrow-up
          12
          arrow-down
          1
          ·
          4 days ago

          It is not even close to being a main factor at the moment. Main factors are still transportation and manufacturing. Trump’s war in Iran is doing way more to reduce global emissions than the data center protests (though it’s great that those are also happening). Same for Putin’s war in Ukraine which started the fuel price raises.

    • lichtmetzger@discuss.tchncs.de
      link
      fedilink
      arrow-up
      8
      ·
      4 days ago

      Coders will abandon AI

      I secretly wish for it, but that will probably never happen. But the ridiculous excesses - like running hundreds of LLM agents in a loop to write your software - will go away. They’ll be way too expensive to run for most companies after the subsidies run out.

    • thingsiplay@lemmy.ml
      link
      fedilink
      arrow-up
      10
      arrow-down
      3
      ·
      4 days ago

      I don’t think that most will abandon in the future, as the Ai even becomes better and most people only look at the surface. The biggest problem (besides the unethical training data and not respecting licenses from the original data) is if you don’t know what it produces and don’t check it without understanding. Where it can be useful is aiding in code analysis, but not replacing it. And most will shift to local available models (I hope so), as local hardware becomes better at it too.

      I’m not the biggest fan of Ai at all. But I don’t see a reality where Ai disappears in the future, unless every company is doing it gets bankrupt. Looking at Microsoft and Nvidia, this sounds unreasonable. Because if one major player like Anthropic goes down, another one will rise up, maybe from China.

    • jimmy90@lemmy.world
      link
      fedilink
      arrow-up
      2
      arrow-down
      4
      ·
      3 days ago

      it’s great for generating code

      but you have to double check everything because 80% accurate is disastrous for code

      i like this creative process but i’m fairly sure it’s economically not much different

      • Solumbran@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        3 days ago

        All studies show that it produces worse results and hidden bugs, how is it great?

        You don’t use a slop machine to make software. Or anything elae.

  • BlaestEgnen@feddit.dk
    link
    fedilink
    arrow-up
    10
    ·
    3 days ago

    From most companies I hear about, the two common camps are.

    Frontend devs fucking loving AI agents to code and do as much as possible. Because if something breaks, yeah we’ll ship something new and the few missed interactions didn’t truly matter.

    Backend devs do not trust AI agents to the same magnitude, they’re fine outsourcing non critical parts which rarely are prioritised. Such as tests and documentation, both of which LLM based tools excel at. But having LLMs generate all the code, which if anything breaks within. Welp, fuck. Did we just ship 10.000 orders at half price? That’s an issue.

    Well we’ve already seen a lot of companies not understanding development disciplines before the LLM craze, having client side developers make server side code because it’s nodeJS they know JS. Well language is secondary, and you’ll figure that out when incredibly simple bugs are shipped to the server side code.

    I think there’s at least one more year of runway, before we’re seeing any greater understanding from C-suites in general. For why a developer isn’t just a developer, why some are specialised in servers and some in clients. Because those disciplines are miles apart.

          • BlaestEgnen@feddit.dk
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            3 days ago

            I am, not sure if you’re indicating I know too little about frontend developers?

            I have friends and acquaintances of all sorts of developers, there’s a clear tendency to who is most in favour of agentic tools to have more control

            Let’s be clear, there’s also frontend devs who despise the idea of these tools takes control. They’re just a lot less common than backend devs

            • outerspace@lemmy.zip
              link
              fedilink
              arrow-up
              1
              ·
              3 days ago

              I think you are just happen to be in an area where the frontend is less important. Where I work we have 100 people on the frontend and none of them think that llms need more control, here everything has to be precise, frontend has more tests then backend, more standardized too

              So my point is it’s not about area, it’s about a task

  • Feyd@programming.dev
    link
    fedilink
    arrow-up
    18
    ·
    4 days ago

    So they came to the conclusion that the actually competent people they refused to listen to said after touching it once.

  • jtrek@startrek.website
    link
    fedilink
    arrow-up
    15
    ·
    4 days ago

    No shit.

    One of the problems is all the people who were fucking wrong don’t suffer any lasting consequences. They will be listened to again.