Test Driven Development or TDD can be a useful deterrent for bugs in huge codebases. Writing tests can get complex when trying to introduce them into an existing codebase, especially if there is tightly coupled classes. One way to start doing TDD in an existing codebase is to start introducing unit tests for each bug that the engineer is working on. Ideally every time an engineer is fixing a bug, they would make the unit test that would verify the expected behavior, then once they have the unit test failing, they would actually fix the bug. If engineers took this approach to start doing TDD in an existing codebase, eventually code coverage will grow as the bugs are resolved one by one.
One problem with introducing TDD into an existing project is the testability of the code. Depending on the quality of the architecture and design patterns used in the codebase and amount of coupling, the engineer might have to do substantial refactoring to make the code testable. Either way refactoring code to be testable is actually a major improvement which will facilitate more ease of development. Other engineers will be more confident that they will not break other parts of code once tests are introduced from other TDD tasks and code coverage climbs.
TDD can be a very powerful way to ensure quality of production code and engineers will have to deal with a great deal less of bugs in the long run. At first doing TDD in an existing codebase will take longer than if it was done since the beginning of writing the application. Once the coverage gets to a certain point in an application, the code should be refactored to be testable enough that engineers will take less time to introduce new tests and code.