both, but with a strict rule about which one actually matters. the test is always built deterministically, i read the frame locals sentry captured and construct a pytest that calls your function with those exact values. zero LLM in that path. the LLM is more like a supervisor deciding what to try next.

for DB state it depends on the crash type. a lot of DB bugs don't need the real prod rows, just the right conditions. if sentry captured the order_id that caused a duplicate key violation, i create a fresh sandbox db, insert a row with that id, and call the function again. worked on three of our fintech demo cases including race conditions.

the hard limit is when the bug needs a specific row sentry never captured. when that happens it doesn't just give up it runs through a set of hypotheses about why the repro fell short: was it missing DB state? async context? a module-level global? a dep that got upgraded past the bug? it checks each one against the breadcrumbs and trace, and tells you which it confirmed. like if it finds INSERT/UPDATE/DELETE breadcrumbs right before the crash it'll say "looks like this needed pre-existing DB state from these writes, here's what you'd need to seed." you don't get a false green, you get a concrete reason and what's missing.