You're right that IDE/dev-time performance might be slower than using generated types since this relies on "dynamic" TypeScript inference rather than static codegen'd types.
That said, depending on how your codegen works and how you're using protos at runtime, this approach might actually be faster at runtime. Types are stripped at compile-time and there’s no generated class or constructor logic — in the compiled output, you're left with plain JS objects which potentially avoids the serialization or class overhead that some proto codegen tools introduce.
(FWIW, type inference in VSCode seemed reasonably fast with the toy examples I was playing with)
Typescript never generates classes or constructors that aren't present in source code. Whether or not constructors are present is completely independent from whether you're using code gen.
> depending on how your codegen works and how you're using protos at runtime, this approach might actually be faster at runtime
If your codegen is introducing runtime overhead you should use a different codegen.
> type inference in VSCode seemed reasonably fast with the toy examples I was playing with
It usually is. It can become a problem in a real project that has a lot of stuff going on, though.