We built thisfor ourselves.

Where it comes from — usually — is someone at 11pm copy-pasting OTel setup code, squinting at the semantic conventions spec, and wondering why their spans aren't showing up in the collector.

We've been that person. Multiple times. Between shipping Parseable and helping customers onboard, we instrumented dozens of services ourselves. Every time it was the same slog: hunt down the right SDK, figure out the right imports, manually wrap every route and query handler, then spend another hour verifying the attribute names were actually correct.

There was no shortcut that didn't eventually cost you.

The AI code gen experiment.

When LLM-based code generation took off, we tried it like everyone else. It was fast. It was surprisingly coherent. And the spans it generated looked right.

Until they weren't.

LLMs aren't consulting the OTel semantic conventions spec. They're predicting the most likely token sequence. That produces spans that look correct 80% of the time — which is worse than wrong 100% of the time, because you can't tell which 20% is broken.

A different approach.

Otex doesn't predict. It looks.

It parses your codebase with a real AST, finds every HTTP call, database operation, file I/O, and RPC — across every file and every framework boundary. Then it sources every attribute name directly from the OpenTelemetry semantic conventions spec. Deterministically, every time.

The result isn't AI-generated code. It's spec-driven code, generated by a system that knows what db.statement is supposed to be because it read the spec — not because it was trained on Stack Overflow answers that happened to mention it.

What we believe.

Instrumentation should be invisible infrastructure. Not a week-long project. Not a thing that breaks on every PR. Not something your team debates at code review.

It should just be there — correct, complete, and out of your way — so you can focus on building the thing that actually matters.

We built Otex because we got tired of paying that cost.