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.
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.