It could be we're using two different definitions of manual test. When I was referring to manual tests, I was referring to tests that are manually done by directly entering inputs to the software, either thru a GUI or a command-line, then observing the results visually. This is very "old school" testing, which I did a lot of in my early software career. Now we only use this kind of testing for UX testing (well, except for one project where the manager is still very old school and more of an engineer than a computer science guy).

But another view of automated versus manual is one where any test where the inputs which are generated by testing software are considered automated tests (and this testing software explores the input space in some way), whereas humans specifying the inputs are considered manual tests, with these latter tests being used to test edge cases that weren't explored by the less intelligent but larger set of inputs generated by the automated software.

If that's what you meant by manual (which is what I was led to believe by your use of the phrase "edge case"), then I think most of Hive's current tests are manual in this sense, but we code those sets of inputs into automated tests that can be re-run over and over again.

For the most substantial tests, the automated testing system then applies the same inputs to a golden reference model (which generally is the old version of the code) and to the current code under development, and reports differences in the results as potential problems.