I'm missing more about the second stage here. Clearly, writing code is an AI job, we can discuss about openspec or, like in the post, close programming with the agent.
I'm more interested in how to automate the review process and which workflows work better.
It’s not AI’s fault. It’s like leaving an inexperienced intern alone with all the production passwords and encouraging them to experiment.
Blaming the AI or the cloud provider is like deploying an unverified tool you “found somewhere”, or running a forum script meant for a different version or a “similar enough” environment.
Hi - I built Kaniop, a Kubernetes operator for Kanidm.
The goal is simple. Manage my IDM in a GitOps way. I wanted a declarative operational model to configure in an easy way all my OAuth2 clients, apart from keeping track of them.
It is fully operational, and I've been using it for 6 months. In this time I've being listening the community and with some mates we improved the edge cases and tune the operator to be bullet proof.
It was working perfectly since the first day, no bugs, just minor tweaks. I handwrote it 1 year ago with a strong architecture and intensive e2e testing. Currently, I use AI for maintaining it and applying fast tweaks, it helped me keep the feedback loop fast and the tool maintainable and full of features.
The performance is great, the consumption of resources for the full services is pretty low, thanks to Rust and a good engineering job. Kanidm is awesome in that part because it doesn't require any external database, and the footprint is minimal.
I would especially like feedback on:
- operator shape and CRD ergonomics
- whether the GitOps identity-management angle is useful in practice
- what people would expect from upgrades, backups and day-2 operations