> if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then.
In this side sentence you're introducing so much vagueness. Can you share insights to get some validation on your claim? What metrics are you using and how is your code from 10, 5, 0 years performing?
I feel throwing in a vague claim like that unnecessarily dilutes your message and distracts from the point. But, if you do have more to share I'd be curious to learn more.
The anecdote the GP is providing there rings true for me too - although I'm not sure if I am going offer better detail.
I'm a proponent of architectural styles like MVC, SOLID, hexagonal architecture, etc, and in pre-LLM workflows, "human laziness" often led to technical debt: a developer might lazily leak domain logic into a controller or skip writing an interface just to save time.
The code I get the LLM to emit is a lot more compliant with those BUT there is a caveat that the LLMs do have a habit of "forgetting" the specific concerns of the given file/package/etc, and I frequently have to remind it.
The "metric" improvement isn't that the LLM is a better architect than a senior dev; it's that it reduces the cost of doing things the right way. The delta between "quick and dirty" and "cleanly architected" has shrunk to near zero, so the "clean" version becomes the path of least resistance.
I'm seeing less "temporary" kludges because the LLM almost blindly follows my requests
I don't think I'd like your code. But apparently there's enough implied YAGNI in my CLAUDE.md to prevent the unnecessary interfaces and layers of separation that you apparently like. So I guess there is a flavor for everyone.
I've recently had the interesting experience of working on a Clean Architecture project for the first time. Pre and post-LLM adoption.
It has been... difficult. Services/modules organised by infrastructural layer rather than by feature. A mediator pattern abstracted away the handling of commands. Just in case one day you needed CreateFooCommand to be executed by a different handler, or something, I dunno. It was so hard to figure out how to navigate everything. And it felt like the entire tradeoff was for the purpose of stopping smoothbrains from adding the ORM to an API endpoint - but with the cost of this crushing accidental complexity that made it hard for everyone to hold everything in their heads, not just for me but also for the smart guys on the team.
It turns out that the LLMs also performed extremely poorly. All the heavy abstractions were too hard for them (not to mention most of the developers).
I knew I had no chance of shifting things away from that paradigm. But as luck would have it... we started basically vibe-rewriting it from scratch without bullshit enterprisey crap and its (a) dead simple (b) has most of the features after one month (c) even though the code is questionable, inelegant AI slop, with nearly zero regard to proper architectural design, it's way easier to deal with than before
> Services/modules organised by infrastructural layer rather than by feature.
That is actually true to the original CA as far as I am aware. The "veritcal slices" style of development came after.
> with the cost of this crushing accidental complexity that made it hard for everyone to hold everything in their heads, not just for me but also for the smart guys on the team.
What? You don't like editing 50 files every time a new column is added to a DB table?
> And it felt like the entire tradeoff was for the purpose of stopping smoothbrains from adding the ORM to an API endpoint
There is nothing wrong with this, and I will die on this hill. The entire purpose of CA was for people to make money off book sales, lectures, and consulting. Notice how every single on of the people involved with promoting CA have absolutely nothing noteworthy to their names. In fact, you might be surprised who was one of the consultants on a major failure of a solution... *cough cough*
Business logic is usually the most substantial part of legacy systems in my experience, so I imagine so.
Not to be too negative but a lot of modern software complexity is a prison of our own making, that we had time to build because our programs are actually pretty boring CRUD apps with little complex business logic.
I can only assume there's a ton of domain knowledge accrued over those years and beyond baked into the legacy code, that an LLM can just scoop up in a minute.
How much time to verify and validate that large corpus of code that they generated? Not including back and forth to get rid of hallucinations and other mistakes.
How does the code look? I am curious if there is proper usage of abstractions, or is logic just kind of all over the place?
Some part of me feels like LLM generated code is great if one cares about the solution, but leaves a lot to be desired if one actually cares about code quality. Then again, maybe I am just bad as using LLMs -- I prefer the chat over lettings LLMs do the work for me.
> if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then.
In this side sentence you're introducing so much vagueness. Can you share insights to get some validation on your claim? What metrics are you using and how is your code from 10, 5, 0 years performing?
I feel throwing in a vague claim like that unnecessarily dilutes your message and distracts from the point. But, if you do have more to share I'd be curious to learn more.