[rapind]

I always thought AOP was super cool, but also that it completely destroys readability and the ability to understand a codebase. I also think it's probably one of the worst concepts to embrace in the age of agentic coding. That would be like a foot missile.

There are a limited number of patterns that absolutely do benefit from AOP though. The obvious one is logging. I don't think there's many though.

Regardless, AOP is the last thing I'll be using these days. With LLMs I've been moving in the opposite direction with a focus on explicitness and correctness. Typed, compiled, non-null languages with clear, obvious, and well documented conventions.

[kazinator]

> destroys readability and the ability to understand a codebase.

Aha! That's exactly the sort of thing that can make code impervious to LLM AI.

LLMs have no grasp of any issues that are not visible in syntax, like concurrency. Code that has deadlocks or race conditions (because of other code not seen elsewhere) can look right, but be wrong.

In other words, if you write a program using convoluted spaghetti logic full of invisible data members and control flows injected remotely by aspects, LLMs trained on the code will have no understanding of it; they will just predict tokens according to the naive, visible code.

Imagine if all code out there available for training LLMs was heavily AOP. LLMs trained on it wouldn't be worth a damn. They would not correctly crib the entire solution: generate the code, and bring in the invisible aspects needed to actually make it work. All their solutions would just be the naive surface code that must be invisibly instrumented by half a dozen aspects to be complete.

AOP-heavy code would have to be somehow cleverly preprocessed for training in order for token prediction to do meaningful things with it.

[Zababa]

This is not true, LLM can write and run code to check for deadlocks or race conditions.

[kazinator]

Generating code on the topic of deadlocks and race conditions is different from understanding those issues and recognizing them in a wide variety of contexts.

[Zababa]

I don't know about understanding but Claude and GPT can "recognize" lots of race conditions/possible deadlocks and then run Go with the race detector to figure out if they really happen (actually not all the time they tend to be overconfident that things are race conditions without testing first!).

I don't really know what to call that, if it's understanding, recognition, but it's clearly helping reduce the number of race condtions.

[jolt42]

I've feel like AOP is Spring on steroids. Same downside for both IMO.

[ctkhn]

I think that's a good point, never thought about it like that. I like the abstraction level that Spring Boot brings, but working with a principal engineer who was very into AOP on my previous team was a huge pain. Like you and GP said, AOP absolutely destroys readability. Current team has code split into a million xyz-common libraries, which isn't my preference, but I can still click through to see the source of the library. I will never get what AOP truly improves on

[rapind]

I think the issue is that a lot of concerns that appear to be "cross-cutting" at first glance, don't hold true to that design... but teams will try to stay the course, possibly due to existing debt, and it goes south pretty quickly from there. That's what I mean when I say there are some patterns that are obvious and proven cross cutting concerns (like logging), but there's really not a ton of them IMO, and if you're going to experiment with new potential concerns, then you must be ready to rip it up when it proves not to be the shape you thought it was.