u/Enthu-Cutlet-1337

Genuine question because i feel like im missing something. been seeing this push (thariq from anthropic wrote a whole thing on it) where the move is to have claude generate HTML instead of markdown for plans, specs, code reviews, basically everything.

Using Claude Code: The Unreasonable Effectiveness of HTML

I tried it for a week. the output is genuinely nicer to look at. SVG diagrams, tables that arent ascii, can share a link insted of a file. fine.

but my repo is now full of .html files i cant grep meaningfully, cant diff in a PR without my eyes glazing over, and cant open in my editor without it being weird. and the generation time is noticably slower, like he says 2-4x but it feels worse on bigger docs.

and honestly the thing that gets me is half these "HTML wins" are really just "the markdown was too damn long". if claude is writing 800 line plans nobody reads, the fix isnt prettier rendering its shorter plans. swapping formats feels like papering over the actual problem which is that agents overproduce.

the one thing i do think is legit is the throwaway interactive tool idea. build a quick drag-drop ui to reorder tickets, hit a button, paste the result back as a prompt. thats a real new pattern and it doesnt work in markdown at all. but thats like 10% of what hes pitching, the other 90% is just "static docs but fancier".

Is everyone elses workflow just html now. What does your review process look like if your specs are html.

What do you think?>

I am seeking an arXiv endorsement for a paper titled “Anneal: LLM-Guided Artifact Optimization as Principled Search.”

The work introduces an open-source framework for autonomous optimization of prompts, code, configs, and other text artifacts using LLM-guided mutation, statistical acceptance testing, metaheuristic search, structured experiment memory, and git-isolated reproducible evaluation loops.

I am preparing to submit it to arXiv under a relevant CS/AI/ML category, but this is my first submission in that endorsement domain.

If you are eligible to endorse in the relevant arXiv CS domain and are willing to check whether the paper fits arXiv’s scope, please DM me. I can privately share the manuscript, abstract, repository, target category, author details, and endorsement code.

Building a local-first speech translator in Rust. It needs to capture whatever the user is hearing (system audio) so the model can translate it on-device — no cloud round-trip, no bot joining the call.

macOS 14.2+ Core Audio Taps look like the right primitive. CATapDescription::initStereoGlobalTapButExcludeProcesses(@[]) paired with an aggregate device + IOProc gives me a healthy IO callback at ~94 Hz on a stereo 48 kHz tap. But every buffer is zero-filled. Frame count is correct, samples are exactly 0.0. Classic TCC csreq-failure signature: the tap is "permitted" in System Settings but the OS silently zero-fills delivery.

Tried so far:

• Granted Audio Capture in System Settings → nothing changes
• codesign --force --sign - (ad-hoc) → still zero-filled
• tccutil reset SystemAudioRecording → "Failed to reset" on macOS 15+ (the service name doesn't exist there)
• Reinstalled to a stable PATH so TCC had something durable to bind to → no change

No Apple Developer membership — $99/yr is a steep entry fee for an open-source side project that may never ship a release.

Three questions:

1. Is a paid Developer ID actually mandatory for Core Audio Taps to deliver real samples, or does a self-signed Keychain cert + manual trust work durably across rebuilds?
2. What's the right tccutil reset service name for system-audio capture on macOS 15/16? Or is the only durable reset path through the Privacy & Security UI now?
3. The long-term plan is to ship on Linux (PipeWire/Pulse) and Windows (WASAPI loopback) as well, so the cross-platform shape matters from the start. Do those paths have equivalent unsigned-binary gating headaches, or does system-audio capture "just work" there for an open-source dev build?

Curious how others who've shipped similar local-audio tools handled the cross-platform story.

Building a local-first speech translator in Rust. It needs to capture whatever the user is hearing (system audio) so the model can translate it on-device — no cloud round-trip, no bot joining the call.

macOS 14.2+ Core Audio Taps look like the right primitive. CATapDescription::initStereoGlobalTapButExcludeProcesses(@[]) paired with an aggregate device + IOProc gives me a healthy IO callback at ~94 Hz on a stereo 48 kHz tap. But every buffer is zero-filled. Frame count is correct, samples are exactly 0.0. Classic TCC csreq-failure signature: the tap is "permitted" in System Settings but the OS silently zero-fills delivery.

Tried so far:

• Granted Audio Capture in System Settings → nothing changes
• codesign --force --sign - (ad-hoc) → still zero-filled
• tccutil reset SystemAudioRecording → "Failed to reset" on macOS 15+ (the service name doesn't exist there)
• Reinstalled to a stable PATH so TCC had something durable to bind to → no change

No Apple Developer membership — $99/yr is a steep entry fee for an open-source side project that may never ship a release.

Three questions:

1. Is a paid Developer ID actually mandatory for Core Audio Taps to deliver real samples, or does a self-signed Keychain cert + manual trust work durably across rebuilds?
2. What's the right tccutil reset service name for system-audio capture on macOS 15/16? Or is the only durable reset path through the Privacy & Security UI now?
3. The long-term plan is to ship on Linux (PipeWire/Pulse) and Windows (WASAPI loopback) as well, so the cross-platform shape matters from the start. Do those paths have equivalent unsigned-binary gating headaches, or does system-audio capture "just work" there for an open-source dev build?

Curious how others who've shipped similar local-audio tools handled the cross-platform story.