Metaprogramming: Unlocking code automation
Table of contents

Metaprogramming is the art of writing programs that generate or transform other programs. In practice, it means letting the computer take care of the repetitive, boilerplate parts of your code so you can focus on logic and design.
The mindset of automating what can be automated closely mirrors the role of AI in software development, where models are taking on more of the writing, reviewing, and even reasoning around code. The difference lies in focus: AI brings intelligence and adaptability into the tools, while metaprogramming brings structure and intent — you define the rules, and the machine executes them precisely.
Metaprogramming and AI: Two sides of the same coin
Metaprogramming and AI share a common goal: reducing the amount of manual work developers need to do by generating code automatically.
While metaprogramming relies on explicitly defined rules and structures to produce code, like templates or compiler-time generators, AI models take a more flexible, learned approach. But in both cases, the result is the same: The machine writes code for you.
That’s why the two often go hand in hand and are sometimes used interchangeably in practice. When tools like Claude Code or ChatGPT generate a Python script or TypeScript client from your natural language prompt, they’re essentially performing metaprogramming, in that they’re writing a program that writes a program. The main difference is that AI does it probabilistically, while traditional metaprogramming does it deterministically.
Both are powerful, and both are reshaping how modern software is built.
The power of code generation in .NET
Why generate code at all?
- Eliminate duplication — Generated classes remove copy‑and‑paste hazards.
- Guarantee consistency — If a schema changes, regenerate the artefacts instead of hunting for manual edits.
- Enable compile‑time safety — With Source Generators(opens in a new tab), the new code is compiled along with the rest of the project, so type errors surface immediately.
Automation therefore acts as a force‑multiplier: Instead of writing thousands of lines by hand, you write a generator once and let the machine do the rest.
In .NET this idea isn’t new: Text Template Transformation Toolkit, or T4, has been available for more than a decade. But the arrival of Source Generators in the Roslyn compiler has changed the landscape. Together, these two techniques let you automate everything from data‑transfer objects to entire configuration layers, while keeping your codebase type‑safe and maintainable.
T4 templates
T4 files (*.tt
) are text templates that mix plain text with control blocks written in C#. When a template runs, it produces any text you like (often C# source files, but not necesarily). That file can then be compiled or fed to another tool (such as Visual Studio).
A minimal example:
<#@ template language="C#" #><#@ output extension=".cs" #>namespace Generated{ public static class <#= ClassName #>Extensions { public static string Describe(this <#= ClassName #> item) { return $"Instance of {nameof(<#= ClassName #>)}"; } }}
Set ClassName
in the template parameters and save, and a new .cs
file appears. Because the file is generated before compilation, no runtime cost is incurred. Visual Studio ships with a T4 engine(opens in a new tab), and since 2023, it’s also possible to invoke T4 from the command line(opens in a new tab) in .NET 6+ projects, making it CI‑friendly.
Strengths
- Works in any .NET version.
- Generates any text, not just C#.
- Simple to start: Add a
.tt
file and press save.
Limitations
- Runs outside the compiler pipeline, so it cannot inspect the typed syntax tree.
- Debugging templates can be awkward.
- Large templates can become hard to read because logic and text are interleaved.
Source Generators
Source Generators(opens in a new tab) are a Roslyn compiler feature introduced in .NET 5 and expanded in later releases. A generator is a class that implements ISourceGenerator
(or the newer incremental APIs(opens in a new tab)). During compilation, the generator receives the current Compilation
object — including full syntax and semantic models — and then emits additional C# source code that’s fed right back into the same compilation.
Here’s a stripped‑down incremental generator:
[Generator]public sealed class NotifyGenerator : IIncrementalGenerator{ public void Initialize(IncrementalGeneratorInitializationContext ctx) { var classes = ctx.SyntaxProvider .CreateSyntaxProvider(IsCandidate, Transform) .Where(static m => m is not null);
ctx.RegisterSourceOutput(classes, static (spc, source) => { spc.AddSource($"{source!.Name}.g.cs", Generate(source)); }); } /* helper methods omitted for brevity */}
At build time, the compiler:
- Filters syntax nodes (e.g. classes marked with
[AutoNotify]
). - Builds an abstract representation (AST) you can walk.
- Emits new
.g.cs
files that participate in the same compilation unit.
Microsoft ships official generators — for example, the configuration‑binding generator(opens in a new tab) added in .NET 8 that replaces reflection with compile‑time code.
Strengths
- Full access to the typed abstract syntax tree, symbols, and semantic information.
- Generated code is visible in IDEs with “Go to definition.”
- Runs on every build; no separate tooling step.
Limitations
- Requires the analyzer SDK infrastructure.
- Only produces C# source files: no arbitrary text like T4.
- More initial boilerplate than a T4 file.
- Slightly more difficult to debug and write.
A short detour: Understanding ASTs
An Abstract Syntax Tree (AST)(opens in a new tab) is a tree representation of code after tokenization and parsing. Each node represents a language construct: Namespaces contain classes, classes contain methods, and methods contain statements and expressions. Generators traverse this tree to decide what to emit.
Although .NET developers use Roslyn’s AST, the idea is universal. In C++ tooling, for instance, Clang(opens in a new tab) exposes its AST so that static‑analysis tools can match patterns or rewrite code automatically. Seeing the same abstraction across ecosystems helps explain why metaprogramming techniques feel similar even when languages differ.
T4 vs. Source Generators
Feature | T4 templates | Source Generators |
---|---|---|
Execution time | Design‑time or via CLI prior to compilation | During compilation, inside Roslyn |
Input data | Arbitrary files, SQL, HTTP, anything available on disk | Current compilation: Syntax trees, symbols; additional files via AdditionalFiles |
Output | Any text (C#, XML, HTML, etc.) | C# code only |
IDE integration | Generates physical files on save; shows in Solution Explorer | Generates virtual *.g.cs files visible in IDE; updates on build |
Typical use cases | Large boilerplate artefacts, code from external schemas, code + docs bundles | Compile‑time augmentation (e.g. INotifyPropertyChanged ), interception, AOT‑friendly replacements |
Learning curve | Low; template language is ordinary C# | Moderate; requires understanding Roslyn APIs |
Performance impact | None at runtime; can slow design time if templates are heavy | Slightly longer builds; zero runtime cost |
Choosing the right tool
If you need to generate non‑C# artefacts (HTML, SQL scripts) or you want a quick design‑time shortcut, T4 remains valuable. Its templates are easy to version‑control and run in any environment where the T4 engine exists.
When you need to augment user code with strong typing — for example, to replace reflection, remove runtime emit, or intercept API calls in AOT scenarios, Source Generators are the modern answer. They keep generated code indoors, reviewed by the compiler, and visible in the IDE without polluting the repository with checked‑in artefacts.
In many organizations, the two live side by side: T4 for scaffolding large initial files, and Source Generators for fine‑grained compile‑time weaving.
Putting metaprogramming to work at Nutrient
At Nutrient, we use both T4 templates and Source Generators to automate parts of our development process where manual work would be repetitive and error-prone — for instance, in our .NET SDK and Java SDK. But these aren’t the only places, as T4 can be used anywhere. We use it as a general purpose template generator.
We rely on these techniques to generate consistent, reliable code — from scaffolding models to injecting configuration or logic automatically. This not only speeds up development, but it also helps us maintain high quality by reducing the risk of inconsistencies or missing pieces.
By letting the tools handle what’s repetitive, our engineers can focus more on product design and bringing new innovative capacities. This approach doesn’t just make our SDK better; it strengthens the overall quality and reliability of everything we build.
Conclusion
Software projects rarely fail because we wrote too little code. They fail when duplicated logic drifts apart, when human error creeps into boilerplate, or when maintenance grinds to a halt. Metaprogramming flips that script. By using T4 templates for broad‑brush text generation and Source Generators for precise compile‑time augmentation, developers can offload repetition to the machine and focus on the genuinely difficult problems.
The next time you add a hundred similar properties by hand, ask yourself whether the compiler could do it for you. Code that writes code isn’t magic; it’s simply the right tool applied at the right point in the pipeline. Be clever, automate the mundane, and let your creativity tackle what truly matters.