silbercue

6 ms·

1.
Show HN: Public Browser – a Chrome MCP server with ~40% fewer tool calls(github.com)
2 points by silbercue 2d ago|0 comments
2.
by silbercue 5mo ago
been eyeing Instruments integration for my own iOS tooling for months and kept bouncing off it. xctrace output + parsing traces felt like a rabbit hole. DuckDB + Parquet is a way nicer angle than what I had in mind. > Where the AI trips
3.
by silbercue 5mo ago
> Streaming would make sense if I were piping large sample arrays directly, but those get aggregated server-side before returning thitami's point on perceived latency is the thing I'd still watch. had the same "its fine, i
4.
by silbercue 5mo ago
mine kept growing until I'm pretty sure claude was just skipping half of it. ended up doing the same... moved verbose stuff into separate files and only kept the absolute hard rules in claude.md. rules it cant grep its way around. on t
5.
by silbercue 6mo ago
been ordering from REWE for years =) always wished the app was less annoying. all my programm skills - for what? lol. probs for reverse engineering the mTLS part, most people would have just given up. how stable this is in practice? Intern
6.
by silbercue 6mo ago
> Claude code hooks are blocking - performance degrades rapidly if you have a lot of plugins that use hooks can confirm. ended up being really careful about what runs synchronously vs in the background. IMHO the "sanitised optimism&
7.
by silbercue 6mo ago
> Claude Code (Opus) wrote ~95% of the code. I provided architecture, constraints, and direction 76k lines in 53 days? Crazy. How much of the 95% did you end up rewriting? > 87 plans total, averaging 2-3 pages each. The CLAUDE.md proj
8.
by silbercue 6mo ago
Cool) I'm doing something similar atm for iOS simulators instead of macOS / same idea though, giving Claude direct access through MCP instead of going through computer use. The latency difference is huge when you skip the screensh