> 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.
Ha, yeah, of course I know too! I should have said it different, I meant other people were talking about needing this feature for very large teams, but I find it's needed for very small teams for perhaps different reasons related to their smallness! I need to stack PR's because I need to keep writing on top of the completed PR(s) but it might be a few days until someone else can get to reviewing because there are only a few of us and we're all doing everything.
I'm thinking that the domain of (competitive) sports is an outlier as such as it's probably the one domain where physical properties like muscle structure, height etc. have the biggest impact on "performance".
But the discussion in the article is not about performing to a high level in order to accomplish a certain outcome (win the match), it's more about exploring one self and honing a certain talent to reach deeper levels of self-expression and self-actualization: OP has a unique way of playing the piano, and they honed it by pouring love and time into it. They would probably not perform super well in some kind of piano contest where you need to play by ear, for example. And that's not the point I got.
Everyone can principally pour love and time into any domain or activity. A 1.50m tall person can explore and hone their basketball talent in order to form a deeper understanding of that part of themselves and share it with the world.
Reminds me of the meme where a kid is dropping tears on the math assignment sheet, "when you do homework with your dad". Forcing kids to spend time on something is an effective way to spoil it for them.
Exploring [math] from a place of curiosity, openness, joy - so, love - is to act out of alignment.
This also means that you need to start from within to develop your talent. What are you curious about, what excites you? Doesn't matter if that's math, obscure bird species or screws.
There's a compounding effect here, once you're deep enough in a couple domains you're starting to see their commonalities and less explored nuances at the domain boundaries.
> Forcing kids to spend time on something is an effective way to spoil it for them.
I generally agree. However most school systems force students to learn basic math, which is generally used for testing whether the student is able to think structurally and follow simple rules. Although I agree intrinsic motivation to be extremely valuable, not doing math with children the way school intends may just lead to worse grades and outcomes.
In Japan, physical maps like in parks and city information booths are oriented to be aligned with the actual geography. Meaning, north on the map points to actual north.
Made me think of how much more accurate the end to end process of putting up that map has to be vs. maps oriented by "north is up".
Just imagine the map needs to be moved by 10m and rotated around for some last minute restructuring of the park before finalizing the project.
Anyway, it was fun to read these maps and think about how many assumptions we carry around that are shaped by objects around us we use daily.
This is similar to the modern car GPS question → do you always have the little arrow pointing up in the middle and the map rotates, or is the map still and the car rotates?
True! When I started driving, I was using the "north is always up" setting as it helped me get a better understanding of where I was in the city. Somehow this was more fun.
At some point I switched to the more common setting (I assume) of having the map rotate.
I still have my map as going in the direction I'm going. Being from Europe wind directions don't matter. The roads don't care.
Then the 3d view came out, and that got my preference, and I'm always hoping one day the clouds will represent actual weather.
Anyway, the first car I got when moving to the USA got one of those direction things in the mirror, and I actually started to force myself to think in those terms. It removes a lot of ambiguity when explaining things, for example: you then turn left is more ambiguous than you then turn West.
Good point is - "it helped me get a better understanding of where I was".
That's repeated by many users having the "north is up" setup.
Certainly, if you have the other setting where your arrow is following the vehicle's direction, then what you see on the map is just an extension of what your eyes see already.
While it might be very helpful in specific situations like crossroads and switching lanes, in general it doesn't help much when one wants to learn how things are interrelated in space around. "North is up" gives that. Mind has amazing capabilities of learing even when busy
Arrow points up, map is displayed with a slight perspective.
If there is no perspective, then at the very least, the car is about halfway between the middle of the screen and the bottom of it. I care far more about what's in front of me than what's behind me.
What I really hate is that the nav in my Tesla will typically show a perspective view while navigating, but as I approach a turn, it changes to a top-down view and zooms in, often to the point where the actual turn is no longer even on the screen, so I don't know where I'm actually supposed to go anymore.
It just needs to me moved not rotated if it's horizontal though, those are not so uncommon either as physical/tactile minature models or maps on podestals, tables or on the floor even in europe.
Einnorden used to be quite a thing with paper maps in the field.
The term Orientation even goes back further referencing to the era of T and O maps in occidental Europe where east was up and where the sun rises and also of significance to Christianity
https://en.wikipedia.org/wiki/T_and_O_map
Then again nobody seems to notice the Manhattan grid is actually not north up.
Nasrudin (or Nasreddin)[0] is an apocryphal Sufi priest, who is sort of a "collection bin" for wise and witty sayings. Great stories. Lots of humor, and lots of wisdom.
One of my "go-tos" from him, is the Smoke Seller[1]. I think that story applies to the Tech Scene.
I first heard the GC quote as attributed to Will Rogers, then, to Rita Mae Brown.
I was there for the first few iterations of TPP and it is probably my favorite moment of the internet.
The lore created around TPP was insanely good and captivating, like ascribing god-like status to certain Pokémons and finding funny interpretations of in-game events and random Pokémon names
> 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.
reply