It is not impossible to have a large code base without unit tests. I'm sure my employer's code base is in the millions of LOC. At least 99% is not covered by unit tests. Probably 99.9%.
That might work for you, but is a bad idea in 99% of cases (I am not implying that most code has tests in place). I guess your code changes very rarely.
If you have to change something in core part of application with a lot of dependencies, good luck. Also, when several programmers are working on the same part of code (perhaps in a span of 5-6 years), they will need some time to understand code to be changed, then think more where something might break if they change it. At the end, they will lose a lot time and still not catch all the interactions with other code.
It took me a lot of time to understand why people want to write tests first, then code. It was more natural for me to make optimal code, then test expected/unexpected inputs and edge cases. The answer turned out to be that code ends up much cleaner and all code paths end up tested properly because you never write a single line of code which isn't explicitly there to satisfy a test.