It's sort of postponing the actual work, though: there is indeed value in asserting that your code adheres to some domain model, but it's not entirely clear to me whether the value is outweighed by the friction when that arbitrary ChatGPT-generated domain model disagrees with your domain. There is dramatically more value in asserting that your code adheres to the correct domain model, and you can only know that by, well, modelling your domain.
This is true, but: it’s far easier to get there once you have gotten types in place in the first place—because that kind of domain modeling very often entails non-trivial refactoring work. Our guidance to folks when I was at LinkedIn was that as much as PRs possible adding types should not change the runtime code at all, only describe what was already there (even if it was really dumb!). That meant TS conversions were never going to be at fault for prod issues, only for fixing prod issues; and it therefore also meant that those PRs were much less likely to get reverted… which is super important since a revert would then have knock-on effects on any other modules which relied on the types from the reverted PR.
Comments
You can do a refactoring later, or reap the benefits of typescript for all new code.
ChatGPT here doesn't need to do a good job. You get value just by getting a codebase type-annotated.
It's sort of postponing the actual work, though: there is indeed value in asserting that your code adheres to some domain model, but it's not entirely clear to me whether the value is outweighed by the friction when that arbitrary ChatGPT-generated domain model disagrees with your domain. There is dramatically more value in asserting that your code adheres to the correct domain model, and you can only know that by, well, modelling your domain.
This is true, but: it’s far easier to get there once you have gotten types in place in the first place—because that kind of domain modeling very often entails non-trivial refactoring work. Our guidance to folks when I was at LinkedIn was that as much as PRs possible adding types should not change the runtime code at all, only describe what was already there (even if it was really dumb!). That meant TS conversions were never going to be at fault for prod issues, only for fixing prod issues; and it therefore also meant that those PRs were much less likely to get reverted… which is super important since a revert would then have knock-on effects on any other modules which relied on the types from the reverted PR.