bugs that you can reproduce are the easiest ones to fix, claude opus for example would normally do the unit test and verify everything without much hand holding
how about about bugs that don't have a scenario or easy way to reproduce?, just some crash call stack, some corruption, something that happens once a year and you only have some logs?
Using the name "verifier" suggests some sort of formal verification. As far as I can see, this is just a glorified test rig.
I once saw a bug that only happened on Thursdays, and even then only very intermittently, because Thursday was day 0x04 of the week, with a bit that neatly hit a particular flag bit in a data structure that itself was only hit through a combination of pointer aliasing and a timing race. I wonder how this might be expected to cope with that?
5 comments
[ 0.24 ms ] story [ 8.9 ms ] threadhow about about bugs that don't have a scenario or easy way to reproduce?, just some crash call stack, some corruption, something that happens once a year and you only have some logs?
I once saw a bug that only happened on Thursdays, and even then only very intermittently, because Thursday was day 0x04 of the week, with a bit that neatly hit a particular flag bit in a data structure that itself was only hit through a combination of pointer aliasing and a timing race. I wonder how this might be expected to cope with that?