It's mostly foundational work around developer tooling and infrastructure that isn't already covered by other dedicated teams (eg, there is a dedicated Cinder team). My latest work has focused around formatting and linting, and includes open source work on µsort, our import sorter [1], and fixit, our custom linter [2] that makes it easy for teams to build and deploy their own custom lint rules with autofixes.
Some of my team mates work on driving internal adoption of Cinder, rolling out new versions of Python everywhere, improvements to our build and packaging systems, supporting other Python tooling teams, etc. There's a lot of cross-functional project work, and our primary goal is to improve the Python developer experience, both internally and externally wherever we can.
Keep in mind that many/most of these tools also need to work in diff review and CI tools, not just in an editor. That said, we primarily support developers using VS Code (with internal LSP/plugins/integrations) or our internal version of Jupyter notebooks. We also have a non-negligible number of folks that prefer alternative IDEs or editors like pycharm, vim, or emacs. We try to build our tools such that they are accessible by CLI or APIs, so that they can fit into any of these systems as needed.
I'm not familiar enough with Django to say for sure, but I assume at this point it's almost entirely custom ORM and libraries on top of async django routing/response.
I believe the django app would use a python version of the internal ent ORM. You can get a sense for the style of ent/node from this external fork that was written while the author had access to the original ent https://entgo.io/docs/getting-started
