But is it similar to how a compiler uses high level syntax to generate low level assembly code?

This is an apt comparison, actually.

Is compiling a type of automatic code generation?

This is also an apt comparison. Most modern languages are interpreted rather than compiled. C#*, Java, Ruby, Python, Perl… these all sit on top of runtimes or virtual machines such as .NET or JVM. Compilation is a process of turning human-readable language into assembly. Interpreting turns human-readable programming language into instructions for the runtime; in the case of .NET, C# gets interpreted into MSIL which tells the .NET runtime what to do, which in turn tells the hardware what to do.

Automatic code generation is more of “Hey computer, look at that code. Now translate that code to do different things, but use these templates I made.”

FWIW, compilers was two semesters in engineering school, so I’m trying to keep this discussion accessible.

*Before anyone rightfully and correctly jumps on my shit about C#, yes, I know C# is technically a compiled language.

Is automatic code generation LLM

Not at all. In my case, automatic code generation is a process of automated parsing of an existing Ruby on Rails API code plus some machine-readable comments/syntax I created in the RoR codebase. The way this API was built and versioned, no existing Gem could be used to generate docs. The code generation part is a set of C# “templates” and a parser I built. The parser takes the Ruby API code plus my comments, and generates unit and integration tests for nUnit. This is probably the most common use case for automatic code generation. But… doesn’t building unit tests based on existing code potentially create a bad unit test? I’m glad you asked!

The API endpoints are vetted and have their own RoR tests. We rebuilt this API in something more performant than Ruby before we moved it to the cloud. I also built generators that output ASP.NET API endpoint stubs with documentation. So the stubs just get filled out and the test suite is already built. Run Swashbuckle on the new code and out comes the OpenAPI spec, which is then used to build our documentation site and SDKs. The SDKs and docs site are updated in lockstep with any changes to the API.

Edit: extra word and spaces

I tightly curated my feeds to stick to trusted sources on specific topics. The most “controversial” topic in my feed might be how to cook certain things certain ways or maybe business analysis. The rest of my topics are known, trustworthy primary sources for things such as software, electrical, and mechanical engineering, culinary science and techniques.

There’s also a bunch of “how to more efficiently do [thing that I already do] with [system I already use/own].” It’s pretty difficult to get suckered into misinformation on techniques for automatic code generation in C# or how to cook a carbonara sauce from the author whose books I already own.

Something that really helps is never clicking on anything like “I should have bought this years ago” or any similar shit. I realize that I might be missing out on things that would actually make a certain task easier. But if it’s really life changing, I’m sure one of my trusted sources, online or otherwise, will get around to suggesting it to me.

Staying away from talking heads, even ones I like, goes a very long way to preventing blatant bullshit ever getting suggested. I click quite often on “don’t suggest again.” It’s a chunk of effort up front, but then it’s a small amount of maintenance from there.

This response is so boot-lickingly simplistic and lacking in context and nuance. I wish I could get to live in the world where this blanket statement just made everything okay again. It’s almost as if you actually have no reasonable counter to the points raised by the commentor.