Generators are All You Need

Randolf J. — Wed, 16 Sep 2026 00:52:22 +0000

If you've been in development long enough, you know that one of the hardest parts of coding is building on top of existing code. I remember reading a statistic suggesting that starting a codebase from scratch is faster than building on an existing one. With AI, some of that has gotten better. But we also spend a lot of time forcing AI to work within the code we already have, and that comes with its own problems. If I were to make up a statistic myself, I'd probably say it's still faster to have an AI build something from scratch than to have it wrestle with an existing implementation.

One place I keep running into this is with open source.

I love open source. I've personally maintained one of the largest open source codebases on GitHub. But when you're using it inside a company, you can spend a surprising amount of time dealing with bugs, gaps in functionality, and dependencies that nobody has had time to maintain. And I get it. People are often doing this work for free. I don't think it's reasonable to expect them to deliver everything our company needs.

Still, we spend a lot of time trying to make those dependencies fit our codebase.

Some of the most important tools we use are generators: things that generate OpenAPI documents, internal APIs, or the scaffolding we build the rest of the application on. At one point, I spent maybe a month trying to get code generators to work. I had an AI go through OpenAPI generators across every language and every one we tried was missing something that prevented it from handling the full specification we needed.

Usually, you'd patch the dependency or vendor it and maintain your own copy. But I wanted to experiment, so I thought, why not have a coding agent build the generator?

My hypothesis was pretty simple. Coding agents are good at problems where they can verify the result, and generators seem like a good fit for that. You have a specification. You have an expected output. You can define the behavior through a contract and check it with end-to-end tests. The agent has something concrete to work toward and a way to tell whether it's getting there.

It took me one hour to build the generator.

I remember thinking, why did I spend a month trying to force all of this to work?

That experience changed how I thought about where to use AI. As these models get smarter, and I mean really smart, to the point where maybe they can even solve Navier-Stokes, I expect them to get very good at building things like compilers and generators. Even with what we have today, having an agent build a generator can be more efficient than writing and maintaining all the code it produces.

So we went on a bit of an escapade and converted a vast majority of our code to generated code. By that, I mean we had an AI build the generators, then used those generators to produce code from specifications. Kind of meta, but it works.

It's been much easier to maintain. Our generators contain less code than the code they produce, so we have less to work through when something needs to change. We change the generator, regenerate the code, and that change carries through the rest of the codebase. We've found that having an AI repair the generator is often more efficient than having it work through all the handwritten code we'd otherwise need to maintain.

This feels like a different way of working from asking an AI to vibe code an entire app, or having a human write the whole thing by hand. We're putting more of the work into the specifications and the generators, and we're using tests to check that the generated code does what we expect.

Based on my experience, I think a lot of coding could end up looking like this. We'll maintain a collection of generators and use them to produce the code we need. There's still work in defining the contract and making sure our tests cover it. But once we have a contract we can verify, we give the agent a problem it can keep testing and refining.

Readable stack traces in production: source maps + OpenTelemetry

Randolf J. — Tue, 10 Mar 2026 10:35:11 +0000

Two years ago I left Sentry and moved to OpenTelemetry. The one thing I had to rebuild was source map resolution. I built smapped-traces internally to do it, and we are open sourcing it now that it has run in production for two years.

The problem with naive approaches

Serving source maps from your build output exposes your source code publicly. Restricting access requires your error handler to authenticate against a source map server at resolution time, which is complexity you do not want in that path. Bundling source maps into your collector configuration does not work either; the collector has no stable way to associate a map with a minified file across deployments.

Debug IDs

The approach I landed on uses debug IDs, a mechanism now supported by Turbopack natively and by webpack via the TC39 proposal. At build time, the bundler generates a UUID per source file and writes it into both the compiled output and the corresponding .js.map as a debugId field. It also injects a runtime global (_debugIds for Turbopack, __DEBUG_IDS__ for webpack) mapping source URLs to those UUIDs.

Any stack frame URL resolves to its source map without scanning or path matching.

Architecture

Browser                     Your server             OTel collector
  │                              │                       │
  │  SourceMappedSpanExporter    │                       │
  │  (attaches debug IDs to      │                       │
  │   exception events)          │                       │
  │──────────────────────────────▶  createTracesHandler  │
  │                              │  (resolves stack      │
  │                              │   traces via store)   │
  │                              │──────────────────────▶│

@smapped-traces/nextjs hooks into runAfterProductionCompile, extracts the debugId from every .js.map, uploads the content to a store, and deletes the map files from the build output.

On the client, SourceMappedSpanExporter wraps your span exporter. On exception events, it reads the debug ID globals, resolves each frame URL to a debug ID, and attaches them as span attributes before forwarding as standard OTLP.

createTracesHandler() runs on your server. It receives OTLP traces, resolves each debug ID against the store, rewrites the stack frames with original file and line information, and forwards to your collector. The minified trace is preserved as exception.stacktrace.original.

Setup (Next.js)

npm install smapped-traces @smapped-traces/nextjs @smapped-traces/sqlite

// next.config.mjs
import { withSourceMaps } from "@smapped-traces/nextjs";
import { createSqliteStore } from "@smapped-traces/sqlite";
import { join } from "node:path";

export default withSourceMaps(
  {
    /* your existing config */
  },
  { store: (distDir) => createSqliteStore(join(distDir, "sourcemaps.db")) },
);

// instrumentation-client.ts
import { SourceMappedSpanExporter } from "smapped-traces/client";
import { SimpleSpanProcessor } from "@opentelemetry/sdk-trace-base";
import { WebTracerProvider } from "@opentelemetry/sdk-trace-web";

const exporter = new SourceMappedSpanExporter("/api/sourcemaps");
new WebTracerProvider({
  spanProcessors: [new SimpleSpanProcessor(exporter)],
}).register();

// app/api/sourcemaps/route.ts
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
import { createTracesHandler } from "smapped-traces/route";
import { createSqliteStore } from "@smapped-traces/sqlite";
import { join } from "node:path";

export const POST = createTracesHandler({
  exporter: new OTLPTraceExporter({
    url: `${process.env.OTEL_EXPORTER_OTLP_ENDPOINT ?? "http://localhost:4318"}/v1/traces`,
  }),
  store: createSqliteStore(join(process.cwd(), ".next/sourcemaps.db")),
});

Storage

SourceMapStore is an interface over get(debugId) and put(debugId, content). Three implementations are included:

createSqliteStore(path) — local SQLite via better-sqlite3
createS3Store({ client, bucket, prefix? }) — any S3-compatible backend (AWS, Cloudflare R2, GCS)
createHttpStore(url) — HTTP client against a createStoreHandler() deployment

For distributed or serverless environments, point both the build plugin and the handler at the same shared store.

Runtime compatibility

The handler uses standard Web Request/Response and has no Node.js dependencies, so it runs in Bun, Deno, Cloudflare Workers, or any edge runtime. For non-Next.js builds, source map collection is a loop over build artifacts calling store.put(debugId, content).

Requires OTel SDK v2+ and Next.js 16+ for @smapped-traces/nextjs.

GitHub: https://github.com/jrandolf/smapped-traces

Turbopack and webpack are supported. Vite and esbuild are not; support depends on whether those bundlers implement the ECMA-426 debug ID spec.

DEV Community: Randolf J.