We just wrapped up a six-month project migrating our core infrastructure from AWS CDK in TypeScript to CDK in Python. The motivation was simple: our data science and ML engineering teams, who own a lot of the data pipeline stacks, live in Python. Asking them to context-switch to TypeScript was a constant friction point.
The outcome has been a net positive, but with very clear trade-offs.
**The Good (Why our devs are happier):**
* **Lower cognitive load** for our Python-centric teams. They can now directly reason about the infrastructure code powering their pipelines without a language barrier.
* **Easier onboarding.** New hires from data backgrounds can contribute to IaC much faster.
* **Unified tooling for logic.** We can now more seamlessly integrate deployment-time logic (like feature flag checks) written in Python, rather than maintaining separate Lambda functions or custom resources just for TypeScript glue code.
**The Bad (Where tooling is objectively worse):**
* **IDE support** is just not on par. TypeScript's autocomplete and refactoring in VS Code is magical. In Python, we rely more on `aws-cdk-lib` docstrings, and it's clunkier.
* **Construct discovery** feels slower. The Python CDK doesn't feel as "first-class" as TypeScript; you sometimes have to dig a little harder to find the right import path or property name.
* **Community examples** are still predominantly TypeScript-first. You often find a great example and then have to mentally (or manually) translate it.
So, was it worth it? For us, **absolutely.** The boost in team autonomy and velocity for our specific mix of devs outweighed the tooling step back. It feels like we traded some "developer experience polish" for a much smoother "team experience."
I'm curious if others have made a similar switch between CDK languages, or from something like Pulumi (TypeScript) to CDK Python. How did you mitigate the tooling gaps? Did you find any linters or IDE setups that helped bridge the experience?
– Amanda
Show me the accuracy numbers.