A few small decisions are turning into big headaches this week: defaults that surprise developers, a new open AV2 decoder trying to fill a hardware gap, and a tidy opt‑out idea for CLI telemetry. The longer read shows how Mercury made Haskell work at scale — practical tradeoffs that matter whether you run production systems or just hate noisy defaults.
In Brief
VS Code inserting 'Co-Authored-by Copilot' into commits regardless of usage
Why this matters now: Visual Studio Code's Git extension default for adding AI co‑author metadata was changed to "all," potentially appending "Co-authored-by" trailers to developer commits without clear consent.
A seemingly tiny config flip in VS Code — the schema default for git.addAICoAuthor moving from "off" to "all" — produced an inconsistent runtime. In some code paths the extension still falls back to 'off', but hosts or tests that don't load contributed defaults can see the new value, and users reported commits getting AI co‑author trailers unexpectedly. That raises real questions about attribution, audit trails, and consent for millions of developers relying on VS Code's git integration.
"incredibly hostile to standards" — a top comment reflecting the thread's frustration with defaults that push AI features.
The problem is mostly a configuration bug, but it's a tidy example of why defaults matter: changing behavior quietly at scale can affect licensing signals, supply‑chain metadata, and a project's commit history. For now, check your VS Code git settings and extensions, and watch the pull request discussion for fixes.
dav2d: an AV2 decoder from VideoLAN
Why this matters now: VideoLAN's open dav2d project aims to provide a fast, portable AV2 software decoder that can enable playback before hardware support is widespread.
VideoLAN published dav2d as a clean‑room, BSD‑2‑clause‑licensed AV2 decoder, modeled after dav1d. The repo is intentionally early — maintainers warn "should not be used in production" — but the roadmap is concrete: a correct C decoder, then hand‑tuned assembly (AVX2, ARM) and threading for performance. Historically, a good open software decoder has helped codec adoption by covering devices that lack hardware support; dav2d aims to play that role for AV2.
"should not be used in production" — the project's own caution while it matures.
Caveats matter: AV2's spec and patent landscape are still in flux, so embedding or shipping the decoder carries legal risk until licensing is clear. If you care about cross‑platform playback or contributing to codec tooling, dav2d is worth watching and helping with C/assembly ports and testing.
Do_not_track: a single env var to opt out of telemetry
Why this matters now: The Do_not_track proposal asks CLI tools and SDKs to honor a single environment variable — DO_NOT_TRACK=1 — to disable non‑essential telemetry across the command line.
A short, practical proposal suggests normalizing an opt‑out via a single environment variable: "export DO_NOT_TRACK=1" and a simple ask that CLI tools stop outgoing telemetry and crash reporting when set. The write‑up includes copyable instructions for shells and Windows, positioning the var as a command‑line sibling to NO_COLOR or FORCE_COLOR.
"export DO_NOT_TRACK=1" — the suggested universal signal.
Commenters liked the clarity but warned about adoption: services that profit from telemetry won't voluntarily respect it, and a global opt‑out flag itself could become a privacy signal. Still, for individual developers and admins, adopting a shared convention would be a low‑friction improvement when tools actually honor it. The proposal and community thread are at donottrack.sh.
Deep Dive
A couple million lines of Haskell: Production engineering at Mercury
Why this matters now: Mercury's operational write‑up shows how a fintech company runs "a couple million lines of Haskell" reliably in production, turning language features into maintainability and observability wins.
Mercury's post is unusually candid about tradeoffs. The headline point is practical: Haskell's type system can act as an operational aid, encoding invariants that prevent classes of silent corruption and making intent visible to future maintainers. That doesn't mean every problem is solved by types — they treat "purity as a boundary, not a property," deliberately isolating imperative or unsafe operations behind narrow interfaces so the rest of the code can stay declarative and easy to reason about.
"purity is a boundary, not a property" — a concise rule they use to balance safety and pragmatism.
Several engineering practices stand out as broadly applicable beyond Haskell shops. First, they built replayable, durable workflows (using Temporal and their open‑sourced hs‑temporal‑sdk) to replace brittle cronjobs and ad‑hoc state machines. Making workflows durable turned operational debugging from a guessing game into a repeatable exercise: you can replay a workflow and observe the same state transitions, which is a huge win for correctness in financial systems where mistakes are costly.
Second, Mercury invests in observability at the library level. They design instrumentation into core libraries — record function calls, middleware hooks, and OpenTelemetry-ready traces — so operators can actually see what’s running. This reduces the classic gap where app code has business logic but no way to inspect it outside unit tests. It also lowers the cognitive load when incidents happen: the data you need to triage is already being produced.
They also embrace pragmatic exceptions to purity. The post recommends using unsafePerformIO or equivalent when it's the least bad option, but only with strict documentation and narrow scopes. That practical honesty matters: engineering teams win by having rules for when to bend purity rather than pretending the language enforces perfect behavior everywhere.
For teams considering stronger type systems or functional languages, Mercury's experience is instructive: you gain long‑term maintenance benefits, clearer domain modeling, and fewer silent failures, but you must pair the language with good workflows, observability, and a culture that documents necessary exceptions. Their post is a useful operational playbook whether you run Haskell, Rust, or a type‑heavy TypeScript stack — the tooling and process choices matter as much as the language itself. Read the full write‑up at blog.haskell.org.
Closing Thought
Small defaults and simple conventions are surprisingly powerful — for better or worse. A toggle buried in an editor can change thousands of repos; a single environment variable could protect user privacy if enough tools agree to honor it; an open decoder can unlock formats while hardware catches up. Mercury's pragmatic Haskell lessons tie these threads together: the best engineering choices are the ones that make intent visible, behavior repeatable, and surprises rare.