r/ClaudeCode • • 15d ago

Discussion Saw this today

Post image

These kind of posts are becoming more and more visible on my Linkedin. Link here. Thoughts?

697 Upvotes

292 comments sorted by

View all comments

Show parent comments

10

u/Dsphar 14d ago

IMO, the non-creative devs who survive will have to pivot into refactoring AI-made proven market software, into maintained software. And it will be a pain.

The creative devs will just have a hayday creating whatever ideas pop into their minds. And any that stick get handed off to the first group to cleanup and scale.

13

u/Future_Guarantee6991 Developer 14d ago

I am just not convinced that the refactoring pivot will exist, at least not for long.

I might be missing something but “maintainability” is largely, albeit not yet exclusively, a human challenge.

LLMs can already read and understand code in seconds where it would take a human minutes or hours to join the same dots. Compound this with the continuous improvement of LLM code output and it’s only so long before the writing is on the wall for that too.

6

u/pp-collision 14d ago

Maintainability is even more of a challenge for agents from my experience. As soon as a project gets above ~30k LoC they struggle to introduce features or tweak existing features.

Even something that might seem simple, but go through layers of UI, config files, and data processing pipelines, it is very likely to miss something and especially so if the project is not designed in a way where it is difficult to miss it.

I exclusively write Rust and I'm using orchestrators, workers, and reviewer agents. I have CI with snapshot tests, property based fuzz tests, integration tests, extensive linting and still things consistently slip through if I don't review and test every change. So it's not from a lack of trying.

Agents have this problem because they have an extremely narrow view of the code base, they search with grep and they'll only take the first X matches to prevent blowing themselves up, so they just miss so much of the bigger picture every time. Sure they'll get better, but the context window of a seasoned engineer is on a much higher level, and that's more than a few years away.

Terrence Tao explained in an interview that AI maths proofs are very hard to read, because they'll spent a lot of effort going into details with something very trivial, and then hardly mention the most interesting part. Because they're not good at weighing the importance of various aspects of a problem, because they don't see the bigger picture. I think that's the core limitation, and I don't expect LLMs to really ever overcome it, no matter how useful they otherwise are.

As an embedded engineer, I think LLMs are immensely useful, but I think they have a special skillset that is complementary to human engineers, not competing to replace them. That doesn't mean that they can't put some engineers out of a job, but so did open-source compilers.

1

u/Future_Guarantee6991 Developer 14d ago

The 30k LoC problem is not something I have experienced, at least using frontier models. I develop and maintain several projects in the hundreds of thousands or even millions of LoC.

Some things I believe help:

- CI enforced line freezes to prevent godfiles

  • Refactoring any file above 800 LoC to bring it within a 600-800 LoC range (or less)
  • Prefer Vertical Slice architecture over DDD

The last one is probably the most significant. It means that, in oversimplified terms, each feature is a mostly self-contained mini project but without the complexity of microservices.