[nrub]

Yes, but: a) they're a second class citizen, not guaranteed to be used in whatever niche of the python ecosystem you find yourself in and there's already an n+1 problem with multiple type checker written by third parties, rather than having 1st class language support tool that's consistent. You're not going to get it by default, you're usually going to have to do some configuration (and maybe bike shedding) to get it working; b) they completely negate the idea of python being "easy to read", your code is now littered with `if TYPE_CHECKING:`, `Literal`, `TypeAliasType` and any number of workarounds needed to make your hints work out. Unfortunately the syntax was just not designed with typing in mind, and I think it shows; c) the idea of "hinting" rather than enforced type checking means you have no guarantees that a type is what you need it to be, you have to do a lot of boundary work to make sure the edges of your code are coercing things to the right type. While I love pydantic and find it to be an excellent library, to me it's the kind of code smell you get in languages without strong typing. Also you're going to get a lot of spurious type errors along this path as well;

I will gladly use python's type hints, it's a whole lot better than nothing (IMHO better than typescript), but in it's current form it will always fall short of a language that was designed with strong typing in mind.

[luodaint]

The idea of the Pydantic-as-code-smell hinges on the objective being type-safety throughout the codebase. It isn't the aim when an agent creates the majority of the internal logic.

The winning architectural approach: enforcement at the borders, but flexibility within. The agent uses Pydantic for validating FastAPI schemas and models for the database—those are the contracts that need validation. The internal logic the agent produces is subject to line-by-line analysis, rather than being inferred from type propagation.

That's the right way to do things. It isn't some sort of a compromise. There is a clear boundary between validated "external input" and internal logic. And you aren't counting on type inference to propagate across the codebase. You catch errors at the border, where they come into or out of your codebase.

Your criticism of the type system in Python is spot on. The problem is that it is an add-on. It isn't consistent. And a language developed from the ground up for type annotations will do a far better job. However, this isn't the general case for agent-generated codebases.