[HelloMCP]

This feels like a preview of where debugging is going. Dashboards are good for people but we also need to make raw telemetry directly queryable by agents.

Curious how well this holds up across different traces. Instruments data can be pretty noisy and context-dependent. @jlreyes - do the derived views generalize, or do you end up encoding a lot of assumptions about what “jank” looks like?

[jlreyes]

Identifying bottlenecks is pretty generalizable. There is a distinction the skill tries to draw between targeting median FPS and P95, but from there the AI is quite good at narrowing to the relevant data.

Where the AI trips up is getting distracted by aggregate signals instead of digging deep into root causing specific frame drops, but I see humans and existing tooling getting distracted by that too.

Root causes are often context-dependent, but they tend to cluster into a handful of common issues. If you're able to enable the new swiftui instrument (from WWDC 2025), the entire attribute graph is encoded, and it can get you to the precise issue quite well.

[silbercue]

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 =)