I did a lot of work on intentional programming at Microsoft back in the 90s on C++, and also intentional software later.
Our approach was quite a bit different to Kiczales at the time. We had "attribute providers" which were essentially compiler plugin DLLs.
These plugins could register themselves at various parse points and add work like enzymes on the AST.
So here we have a compile time attribute that writes all the boilerplate to add windowing support to a class. Adding message maps, hooking up the dispatch, life cycle etc.
[Window] class MyWindow { };
It worked, but as others pointed out, it suffers from combinatorial explosion, and issues with debug ability.
That said, as long as you stick within well defined verticals it was still very useful and saved a lot of typing, and reduced cognitive load.
I have thought quite a lot about modern versions of this using LLMs and I can see why the article notices a parallel to prompts or spec based designs.
At some point I tried to make a version of the system we built almost 30 years ago, but using an LLM as the preprocessor instead of rigid AST hackery.
It works a lot better, and you can approach a more continuous interpolations between intent blocks and generated code. Even the combinatorial problem largely disappears.
I stopped working on it though because I couldn't really see anyone wanting to adopt a new language or some whacked out extensions these days.
Maybe it does have its place though in certain fields. It might be worth having another go at it with fresh hindsight.