[jwpapi]

Crazy how many engineers in here just say they are using another prompt on top. From my experience that makes things worse. It does abstractions, but the wrong ones. It overcomments, confusing future calls of the LLM.

To me building on multiple scalable systems this has been the most dangerous part of LLMs. On a good codebase it will work good, but it will maek it worse, so you keep using it, till it doesnt work and then you have to pay the bill and fix for what you didn’t build before.

If you put an agent on a fresh codebase 2 things are often given:

-> You have a mental model of the code -> The code is somewhet concise

After multiple iterations both is lost and LLM performance degrades. To solve this you can regular refactor, but it’s not a nice experienc. So my best solution is:

I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.

Sometimes I race AI i give it a prompt /bug to fix and at the sametime im greping/symboling through the codebase and tryto fix it myself. AI isn’t always faster.

[swatcoder]

> I write the code myself. I find it hard to believe why so many engineers try to avoid it.

Gradually over its recent booming years, software work went from one of several practical engineering refuges for curious tinkers and puzzle-addicts to a career path for financially ambitious bright people akin to finance, law, or medicine.

Many people carrying a "software engineer" title now never really enjoyed that part of the work at all but were suitably clever and responsible to accomplish what modest ends they were tasked to by their very generous employers. Mostly (but not entirely), those people are the ones most eager to have AI agents shield them from rigorous design and puzzle work and enable them to leverage their innate cleverness more lazily. They never really internalized the coding and engineering principles of the industry and so can't foresee what might be down the road for them with this technique, especially when they're surrounded by peers with the same mindset.

> AI isn’t always faster.

It is when coding was an extremely frustrating and high friction experience for you in the first place, as is the case for many who work among us now.

[cline6]

100 times this. Maybe this was the thing all along that was so difficult to put our finger on for why some engineers seem to have "it" while so many others, despite being productive, don't. It's just that they loved it. It brings me so much sadness to see so many people happily relegate themselves to typists instead of a person with real motivations and skills.

[skydhash]

If there's one thing I've remarked, even before LLM tooling, is that there's a class of people that is ready to try things for weeks until it magically work (with no guarantee it will hold), instead of spending one hour designing it and formalizing it. They won't get functional abstraction, maintainability means nothing to them, and architecture don't matter.

They're the one copy-pasting straight from StackOverflow, and if it does not work, will copy-paste something over it. When something works, they will copy-paste it all over the codebase regardless of context.

For those people, LLM tooling are the Second Coming. Because it helps them eliminate all the telltale signs of bad works they've been doing. For them, "Use the AI" is the new mantra because they can't imagine not needing to use it.

[softwaredoug]

This is exactly why I advocate people write code, even in a world where agents code “better”

It’s not enough to read code. You don’t internalize it. You need to experience it painfully :)

Also agents frequently defensively wrap old code instead of questioning whether legacy paths should exist. You get this nested doll layering effect of extremely large amounts of defensive code.

https://softwaredoug.com/blog/2026/07/09/write-code

[leptons]

>Sometimes I race AI i give it a prompt /bug to fix and at the sametime im greping/symboling through the codebase and tryto fix it myself. AI isn’t always faster.

+1 - this is also my experience. I also "race" the AI on some tasks, especially when it's simple and the AI is taking forever to return a result - so it even has a head start, and I often complete it faster or around the same time.

For some things maybe it is faster, but it isn't really returning a better result. It often turns into spaghetti, doing things I didn't ask it to do.

[ponector]

>> AI isn’t always faster

It is always faster if you don't care about quality and need to churn out code as fast as possible to close tickets.

[Exoristos]

And as time goes on?

[swat535]

You get promoted and let other people deal with the mess.

The truth is that no one in management cares about your perfect code, they only care about the projects you deliver, the features you push out and the meeting KPIS.. Your customers don't care about your perfect abstractions either, they just want the button to work when it's clicked.

You can always argue about maintenance, but who is going to listen? By the time it's an issue, the business is throwing money at the problem to make it go away. Heck, even major security issues are a nothing burger.. I've lost count on the number of breaches big companies have had in the last decade..

Such is the plight of our industry.

[skydhash]

> The truth is that no one in management cares about your perfect code, they only care about the projects you deliver, the features you push out and the meeting KPIS.. Your customers don't care about your perfect abstractions either, they just want the button to work when it's clicked.

I don't think most developers care about perfect code (if such thing exists). What they care about is maintainability, so that the project is delivered on time, features keep getting pushed and KPIS can be actually met. And that the customers have a working button.

Instead we got projects that keeps being dragged around (until it's put out of its misery), half baked features, and KPIs that are twisted until they're barely looks like what was stated at the beginning of the quarter. And the customer is complaining about another button breaking.

What I do is never ask for permission, because that's an engineering concern, not a product/management one. I just tidy the code I work on, one step at a time.

[M0r13n]

Exactly. I follow a similar workflow. I am still writing code by hand. Not all code. Parts are generated by Opus.

[radlad]

> I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.

At my workplace, there is more work to be done than there is engineers, and approximately 2 engineers per service. I can spin off multiple Claude Code instances on unrelated work, steering them occasionally, and then finally reviewing the output. After I have reviewed it, I post it for team review.

You're absolutely right that my depth of familiarity is lesser with this code, but we are absolutely shipping more as a result of increased parallelization.

The bottleneck now is typically reviews - both pre-push and team reviews.

[M0r13n]

This seems to assume more code shipped equals more work done. I am still not convinced that this is necessarily the case. Sometimes it is. Sometimes it is not. You mentioned that reviews are now the bottleneck and that your familiarity with the code has decreased. That tradeoff might eat into the parallelization gains over time.

[radlad]

Definitely not - the biggest risk with this increased speed is going full-bore in the wrong direction. A product mindset (and a critical eye to architecture) matters more now than ever.

[leptons]

Most people hyping their AI use mention the short-term gains without taking into account how it affects overall long-term success. We are creatures of convenience.

[radlad]

Considering most teams have only switched to heavy AI use in the past few months, the verdict is still out on this.

That said, I've had lots of success using AI to learn, refactor and clean up codebases.

I notice another trend were a lot of AI naysayers haven't really spent a ton of time getting intimately familiar with AI.

[leptons]

>I notice another trend were a lot of AI naysayers haven't really spent a ton of time getting intimately familiar with AI.

I don't think that's really true, it's more your feels than anything. I've noticed this thing where everyone that's using AI think nobody else is using AI, or at least not the cool way they are doing it. It's typically nonsense.

I've been using AI for quite a while, personally and professionally, and I can already see the clusterfuck it's causing. I still don't let it work on my important personal projects, but for simple tools and websites, sure. At work we're told to use AI exclusively to code, and it's already causing problems - the AI just endlessly applies bandaid after bandaid and it's turned the code to spaghetti. Nobody even reads the code, the people above just tell us to approve it and ship it. I'm looking for a new job because I already know this isn't going to produce the long-term success they are expecting. All it is doing is making it more expensive to write software, without the knowledge of how the code works, and if you can't already understand how that looks in the future, well... I don't know what to tell you.

[radlad]

I'm sorry to hear that's how it's going at your work.

[tzone]

have been doing "racing to debug" things with AI for quite some time too. Have to say, before Opus 4.8, there wasn't even a comparison for anything slightly complex.

Opus 4.8 has been the turning point though. I am not winning many races compared to Opus 4.8, especially if it is something more complex.

I think if everyone was using Opus 4.8 (or better) for every single task/question/etc, you would have much different overall sentiment. I don't think you would have many AI disbelievers left.

[zahlman]

> To solve this you can regular refactor, but it’s not a nice experienc.

Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better.

I agree with you about the joy of writing things directly, overall. But being able to get a few hundred lines of new approximately-what-I-wanted-to-type code (which I generally can read and fix much faster than I would have written it from scratch) definitely improves the experience, when my brain is racing ahead of my fingers. Certainly it gets me more motivated to actually start on a new feature. Similarly for all the not-exactly-exact find-and-replace tasks.

(I'm not a slow typist, but I slow myself down when I write the code, by thinking too much about details that won't be important until after the tests run.)

[jwpapi]

I generally like refactoring too, like cleaning up at home, but if you open up a codebase that has been vibecoded and it seems like it’s a never-ending chain of bad practices leading to performance, security, maintenance problems.

I’ve recently been given the task to work on a fully vibe-coded app. I reduced the code from 140k to 28k lines. This was luckily pre-mvp stage so no users. But if people get stuck at this stage, imagine what’s happening with real workload.

I’ve always been a solo dev, but I’m wondering how in big companies there is even so much to you can actually touch that you need an LLM to do that. Like I can’t delete refactor 120k lines in an established codebase. And one task to fix, takes review time and product time. Like are there now engineers that commit 1k+ lines a day of LLM produced output ?

Bugfixing often is just a bunch of lines, or a replacement of a service often isolated maye 150-200 lines, but I just might be just not experienced enough on these kind of codebases. I can’t grasp the notion of the LLM-multiplex and I don’t know where it’s going.

I have to say I have seen some good solo-dev projects popping up recently (games) that actually got profitable, but usually they were experienced in their discipline before.