惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog
D
Docker
J
Java Code Geeks
腾讯CDC
Blog — PlanetScale
Blog — PlanetScale
G
Google Developers Blog
M
MIT News - Artificial intelligence
L
LangChain Blog
T
The Blog of Author Tim Ferriss
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
博客园 - Franky
GbyAI
GbyAI
Hugging Face - Blog
Hugging Face - Blog
aimingoo的专栏
aimingoo的专栏
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 聂微东
N
Netflix TechBlog - Medium
B
Blog RSS Feed
Y
Y Combinator Blog
阮一峰的网络日志
阮一峰的网络日志
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News

Inside Nutrient

A guide to the invisible work behind documents Introducing Nutrient Documents for Salesforce: Native document generation and signing Document AI vs. traditional OCR: Choosing between OCR, AI, and hybrid pipelines PDF SDK compliance and security evaluation checklist for enterprise teams (2026) Invariant Corp replaces paper processes with Nutrient Workflow and scales without limits What is process mapping? A complete guide Nutrient vs. Conga Composer for Salesforce document generation (2026) Document routing: How to automate document distribution The CTO’s AI playbook: Why accountability architecture beats orchestration Compliance workflow automation: Why built-in compliance is table stakes Workflow diagrams: Examples, symbols, and how to build one that actually runs Digital forms: Replace paper forms with automated workflows Approval workflow software: How to automate approvals Why document-centric automation is different The CEO’s AI playbook: Why decision architecture beats model selection Nutrient SDK product updates for Q1 2026 PDF redaction verification: How to prove sensitive data is permanently removed What is a VPAT? The complete guide to accessibility conformance reports What is PDF/UA? The accessible PDF standard explained Salesforce eSignatures: Generate, sign, and track documents in one flow Online document viewer: Options, tradeoffs, and how to embed one Document viewer for web apps: React, Vue, Angular (2026) Best document viewers in 2026: A buyer’s guide How to edit a PDF in Python: Add text, images, and annotations Nutrient advances Workflow platform with agentic AI for enterprise-grade speed and consistency in document-heavy operations How to create a Salesforce quote template from opportunity data The business case for accessibility: Five ways it drives enterprise value Python PDF library comparison (2026): 7 libraries for developers Why your AI agent hallucinates PDF table data PDF.js limitations: When to upgrade to a commercial PDF SDK
Metaprogramming: Unlocking code automation
Etienne Alby · 2025-09-18 · via Inside Nutrient

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 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?

  1. Eliminate duplication — Generated classes remove copy‑and‑paste hazards.
  2. Guarantee consistency — If a schema changes, regenerate the artefacts instead of hunting for manual edits.
  3. 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:

  1. Filters syntax nodes (e.g. classes marked with [AutoNotify]).
  2. Builds an abstract representation (AST) you can walk.
  3. 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

FeatureT4 templatesSource Generators
Execution timeDesign‑time or via CLI prior to compilationDuring compilation, inside Roslyn
Input dataArbitrary files, SQL, HTTP, anything available on diskCurrent compilation: Syntax trees, symbols; additional files via AdditionalFiles
OutputAny text (C#, XML, HTML, etc.)C# code only
IDE integrationGenerates physical files on save; shows in Solution ExplorerGenerates virtual *.g.cs files visible in IDE; updates on build
Typical use casesLarge boilerplate artefacts, code from external schemas, code + docs bundlesCompile‑time augmentation (e.g. INotifyPropertyChanged), interception, AOT‑friendly replacements
Learning curveLow; template language is ordinary C#Moderate; requires understanding Roslyn APIs
Performance impactNone at runtime; can slow design time if templates are heavySlightly longer builds; zero runtime cost

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.

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.