That's definitely true, but I do think production rules have some uses that are less obvious.

For instance, XSLT is not "an overcomplicated Jinja 2" but rather it is based on production rules but hardly anybody seems to know that, they just think it's a Jinja 2 that doesn't do what they want.

Production rules are remarkably effective at dealing with deep asynchrony, say a process that involves some steps done by people or some steps done by humans, like a loan application being processed by a bank that has to be looked at by a loan officer. They could be an answer to the async comm problems in the web browser. See also complex events processing.

Production rules could be a more disciplined way to address the issues addressed by stored procedures in databases.

I've written systems where production rules are used in the control plane to set up and tear down data pipelines with multiple phases in a way that can exploit the opportunistic parallelism that can be found in sprawling commercial batch jobs. (The Jena folks told me what I was doing wasn't supported but I'd spent a lot of time with the source code and there was no problem.)

I use Junie to get tasks done all the time. For instance I had two navigation bars in an application which had different styling and I told it make the second one look like the first and... it made a really nice patch. Also if I don't understand how to use some open source dependency I check the project out and ask Junie questions about it like "How do I do X?" or "How does setting prop Y have the effect of Z?" and frequently I get the right answer right away. Sometimes I describe a bug in my code and ask if it can figure it out and often it does, ask for a fix and often get great results.

I have a React application where the testing situation is FUBAR, we are stuck on an old version of React where tests like enzyme that really run react are unworkable because the test framework can never know that React is done rendering -- working with Junie I developed a style of true unit tests for class components (still got 'em) that tests tricky methods in isolation. I have a test file which is well documented explaining the situation around tests and ask "Can we make some tests for A like the tests in B.test.js, how would you do that?" and if I like the plan I say "make it so!" and it does... frankly I would not be writing tests if I didn't have that help. It would also be possible to mock useState() and company and might do that someday... It doesn't bother me so much that the tests are too tightly coupled because I can tell Junie to fix or replace the tests if I run into trouble.

For me the key things are: (1) understanding from a project management perspective how to cut out little tasks and questions, (2) understanding enough coding to know if it is on the right track (my non-technical boss has tried vibe coding and gets nowhere), (3) accepting that it works sometimes and sometimes it doesn't, and (4) recognizing context poisoning -- sometimes you ask it to do something and it gets it 95% right and you can tell it to fix the last bit and it is golden, other times it argues or goes in circles or introduces bugs faster than it fixes them and as quickly as you can you recognize that is going on and start a new session and mix up your approach.