Kubernetes AI Politikası: Açık Kaynak Sürdürücülüğü Yeni Çağda
Garip gelecek ama, Açık konuşayım: Açık kaynak dünyasında son iki yılda olan biteni izlerken bazen kafam karışıyor. Bir yanda AI ile kod yazmak hiç olmadığı kadar kolaylaştı, öte yanda o kodu sürdüren, bakımını yapan, gerçekten neyin neden yapıldığını bilen insan sayısı aynı hızda artmadı; hatta çoğu yerde maintainer’lar daha da yoruldu. İşte Kubernetes topluluğunun yeni yayımladığı AI katkı politikası tam bu yarığa dokunuyor.
Açık konuşayım, Bu yazıda hem politikanın detaylarına gireceğim hem de — daha önemlisi — bunun Türkiye’deki kurumsal açık kaynak kültürü için ne anlama geldiğini konuşacağım. Çünkü mesele sadece Kubernetes değil. Mesele, AI çağında “katkı” kelimesinin neye dönüştüğü.
Önce şu tabloyu netleştirelim: Neden bir politikaya ihtiyaç vardı?
Geçen yıl boyunca büyük açık kaynak projelerinde PR (pull request) tartışmalarının yarısı koda dair değil, “bu kodu sen mi yazdın yoksa Copilot mu” sorusuna döndü. Reviewer açıklama istedi, katkıcı boş baktı, sonra da “yapay zekâ yazdı, ben tam bilmiyorum” cevabı geldi. Kısacası ortam biraz dağıldı.
Kubernetes gibi binlerce kişinin katkıda bulunduğu, milyonlarca production cluster’ı besleyen bir proje için bu iş daha da kritik. Bir PR merge öldü diyelim, üç ay sonra garip bir regression çıktı; kimi arayacaksın? Modeli mi? Tabiî ki hayır. Karşında sorumluluk alacak bir insan olmalı, işte politika da bunun için gerekiyor.
“AI bir araçtır, bir katkıcı değil. Üretilen kodun arkasında her zaman bir insan durmalı — kim olduğunu, neyi neden yaptığını anlatabilen bir insan.”
Politikanın dört temel direği
Politika aslında dört basit prensip üzerine kurulmuş. Lafı gevelemeden tek tek bakalım: (inanın bana)
1. Şeffaflık — “AI kullandım” demek
İlk kural gayet net: AI kullandıysan PR açıklamasında bunu belirt (yanlış duymadınız). “This PR was written in part with the assistance of generative AI” gibi tek cümle yeterli oluyor. Reviewer bunu görünce nasıl yaklaşacağını biliyor; yanı satır satır mı inceleyecek, yoksa daha çok mantık akışına mı bakacak, en azından yönünü şaşırmıyor.
Durun, bir saniye.
Bu kural ilk bakışta sıradan görünebilir ama bence işin kilidi burada. Çünkü şeffaflık olmayınca güven de olmuyor. Sahada sık gördüğüm şey şu: Katkıcı AI kullandığını saklıyor, sonra review sırasında gelen basit sorulara cevap veremeyince işler çorba oluyor; halbuki baştan söylese kimsenin itiraz edeceği bir durum kalmayacak.
2. İnsan hesap verebilirliği
Hani, Politikanın açıkça yasakladığı birkaç şey var ve bunlar epey düşündürücü:
- AI’ı commit’lerde co-author olarak listelemek (bu kritik)
- AI co-signing kullanmak
- assisted-by” veya “co-developed” gibi trailer’larla işi AI’a atfetmek
İlk anda “neden ki, transparent olmak iyi değil mi” diye düşünebilirsiniz. Ama mantık şu: Bir bug çıktığında, bir CVE açıldığında ya da mimarı karar sorgulandığında karşında yine bir insan olmalı; çünkü AI’a soru soramazsın (sorar gibi olursun. Cevap seni bağlamaz), mahkemeye çıkamazsın ona laf anlatamazsın, lisans imzalatamazsın da. Sorumluluk insanda kalıyor.
3. CLA enforcement co-author’lar için de
CNCF her PR’da Contributor License Agreement (CLA) doğrulaması yapan bir araç sunuyor zaten. AI ajanları bu CLA’yı imzalayamadığı için proje co-author’lar için de CLA kontrolünü aktif etmiş durumda; yanı biri commit’e AI’ı co-author olarak eklerse CLA fail oluyor. PR merge edilemiyor. Basit ama işe yarayan bir fren mekanizması bu. Cosmos DB Rolleri: Uygulamam İçin Hangisi Doğru Seçim? yazımızda bu konuya da değinmiştik.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
4. İnsan etkileşimi zorunlu
Bence en sert kural burada geliyor. Reviewer’lar gerçek kişiyle muhatap olmak istiyor; review yorumlarına AI ile cevap vermek yasaklanmış durumda. Eğer AI’ın ürettiği kodu kendin açıklayamıyorsan PR kapanıyor, nokta.
Eh, Buna ilk anda biraz sert diyebilirsiniz ama açıkçası mantıklı tarafı ağır basıyor. Çünkü bilgi transferi olmadan açık kaynak topluluğu büyümüyor; yeni katkıcı kodu anlamadan merge ettirirse beş yıl sonra o parçanın niye orada durduğunu kimse hatırlamayacak ve sürdürülebilirlik sessiz sedasız bitecek (buna dikkat edin)
Türkiye’deki açık kaynak ekosistemi açısından bu ne demek?
Şimdi işin benim açımdan ilginç kısmına geliyoruz. Türkiye’de kurumsal şirketlerin açık kaynağa katkısı son yıllarda belirgin biçimde arttı; bankacılıkta da telekomda da e-ticarette de ekipler artık fork edip içeride saklamak yerine upstream’e patch göndermeye çalışıyorlar.
Güzel trend.
Ama küçük bir gerçek var: Bizim ekipler İngilizce yazılı iletişimde çoğu zaman rahat etmiyor.
Bu yüzden PR açıklamaları, review yanıtları. Design doc’lar sık sık AI yardımıyla yazılıyor.
Tamamen anlaşılır bir durum.
Kubernetes politikası burada tuzak gibi mi okunmalı?
Bence hayır — aksine fırsat gibi okumak daha doğru. VSIX Yayınını GitHub Actions’a Devretmek: Sade ve Tekrar Edilebilir Bir Yol yazımızda bu konuya da değinmiştik.
Şu ayrımı koymak lazım: AI ile çeviri/redaksiyon yapmak başka şeydir, AI ile kodu üretip arkasında durmamak bambaşka şeydir.
Politika ikinciyi hedef alıyor.
Bir Türk geliştirici Türkçe düşündüğü argümanı AI’a İngilizce çevirtebilir — bunda sorun yok.
Yeter ki o argüman gerçekten kendi kafasındaki argüman olsun; yanı kodu anlasın ve review sorularına çat diye cevap verebilsin.
Evet, doğru duydunuz.
Bu sizi şüpheli göstermez.
Tam tersine biraz olgun görünürsünüz.
Birçok maintainer bu şeffaflığı pozitif okuyor.
Startup vs Enterprise: Pratik öneriler
Küçük ekipseniz ya da solo geliştiriciyseniz hayatınız nispeten basit.
Copilot’u veya Claude’u kullanın, kod üretin ama kendinize şu testi uygulayın:
“Peki biri iki ay sonra gelip ‘neden buraya bu satırı koydun’ derse ben cevap verebilir mıyım?”
Cevap hayırsa önce sız anlayın, sonra gönderin.
Kolay gibi dürüyor ama bazen asıl mesele tam burada patlıyor. Agent Framework ile Kendi Claw’unu Kurmak: Saha Notları yazımızda bu konuya da değinmiştik. Claude Opus 4.8 Fast Mode Copilot’ta: Hız mı, Cüzdan mı? yazımızda bu konuya da değinmiştik.
Enterprise tarafındaysanız iş biraz katmanlı hâle geliyor.
Büyük şirketlerde gördüğüm yaygın hata şu:
Birden fazla geliştirici aynı AI prompt’ünü kullanıp birbirine benzeyen kod parçaları üretiyor,
kimse derine inmiyor,
sonra audit zamanı geldiğinde herkes birbirine bakıyor. Sız ne dersiniz? Odada garip bir sessizlik oluşuyor.
Bunun önüne geçmek için pratik bir checklist fena olmaz:
- Içerik politikasını netleştirin: — bunu es geçmeyin
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
Birkaç noktayı özellikle ayırmak lazım
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
- Içerik politikasını netleştirin:
Neyse uzatmayalım…
| Davranış | Evet/Hayır | Neden? | Davranış | Evet/Hayir | Neden? | |
|---|---|---|---|---|---|---|
| Davranış | Evet/Hayir | Neden? | ||||
| Davranış | Evet/Hayir | Neden? | ||||
| Davranış | Evet/Hayir | Neden? | ||||
| Davranış | Evet/Hayir | Neden? | Davranış | Evet/Hayir | Neden? |
|---|
| Aynısı Aynısı Aynısı 💡 Bilgi: Not
Copilot Code Review Azure Repos’a Geldi: Sahadan Ilk IzlenimlerKubernetes CVE Kayıt Düzeltmesi: Tarayicilariniz SasiracakAgentic Cloud Operations: Icgoruden Eyleme Geçen Bulut Devri Sıkça Sorulan SorularKubernetes’e AI yardımıyla kod gönderebilir mıyım?Evet, gönderebilirsin. Yeter ki PR açıklamasında AI kullandığını belirt, kodu kendin anlıyor ol ve review sorularına insan gibi cevap ver (inanın bana). AI’ı co-author olarak ekleme sakın — hani bu CLA kontrolünden geçmiyor. AI’ı sadece İngilizce çeviri için kullanıyorum, bunu da belirtmem gerekiyor mu?Küçük bir detay: Genelde gerekmiyor aslında. Politika daha çok kod üretimindeki AI kullanımına odaklanıyor (ciddiyim). Açıklama metnini AI ile düzenletmek farklı bir kategori. Yine de büyük bir tasarım dokümanı çeviriyorsan, kısa bir not eklemek iyi niyet göstergesi olur — bence eklemekte zarar yok. Review yorumuna AI ile taslak hazırlayıp manuel düzenleyebilir mıyım?Araya gireyim: Pratikte kimse karışmaz ama yorum özünde sizin kafanızdan çıkmalı. Yanı AI’ı düşünceni netleştirmek için kullanmak ile AI’ın senin yerine konuşması arasında ciddi bir fark var. Açıkçası şunu öneririm: reviewer bir soru sorduysa, cevabı önce kendi kafanda kur, sonra dili düzeltmek için AI’dan yararlan. Şirketim için iç AI katkı politikası nasıl yazmalıyım?Açıkçası, Kubernetes politikasını şablon olarak al, dört temel direği körü: şeffaflık, hesap verebilirlik, CLA ve insan etkileşimi. Onların üstüne şirkete özel kısımları ekle — mesela hangi AI araçları onaylı, hangi veriler prompt’a girmemeli, kod sahipliği nasıl belgelenecek. Bir de hukuk ekibinle bir kez gözden geçirmeyi unutma, tecrübeme göre o adımı atlamak sonradan sorun çıkarabiliyor. AI ile üretilen testler de aynı kuralla mı değerlendiriliyor?Politika test/kod ayrımı yapmıyor, hepsi aynı çerçevede değerlendiriliyor. Ama pratikte test PR’larında reviewer’lar biraz daha esnek davranıyor — hani test kodu doğrulama aracı, production’a doğrudan girmiyor çünkü. Yine de testin neyi neden doğruladığını açıklayabiliyor olmak lazım. Kaynaklar ve İleri OkumaAçıkçası, Open source maintainership in the age of AI — Kubernetes Blog |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments