Strict typing is a business decision

There is a moment in every codebase's life where someone proposes turning off the strict compiler settings, or never turning them on, because the errors are slowing the team down. The argument sounds pragmatic. Ship now, tidy later. It deserves a serious answer rather than an eye-roll, so here is the serious answer.

Type strictness is not about catching typos. It is about what the computer can promise you when you change things. In a strictly typed codebase, renaming a field, changing a function's contract, or restructuring a data model produces a complete, mechanical list of every place that must be updated. The compiler is not nagging; it is doing an exhaustive impact analysis in seconds, for free, every time.

Now price the alternative. In a loosely typed codebase, that same impact analysis is performed by a human, with grep and hope. Some call sites get missed. The missed ones fail at runtime, in production, in the shapes that are hardest to reproduce: the null that only appears when a user has no billing history, the undefined that only occurs for accounts created before the migration. Each of these costs hours to diagnose and lands on your most experienced people, because they are the only ones who can hold the whole system in their head.

That is the actual trade. Strictness costs minutes continuously, at the keyboard, where fixes are cheapest. Looseness costs hours unpredictably, in production, where fixes are most expensive and most stressful. Framed as an engineering preference, this is a debate. Framed as a question of where you want to pay, it stops being close.

The objection about velocity deserves its own paragraph, because it is backwards in an interesting way. Teams feel fast without strictness because the friction is deferred, not removed. The cost reappears as defensive programming (checks scattered everywhere because nothing can be trusted), as fear-driven development (nobody refactors the billing module because nobody knows what touches it), and as slow onboarding (new engineers cannot lean on the types to learn the system, so they lean on the senior engineers instead). A team that cannot refactor confidently slows down every quarter. The strict team pays a small toll daily and keeps its top speed for years.

There is also a quieter benefit that rarely makes the argument but should: types are the only documentation that cannot go stale. Comments lie within a month. A type signature is enforced truth about what a function accepts and returns, checked on every build. In a codebase that outlives its original authors, which is every codebase that matters, this is worth more than any wiki.

We hold this position for AI-assisted development too, perhaps especially there. Generated code arrives fast and plausible, exactly the combination that benefits most from a compiler that refuses to accept contradictions.

Turn on strict. Keep it on. When it complains, it is telling you about a bill you would otherwise pay later, with interest, at the worst possible time.