Ai
Mar 27, 2026

Kat Cosgrove, Head of Developer Advocacy at Minimus, brings a grounded and transparent perspective to the evolving Kubernetes ecosystem. From her leadership roles across the Kubernetes Steering Committee and Release Team, she highlights a community becoming more structured while staying true to open-source principles.
In this conversation, she reflects on the realities of large-scale collaboration, the growing influence of AI, and why strong documentation and contributor engagement remain critical to sustaining Kubernetes’ long-term success.
Kubernetes is a very large project now, both in the scope of our influence and in the number of contributors we have. We’ve had to get much more well-organized, and function more like an exceptionally transparent company. We still do everything in public since this is still open source, but we now have an extremely well-defined and publicly-documented organizational structure.
There is no such thing as perfect. No matter how good you are at your job, something out of your control will go wrong and it will be your responsibility to clean it up. Everyone else in the project knows that, though, and many of them have experienced it themselves, so it’s nothing any of us are ashamed of or embarrassed about.
We always have more work available than we have contributors to do it. I think the best place to start is in SIG Docs or SIG Release, since they both allow you to have regular contact with people in other parts of the project and make it easier to sort of dip your toes in before you start filing KEPs. If you already know what part of the project you want to work in, though, the single best thing you can do is go to the regular meetings. All SIGs and WGs have meetings scheduled weekly or biweekly.
The Release Team does a lot of project management type of work. We aren’t responsible for the work on a specific enhancement that makes it qualify for Beta or GA, but we are responsible for ensuring those qualifications are met. That means ensuring an enhancement has had Production Readiness Review, that it has documentation for any user-facing changes, that merging new code doesn’t cause any test failures, that things merge on time – it’s a lot of work and requires a lot of attention.
AI is presenting fairly significant challenges. We don’t have a problem with the use of AI as long as it’s disclosed and the submitter understands their code and can interact with reviewers using their own words. Not everyone obeys those requirements though, and the prevalence of AI coding assistants has resulted in a large number of fully-generated low-quality PRs that are creating a significant burden for reviewers.
If you want people to be able to use your tool, you have to tell them how. Kubernetes is notoriously complex; without good documentation, it would be impossible for most people to use. We believe this so strongly that we do not allow enhancements into a release unless its user-facing changes are documented, even if it’s something as simple as a feature flag.
Technology tends to move in hype cycles, and we’re in the middle of a hype cycle for AI right now. Everyone is trying to figure out where it fits, and the result is that we’re sort of inundated with a lot of AI tooling where it doesn’t really make sense, but everyone is trying to use it anyway because nobody wants to be left behind. I think the next significant development will be figuring out how to use AI in a way that is effective and useful to human practitioners without creating a burden elsewhere, eroding trust, or causing actual harm.
Connect with Kat on LinkedIn for more updates.
Related Articles