You Are Lying to Your Compiler. Use "satisfies" Instead of "as". A developer argues that TypeScript's `as` type assertion silently suppresses compiler errors and can ship runtime bugs, and recommends the `satisfies` operator introduced in TypeScript 4.9 instead. The writeup shows that `satisfies` validates object literals against a type while preserving literal types, so typos and missing properties are caught at compile time and keys like `colors.pink` produce errors, while `as` remains appropriate for cases such as DOM queries where the compiler cannot know the runtime value. You are lying to the compiler. It is time to stop. I am going to say something that might make some of you uncomfortable. Every time you write as in TypeScript, you are basically telling the compiler to shut up and trust you. That feels powerful in the moment. It is also how you ship bugs to production. The as keyword does not check anything. It is a command, not a question. You are saying "I know better than you, compiler, and I don't need your help." Sometimes that is true. Most of the time it is not. TypeScript 4.9 gave us something better. It is called satisfies. Once you understand what it does, you will wonder how you ever lived without it. What as actually does Let me be clear about the mechanics here. When you write: const user = { name: "Alice" } as User; You are doing a type assertion. You are overriding TypeScript's type inference with your own judgment. The compiler will check that the assertion is plausible. It will not verify that your object actually has all the required properties. Here is the problem. as suppresses errors. It does not catch mistakes. It hides them. Look at this: js interface User { name: string; email: string; } const user = { name: "Alice", username: "alice123" } as User; TypeScript will not complain. But you just created an object that claims to be a User while missing the email property and carrying an extra username field. If your code later tries to read user.email , you get undefined at runtime. This is exactly the kind of silent failure TypeScript was supposed to prevent. Enter satisfies The satisfies operator does something different. Instead of overriding the type, it validates it. Same example with satisfies: js const user = { name: "Alice", email: "alice@example.com" } satisfies User; If you misspell email as emial , or forget it entirely, TypeScript throws an error immediately. Your IDE will yell at you. The compiler will refuse to build. But here is the beautiful part. satisfies does not widen your types. With a type annotation like const user: User = {...} , TypeScript treats user.name as string . With satisfies , TypeScript keeps the literal type. If you wrote name: "Alice" , then user.name is exactly "Alice" , not just string. The difference in practice Let me show you a real scenario that changed how I write TypeScript. Imagine you are defining a color palette: type ColorConfig = Record