Why not both?
In any case, a rudimentary implementation is actually in Go's standard library already for a long time: https://pkg.go.dev/testing/quick@master
Though, note:
> The testing/quick package is frozen and is not accepting new features.
Absolutely fine and often good enough, these tests are typically very simple and easier to reason about, and make more sense in a whole range of situations (eg regression tests).
However, I would take a single input fuzzing test over one that uses hard coded inputs.
Go's fuzz tester takes this approach. When a failing input is found, it's added to the source code directory with the intent of you checking it in.