When Bjarne Stroustrup first implemented C++ it was called "C With Classes". The implementation worked by generating C source code; that became known as CFront.

It should be obvious that you don't get the equivalent of the C++ language simply by writing code in C, rather than writing C++ and having that translated to C.

Generating source code lets us have a different language which expresses solutions in different styles. Also, it lets us have higher level languages instead of writing in assembly language. Though some compilers generate machine code directly, the generation of assembly language is also an approach which is used, with equivalent results. That is also "source code generation".

Instead of generating assembly language from a higher level language, we could write procedures in assembly language. That would be time-consuming to develop and debug, and also have to be rewritten when ported to another processor.

The nice thing about code generation is that we can adjust some parameters in it and run it again. If a human coder makes the same mistake repeatedly, it has to be individually hunted down and fixed. If a code generator makes a systematic mistake, we fix that in the code generator and then just run it again on the code base.

Code generation is an anti-pattern when it costs more than it accomplishes. This situation occurs when generation takes place from A to B where A is almost the same language as B, but with some minor extensions that could be done just by coding in A with less effort than all the custom tooling and build staging for A to B.

The trade off is more prohibitive against code generation in languages that don't have meta-programming facilities (structural macros) because of the complications and inadequacies of achieving metaprogramming through the staging of external text processing.

The poor trade off could also have to do with the quantity of use. Language A could be substantially different from B, but the whole project with its custom code generator only uses A in one or two small places, so that the total amount of complexity (small bits of A, plus the A -> B code generator, plus the surrounding build staging) exceeds the complexity of a solution just done in B.

Basically, if we commit to code generation, we should probably "go big or go home": make it have substantial semantics, and use it a lot, or don't bother.