I have secretly held the belief for a while that the Java implementation should be mechanically translated to TypeScript and then fixed up, annotated, and maintained not just primarily but entirely in that form; the requisite R&D/tooling should be created to:

(a) permit a fully mechanical, on-the-fly rederivation of the canonical TypeScript sources into Java, for Java consumers that need it (a lot like the ts->js step that happens for execution on JS engines), and

(b) compiler support that can go straight from the TypeScript subset used in the parser to a binary that's as performant as the current native implementation, without requiring any intermediate C++ form to be emitted or reviewed/vetted/maintained by hand

(Sidenote: Hejlsberg is being weird/not entirely forthcoming about the overall goals wrt the announcement last year about porting the TypeScript compiler to Go. We're due for an announcement that they've done something like lifted the Go compilers' backends out of the golang.org toolchain, strapped the legacy tsc frontend on top, allowing the TypeScript compiler to continue to be developed and maintained in TypeScript while executing with the performance previously seen mostly with tools written in Go vs those making do with running on V8.)

I agree with the overall conclusion of the post that what is demonstrated there is a good use case for LLMs. It might even be the best use for them, albeit something to be undertaken/maintained as part of the original project. It wouldn't be hugely surprising if that turned out to be the dominant use of LLM-powered coding assistants when everything shakes out (all the other promises that have been made for and about them notwithstanding).

No real reason that they couldn't play a significant role in the project I outlined above.