When coding telemetry becomes behavioral data

I’m increasingly uncomfortable treating coding-assistant telemetry as ordinary product analytics. GitHub documents metrics such as suggestions shown and accepted, while its enterprise OpenTelemetry examples include accepted or rejected agent edits. JetBrains describes an opt-in mode that can collect full LLM communications, prompts, code fragments, edit history, and terminal usage. Those events may be useful for debugging and model evaluation, but once tied to an account and retained, they describe a person’s working behavior—not just system performance.

I’m not claiming every tool records cursor movement or typing pauses; public documentation does not establish that as routine. But if products can measure hesitation, rejection, or time-to-accept, that coding rhythm should not become a durable employee profile. My preferred boundary is local aggregation by default, short retention for raw events, explicit opt-in for retention, and a ban on using hesitation patterns for performance decisions.

What would a practical privacy-preserving telemetry policy look like, and what counterexample would justify keeping individual-level interaction data?

The distinction I’d insist on is between documented collection and inferred capability. Acceptance metrics are clearly documented in some products; cursor paths and typing pauses are a separate claim. A policy should name each event, purpose, retention period, and recipient rather than hiding everything under “usage analytics.”

There is a product tradeoff here: raw events can reveal failures that aggregates hide. But that does not require indefinite storage. A vendor could keep a short-lived diagnostic window, then export only cohort-level counts. The commercial challenge is making that limitation legible enough that customers trust it.

I’d threat-model the telemetry pipeline like any other sensitive data path. Account linkage, admin dashboards, exports, and vendor support access all matter. Local aggregation reduces exposure, but it is not magic if the client can still be configured to upload raw prompts. The default needs to be enforceable, not merely documented.

The workplace effect may be larger than the database effect. Once a dashboard shows acceptance rate, managers will be tempted to read it as competence, diligence, or “engagement,” even if the metric was designed for relevance testing. Prohibiting personnel use is as important as minimizing collection.

This is exactly the sort of requirement procurement can put into a contract: event-level schema, purpose limitation, retention SLA, tenant-level disablement, and a statement that telemetry cannot feed employee evaluation. “We don’t train on your code” is too narrow if behavioral metadata remains identifiable.

I’m not fully convinced that individual-level data is always unjustified. During a support incident, a recent sequence of prompts, tool calls, and accept/reject events could materially shorten diagnosis. I’d allow narrowly scoped incident capture with user notice and automatic deletion, rather than banning the category outright.

A useful architecture is to compute counters in the editor and upload only noisy, time-bucketed aggregates. The raw event stream can remain local for a user-configurable debugging window. If a support case needs more, the user explicitly shares a bundle. That makes disclosure an action instead of the ambient default.

I’d also avoid saying “telemetry” as though it has one fixed meaning. Product metrics, diagnostic logs, prompts, code fragments, and edit history have different sensitivity and retention needs. The policy should classify fields individually; otherwise a harmless count becomes cover for collecting the whole interaction transcript.

The operational edge case is contractors and shared workspaces. An opt-out buried in a personal settings page may not control organization-level OpenTelemetry configuration. There should be a visible effective-policy indicator in the IDE, plus an audit record showing who changed collection and when.

For a small team, I’d take the boring option: collect crashes and aggregate feature counts, keep prompts and interaction timing off, and ask for a redacted diagnostic bundle when something breaks. Most teams do not need a behavioral science project to know an autocomplete feature is failing.

“Can we collect it?” and “should we keep it?” are different questions. The second one is where most analytics designs mysteriously lose interest. Delete the fine-grained trail and the argument gets shorter.

My minimum policy would be: no raw interaction telemetry by default; local aggregation; explicit, revocable opt-in for prompts or edit history; short fixed retention; user-visible export and deletion; and a contractual ban on employment decisions based on interaction patterns. Quality evaluation can use sampled, minimized data without creating a permanent dossier.