Systems that have a structured formal language will have interesting applications with LLMs.

Writing code (or any formally structured document, e.g a Domain Specific Language) has two things that must be true:

syntactic correctness (is this thing described in a legal way)

semantic correctness (does it do the things that I want it to do).

The latter is by far the most important, but most human effort in programming and distilling formal documents in a given DSL is occupied by the former.

Systems like code and formal DSLs have a form of built-in ground truthing for syntactical correctness: "does this compile? Are there any errors?".

LLMs often hallucinate, but if you have a formal DSL you can automatically achieve syntactical correctness. "That didn't compile, I got this error: (error). Try again."

The LLM is throwing a bit of spaghetti at the wall, but it's possible to automatically check if it stuck on the wall or not.

This allows you to use LLM's indefatigability to help find things that would have been a time-consuming pain to do yourself.

This gives you a kind of self-smoke-testing in these contexts. So in those domains you can almost completely remove the mental energy spent on syntactical correctness, freeing up more to focus on semantic correctness.

Of course, semantic correctness is significantly harder to reason through than syntactic.

When you're struggling through the details of syntactical correctness, you have more of the state loaded up in your head, and have your head "in the game" more thinking about the implications of each bit of functionality, you're on the dance floor with the code.

This also helps you intuit semantic issues in the code more easily.

When you're doing only the semantic correctness, you have a more detached, passive perspective, from the balcony.

You might not grok subtle semantic correctness issues you would have if you had written it yourself.

Still, with LLM-written docs we can act like a senior developer doing code review an intern's work: it's likely to do roughly what we wanted, and we can take for granted that it is syntactically correct (that is, it compiled).

The important work shifts from creating syntactically valid code to verifying its semantics: less of a programmer mindset, more QA.

There's a lot of places where this "senior expert reviewing an intern's work" applies, but code and other formal DSLs are special in that they can self-smoke-test.