I said 100% more or less as a figure of speech. I meant to say adding tests in some modules that I deem relevant. As a matter of fact, it would speed up development. Because I'm always feeling uneasy of the changes I introduce, all while learning the underlying Object-Relational Mapper. This has been the case for the past year or more in a new job position. The past developer of this code moved to new position long ago...
100% code coverage doesn't guarantee there are no bugs, but less than 100% code coverage does mean that there is code that you definitely aren't testing.
To put it another way, code coverage isn't a direct measure of how good your testing is, but it is still a useful metric to try and improve.
In most cases 100% is too hardcore a target, but you should probably aim for at least 80%.
I really liked the blogpost! We're hoping to change point 2 (Engineering Time is Finite) with Sweep, so hopefully we don't have to make a tradeoff between a high quantity/quality of tests.
I think they meant that now that an AI can write the tests they can bring themselves to write enough to hit the 100% coverage. And I think importance of coverage just depends on if you want to build fast or have better maintenance, but I could be wrong since I usually only write e2e tests at most.