I think people don't really realise that compilers are "difficult" projects in the same way as an appendicectomy is for a skilled surgeon, i.e. the surgery is "routine" only because the surgeons spent decades honing their skills to do these routinely. The hard part was training someone to be able to do that.
Writing a compiler/interpreter is _extremely_ straightforward; a lexer -> parser -> ast -> semantic analysis -> {codegen -> linker | evaluator} pipeline is a very widely understood and tested way to write a compiler in any language, regardless of what language you are trying to compile. The hard part is _learning_ how it works, but after that implementing a compiler is a kind of mechanical activity. That's why LLMs are so great at writing parsers: they can just read the source of any compiler (and they probably read all of them) and apply the same stuff mechanically, with almost a 100% accuracy. We even have formal languages to define parsers and RTL and stuff, that's how "mechanical" the whole process can be.
I'm pretty sure that any skilled compiler dev with the ISO C standard and a few packs of Red Bulls can apecode a working C compiler in a few days, give or take. The hard part isn't doing that, the hard part is the decades of iterative improvements to make it generate extremely performant yet correct code as fast as possible.
This is the first time I've heard the term 'apecode', and I will make sure to use it at every opportunity.
It is not mine unfortunately, it comes from a very funny write-up by rsaksida: https://rsaksida.com/blog/ape-coding/