Yapay Zekâ Destekli Kodlama ve Güvenlik: Liderlerin Ekiplerin Yapay Zekâyla Geliştirme Yapması Hakkında Bilmesi Gerekenler
Yapay Zekâ Bilgisi Eşitsizliği: Ekip üyeleri yapay zekâ araçları ve yetkinlikleri konusunda kendilerini geride bıraktıkça liderler zorluklarla karşılaşıyor.
Yapay Zekâ Destekli Kodlama Açıklaması: Teknik olmayan çalışanlar, istemler vererek işlevsel araçlar oluşturuyor ve fikirlerin hayata geçirilmesindeki boşlukları kapatıyor.
Güvenlik Endişeleri: Yönetilmeyen yapay zekâ destekli kodlama araçları, özellikle kişisel olarak tanımlanabilir bilgilerin güvenlik açıkları olmak üzere veri işleme ve veri açığa çıkması riskleri oluşturuyor.
Maliyet Etkileri: Yapay zekâ araçlarının optimize edilmeden kullanılması beklenmedik giderlere ve finansal risklere yol açabilir.
Ölçeklenebilirlik Sorunları: Başarılı yapay zekâ destekli kodlama araçları, ölçeklenebilirlik ve güvenilirliği sağlamak için profesyonel denetim gerektirir.
Dürüst olalım: Yapay zekâ söz konusu olduğunda hepimiz farklı noktalardayız. Liderler için bu durum rahatsız edici olabilir — ekip yöneticilerini yapay zekâ bilgisi ve kullanımını mümkün kılma konusunda geride bırakan, hızla ilerleyen ve çoğu zaman bazı şeyleri bozan doğrudan rapor veren çalışanların sayısı hiç olmadığı kadar arttı.
Birçok kuruluş yapay zekâ araçlarının açıkça keşfedilmesini teşvik ederken, teknik olmayan birçok çalışan için yapay zekâ kullanımını mümkün kılmanın bir sonraki aşaması olan doğal dille kodlama; ne inşa ettiğinize, bunu kimin için yaptığınıza ve hangi verilerin depolanıp kullanıldığına bağlı olarak farklı risk düzeyleri barındıran bir maceradır.
Bu durum, özel araçlar geliştirmeyi süreç ihtiyaçları için çoğu zaman en bariz çözüm hâline getiren proje yönetimi ve operasyon ekiplerinde özellikle yaygınlaşıyor — ayrıca yapay zekâ kodlama ajanlarıyla bunu onaylamak hiç olmadığı kadar kolay.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Ekipler bir şeyler geliştirmeye başladığında nelere dikkat etmemiz gerektiğini anlamamıza yardımcı olması için, DPM'nin Yapay Zekâ Başkan Yardımcısı Tim Fisher'ı konuyu açıklaması için davet ettim. Bu makale, "Hey patron, Claude ile yaptığım şu harika şeye bak!" mesajını alan herkes için — umarız faydalı olur.
Öncelikle, Doğal Dille Kodlama Nedir? Ve Aslında Neden Değerlidir?
Bu makale kapsamında doğal dille kodlama, özellikle teknik olmayan bir kişi tarafından komutlar vererek kodlama yapılması anlamına gelir. Bu, bir yazılım geliştiricisinin GitHub Copilot gibi bir araç kullanmasından farklıdır; çünkü bu durumda insan, çalışmaya hâlâ anlamlı bir teknik bilgi birikimi getirir. Burada sözünü ettiğimiz kişiler CFO, operasyon koordinatörü, daha önce tek satır kod yazmamış ve şimdi yalnızca doğal dilde komutlar kullanarak işlevsel araçlar geliştiren proje yöneticisidir.
Fisher'ın konuya giriş değerlendirmesi sizi şaşırtabilir: Bu konuda gerçekten hevesli. "Kod yazamayan insanların artık istedikleri şeyi zihinlerinden çıkarıp herkesin görebileceği, üzerinde oynayabileceği ve kullanabileceği bir biçime dönüştürebilmeleri fikrini seviyorum," diyor. "Bu, daha önce var olmayan bir iletişim kurma biçimi." Bunu teknik bir yetkinlikten çok, yeni bir iletişim ortamı olarak değerlendiriyor — her zaman fikirleri olan ancak bunları ifade edecek teknik kelime dağarcığından yoksun kişilerin vizyonu ile uygulama arasındaki boşluğu kapatan bir ortam.
Doğal dille kodlama, daha önce var olmayan bir iletişim kurma biçimidir.
Fisher açıklıyor: "Bu, insanların tasarım ekipleriyle çalışırken yaşadığı zorluklara biraz benziyor. Çöp adam bile çizemem. Bu yüzden birine görsel bir şeyi anlatmak istediğimde, iyi olduğum, üzerinde iyice düşünülmüş pek çok kelimeyle bir şeyi açıklamama ve diğer taraftan tasarım yapmayı bilen birinin 'Şimdi ne istediğini anladım' demesine olanak tanıyan araçların var olmasına çok seviniyorum."
Liderler için bu bakış açısı değişikliği önemlidir. Doğal dille kodlamayı tamamen durdurma dürtüsü, burada gerçekten faydalı olan şeyi gözden kaçırır: Doğal dille kodlama uyumu hızlandırabilir, fikirleri daha hızlı görünür hâle getirebilir ve teknik olmayan ekip üyelerine katkıda bulunmaları için yeni bir yol sağlayabilir. Soru, buna izin verip vermemek değildir. Asıl soru, araç geliştirildikten sonra neler olduğunu anlayıp anlamadığınızdır.
Değerin Sona Erdiği ve Riskin Başladığı Nokta
Fisher, doğal dille kodlamanın "iletişim" aşamasını, bunun ardından gerçekleşme eğiliminde olan şeylerden dikkatle ayırıyor — tonu da tam bu noktada değişiyor. "Bence bunun değeri çoğu zaman burada sona eriyor," diyor. "Fikirleri ve yönlendirmeleri iletmenin çok daha iyi bir yolu. Ancak gördüğümüz şu ki, bundan sonra bazı şeyler gerçekleşebiliyor ve bunlar 'Bak, sana bir fikir ilettim, artık ortak bir dil kullanıyoruz' noktasının ötesine geçiyor. İşte o zaman korkutucu hâle geliyor."
Sorun komutlar vermek değil. Sorun devreye almak. Bir prototipin gerçek insanların kullandığı, gerçek verileri depolayan ve gerçek altyapı üzerinde arka planda çalışan bir araca dönüştüğü an — ve onu geliştiren kişinin hâlâ perde arkasında neler olup bittiğini bilmemesi.
Liderlerin Bilmesi Gereken Güvenlik Açıkları
Kişisel Olarak Tanımlanabilir Bilgiler ve Veri İşleme
Çoğu lider için en sezgisel risk, kişisel olarak tanımlanabilir bilgilerle (PII) ilgili olacaktır. Fisher, sınırın nerede olduğunu somut bir örnekle açıklıyor: "Bence karmaşıklığın sınırı, çalışan veya müşteri verilerinin bu verileri başka kişilere aktaran bir sisteme alınmasından hemen önceki noktadır. PII sorunlarıyla karşılaştığınız an budur."
Karmaşıklık sınırının, çalışan veya müşteri verilerinin bu verileri başka kişilere yeniden sunan bir sisteme aktarılmasından hemen önce olacağını düşünüyorum.
Risk, verilerin hassasiyeti ve bu verilere erişebilecek kitleyle birlikte artar — operasyon ve proje yönetimi ekiplerinde bu veriler çoğunlukla müşteri bilgilerini, çalışan kayıtlarını, ücretlendirme verilerini veya gerçek hukuki risk taşıyan iletişim bilgilerini içerir.
Kontrolden Çıkan Maliyetler ve Belirteç Kullanımı
Birçok yöneticiyi hazırlıksız yakalayan risklerden biri verilerle değil, tamamen parayla ilgilidir. Fisher, çoğu kişinin fark ettiğinden daha yaygın olan bir senaryoyu şöyle açıklıyor: "Diyelim ki biri yanlışlıkla bir ajan kodlayıcıyı yanlış yöne yönlendiriyor ve bu da kodlayıcının sürekli çalışan, durmadan yüksek ücret oluşturan bir döngü yaratmasına neden oluyor. Siz daha ne olduğunu anlamadan, aslında 5.000 $ olması gereken bir proje, mekanizmanın arka planında neler olup bittiğini bilmedikleri ve ajan kodlayıcının bunu fark edeceğini varsaydıkları için 50.000 $'a mal oluyor."
Teknik olmayan geliştiricilerin genel olarak belirteç kullanımını optimize etme olasılığı da daha düşüktür; bu da maliyetlerin sessizce ve hızla birikmesine neden olur. Araçlarının üzerinde çalıştığı altyapıyı göremeyen ekip üyeleriniz, fatura gelene kadar bir sorun olduğunu fark etmeyebilir.
API Anahtarları ve Bilgi Güvenliği
Fisher'ın güvenlik ekiplerini geceleri uyanık tutan konulara girdiği yer burasıdır. Anlattığı senaryo, birinin tehlikeli olabilecek kadar bilgi sahibi olduğunda nelerin ters gidebileceğine dair ders kitabı niteliğinde bir örnektir: "Yaygın hatalardan biri, birinin bir şeyin gerçekleşmesi için API anahtarına ihtiyaç duyduğunu bilecek ve ifade edebilecek kadar bilgi sahibi olmasıdır. Anahtarı bir istem içinde verir ve anahtar gizli bir konumda saklanmaz – yalnızca bir dosyaya dökülür veya doğrudan komut dosyasına yazılır. Ardından biri kodu GitHub'da paylaşır, belki de kodu gizli yapmayı unutur ve artık bu API anahtarı, 100.000 $ tutarında bir belirteç faturası oluşturmak gibi kötü niyetli bir şey yapmaya istekli herkes tarafından kötüye kullanılabilir.”
Bu senaryoyu okumak ve bunun uzun bir hata zinciri gerektirdiğini düşünmek kolaydır. Fisher bu içgüdüye karşı çıkıyor: "Gerçekleşmesi pek olası olmayan şeylerden oluşan uzun bir zincir varmış gibi görünüyor, ancak bu hiç de olasılık dışı değil. Aslında özellikle teknik olmayan kişiler arasında son derece yaygın."
Fisher'ın gündeme getirdiği belki de en endişe verici risk, deneyimli geliştiricilerin bile düştüğü bir hatadır. "Deneyimli geliştiricilerin bir işletmenin tüm kod tabanını bir ajan kodlayıcıya aktarıp bir şeyleri değiştirdiğini ve ardından tüm kod tabanının tamamen yasal sınırlar içinde başka bir şirkete ifşa edildiğini anlatan korkunç hikâyeler duydum." Deneyimli geliştiriciler bile bu hatayı yapabiliyorsa, hızlı ve denetim olmadan geliştirme yapan teknik olmayan bir çalışanın risk profili çok daha yüksektir.
More Articles
- Sezgisel Kodlamanın Yükselişi: Proje Yöneticileri İçin Yararlı Olabilir mi?
- Baş Mühendislik Müdürü, teslimat liderlerinin gerçek zamanlı, sinyal öncelikli sistemleri benimsemesi gerektiğini söylüyor
- Google’da teslimat lideri, ajan tabanlı iş akışlarının ürün yöneticiliği modellerini nasıl değiştirdiğini anlatıyor
- Bu Eski Google Ürün Yöneticisi, Yapay Zekâ Aracıyla Proje Ekiplerinin Çalışma Biçimini Değiştiriyor
- Deneyimli Bir Proje Yöneticisi Teslimatı Yapay Zekâyla Nasıl Güçlendiriyor?
Ölçeklenebilirlik Sorunu — Gerçekten İşe Yaradığında Ne Olur?
Yöneticiler için daha zor konuşmalardan biri, bir vibe kodlama aracı gerçekten bir sorunu çözdüğünde ve insanlar ona güvenmeye başladığında ne yapılacağıdır. Başarı durumu sessizce bir yükümlülüğe dönüşebilir. Fisher yapısal sorun konusunda açık: "Genel olarak konuşursak, tüm vibe kodlama projeleri ölçeklenebilir değildir; bunun temel nedeni ajandan ölçeklendirmeyi göz önünde bulundurmasını istememenizdir. Geliştirici olmayan kişiler muhtemelen hata yönetimi gibi şeyleri bile talep etmez. Hataların nerelerde ortaya çıktığını anlamıyorsanız, ajanın bu hataları yakalayıp uygun şekilde ele aldığından emin olmak için yeterli bilgiye sahip değilsiniz."
Genel olarak, vibe kodlamayla oluşturulan tüm projeler ölçeklenebilir değildir; bunun temel nedeni, ajandan ölçeklendirmeyi göz önünde bulundurmasını istememenizdir.
Hesap verebilirlik açığı, baskı altında en görünür hâle gelir. "Genellikle şöyle bir şey oluyor: Birisi bir şeyi vibe kodlamayla oluşturuyor ve sonra çalışıyor; ancak bu kişi bu ürünün 7/24 teknik desteğini sağlayacak mı?" Teslimat ve operasyon liderleri için iyi niyetle oluşturulmuş bir iç aracın kurumsal bir riske dönüştüğü an budur — çünkü ekipler ona ne kadar çok güvenirse bozulma veya sürekli teknik desteğe ihtiyaç duyma olasılığı da o kadar artar.
Fisher'ın ilgi gören araçlar için önerisi, sorunsuz bir devir teslimi yapılmasıdır: "İnsanların güvendiği bir şey oluşturursanız, bunun yalnızca vibe kodlamayla oluşturulmuş bir projeden daha fazlası hâline gelmesi gerekir; profesyonel olarak bu işi yapan ve sizin sormayı aklınıza bile getirmeyeceğiniz şeyleri bilen kişiler tarafından devralınması gerekir."
Liderler Ne Yapabilir — Pratik Koruyucu Sınırlar
Bunların hiçbiri, çözümün genel bir yasaklama olduğu anlamına gelmez. Fisher bu noktada tutarlıdır — teknik olmayan kişiler için vibe kodlama araçlarının değeri gerçektir, ancak belirli bir alanda kullanılır. "Kod yazmayan kişiler için bu araçların değeri, bir fikir etrafında mutabakat sağlamak gibi şeyleri kısa yoldan geçebilmek ve 'bu işe yarayacak mı?' aşamasını geride bırakabilmektir," diyor. Prototip aşaması, iletişim aşaması, "bunu oluşturmak gerçekten değer mi?" aşaması — vibe kodlamanın öne çıktığı ve riskin hâlâ yönetilebilir olduğu yer burasıdır.
Liderler için pratik yol haritası kabaca şöyle görünür: vibe kodlamayı prototip oluşturma ve iletişim aracı olarak teşvik edin ve bir aracın daha geniş kullanıma sunulmadan önce teknik uzmanlığa sahip biri tarafından incelenmesi gereken net bir eşik belirleyin. Ekibinizle bu konuşmaları yapmak — böylece riskleri anlamalarını ve seçeneklerini bilmelerini sağlamak — akıllı yapay zekâ keşfi kültürünü yalnızca hızla ilerleyip en iyisini uman bir kültürden ayıran şeydir.
Amaç, hayır diyen lider olmak değil. Amaç, ekibin neye giriştiğini bildiğinden emin olan lider olmaktır — böylece biri gerçekten harika bir şey oluşturduğunda, bu şey gerçekten ilerleyebilir.
Bunun gibi daha fazla içgörü mü istiyorsunuz? Bu uzmanlar gibi daha fazla uzmandan bilgi almak için ücretsiz bir DPM hesabı oluşturun.
