DEV Community: Alexander Novikov

MLIR, Nanopass, and Green-Red Trees: Compiler Ideas That Make Code Generators Better

Alexander Novikov — Mon, 23 Mar 2026 11:08:51 +0000

Most code generators are monolithic. A single class reads some input, makes a bunch of decisions, and spits out source files. It works until it doesn't — until you need to support another target language, until you need incremental builds, until a 2000-line generator method becomes everyone's least favorite file to touch.

I hit this wall while building Proto Wrapper Plugin, a tool that generates version-agnostic Java wrappers from multiple protobuf schemas. The generator worked fine, but every new feature meant wrestling with a monolith. Adding Kotlin support would have meant duplicating the entire thing.

So I went looking for better ideas. I found three — from compiler design, of all places — and they changed how I think about code generation entirely.

Update: These ideas have since been implemented as IRCraft — a standalone Scala 3 library for multi-language code generation with MLIR-inspired dialects, nanopass pipelines, and immutable green trees.

The Three Concepts

Concept	Origin	What it gives you
MLIR Dialects	LLVM/MLIR project	Structure — multiple abstraction levels with typed operations
Nanopass	Academic compiler research	Modularity — many small composable transformations
Green-Red Trees	Roslyn (C# compiler)	Immutability — safe, cacheable, incrementally updatable AST

Each one is powerful on its own. Together, they form an architecture that's extensible, testable, and surprisingly elegant.

Let's look at each one.

MLIR: Stop Mixing Abstraction Levels

The Idea

MLIR (Multi-Level Intermediate Representation) is an LLVM project that structures compiler IR into dialects — groups of operations at a specific abstraction level. Instead of one giant IR that represents everything from high-level constructs to machine instructions, MLIR lets you define separate dialects and lower between them progressively.

The key insight: different stages of compilation think in different abstractions. Forcing everything into one representation creates a mess.

How This Applies to Code Generation

A typical code generator goes straight from input to output:

Everything happens at once. The code that understands protobuf semantics is tangled with the code that knows Java syntax. Want to add Kotlin output? You'd need to rewrite everything.

With dialects, you get clean separation:

Each dialect defines its own operations — typed IR nodes that belong to that abstraction level. A MessageOp belongs to the Proto Dialect. A ClassOp belongs to the Semantic Dialect. You can't accidentally mix them.

The critical piece is the Semantic Dialect — it captures OOP concepts (classes, interfaces, methods, fields) without any language-specific details. This layer is shared. Adding Kotlin support means writing a new Code Dialect and an emission pass. The entire Proto → Semantic pipeline stays untouched.

Beyond Code Generators

The dialect idea applies anywhere you have multiple abstraction levels:

API gateways — represent requests at the protocol level (HTTP, gRPC), the domain level (business operations), and the backend level (database queries, service calls)
Configuration management — high-level intent ("deploy this service with 3 replicas"), mid-level plan ("create these Kubernetes resources"), low-level actions ("apply these YAML files")
Data pipelines — logical plan (what to compute), physical plan (how to compute it), execution plan (where to run it)

The pattern is always the same: define clean abstraction boundaries, type the operations at each level, and lower progressively.

Nanopass: Small Passes Beat Big Passes

The Idea

The Nanopass Framework comes from academic compiler research. Its premise is simple: instead of a few large compiler passes that each do many things, write many small passes that each do one thing.

A traditional compiler might have a "type checking" pass that also resolves overloads, infers types, checks visibility, and validates constraints. A nanopass compiler splits that into five separate passes, each focused on a single concern.

How This Applies to Code Generation

My original generator was one method that:

Read protobuf descriptors
Decided which messages to include
Resolved type references
Detected type conflicts between versions
Generated interfaces
Generated abstract classes
Generated implementations
Generated builders (conditionally)
Generated VersionContext factory
Wrote files

That's 10 responsibilities in one place. Testing any of them in isolation was nearly impossible.

With nanopass, each becomes a standalone transformation:

Each pass is a pure function: immutable input → immutable output. Each can be tested with a 10-line unit test. Each can be conditionally enabled:

// AddBuildersPass only runs when the user configured generateBuilders=true
@Override
public boolean isEnabled(PassContext context) {
    return context.getConfig("generateBuilders", false);
}

The Composition Problem

Small passes need a way to compose. In our case, it's a simple pipeline:

Pipeline<ProtoFileInput, List<JavaFile>> pipeline = Pipeline
    .from(ProtoFileInput.class)
    .then(new ParseProtoPass())
    .then(new ResolveTypesPass())
    .then(new FilterMessagesPass())
    .then(new ValidateProtoPass())
    // ... more passes
    .build();

List<JavaFile> output = pipeline.execute(input, context);

The pipeline handles execution order, skips disabled passes, and logs timing. Passes communicate through PassContext — a typed key-value store for shared data (e.g., a type registry built by one pass and consumed by another).

Beyond Code Generators

Nanopass is just the Single Responsibility Principle applied to data transformations. It works anywhere you have a processing pipeline:

Image processing — resize, crop, watermark, compress, optimize — each as a separate filter
Request validation — authenticate, authorize, validate schema, check rate limits, sanitize input — each as middleware
Data migration — extract, clean, transform, validate, load — each as a named step with independent rollback
Document processing — parse, normalize, enrich, validate, render — each as a pipeline stage

The pattern gives you testability (test each step alone), composability (add/remove/reorder steps), and observability (log/time each step independently).

Green-Red Trees: Immutability That Pays for Itself

The Idea

Green-Red Trees come from Roslyn, Microsoft's C# and VB.NET compiler. The problem Roslyn solves: an IDE needs to re-parse code on every keystroke, but re-creating the entire syntax tree each time is expensive.

The solution splits the tree into two layers:

Green tree (the data):

Immutable
Content-addressable (identity based on content, not object reference)
No parent references
Relative positions (width), not absolute

Red tree (the navigation):

Lightweight facade over green nodes
Adds parent references and absolute positions
Created lazily during traversal
Thrown away entirely on any change

The insight: most of the tree doesn't change between edits. If you insert a character on line 50, every node on lines 1-49 is structurally identical. With content-based identity, you can reuse those green nodes directly — no copying, no diffing.

How This Applies to Code Generation

All our IR nodes are immutable case classes. Each computes a contentHash from its content:

case class MessageOp(
    name: String,
    presentInVersions: Set[String],
    regions: Vector[Region],
    attributes: AttributeMap,
    span: Option[Span]
) extends Operation:

  lazy val contentHash: Int =
    ContentHash.combine(
      ContentHash.ofString(name),
      ContentHash.ofSet(presentInVersions),
      ContentHash.ofList(fields.toList)(using Operation.operationHashable)
    )

Two MessageOp nodes with the same content have the same hash. This gives us:

Change detection. After running a pass, compare output hash to input hash. Same hash? Nothing changed — skip downstream passes for this node.

Caching. Store contentHash → generated output mapping. If a proto file hasn't changed, reuse the previous output without running the pipeline.

Incremental builds. In a project with 50 proto files, changing one file triggers regeneration for only that file's IR subtree. Everything else is a cache hit.

The "red tree" layer (parent references, absolute positions) is planned for IDE integration — enabling "go to definition" and "find usages" across proto schemas and generated code.

Why Immutability Matters for Passes

Nanopass transformations are pure functions: GreenNode(v1) → GreenNode(v2). The input is never modified. This means:

No defensive copying. You know the input won't change under you.
Safe parallelism. Multiple passes can read the same input concurrently.
Time travel. Keep the input around for debugging — it's immutable, it won't change.
Structural sharing. If a pass only modifies 2 out of 20 fields in a message, the unmodified field ops are shared between input and output trees.

Beyond Code Generators

Immutable content-addressed trees appear in many systems:

Git — the entire object model (blobs, trees, commits) is content-addressed and immutable. Every git commit creates new tree objects while sharing unchanged blobs.
React — virtual DOM diffing works because components produce immutable trees that can be compared efficiently.
Nix — the package manager uses content-addressed derivations. Same inputs always produce the same output hash.
Persistent data structures — Clojure's vectors, maps, and sets use structural sharing to create "modified" copies in O(log n) time.
Event sourcing — events are immutable facts. State is derived by replaying events, with snapshots as caching.

The principle is the same: make data immutable, identify it by content, share structure where possible.

How They Work Together

The three concepts are complementary:

Dialects define the abstraction levels (where)
Passes define the transformations (how)
Green nodes define the data model (what)

Each pass is a pure function: GreenNode(v1) → GreenNode(v2). Input is never modified. This means no defensive copying, safe parallelism, and the ability to keep previous IR versions around for debugging.

When to Use These Ideas

You don't need all three concepts, and you don't need to build a full compiler framework. Here's when each one pays off:

MLIR Dialects — when your system has multiple abstraction levels and you're fighting the urge to put everything in one data model. If you find yourself adding "kind" or "type" fields to distinguish between fundamentally different operations, you probably want dialects.

Nanopass — when you have a processing pipeline with more than 3-4 concerns. If your generate() or process() method is over 200 lines and growing, break it into passes.

Green-Red Trees — when you need change detection, caching, or incremental processing. If your data is already immutable (or should be), content hashing is a natural extension.

Practical Advice

Start with nanopass. It's the easiest to adopt and gives the most immediate benefit. Take your monolithic processor, identify the distinct responsibilities, and extract them into passes. You'll immediately gain testability.

Add content hashing when you need caching. If your pipeline runs on every build and takes noticeable time, add contentHash() to your data types. Use it for short-circuiting ("nothing changed, skip this pass") and caching ("same input, return cached output").

Introduce dialects when you add a second target. If you only generate Java, one abstraction level might be fine. The moment you need Kotlin, TypeScript, or any second output format, the dialect split pays for itself instantly.

Don't over-abstract. These are tools, not rules. A 50-line code generator doesn't need an IR framework. Use the ideas when the complexity justifies them — and not a moment sooner.

Do You Still Need Computer Science in the Age of AI

Alexander Novikov — Fri, 20 Mar 2026 23:10:21 +0000

"Maybe I Should Become a Welder"

A colleague recently told me about a conversation with someone at Amazon. The person described how the company is aggressively pushing AI tools for code generation — management pressure to move faster, ship more, spend less. My colleague, twenty years in the industry, went quiet afterward. "Maybe I should learn welding," he joked. It was only half a joke.

I get it. When you've spent twenty years in this profession and keep hearing that any intern with Copilot will soon do the same thing — it hits not your skills, but your identity. The sense that everything you've learned actually mattered.

Amazon, like any large company, has plenty of strong engineers who've given years to the craft and understand exactly what's happening. But popular opinion doesn't make distinctions: why learn algorithms if AI will write them? Why bother with design patterns if Claude or Copilot can generate a working service in an hour? Why understand how a hash table works when the library gives you one out of the box? It seems like you just need to ask — "build me a service" — and it all works out.

I disagree. Not because I'm defending my profession. But because I can see where mindless use of a tool leads.

A Tool, Not a Replacement

There was a time when we wrote code in terminal editors. Vim, Emacs — rough days. Then came Eclipse, Visual Studio, IntelliJ IDEA. It was a quantum leap in productivity: autocomplete, refactoring, debugger, VCS integration. Nobody said IDEs replaced programmers. IDEs made programmers faster.

But using even an IDE mindlessly comes at a cost. I once came across job postings — from different companies, so this wasn't a one-off — that listed as a requirement: "ability to write and run a Java program outside of IntelliJ IDEA." I laughed for a while, then stopped to think. People had become so dependent on the tool that they couldn't perform a basic task without it. They didn't understand what was happening under the hood.

AI is the next step in that same evolution. A more powerful tool. But still a tool. And depending on it without understanding the fundamentals leads to the same place — only the stakes are higher.

What AI Actually Automated

Let's be honest: what does AI do well?

It's excellent at generating boilerplate code. CRUD services, data mapping, standard integrations — everything an experienced developer writes on autopilot, AI writes faster. That's real value, and arguing against it is pointless.

But AI doesn't understand your business context. It doesn't know why you chose eventual consistency over strong consistency. It can't see that your current load will grow tenfold in six months. It doesn't account for the fact that this service will be maintained by a team of three, not twenty. AI doesn't make architectural decisions — it generates code within the decisions that you (or nobody) made for it.

And that "or nobody" is key. If you don't make a decision deliberately, AI will make it for you. Quietly, confidently, and unconsciously.

Two Price Tags

Every piece of software has two costs: the cost of writing it and the cost of maintaining it. The second is almost always several times higher.

AI has radically reduced the first cost. Generating code is fast, cheap, practically free. But it hasn't reduced the cost of maintenance. If anything, it's made it worse: when code is generated ten times faster, it needs to be reviewed ten times more. And if there's no review, or the reviewer doesn't understand what they're looking at — the cost of maintenance grows exponentially.

Code that's easy to write and expensive to maintain isn't a savings. It's technical debt taken out at a high interest rate.

What Happens Without Oversight

This isn't theory. In March 2026, Amazon faced a series of incidents tied to AI-generated code. On March 2nd — 120,000 lost orders and 1.6 million website errors. On March 5th — a 99% drop in orders across North America: 6.3 million lost orders in a single day. In a separate case, the AI agent Kiro, attempting to fix an issue with a cost calculation system, decided to delete and recreate the environment from scratch. Thirteen hours of downtime.

Amazon's response is telling. Not abandoning AI. Tightening the requirements for reviewer qualifications. Now any AI-assisted code must be approved by a senior engineer before deployment. Amazon essentially confirmed: the problem isn't the tool — it's who's using it.

And this isn't just Amazon. According to CodeRabbit, AI-generated code contains 1.7x more bugs than human-written code. 1.75x more logic errors. 1.57x more security issues. And eight times more unnecessary I/O operations. In 2025, pull requests per developer increased by 20%, while incidents per PR rose by 23.5%. More code — more problems.

A telling case: in February 2026, AI generated code using Promise.all that fired 4,200 simultaneous requests for user data synchronization. The connection pool couldn't handle it — twenty-two minutes of downtime. Anyone who understands concurrency and backpressure would have spotted the problem in seconds. But whoever accepted this code either wasn't taught that, or decided it no longer mattered.

The Language of Task Definition

And this brings us to the main point. Why do you need Computer Science if the machine writes the code?

Not to write a sorting algorithm on a whiteboard during an interview. Not to memorize the pseudocode for depth-first search. That really is routine work, and yes, the machine can reproduce it.

The value of Computer Science is in the conceptual framework. In the ability to think systematically, decompose problems, distinguish between abstractions, understand constraints and trade-offs. In the ability to verify what AI just generated for you.

Without terminology, a person says: "rewrite this better," "something's off here," "make it look nice," "speed it up," "fix the architecture." Fix it how? Speed up in what direction? What does "better" mean?

With terminology, a person says: isolate the domain from infrastructure, wire dependencies through IoC, implement an adapter for the legacy API integration, replace branching with the strategy pattern, reduce coupling, separate component responsibilities, fix the abstraction leak, break circular dependencies, extract object creation into a factory. Use a doubly linked list instead of an array, optimize hash table collisions, reduce unnecessary allocations. Protect the module from race conditions, add backpressure, use a circuit breaker. Don't mix application service with domain service, preserve aggregate invariants, make the operation idempotent.

The first person asks AI to guess what they mean. The second precisely defines the task. And more importantly, the second one can verify the result.

CS as a Frame of Reference

I'm not saying you need to implement a hash table from scratch with your eyes closed. I'm saying you need to understand how it works — so you can notice when AI suggests the wrong data structure. You don't need to remember Dijkstra's implementation — but you need to understand algorithmic complexity to see when AI produces O(n²) where O(n log n) would do.

Though it's still better to both understand and know how to implement. Or at least strive for it.

Computer Science isn't a set of skills you need to reproduce by hand. It's a frame of reference in which you think about software. IoC, SOLID, GRASP, DDD, Clean Architecture, CQRS, Event Sourcing, CAP theorem, ACID, consistency models, memory model, cache locality, idempotency, fault tolerance — these aren't for exams. They're a working vocabulary that lets you define tasks precisely, review results meaningfully, and tell working architecture from a convincing-looking hallucination.

Not About Fear

I'm not trying to scare anyone. AI is a breakthrough, and I use it every day. It makes me more productive. But it doesn't make me unnecessary — just as IntelliJ didn't make Java developers unnecessary.

To that colleague who joked about becoming a welder, I'd say: your twenty years of experience haven't lost their value. They've become more valuable. Because now you're needed not to write code, but to understand what's been written. To control quality. To make architectural decisions. To spot design flaws before they become production incidents.

Computer Science matters. Maybe more than ever. Just not the kind they ask about in interviews. The kind that lets you think.

Originally published at alnovis.io on March 20, 2026.

Proto Wrapper Plugin: How I Stopped Fighting Protobuf Versioning

Alexander Novikov — Wed, 04 Mar 2026 12:03:59 +0000

If you've ever worked on a system that processes protobuf messages from multiple protocol versions, you know the pain. You add a new field, change a type from int32 to enum, and suddenly your codebase is littered with if (version == 1) ... else if (version == 2) blocks.

I built Proto Wrapper Plugin to solve this problem once and for all.

The Pain Point

Here's a typical scenario. You have a payment processing system. Version 1 of your protocol uses an integer for payment type:

// v1/payment.proto
message Payment {
  int32 payment_type = 1;  // 1=cash, 2=card, 3=transfer
}

Then someone decides (rightfully so) that enums are better:

// v2/payment.proto
message Payment {
  PaymentType payment_type = 1;
}

enum PaymentType {
  CASH = 1;
  CARD = 2;
  TRANSFER = 3;
}

Now your code looks like this:

// This is everywhere in your codebase
if (protocolVersion == 1) {
    int type = paymentV1.getPaymentType();
    processPayment(type);
} else if (protocolVersion == 2) {
    PaymentType type = paymentV2.getPaymentType();
    processPayment(type.getNumber());
}

Multiply this by dozens of messages, and you have a maintenance nightmare.

The Solution: One Interface to Rule Them All

Proto Wrapper generates a unified Java API that works across all your protocol versions:

// Single code path. Works with v1, v2, v3... whatever.
Payment payment = versionContext.wrapPayment(anyProto);
int type = payment.getPaymentType();  // Always returns int
PaymentType typeEnum = payment.getPaymentTypeEnum();  // Returns enum when available

byte[] bytes = payment.toBytes();  // Serializes back to original version

The plugin analyzes your proto schemas, detects conflicts, and generates appropriate accessors. You write version-agnostic code, and the generated wrappers handle the details.

Getting Started

Add the plugin to your Maven build:

<plugin>
    <groupId>io.alnovis</groupId>
    <artifactId>proto-wrapper-maven-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <basePackage>com.example.model</basePackage>
        <protoRoot>${basedir}/proto</protoRoot>
        <versions>
            <version><protoDir>v1</protoDir></version>
            <version><protoDir>v2</protoDir></version>
        </versions>
    </configuration>
    <executions>
        <execution><goals><goal>generate</goal></goals></execution>
    </executions>
</plugin>

Or if you prefer Gradle:

plugins {
    id("io.alnovis.proto-wrapper") version "2.3.2"
}

protoWrapper {
    basePackage.set("com.example.model")
    protoRoot.set(file("proto"))
    versions {
        version("v1")
        version("v2")
    }
}

Run mvn generate-sources or ./gradlew generateProtoWrapper, and you get a clean API.

What Conflicts Can It Handle?

Over time, I've added support for pretty much every type conflict I've encountered in production:

INT_ENUM — The most common one. Field starts as int32, becomes enum. You get both getField() (returns int) and getFieldEnum() (returns enum).

ENUM_ENUM — Two different enums across versions. Unified as int with enum conversion methods.

WIDENING — int32 grows to int64. The wrapper uses long everywhere, with runtime validation for versions that need the narrower type.

FLOAT_DOUBLE — Precision change from float to double. Unified as double.

SIGNED_UNSIGNED — int32 vs uint32, sint32 vs int32. Unified as long with proper range validation.

PRIMITIVE_MESSAGE — A simple int64 total becomes Money total with amount and currency. You get getTotal() for primitive versions and getTotalMessage() for message versions.

STRING_BYTES — Someone decides string should be bytes. Dual accessors handle the conversion.

REPEATED_SINGLE — Field changes from singular to repeated or vice versa. Returns List in all cases.

FIELD_RENUMBER — Sometimes field numbers change between versions (legacy systems, don't ask). You can explicitly map them:

<fieldMappings>
    <fieldMapping>
        <message>Order</message>
        <fieldName>parent_ref</fieldName>
        <versionNumbers>
            <v1>3</v1>
            <v2>5</v2>
        </versionNumbers>
    </fieldMapping>
</fieldMappings>

The diff tool can even detect suspected renumbering and suggest the configuration.

Batteries Included

A few things that make life easier:

No protoc installation required. The plugin downloads the right protoc binary for your platform automatically. Just works.

Incremental builds. Changed one proto file? Only affected wrappers regenerate. Saves 50%+ build time on large projects.

Well-known types conversion. google.protobuf.Timestamp becomes java.time.Instant. Duration becomes java.time.Duration. No more manual conversions.

Builder pattern. Full support for creating and modifying messages:

Payment payment = Payment.newBuilder(ctx)
    .setPaymentType(PaymentType.CARD)
    .setAmount(Money.newBuilder(ctx)
        .setValue(1000)
        .setCurrency("USD")
        .build())
    .build();

Spring Boot Starter. For Spring Boot 3+ projects, there's an auto-configuration that handles version context per HTTP request.

Schema Diff Tool

Before deploying a new protocol version, you probably want to know what changed. The built-in diff tool helps:

mvn proto-wrapper:diff -Dv1=proto/v1 -Dv2=proto/v2

It shows added/removed fields, type changes, and flags breaking changes. You can integrate it into CI to catch compatibility issues before they hit production:

mvn proto-wrapper:diff -Dv1=proto/production -Dv2=proto/development -DfailOnBreaking=true

Output formats include text, JSON, and Markdown for reports.

Version Constants

No more magic strings. The plugin generates a ProtocolVersions class:

// Compile-time constants
String version = ProtocolVersions.V1;

// Runtime validation
if (ProtocolVersions.isSupported(versionId)) {
    VersionContext ctx = VersionContext.forVersionId(versionId);
}

// Fail fast on unknown versions
ProtocolVersions.requireSupported(versionId);

The Generated Code

Here's what the structure looks like:

com/example/model/
├── api/
│   ├── Payment.java           # Interface
│   ├── PaymentType.java       # Unified enum
│   ├── VersionContext.java    # Factory
│   ├── ProtocolVersions.java  # Constants
│   └── impl/
│       └── AbstractPayment.java
├── v1/
│   ├── PaymentV1.java
│   └── VersionContextV1.java
└── v2/
    ├── PaymentV2.java
    └── VersionContextV2.java

The generated code is plain Java. No runtime dependencies beyond protobuf itself. You can read it, debug it, understand it.

Links

The plugin is open source (Apache 2.0) and actively maintained. If you're dealing with protobuf versioning headaches, give it a try.

DEV Community: Alexander Novikov

MLIR, Nanopass, and Green-Red Trees: Compiler Ideas That Make Code Generators Better

The Three Concepts

MLIR: Stop Mixing Abstraction Levels

The Idea

How This Applies to Code Generation

Beyond Code Generators

Nanopass: Small Passes Beat Big Passes

The Idea

How This Applies to Code Generation

The Composition Problem

Beyond Code Generators

Green-Red Trees: Immutability That Pays for Itself

The Idea

How This Applies to Code Generation

Why Immutability Matters for Passes

Beyond Code Generators

How They Work Together

When to Use These Ideas

Practical Advice

Further Reading

Do You Still Need Computer Science in the Age of AI

"Maybe I Should Become a Welder"

A Tool, Not a Replacement

What AI Actually Automated

Two Price Tags

What Happens Without Oversight

The Language of Task Definition

CS as a Frame of Reference

Not About Fear

Proto Wrapper Plugin: How I Stopped Fighting Protobuf Versioning

The Pain Point

The Solution: One Interface to Rule Them All

Getting Started

What Conflicts Can It Handle?

Batteries Included

Schema Diff Tool

Version Constants

The Generated Code

Links