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 up is getting distracted by aggregate signals
this shows up everywhere in agent loops. anytime I hand Claude a wide slice of anything it starts reasoning in averages. the moment I narrow to ~10 rows it locks onto the actual root cause. so derived views sound like exactly the right shape. how big do real traces get in your duckdb format? does a 5min scroll-heavy trace stay manageable =)
> 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, its fast enough" moment in a different MCP context (iOS simulator automation)... turned out the 300ms per-tool-call was what made the whole loop feel sluggish even though each individual query was "fast". got it down to ~20ms and Claude felt noticeably less hesitant between calls after that. cant fully explain why but the behavior shift was real.
probably not your problem at 90 rows of scalar data =) just a thing I wish I had clocked earlier.
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 the fine tune... I feel like the gain probably isnt worth the maintenance vs just adding another constraint to the prompt. did you find concrete cases where prompting just couldnt get you there?
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? Internal APIs tend to break without warning when they update the app.
> 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" thing others mention here is real too. had to add explicit verification steps because Claude kept reporting success when it just silenced the error. now I always make it prove things actually worked before moving on.
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 screenshot-parse-click loop.
tell me more about you handle tool discovery... With macOS scripting there could be a ton of possible actions. I ended up with 49 and already feel like thats a lot for the context window.
> Where the AI trips up is getting distracted by aggregate signals
this shows up everywhere in agent loops. anytime I hand Claude a wide slice of anything it starts reasoning in averages. the moment I narrow to ~10 rows it locks onto the actual root cause. so derived views sound like exactly the right shape. how big do real traces get in your duckdb format? does a 5min scroll-heavy trace stay manageable =)