Your engineers got faster. Your tracking didn't get better — it got worse, at exactly the same rate. That's not a coincidence; it's the same machine.
The new normal
Somewhere in the last eighteen months, agent-written code stopped being a novelty and became the default. Every Series B+ team I talk to now has engineers running Cursor or Claude Code all day, and the numbers are striking — teams that used to merge five PRs a day are merging twenty, thirty, fifty. The bottleneck moved from "writing the code" to "reviewing the code", and review didn't get any faster.
Most of that code is fine. Better than fine, honestly — agents don't get tired, don't skip the error handling, don't forget the test. I use them for nearly everything I ship now, and I'm not going back.
But there's one category of code where agents fail in a way that nothing in your existing process catches: analytics instrumentation. And the failure compounds quietly, PR after PR, until your warehouse is full of events nobody planned and nobody trusts.
Confident, plausible, wrong
Here's the thing about agent mistakes in tracking code: they don't look like mistakes.
A human who doesn't know your tracking plan writes something obviously sloppy — a console.log, a TODO, an event called test_click_2. A reviewer spots it in two seconds. An agent that doesn't know your tracking plan writes checkoutCompleted — camelCased, beautifully typed, with a tidy properties object and a sensible comment. It looks exactly like production-quality instrumentation. It just doesn't exist in any plan, anywhere. Your canonical event is checkout_completed, snake_cased, with a cart_value property the agent has helpfully renamed to totalAmount.
That PR passes the smell test. It passes lint. It passes the type checker. It passes a human reviewer who's looking at the logic, not cross-referencing a spreadsheet of four hundred event definitions — because nobody does that, and nobody ever will.
The error shape is the problem: confident, plausible, wrong. Agents don't produce garbage; they produce near misses. Duplicate properties under new names. Events that are 90% your convention and 10% invention. A second signup_completed that fires alongside the first one because the agent didn't know the first one existed. Each one is individually reasonable. Collectively they're a slow-motion corruption of the one dataset your product, growth and finance teams all depend on.
The quarterly audit is dead
The old defence against tracking drift was the periodic audit. Once a quarter — twice a year, realistically — someone on the data team pulls every distinct event name from the warehouse, diffs it against the tracking plan, winces, and opens a cleanup epic that never quite finishes.
That model assumed drift was slow. A team merging five PRs a day, where maybe one a week touches tracking, generates drift at a rate a quarterly audit can roughly keep up with. A team merging forty agent-written PRs a day generates drift continuously. By the time the audit runs, you're not looking at a handful of stragglers — you're looking at a quarter's worth of compounding near misses, baked into dashboards, propagated into downstream models, already informing decisions.
I'll be honest: I didn't fully see this coming either. When I started building suky, the villain was human inconsistency — the spreadsheet nobody updates, the engineer who guesses. Agents made that problem an order of magnitude bigger and an order of magnitude faster, in about a year.
The conclusion I keep landing on: detection has to move to the change, not the calendar. Every PR that touches tracking code needs to be checked against the contract at the moment it's proposed — because that's the only moment the fix is cheap.
Generation is free now. Verification isn't.
Step back and the structural shift is obvious. For a decade, the hard part of analytics governance was generation — getting correctly-shaped tracking code written and shipped. A whole tool category grew up around making generation easier: typed wrappers, codegen, IDE plugins.
Agents just made generation free. Your coding agent will happily write the tracking call, the typed wrapper, and the test. What it cannot do — what no agent in your SDLC can do — is tell you whether what shipped actually matches what was agreed, because that answer doesn't live in the codebase. It lives in your warehouse, in the events that actually arrived, with the shapes they actually have.
That's the asymmetry: every agent in your SDLC generates; none of them can verify. Verification needs two things agents don't have — a canonical contract that says what each event should be, and a view of reality that says what it is. The only thing that scales with the agents is enforcement against reality: contracts on one side, the warehouse on the other, and a deterministic check between them on every change.
What I'm doing about it
This is the shape suky has settled into, and the agentic SDLC is exactly why:
A contract registry your agents can query. suky exposes your event contracts over MCP — Cursor, Claude Code, whatever your team runs. Before an agent writes a tracking call, it searches the registry, finds checkout_completed, and reuses it instead of inventing a cousin. The near miss never gets written.
A deterministic CI gate. Every PR gets checked against active contracts — breaking, additive, or cosmetic, classified per change. The result is machine-parseable, so the reviewing agent can read the failure and fix it in the same loop, without a human translating.
Draft contracts, human approval. When an agent ships a genuinely new event, it proposes a draft contract rather than writing straight into the registry. A human approves it; from then on it's binding for every subsequent agent. The plan grows with the product instead of trailing it.
Monitoring against reality. Contracts are checked continuously against what's actually landing in your Snowflake — read-only SQL, in your warehouse; we never ingest your events. Because the failure mode isn't "the code looked wrong". The code looked perfect. The data was wrong.
The uncomfortable question
If your engineers have been on coding agents for the last six months, here's the question I'd sit with: what's happened to your tracking quality in that time? Not your velocity — your data. Pull the distinct event names from your warehouse and diff them against your plan. If the answer makes you wince, the drift is already compounding, and it's compounding at agent speed.
The free tier connects read-only to your Snowflake and shows you exactly how far reality has drifted from the plan — no sales call, no payload ever leaves your warehouse. Come take a look. Better to wince now than next quarter.
— Kevin