Telemetry Ethics For Open Source Assistants Production Playbook: practical systems guide

Shipping an AI coding assistant means capturing enough telemetry to debug failures, improve suggestions, and measure impact—without turning your product into surveillance. Most teams handle this poorly: they either log everything and hope GDPR doesn't notice, or they log nothing and guess why prompts fail in production. Neither works when you're running models that cost dollars per thousand tokens and users who expect privacy.

The real challenge isn't technical implementation—capturing events is trivial. It's designing a telemetry layer that aligns incentives: your team needs signal to improve the product, your users need proof you're not training on their proprietary code, and your compliance team needs an audit trail that doesn't require a lawyer to interpret.

The consent surface area problem

Traditional analytics splits cleanly: product metrics go to Amplitude, errors go to Sentry, done. AI assistants blur these boundaries. A single interaction generates product events (user clicked "accept"), operational logs (model latency 2.3s), prompt context (file contents, git history), generated artifacts (the actual code diff), and validation outcomes (did it compile, pass tests, get merged).

Each category carries different privacy implications. Tracking that a user triggered a refactor command is product analytics. Logging the function signature they're refactoring reveals their codebase structure. Storing the full diff with variable names and business logic is potentially sending trade secrets to your telemetry vendor.

The practical system: separate consent tiers from day one. Goatfied's implementation uses three buckets:

**Essential operations** (no consent needed): error rates, latency percentiles, compile/test pass rates aggregated per workspace. These are service health metrics—they tell you the platform works but reveal nothing about what users build.

**Product improvement** (opt-in, default off for self-hosted): interaction patterns, anonymized prompt templates, model selection frequency, retry counts. Strip all code content and file paths. A log entry might record "user requested function extraction, model generated 3 candidates, user accepted candidate 2 after edit" without any actual code.

**Research corpus** (explicit opt-in, never default): full prompts, diffs, and validation results with code content. This is the data you need to train better models or publish benchmarks. Treat it like PHI in healthcare systems—separate infrastructure, retention limits, user-initiated deletion that actually works.

The nuance most teams miss: these tiers need separate infrastructure, not just flags in the same database. If your "anonymized" events share a Postgres instance with full code samples, a JOIN away from re-identification, you don't have privacy—you have liability theater.

What actually needs telemetry in the agent loop

When an AI assistant fails, you need to reconstruct why without replaying the user's entire session. Goatfied's agent loop (plan → constrain → edit → validate → retry) gives natural telemetry boundaries that respect both debugging needs and privacy.

**Plan phase**: Log the constraint set and model selection, not the actual code. Record "tried to modify 3 files, estimated 150 tokens context" rather than the file contents. If a plan fails constraint checking, you need to know *which* constraint triggered (import cycle, test coverage threshold) not the code that would have violated it.

**Constrain phase**: This is where you enforce rules—linting, type checking, security scans. Log violations as structured events: `{rule: "no-unused-vars", severity: "error", count: 2}` tells you the assistant is generating sloppy code. Storing the actual violating lines tells you what the user's codebase looks like—different value, different consent tier.

**Edit phase**: The generated diff is high-signal for improvement but also the most sensitive data. Hash file paths and function names, log token counts and model parameters. If a user opts into the research tier, store diffs in a separate, access-controlled bucket with automatic 90-day expiry. Make deletion synchronous—when a user revokes consent, their data disappears in seconds, not "within 30 days per our DPA."

**Validate phase**: Compile, lint, and test results are gold. A model that generates syntactically valid code 95% of the time is table stakes. One that passes your team's actual test suite 80% of the time is production-ready. Log exit codes, output summaries (test count, pass/fail/skip), timing. Don't log stack traces with variable values or test assertion messages containing user data.

**Retry phase**: When the agent loop retries, you need to know if it's converging or thrashing. Log attempt count, what changed between iterations (added constraint, different model, user override), and whether each attempt moved closer to validation success. This reveals pathological prompt patterns without exposing code.

The self-hosted telemetry escape hatch

Some teams can't send any telemetry externally—finance, defense, healthcare with strict data residency rules. For them, "opt-out" isn't enough; the architecture itself must support air-gapped operation.

Goatfied's approach: telemetry is a plugin boundary, not hardcoded instrumentation. The agent loop emits events to a local interface; what consumes those events is configurable. The managed cloud runs our full telemetry stack. Self-hosted deployments can point at `/dev/null`, a local Prometheus exporter, or the customer's own SIEM.

The key architectural decision: emit structured events, not free-form logs. An event like `{type: "validation_failed", phase: "lint", duration_ms: 340, retry_eligible: true}` works in any backend. A log line "Linting failed after 340ms, will retry" requires parsing, breaks when you change wording, and is useless for aggregation.

This also solves the "telemetry costs more than compute" problem some AI tools hit. If you're sending gigabytes of prompt data to Datadog daily, you're doing it wrong. High-cardinality events (per-invocation timing) stay local, aggregate to metrics (p50/p99 latency) before export. Low-frequency, high-value events (user accepted a suggestion, validation passed on first try) go to your warehouse but shouldn't exceed a few MB/day even at scale.

Making it auditable

When a user asks "what data did you collect about my session?" you need an answer that isn't "check the data warehouse." For AI assistants in enterprise environments, this is a deal-breaker. Legal teams want audit logs, not vague privacy policies.

Practical implementation: every telemetry event includes a `user_session_id` and `consent_tier` field. Users can query their own data via API. The response shows exactly what was captured, when, and under which consent setting. For self-hosted deployments, this query runs entirely on-premises.

The harder part: proving what you *didn't* capture. Goatfied's validation pipeline includes automated checks that scan outbound telemetry for patterns that shouldn't exist—regex for AWS keys, file path structures, code snippets in events marked as "aggregate only." These run in CI before deploying any instrumentation changes. A failed check blocks the deploy, same as a failed test.

Related reading

• [Goatfied vs Cursor vs GitHub Copilot: a benchmark across 50 real PR tasks](/blog/goatfied-vs-cursor-vs-github-copilot-benchmark-50-pr-tasks)
• [The Goatfied agent loop: how we ship code that actually compiles first try](/blog/goatfied-agent-loop-compiles-first-try)