What is a Code Generation?

Why code generation matters

Manual instrumentation is where tracking plans break down. A product manager defines an event in a spreadsheet. An engineer reads the spreadsheet and writes a tracking call. Somewhere in translation, a property name gets misspelled, a type gets wrong, or a required field gets skipped. The event fires, the data looks almost right, and nobody notices the error until a quarterly review reveals that a key metric has been wrong for months.

Code generation eliminates this translation step entirely. Instead of engineers interpreting a document and writing tracking calls by hand, a generator reads the structured event schema and produces platform-specific functions with correct names, typed parameters, and required field enforcement. The schema becomes the code, with no room for human misinterpretation.

The benefit extends beyond accuracy. Code generation also dramatically reduces instrumentation time. When a new event is added to the tracking plan, the generated code updates automatically. Engineers get autocomplete for event names and properties in their IDE. There is no need to look up the plan, no need to check property types, and no risk of a typo that creates a phantom event in the analytics platform.

How it works in practice

The process starts with a structured event schema that defines every event, its properties, and their types. The schema must be machine-readable, not a free-text spreadsheet. From this schema, a code generator produces tracking functions for each target platform: TypeScript for web, Swift for iOS, Kotlin for Android, or any other language the product supports.

For example, an event schema defining Checkout Started with properties cart_total (float, required), item_count (integer, required), and promo_code (string, optional) would generate a TypeScript function like trackCheckoutStarted({ cartTotal, itemCount, promoCode? }). Calling this function with a missing cartTotal is a compile error. Passing a string where a number is expected is a compile error. This is type safety applied directly to analytics.

The generated functions typically wrap an underlying analytics SDK (like Segment, Amplitude, or a custom HTTP client). The engineer calls the generated function; the generated function calls the SDK with the correct event name, validated properties, and any required transformations. This layered approach means you keep the flexibility of your existing SDK while gaining the safety of generated code.

Common mistakes

• Generating code from an unstructured source. A spreadsheet with free-text property descriptions cannot produce reliable generated code. The source schema must define explicit types, required/optional status, and allowed enum values for the generator to produce meaningful output.
• Not regenerating after schema changes. Generated code is only as current as the last generation run. If the schema changes and the code is not regenerated, you have the same drift problem as manual instrumentation. Integrate generation into your CI pipeline.
• Editing generated files by hand. Manual edits to generated code will be overwritten on the next generation run. If the generated output needs adjustment, fix the schema or the generator template, not the output.
• Assuming generated code replaces the SDK. Generated tracking functions are a layer on top of your analytics SDK, not a replacement. You still need the underlying SDK for transport, batching, identity resolution, and platform-specific behavior.

Frequently asked questions

What languages can code generation target?

Any language with a type system can benefit from generated tracking code. The most common targets are TypeScript (web), Swift (iOS), and Kotlin (Android). Some generators also support Python, Java, Ruby, and Go for server-side tracking. The Ordaze code generator produces TypeScript, Swift, and Kotlin from a single schema definition.

What is the difference between manual instrumentation and generated code?

Manual instrumentation means an engineer reads the tracking plan and writes tracking calls by hand, including string event names and untyped property objects. Generated code produces typed functions from the schema automatically, so event names are constants, properties have enforced types, and required fields cannot be omitted. The generated approach catches errors at compile time rather than in production data.

Does generated code replace the analytics SDK?

No. Generated tracking functions are a thin, type-safe wrapper around your existing SDK. The SDK still handles network transport, event batching, retry logic, and identity resolution. Generated code handles the contract layer: ensuring that every tracking call matches the schema in name, property names, and property types.

How does code generation fit into a CI/CD pipeline?

The typical setup runs the generator as a build step that reads the current schema and outputs updated tracking files. If the schema changed since the last build, the generated code changes too. If existing tracking calls no longer match the new schema (for example, a required property was added), the build fails with a type error, catching the issue before it reaches production.