Type systems are a religious topic, and we're not here to convert anyone. But after a decade of building production software — and now agentic AI systems where any inconsistency cascades quickly — we've settled on a clear default: types everywhere, strict, and treated as part of the API contract.
Where we lean in
- TypeScript strict mode on every frontend and Node service.
noImplicitAny,strictNullChecks, the works. - Pydantic / typed Python on every service that talks to a model. Structured outputs aren't a nice-to-have; they're the interface.
- OpenAPI / gRPC contracts as the single source of truth, with client SDKs generated, not handwritten.
- Infrastructure-as-code in a real language (CDK, Pulumi) so the type system covers the cloud, not just the app.
- Schema-validated events end-to-end — at the producer, on the wire, and at the consumer.
What it actually buys you
Three things, mainly. First, fewer 4am pages: most of the production incidents that used to be data-shape mismatches are now compile-time errors. Second, faster onboarding: a new engineer can refactor confidently because the compiler tells them what they're breaking. Third — and this is the underrated one — better AI agents: when a model's tool calls are typed, you can validate, retry, and recover; when they're stringly-typed JSON, you're guessing.
Where it hurts
Types add friction in two places: at the boundary with untyped external systems, and at the very start of a prototype when you're still figuring out the shape. We pay both costs deliberately. The boundary tax is one-time and worth it. The prototype tax is small enough that we'd rather start typed and stay typed than retrofit it later.
The bigger argument
Strict types are a forcing function for thinking. You can't write the type if you can't name the thing. Naming the thing is most of the design. That sequence — name, type, implement — is responsible for more of our shipped quality than any single tool, framework, or methodology.