slopfront
preferences

What does a “normal” professional Python stack look like in 2026?

180 points · submitted Sep 2026 by u/Resident-Donut-4905

Hi! I’m trying to speedrun learning Python and its ecosystem.

I’m already a senior Node.js / TypeScript engineer, so I’m less interested in programming fundamentals and more in the things you usually only learn after working with Python professionally for a while.

I’m using AI plus courses/tutorials, but I’d love some community perspective on what people actually use in real teams.

Some areas I’m trying to understand:

  • uv vs pip / pip-tools / Poetry for project and dependency management
  • FastAPI vs Flask vs Django
  • Pyright vs mypy for static type checking
  • Pydantic for runtime validation/parsing
  • Ruff / Black / Flake8 / isort
  • pytest vs unittest
  • anything else I should definitely know?

A few specific questions:

  1. Do Python devs actually use type hints heavily nowadays? How common is fully typed Python in professional codebases? Do teams usually run mypy/Pyright in CI, or is typing more informal/partial?
  2. What toolset am I most likely to encounter in an established company? For example, I like uv, but should I expect most existing codebases to still use pip + requirements.txt, Poetry, etc.?
  3. What would you consider “must know” ecosystem knowledge for someone joining a Python team? Not necessarily your favorite modern stack, but the things I should recognize immediately when opening an unfamiliar repo.
  4. Framework-wise, what’s worth learning first? FastAPI seems very natural coming from Node, but I assume Django is still much more common in mature product companies. How much Flask should I care about?
  5. Any “Python-specific” practices that surprise experienced JS/TS engineers? Things like virtual environments, import/package layout, sync vs async conventions, typing culture, packaging, etc.
  6. What about design patterns? Is OOP (Object oriented programming) or FP (Functional Programming) more common? Does it depend on the type of application?

I’m basically trying to optimize for:

“I can join a Python team and not look completely lost in the ecosystem.”

Would love to hear what your team actually uses, especially in production.

60 comments · 93% upvoted · other discussions

comments

Diapolo10 119 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

Some areas I’m trying to understand:

  • uv vs pip / pip-tools / Poetry for project and dependency management

uv is the clear winner here, feature-wise. It has the fastest dependency resolution/download, and it also both manages Python versions for you (meaning you don't need pyenv or manual Python installations) and has a growing number of handy features, like uv audit (meaning you don't need tools like pip-audit for auditing your dependencies).

The others simply don't even compare, though Poetry is the closest.

  • FastAPI vs Flask vs Django

Depends entirely on what your goals are, no clear winner. I like to use FastAPI by default unless I have specific requirements other tools work better for.

  • Pyright vs mypy for static type checking

This is a toss-up, people tend to use a mix of both. There's also ty which is growing in popularity, and will likely eventually replace both of these, but it's still in alpha.

  • Pydantic for runtime validation/parsing

Pydantic is great, but mostly reserved for handling API data, since you shouldn't need to clean up internal data.

  • Ruff / Black / Flake8 / isort

Ruff, no doubt. It's all of these in one fast tool with no additional dependencies, and more.

  • pytest vs unittest

Pytest is the industry standard, unittest is more like a stepping stone to it or used for legacy reasons.

  • Do Python devs actually use type hints heavily nowadays? How common is fully typed Python in professional codebases? Do teams usually run mypy/Pyright in CI, or is typing more informal/partial?

It's definitely growing in popularity. Old projects might lack them, but you can still type them yourself using type stub files if you want to. Personally I use them everywhere, both in personal and work projects.

  • What toolset am I most likely to encounter in an established company? For example, I like uv, but should I expect most existing codebases to still use pip + requirements.txt, Poetry, etc.?

I can't speak for every company, but when I joined we used Poetry, and I convinced our technical lead we should switch to uv, and we did. I'd say both are common.

  • What would you consider “must know” ecosystem knowledge for someone joining a Python team? Not necessarily your favorite modern stack, but the things I should recognize immediately when opening an unfamiliar repo.

That depends almost entirely on which field you'd be working in. Still, can't go wrong with knowing some important bits of the standard library (like pathlib, functools, itertools, collections).

  • Framework-wise, what’s worth learning first? FastAPI seems very natural coming from Node, but I assume Django is still much more common in mature product companies. How much Flask should I care about?

All three are in common use. FastAPI and Flask are quite similar, Django is a much bigger thing and takes longer to learn.

  • Any “Python-specific” practices that surprise experienced JS/TS engineers? Things like virtual environments, import/package layout, sync vs async conventions, typing culture, packaging, etc.

I'm a Python dev first, and have only really used JS/TS at my dayjob, so I don't have much insight that'd be useful to you, probably. But maybe project structuring (src vs flat layout) and making the project installable so you can import things in your tests like your project was any other package.

Resident-Donut-4905 [OP] 15 points · Sep 2026

Thanks for the detailed response mate! Helps a ton

proverbialbunny 12 points · Sep 2026

Also PyCharm Community does pretty much all of these by default. (The community version if free.) You can create a new uv base python project with it and not have to think too much about the finer details.

Resident-Donut-4905 [OP] 3 points · Sep 2026

Worth checking too. Thx!

HommeMusical 5 points · Sep 2026

I've spent over 20 years programming in Python; I have nothing to add to the comment you are replying to, it's very good!

Fenzik 7 points · Sep 2026

These are the exact answers I would have given after 10 years working with Python professionally. Listen to this comment OP.

Maybe with only minor thing that although flask is in use, most new projects will start with FastAPI because it’s async-first.

thirdegree 2 points · Sep 2026

Yup, also 10 years professional experience and also my exact answers. Maybe with a note that while ty is in alpha, it is also imo already as good as or better than the competition (in part because it's, in addition to being a very good type checker, also an excellent lsp server that can be integrated into any decent editor).

Diapolo10 2 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

Yeah. Basically FastAPI is great for any use-cases where you don't want to primarily serve HTML (or if you want to write the front-end in another language), Flask is better suited for Python-only websites, and Django is the "everything and the kitchen sink" batteries-included-but-highly-opinionated option you'd use if you want all the features it offers, like the admin panel.

The first two are far easier to get into, and both have good tutorials (FastAPI has its official tutorial, Flask has the Mega-Tutorial). I only briefly played around with Django years ago so frankly I don't have much to say about it tutorial-wise.

Fenzik 2 points · Sep 2026

FastAPI is fine for HTML but not super ergonomic, you need to do most of the work yourself. There’s a few frameworks like fasthx to serve htmx snippets and can be very nice, but depends entirely what you are trying to do.

Diapolo10 2 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

Yes, I never said it can't do it, only that by default Flask is better designed with HTML in mind.

GoguGeorgescu 2 points · Sep 2026

PDM does everything uv does and a bit more, at some point uv will implement everything PDM has, but it's gonna take some time, but you can swap the dependency resolver with uv and get the best of both worlds.

Being a node guy I like my npm scripts, uv doesn't have them, yet, but PDM does.

Fenzik 1 points · Sep 2026

PDM struggles with monorepos/workspaces and is very slow. We set up our monorepo with it at work a few years ago and eventually moved to uv and never looked back.

What do you mean about npm scripts though? What does npm (and pdm) offer that isn’t covered by uv run or the native scripts entrypoint? Not a critique, genuinely wondering

GoguGeorgescu 1 points · Sep 2026

Haven't used monorepos as for workspaces I only used it once so I have limited exposure, you can tell PDM to use UV as its dependency resolver.

The project scripts table is for built binaries, if you set up a script to run main or run the api from a method inside the app programmatically like uvicorn.run() the script is the command you run after you install your api as a wheel, if I have a script myapi that calls I to uvicorn.run(), after I build the api as a wheel and I install it on the server, I just call myapi from the cli to start the server.

Manager scripts like tool.pdm.scripts are development scripts, like test, lint, watch, migrate etc. And you define what the script does.

PDM scripts are really powerful, you can call the shell, you can do composite scripts, and they run in the context of your project. It runs at the project level, not at the system level.

pdm scripts

Fenzik 1 points · Sep 2026

Ah okay so more like Poe the Poet, just, Make, etc. Indeed uv does not offer this!

Diapolo10 1 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

If scripts are the only difference between uv and pdm you care about, personally I've been experimenting with using mise lately to add Taskfile as a dependency and to then use that for scripting development tasks (as opposed to using Makefiles which I currently have, but in practice rarely ever used because they're cumbersome on Windows).

I don't know how pdm handles script caching (if it does that at all), but for Taskfile it's both very configurable and powerful. Every task can define dependencies, so you can be sure any task run will be valid (for example your lint task can require an installation task as a dependency, so you know your project dependencies are installed before the linters run). I got introduced to Taskfile at work, and it's frankly kind of amazing, but I didn't immediately jump ship in my personal projects because then I'd need yet another thing installed on my system to do dev work.

The part where mise comes into this is that I use it for adding programs as dependencies (like specific versions of uv, task, and cspell set in a lockfile), meaning I only need a global mise installation and everything else is project-specific. It's like a cross-platform package manager specifically for dev tools. Incidentally it also works perfectly for keeping local dev environments and CI pipelines as identical as it gets.

GoguGeorgescu 1 points · Sep 2026

I know mise, I briefly present it in my python development environment training I hold internally, I looked for a tool that covers everything so PDM kinda fills all the gaps, one other main requirement was to be conda and artifactory friendly, so far PDM is the only tool to do them all so I'm sorta biased, but, I prefer it due to development time benefits.

The scripts are nice because I'm also a node guy, so they fit my mental models, I usually group my dependencies, so linting and testing have their own dev groups, and in CI, I only install the group I need per stage.

Tbh that is just dev helpers, my images need to be slim and secure, so I use distroless hardened images and I have to fallback to pip and requirements.txt in the runtime stage. Although the CI pipelines run PDM for everything else.

I looked into taskfiles but they are not portable in the way I need them, looked at a lot of them, they still had some gotchas that wouldn't work in my company, so it's makefiles or tooling that works everywhere exactly the same, long running pipelines to lint, test and build take a lot of time to run, I need a fast feedback loop locally and I don't want to remember package names, so scripts are a gift to write once and the whole company can remember, lint, test, coverage, build, that's all you need to remember. We use template projects so everyone uses the same base everywhere regardless of organization to make things simpler to debug and fix and also audit.

Diapolo10 1 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

I looked into taskfiles but they are not portable in the way I need them

Would you mind elaborating on that? Because in my experience the tasks I've written have been very portable.

GoguGeorgescu 1 points · Sep 2026

Mise needs you to know toml, I needed a tool to simplify not add on top, even dagger needs you to know how to structure the tasks, so there's a lot of overhead in knowledge, there's also the case for being compact, that's why I opted out of makefiles also and kept everything in pyproject.toml.

Now that I think of it, that was also one of the top priorities on the list, no extra cruft, keep everything as minimal as possible, so PDM's scripts fully covered that gap.

Diapolo10 1 points · Sep 2026 · I write code for a living -- https://github.com/Diapolo10

Mise needs you to know toml

Eh, that sounds a bit of a weird argument considering pyproject.toml files exist. Did you maybe mean to write that Taskfile uses YAML so you'd need to know that?

On the other hand, most if not all CI pipelines use YAML for configuration so it's not like you're going to escape that either unless you don't use CI pipelines in the first place.

For anyone else coming across this discussion, I currently use this toy project to experiment with this stuff, including using Git hooks without relying on pre-commit or Lefthook (since Taskfile enables me to configure my hooks as I wish).

GoguGeorgescu 1 points · Sep 2026

Good point, but mine also stands, you need both a mise.toml and pyproject.toml to achieve something you can also do with only one.

In my search for minimalism, I just stopped going further than this. It's hard enough to get people out of 2012 and into 2026, add another tool on top and the friction isn't worth it.

qlkzy 10 points · Sep 2026

There is a huge legacy cross-section. The underlying ecosystem is quite unopinionated on tools, so you get the same variation you do with libraries in other languages.

Type hints: varies, but fully-typed with strict typechecking as part of CI is definitely common in serious projects.

Tools etc: uv is most popular at the moment, there's still a long tail of poetry. You need to be able to understand pyproject.toml and requirements.txt. I think ruff has largely subsumed the separate tools.

Frameworks: I would say you just need to know one "heavy" one and one "light" one. Django is by far the most popular "heavy" framework. FastAPI has by far overtaken Flask for new projects, but knowledge is very portable between them: FastAPI is basically "what if we ported all the mistakes of Flask to the current fashions"

Pytest is substantially more popular than unittest from what I have seen.

Pydantic exists alongside data classes and attrs (+ cattrs). Personally I like Pydantic the least, but FastAPI has made it the most popular. You should be aware of the others, though.

In general any sane Python shop will be aware of the variation and account for it in new hires, the same way people account for variations in libraries.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Many thanks! Helpful insights

nog642 6 points · Sep 2026

  1. It varies. I don't think "fully typed" is that common, but at least for some functions it's decently common. Definitely worth knowing how typing works. If a team wants to enforce typing they'll use linting, so you don't need to worry about having it as a habit.

  2. Many companies will have their own systems built on top of pip/whatever. And I'm not totally sure but I think uv isn't broadly adopted, yeah.

HommeMusical 2 points · Sep 2026

I don't think "fully typed" is that common,

I think it's fairly common, particularly in development that has been started in the last five years or so.

I worked on PyTorch, for example, and it's a massive package that's completely typed.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Thanks! I understand that the greatest value lies in typing some domain/model entities not just "str" and primitives. What's the usual approach for typing? Like Python has native typing and/or Mypy/Pyright for static typing? what about Pydantic for runtime validations (although that's another topic maybe more related to validating request shapes etc?)

NerdyWeightLifter 3 points · Sep 2026

I've mostly seen strict typing used when you want to highly optimise some part of your code by using the tricky compiler and GPU extensions, where the hardware needs to know specific types.

Resident-Donut-4905 [OP] 2 points · Sep 2026

Interesting

HommeMusical 1 points · Sep 2026

I understand that the greatest value lies in typing some domain/model entities not just "str" and primitives.

You get value at all levels. Even just typing the primitives will prevent that error when occasionally the number you expected comes in as a string.

If you use a coding assistant, which pretty well all professionals do these days, you simply tell it that everything has to be typed in your AGENTS.md. Then you look at the actual results and request tweaks.

I do fairly often say, "Look at the files in something/ and try to come up with more specific types", and coding agents seem very good at that.

mypy is slow; pyright is slow; use ty for your type checking.

Rain-And-Coffee 10 points · Sep 2026

My company uses FastAPI for some Python API.

We don’t use Django since we prefer to keep UI separate with things like React or NextJS

Resident-Donut-4905 [OP] 1 points · Sep 2026

Gotcha. Thanks!

enigma_0Z 3 points · Sep 2026

to answer your bullet points —

Just about anything is better than raw pip for development environment management, which is where the deps will really bite you in the ass. I really like uv, its usage patterns parallel npm pretty well. Managed to convert a whole shop raw dogging it with just pip and virtualenvs to uv.

I started with flask on a personal project and when it came to productionalizing it, it kinda started melting down. I switched over to fastapi and haven’t looked back. Conveniently my current job also uses FastAPI and made that decision independently.

I like pyright. Specifically I use the basedpyright plugin in codium.

I like pydantic for shaping api data. If you go with FastAPI you pretty much have to use it but it works well for other purposes including validating and loading data from json/yank cleanly and relatively quickly. Watch out for recursion though. I had a bad model with a circular reference and managed to generate a multi-GB JSON file accidentally. (no that is not a typo)

Ruff etc — we use ruff on our team but I kinda feel it’s too prescriptive. Some style / linting is better than none but i don’t use a linter on personal projects.

I like pytest but have used both. Pytest is less prescriptive IME but YMMV.

enigma_0Z 1 points · Sep 2026

Oh an addendum — I wrote a UI in react which embeds itself in the backend for a personal project and I’m honestly quite proud of the pattern.

Never tried Django.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Thanks for the insights!

replicant86 3 points · Sep 2026

We do uv, ruff, pydantic, fast api, pytest and everything is fully typed using mypy on a project with over 500k lines of code. I yearn for ty release

Resident-Donut-4905 [OP] 1 points · Sep 2026

Sounds like a modern stack. Had to look for “ty” because I didn’t know about it. Thanks!

fay-jai 2 points · Sep 2026

Just wanted to thank you for asking this detailed question - this is something that I’ve been thinking about in my recent Python learning as well and I’m following this question so I can learn more as well!

Resident-Donut-4905 [OP] 2 points · Sep 2026

Glad it helps other people too!

enigma_0Z 2 points · Sep 2026

To answer your specifics

  1. In my professional experience it’s pretty commonly pydantic but not always. FastAPI works well with it and i’ve only really seen FastAPI projects professionally though. Personally, i tend to use pydantic if type safety matters a lot, and not if it doesn’t or it’s not a class which would be serialized anyway. Pydantic is particularly good for things you want to get into JSON for APIs

  2. YMMV. The company I’m at now was just using pip and virtualenv like masochists but I converted them to uv after spending a lot of time untangling their old CI. it was a mess. In FOSS projects these days i mostly see uv but seeing any of these would not surprise me.

  3. How does a virtualenv work. How can you build one from a pyproject.toml without uv, poetry, or similar. How does the pyproject.toml work. Do you know how to build a dist for a python project? What about an egg? Knowing these things will make your CICD or DevOps engineer very very happy.

  4. FastAPI is nice. Flask betrayed me right before i went to production with a personal project (and converted to FastAPI). I also work with FastAPI professionally. No opinion or experience on Django

  5. Not using a tool that takes the place of npm in python (i like uv) is absolutely wild but 100% a thing in some places. Get ready for development environment management hell. And dependency hell. And cicd orchestration hell. All in a big dumpster fire. Typing, type safety etc are similar — at least IME — TS / JS / React is one of my other languages. TS can be a bit more persnickety than typehinted PY but less than Pydantic.

  6. OOP and FP in equal parts honestly. since the top level object in a given python file is the actual file (as a module) you’ll see lots of tools which implement both patterns wherever it makes sense. Kinda depends, but i’ve seen both OOP (with multiple inheritance even) and FP with composition.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Thanks! Definitely need to dive deeper on #3

whipdancer 2 points · Sep 2026

uv + ruff + FastAPI (unless there's something specific that needs Flask)

Mix of pyright and mypy

Pydantic since we use FastAPI so heavily

Pytest

We build pre-commit hooks that enforce the linting rules - we require types.

Our TS stuff has an equivalent setup.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Cool! I still don't understand why mypy and pyright coexist?

Ragoo_ 2 points · Sep 2026

Pydantic for runtime validation/parsing

In my opinion only if you are required to use it (e.g. FastAPI) or you really need some advanced validation rules. Otherwise msgspec serves the same purpose but much faster and lighter.

Ruff / Black / Flake8 / isort

These are all bundled in Ruff.

Pyright vs mypy for static type checking

Basedpyright if you want a mature type checker, Pyrefly (or in the future ty) if you want something from the next generation of type checkers.

FastAPI vs Flask vs Django

Flask is probably not really worth using anymore, but FastAPI and Django serve different purposes and you most likely want FastAPI for most use-cases. Litestar sits in the middle but it's not nearly as popular.

Some other common ones where I have a clear preference for the newer one:

  • Polars instead of Pandas for speed and syntax
  • zensical as an mkdocs replacement (mkdocs is no longer updated)
  • niquests instead of requests or httpx
  • marimo instead of Jupyter notebooks
  • and for the last one I will say that Typer and pydantic-settings are quite popular but I prefer the syntax and flexibility of cappa and dataclass-settings. But these are much smaller, so that's a niche opinion

As for your other questions: If a project doesn't have a pyproject.toml file and instead uses requirements.txt, that immediately feels outdated. Any modern project should also be fully type hinted which includes using dataclasses (/pydantic/msgspec) over dicts whenever possible and Literal/Enum. It should also use uv, ruff and a modern type checker and pytest.

OOP is still around and can be abused (Langchain is painful for me). Personally I'd prefer shallow inheritance, more composition, dataclasses for data and functions over methods.

Resident-Donut-4905 [OP] 2 points · Sep 2026

Thanks for the inputs!

cmxthirtysixhundred 2 points · Sep 2026

As far as dependency management, I've been writing Python for 15 years and I've never needed anything more than pip and venv, but maybe my use case is different. I mostly write Pyside6 desktop applications these days.

GoguGeorgescu 1 points · Sep 2026

I am amazed no one mentioned PDM as the project manager, if you're a node guy, you'll love it's scripts in pyproject.toml, just like npm scripts in package.json. UV will probably get them at some point as there is an open issue on their github, but if you want it now you can get it. You can also swap it's dependency resolver with UV and get the best of both worlds.

One more thing that it does, which neither uv or cookiecutter do is run find and replace after you make a new project based off a repo template. Set up a fastapi project in a repo, configure some stuff, add some scripts like a watch script that runs uvicorn on your api with the --reload flag so you do pdm run watch, and save it all in a repo, want a spike to test out something, why run the whole setup and config again, you do pdm new <template_repo[@branch]> new-name, go through the wizard and presto, a configured base api to just start working. Oh, and everything that contains the template name in its path gets renamed to the new name. The branch name is gold, I use it all the time when I have some setup I want to test out before pushing it back into main.

For the rest, mypy, pyright, pydantic, ruff and pytest, there is nothing else you should need in 99% of use cases.

Edit: forgot to mention, setup.py and requirements.txt are dead, PyPA strongly recommends any new projects use pyproject.toml, requirements.txt is left for legacy projects

Edit 2: saw someone mention ty, also excited about it, pyright and mypy have some overlaps but also have some divergence, as with ruff I'm expecting ty to cover both of them across the board.

Resident-Donut-4905 [OP] 1 points · Sep 2026

Will look at PDM! Thanks. Why did you mention both mypy and Pyright? Don’t they serve the same purpose?

Also is anything from this stack used if, let’s say, Django is used?

GoguGeorgescu 2 points · Sep 2026

I mentioned briefly that they overlap for the most part, but they do have some specific cases where they don't, I work in a highly regulated industry and I usually leave them both on just for those edge cases, for many projects just use mypy and go about your day.

Also, vscode's python package comes with it, so there's also that.

If you use Django, nothing in the tooling changes, maybe just the flags for the tools, I think you can find what flags to use in their docs, I don't use Django, so I don't really know.

HommeMusical 1 points · Sep 2026

mypy, pyright

sooooooo..... sloooooooowwwwww

Use ty.

GoguGeorgescu 2 points · Sep 2026

Ty is alpha, not allowed due to company policy, you gotta do with what you got :)

Difficult-Ambition61 1 points · Sep 2026

uv + ruff + ty + prek

pachura3 1 points · Sep 2026

Here is my discussion on the topic:

https://www.reddit.com/r/learnpython/comments/1r75guh/modern_python_techtool_stack_for_implementing/

Better_Carrot7158 1 points · Sep 2026

whatever helps get the job done. Its so fast to learn

seriousgourmetshit -3 points · Sep 2026

1 - not really. If it were that important to me I'd be using another language. Worth learning about though.

2 - I use poetry, but there are lots of good options

3 - nothing in particular tbh. If youre not doing a lot of scientific computing or data heavy stuff, theres nothing that hard that you cant just pick up

4 - I use Django and fast api. Nothing wrong with flask either though.

5 - nothing comes to mind, but i use TS / react on the front end so I could just be used to both

Maybe not very helpful, but thats my thoughts working on python teams for 5 or 6 years

Resident-Donut-4905 [OP] 1 points · Sep 2026

Thanks! What's your experience? which kind of projects did you work on with Python? e.g. business logic services, APIs, other scripts...?

seriousgourmetshit 3 points · Sep 2026

Internal tooling / custom analytics platforms

Resident-Donut-4905 [OP] 1 points · Sep 2026

👍

HommeMusical 1 points · Sep 2026

I gotta yell: TYPE ANNOTATIONS ARE A MUST!!!!!

In 2026, they are no longer optional for serious development.

:-D

HommeMusical 1 points · Sep 2026

1 - not really. If it were that important to me I'd be using another language. Worth learning about though.

BUZZ! This is not the correct answer.

Five years ago, few projects used types. Now nearly all serious new development uses types everywhere, except for tests of course, and one-page scripts perhaps. I have worked for three very different companies during that time and all three of them had almost complete type hints.

Most professionals are using coding assistants now, and you just put a command in your AGENTS.md saying that type hints are mandatory in all new code: sometimes you need to jog the assistant a bit and say, "You can be more specific here," but in my experience the coding assistants really do an excellent job, and having the type in the existing code will make the agent more likely to do a good job in future, so it's win/win.