AI’nin geliştiriciler tarafından yapılan hangi işleri alabileceğine, hangi işlerde onları hızlandırdığına ve hangi sorumlulukların gerçek ekiplerde hâlâ insan liderliğinde kalacağına dair pratik bir özet.
“AI geliştiricilere ne yapacak” konusundaki konuşmalar hızla kafa karıştırıcı olabilir çünkü sık sık araçları ve sorumlulukları karıştırırız. Bir araç kod üretebilir, bir ticket’ı özetleyebilir veya testler önerebilir. Bir sorumluluk ise öneri yanlış olduğunda ekipten kimin hesap vereceğidir.
Bu makale, gerçek ekiplerdeki —son teslim tarihleri, legacy kod, üretim olayları ve güvenilir sonuç bekleyen paydaşları olan— günlük işleri tanımlamak için replace, augment, untouched adlı basit bir çerçeve kullanır.
Replace demek, AI'nın görevi uçtan uca çoğu zaman net koruyucularla tamamlayabilmesi ve insan rolünün denetim ve spot-check'lere kayması demektir.
Örnekler genelde sınırlı işlerle ilgilidir: boilerplate üretmek, diller arasında kod çevirmek, tekrarlayan test vakalarını hazırlamak veya ilk taslak dokümantasyon üretmek.
Replace, insan sorumluluğunun olmadığı anlamına gelmez. Çıktı üretimde bozulma, veri sızıntısı veya standart ihlali yaparsa sorumluluk hâlâ ekipte olur.
Augment demek, AI geliştiriciyi daha hızlı veya daha titiz yapar, ama insan yargısı olmadan işi güvenilir şekilde bitiremez.
Bu, profesyonel mühendislikte yaygın durumdur: faydalı taslaklar, alternatif yaklaşımlar, hızlı açıklamalar veya muhtemel hataların kısa listelerini alırsınız—ancak neyin doğru, güvenli ve ürün için uygun olduğuna geliştirici yine karar verir.
Untouched demek, çekirdek sorumluluğun insan liderliğinde kalmasıdır; çünkü bağlam, ödünleşimler ve hesap verebilirlik promptlara sığmaz.
Düşünün: gereksinimleri müzakere etmek, sistem seviyesinde kısıtları seçmek, olayları yönetmek, kalite çıtalarını belirlemek ve tek bir “doğru” cevabın olmadığı durumlarda karar almak.
Araçlar hızlı değişir. Sorumluluklar yavaş değişir.
Bu yüzden “Bu kodu AI yazabilir mi?” demek yerine “Sonucun sahibi kim?” diye sorun. Bu çerçeve beklentileri doğruluk, güvenilirlik ve hesap verebilirlik temelinde dengede tutar—etkileyici demoların ötesinde daha önemli olan şeyler.
İnsanlar AI’nın geliştirmede neyi “değiştirdiğini” sorduğunda genellikle görevleri kastediyorlar: bir fonksiyon yazmak, test üretmek, doküman taslağı hazırlamak. Ancak ekipler görevleri göndermez—sonuçları gönderir. İşte bu yüzden geliştirici sorumlulukları önemlidir.
Bir geliştiricinin işi genellikle sadece kod yazmaktan daha fazlasını kapsar:
Bu sorumluluklar, “ne inşa etmeliyiz?” den “bu güvenli mi?”ye ve “sabah 3’te kırıldığında ne olur?”a kadar tüm yaşam döngüsüne yayılır.
Her sorumluluk aslında birçok küçük karar içerir: hangi kenar durumlar önemli, hangi metrikler sağlığı gösterir, ne zaman kapsamı kısaltmalı, bir düzeltmenin gönderilmesi güvenli mi, bir ödünleşimi paydaşlara nasıl açıklamalı. AI bu işin parçalarını yürütmeye yardım edebilir (kod taslağı, test önerisi, log özeti), ama sorumluluk sonuç üzerinde sahiplenmektir.
Çoğu çökme handoff sınırlarında olur:
Sahiplik belirsiz olduğunda işler boşluğa düşer.
Sorumluluklardan bahsetmenin faydalı bir yolu karar hakları:
AI yürütmeyi hızlandırabilir. Karar hakları—ve sonuçlar için hesap verebilirlik—halen yanında bir insan ismi gerektirir.
AI kod asistanları, işin öngörülebilir, düşük riskli ve doğrulanması kolay olduğu yerlerde gerçekten faydalıdır. Onları hızlı bir genç ekip arkadaşı gibi düşünün: ilk geçişi iyi üretir, ama net talimatlar ve dikkatli bir kontrol gerekir.
Pratikte bazı ekipler bu değiştirilebilir parçaları hızlandırmak için “vibe-coding” platformlarını (ör. Koder.ai) kullanıyor: scaffold üretimi, CRUD akışlarının kurulması ve sohbetten UI ile backend için ilk taslakların çıkarılması. Ana unsur yine aynı: guardrail’ler, inceleme ve net sahiplik.
Geliştiricilerin zamanının büyük kısmı proje iskeleti ve katmanlar arası bağlantı için gider. AI genellikle üretebilir:
Buradaki guardrail tutarlılıktır: mevcut konvansiyonlarınıza uyduğundan ve yeni desenler ya da bağımlılıklar icat etmediğinden emin olun.
Değişiklik büyük ölçüde mekanik ise—kod tabanında sembol yeniden adlandırma, yeniden formatlama veya basit bir API kullanım güncellemesi—AI yoğun işi hızlandırabilir.
Yine de bunu bir toplu düzenleme gibi ele alın: tüm test süitini çalıştırın, farkları inceleyip istenmeyen davranış değişikliklerine bakın ve AI’nın istenenden fazlasını “iyileştirmesine” izin vermeyin.
AI READMElar, inline comment’ler ve commit notlarından changelog girdileri taslağı oluşturabilir. Bu açıklığı hızlandırır, ama aynı zamanda kendinden emin görünen yanlışlıklar da üretebilir.
En iyi uygulama: AI’yı yapı ve ifade için kullanın, sonra her iddiayı doğrulayın—özellikle kurulum adımları, konfigürasyon varsayılanları ve kenar durumlarda.
İyi tanımlanmış, saf fonksiyonlar için AI tarafından üretilen birim testleri başlangıç kapsaması sağlayabilir ve kenar durumları hatırlatabilir. Guardrail sahiplenmedir: hangi sonuçların önemli olduğunu siz seçersiniz, gerçek gereksinimleri yansıtan assertion’lar eklersiniz ve testlerin doğru sebeplerle başarısız olduğundan emin olursunuz.
Uzun Slack konuşmaları, ticket’lar veya olay logları olduğunda AI bunları kısa notlara ve aksiyon maddelerine dönüştürebilir. Tam bağlamı vererek sonuçları somutlaştırın ve önemli tarihleri, kararları ve gerçekleri paylaşmadan önce doğrulayın.
AI kod asistanları, ne istediğinizi zaten bildiğinizde en iyi performansı gösterir; “yazma işi”ni azaltır ve faydalı bağlamları ortaya çıkarır, fakat sahiplenme, doğrulama ve yargı ihtiyacını ortadan kaldırmaz.
Açık bir spes verildiğinde—girdiler, çıktılar, kenar durumlar ve kısıtlar—AI makul bir başlangıç uygulaması taslağı çıkarabilir: boilerplate, veri eşlemesi, API handler’ları, migration’lar veya basit bir refaktör. Kazanç ivme kazanmaktır: çabuk çalışır hale gelen bir şey elde edersiniz.
Yakalanması gereken nokta: ilk geçiş genelde ince gereksinimleri kaçırır (hata semantiği, performans kısıtları, geriye uyumluluk). Bunu bir stajyer taslağı gibi ele alın: kullanışlı ama kesin otorite değil.
Kullanım örneğin caching vs batching, optimistic vs pessimistic locking gibi seçenekler arasında karar verirken AI alternatifler ve ödünleşmeleri listeleyebilir. Bu beyin fırtınası için değerlidir, ama ödünleşmelerin ekibin gerçekliğiyle (trafik şekli, veri tutarlılığı, operasyonel kısıtlar, ekip konvansiyonları) kontrol edilmesi gerekir.
AI, alışık olmadığınız kodu açıklamakta, kalıpları işaret etmekte ve “bu ne yapıyor?” sorusunu düz dille anlatmakta güçlüdür. Arama araçlarıyla birleştirildiğinde “X nerede kullanılıyor?” sorusuna yanıt bulmaya ve gözden geçirilmesi gereken çağrı yerleri, konfigürasyonlar ve testlerin kısa listesini üretmeye yardımcı olabilir.
Daha net hata mesajları, küçük örnekler ve hazır yapıştırılabilir snippet’ler gibi pratik kalite-yaşam iyileştirmeleri bekleyin. Bunlar sürtünmeyi azaltır, ama kullanıcıları veya üretim sistemlerini etkileyen değişiklikler için dikkatli incelemeyi, yerel çalıştırmayı ve hedefe yönelik testleri değiştirmez.
AI gereksinimleri yazıp düzeltmenize yardım edebilir ama ne inşa etmeliyiz veya neden önemli sorusuna güvenilir şekilde yanıt veremez. Ürün anlayışı bağlamda köklenir: iş hedefleri, kullanıcı ağrıları, organizasyonel kısıtlar, kenar durumlar ve yanlış yapmanın maliyeti. Bu girdiler konuşmalarda, geçmişte ve hesap verebilirlikte yaşar—model özetleyebilir ama gerçekten sahiplenemez.
Erken istekler genelde “Onboarding’i daha kolay yap” veya “Destek biletlerini azalt” gibi genel ifadeler taşır. Geliştiricinin işi bunu net gereksinimlere ve kabul kriterlerine çevirmektir.
Bu çeviri çoğunlukla insan işi çünkü sorgulayıcı sorular ve yargı gerekir:
AI olası metrikler veya kabul kriterleri önerebilir, ama hangi kısıtların gerçek olduğunu bilmez—ve çelişkili bir isteğe geri itme yapmaz.
Gereksinimler işi rahatsız edici ödünleşmelerin su yüzüne çıktığı yerdir: zaman vs kalite, hız vs sürdürülebilirlik, yeni özellik vs stabilite. Ekiplerin riskleri açıkça ifade edecek, seçenekler önerecek ve paydaşları sonuçlar konusunda hizalayacak bir kişiye ihtiyacı vardır.
İyi bir spes sadece metin değil; bir karar kaydıdır. Test edilebilir ve uygulanabilir olmalı, net tanımlarla (girdiler, çıktılar, kenar durumlar ve hata modları). AI belgeyi yapılandırmaya yardım edebilir, ama doğruluk ve “bu belirsiz, karar gerek” demek insanlarda kalır.
Sistem tasarımı “ne inşa etmeliyiz?” sorusunu “ne üzerine inşa etmeli ve işler bozulduğunda nasıl davranmalı?” sorusuna çevirir. AI size seçenekleri keşfetmede yardımcı olabilir, ama sonuçları sahiplenemez.
Monolith, modular monolith, microservices, serverless veya yönetilen platformlar arasında seçim tek doğru cevabı olan bir sınav değildir. Uygunluk problemi: beklenen ölçek, bütçe, pazara çıkış süresi ve ekibin becerileri.
Bir asistan kalıpları özetleyebilir ve referans mimariler önerebilir, ama ekibinizin haftalık on-call döngüsüne, işe alım sürecinin yavaşlığına veya veri tabanı sağlayıcınızın sözleşme yenilemesine dair bilgiyi bilmez. Bu ayrıntılar genelde bir mimarinin başarılı olup olmayacağını belirler.
İyi mimari çoğunlukla ödünleşmelerdir: basitlik vs esneklik, performans vs maliyet, bugünkü hız vs ileride sürdürülebilirlik. AI hızlıca artı/eksi listeleri üretebilir; bu faydalıdır—özellikle kararları belgelemek için.
Yapamayacağı şeyse, ödünleşmeler acı verdiğinde öncelikleri belirlemektir. Örneğin “Sistemi daha basit ve işletmesi kolay tutmak için cevap süresinde biraz yavaşlamayı kabul ediyoruz” iş kararıdır, saf teknik bir karar değildir.
Servis sınırlarını tanımlamak, hangi verinin kime ait olduğunu belirlemek ve kısmi kesintilerde ne olacağını kararlaştırmak derin ürün ve operasyonel bağlam ister. AI hata modlarını beyin fırtınası için önerebilir (“ödeme sağlayıcısı kapandığında ne olur?”), ama beklenen davranışı, müşteri iletişimini ve geri alma planını insanların kararlaştırması gerekir.
API tasarlamak bir sözleşme tasarlamaktır. AI örnekler üretebilir ve tutarsızlıkları bulabilir, ama versiyonlama, geriye uyumluluk ve uzun vadede neyi destekleyeceğinize karar vermeniz gerekir.
Belki en mimari karar “hayır” demek veya bir özelliği silmektir. AI fırsat maliyetini veya politik riski ölçemez. Ekipler bunu yapmalı ve yapmalıdır.
Hata ayıklama AI’nın etkileyici göründüğü yerlerden biridir—ve aynı zamanda en çok zaman kaybettirebileceği yer. Asistan logları tarayabilir, şüpheli kod yollarını işaret edebilir veya “doğru gibi görünen” bir düzeltme önerebilir. Ancak kök neden analizi sadece açıklamalar üretmek değildir; birini kanıtlamaktır.
AI çıktısını sonuç değil, hipotez olarak değerlendirin. Birçok hata birden fazla makul nedene sahiptir ve AI genelde yapıştırdığınız kod snippet’ine uyan düzenli bir hikâyeyi seçme eğilimindedir, çalışır sistemin gerçeğini değil.
Pratik iş akışı:
Güvenilir bir yeniden üretme yeteneği bir gizemi teste dönüştürdüğü için hata ayıklamada üstündür. AI minimal bir repro yazmanıza, bir diagnostic script taslağı hazırlamanıza veya ek log önermeye yardımcı olabilir, ama hangi sinyallerin önemli olduğunu siz belirlersiniz: request ID’leri, zamanlama, ortam farkları, feature flagler, veri şekli veya eşzamanlılık.
Kullanıcılar belirtiler rapor ettiğinde (“uygulama takıldı”), bunu hangi endpoint’in durduğuna, hangi timeout’ların tetiklendiğine, hangi hata bütçesi sinyallerinin değiştiğine çevirmek gerekir. Bu, ürünün nasıl kullanıldığı ve “normal”in ne olduğuna dair bağlam ister.
Bir öneri doğrulanamıyorsa, yanlış olduğunu varsayın. Test edilebilir tahminler yapan açıklamaları tercih edin (ör. “bu sadece büyük payload’larda olur” veya “sadece cache ısındıktan sonra olur”).
Kök nedeni bulduktan sonra bile zor karar kalır. AI seçenekleri özetleyebilir, ama insanlar şu yanıtı seçer:
Kök neden analizi nihayetinde hesap verebilirliktir: açıklamayı, düzeltmeyi ve tekrar etmeyeceğine dair güveni sahiplenmek.
Kod inceleme sadece stil kontrolü değildir. Bir ekip neyi sürdüreceğine, hangi kod için hesap vereceğine ve neyi destekleyeceğine o anda karar verir. AI size daha fazlasını görmede yardımcı olabilir, ama neyin önemli olduğuna, ürün niyetine veya ekibin kabul ettiği ödünleşmelere karar veremez.
AI kod asistanları yorulmaz ikinci göz gibi davranabilir. Hızla şunları yapabilir:
Bu şekilde kullanıldığında AI PR açıldıktan kapatılana kadar olan süreyi kısaltır—riskin fark edilmesini hızlandırır.
Doğruluk kontrolü sadece kodun derlenip derlenmediğiyle ilgili değildir. İnsanlar değişiklikleri gerçek kullanıcı davranışı, üretim kısıtları ve uzun vadeli bakım ile ilişkilendirir.
Bir inceleyicinin hâlâ karar vermesi gerekir:
AI’yı nihai onaylayıcı değil, ikinci bir inceleyici olarak değerlendirin. Belirli bir geçiş isteyin (güvenlik kontrolleri, kenar durumlar, geriye uyumluluk), sonra kapsam, öncelik ve değişikliğin ekip standartları ve ürün niyetiyle uyumu hakkında insan kararı verin.
AI kod asistanları testleri hızlı oluşturabilir, ama kaliteye sahip çıkmazlar. Bir test süiti neyin kırılabileceğine, neyin asla bozulmaması gerektiğine ve hangi kenar durumların kanıtlanmasının gerekli olmadığına dair bahislerin toplamıdır. Bu bahisler ürün ve mühendislik kararlarıdır—halen insanlar tarafından verilir.
Asistanlar birim test iskeleti, bağımlılıkları mock etme ve implementasyondan “mutlu yol” örneklerini üretmede iyidir. Güvenli olmadıkları şeyse hangi kapsamanın önemli olduğu kararını vermektir.
İnsanların tanımlaması gerekenler:
Çoğu ekip “daha fazla test” yerine katmanlı bir stratejiye ihtiyaç duyar. AI bunların birçoğunu yazabilir, ama seçim ve sınırlar insan odaklıdır:
AI tarafından üretilen testler genellikle koda çok benzer; kırılgan assertion’lar veya aşırı mocklanmış kurulumlar üretebilir ve gerçek davranış başarısızken bile geçebilir. Geliştiriciler bunu önlemek için:
İyi bir strateji nasıl yayınladığınızla eşleşir. Daha hızlı sürümler daha güçlü otomatik kontroller ve net rollback yolları gerektirir; daha yavaş sürümler daha ağır ön-merge doğrulaması kaldırabilir. Kalite sahibi alet değil, ekip olmalıdır.
Kalite bir kapsama yüzdesi değildir. Testlemenin sonuçları iyileştirip iyileştirmediğini izleyin: daha az üretim olayı, daha hızlı kurtarma, daha güvenli değişiklikler (daha az revert, daha hızlı güvenli dağıtım). AI işi hızlandırır; hesap verebilirlik geliştiricilerde kalır.
Güvenlik işi kod üretmekten çok gerçek kısıtlar altında ödünleşmeler yapmaktır. AI kontrol listeleri ve yaygın hataları ortaya çıkarma konusunda yardımcı olabilir, ama risk kararlarının sorumluluğu ekipte kalır.
Tehdit modelleme genel bir egzersiz değildir—neyin önemi olduğu işin önceliklerine, kullanıcılara ve hata modlarına bağlıdır. Bir asistan tipik tehditleri (injection, kırık auth, güvensiz varsayılanlar) önerebilir, ama hangi varlığın gerçekten maliyetli olduğunu bilemez: hesap ele geçirilmesi mi, veri sızıntısı mı, servis kesintisi mi veya hangi varlıklar yasal olarak hassas?
AI bilinen anti-patternleri tanımakta iyi, ama birçok olay uygulamaya özgü detaylardan gelir: izinler kenar durumu, “geçici” bir admin endpoint, veya onayları atlayan bir iş akışı. Bu riskler sistemin niyetini okumayı gerektirir, sadece kodu değil.
Araçlar anahtarları hardcode etmemenizi hatırlatabilir, ama tam politika sahipliği insanlarda kalmalıdır:
AI eski kütüphaneleri işaretleyebilir, ama ekipler hâlâ şu uygulamaları yapmalıdır: versiyonları pinlemek, kaynağı doğrulamak, transitif bağımlılıkları incelemek ve riski kabul etme mı yoksa düzeltmeye yatırım mı yapma kararını vermek.
Uyumluluk “şifreleme eklemek”ten ibaret değildir. Kontroller, dokümantasyon ve hesap verebilirlik gerekir: erişim logları, onay izleri, olay prosedürleri ve bunların izlendiğine dair kanıt. AI şablonlar taslaklayabilir, ama insan doğrulaması ve imza gerekir—çünkü denetçiler (ve müşteriler) nihayetinde buna dayanır.
AI operasyon işini hızlandırabilir, ama sahiplenmeyi almaz. Güvenilirlik belirsizlik altında verilen kararların zinciridir ve yanlış bir kararın maliyeti genelde yavaş olmanın maliyetinden yüksektir.
AI operasyon belgeleri—runbook’lar, kontrol listeleri ve “eğer X olursa Y deneyin” oyun kitaplarını taslaklamakta ve sürdürmekte işe yarar. Ayrıca logları özetleyebilir, benzer alarmları kümeleyebilir ve ilk hipotezleri önerebilir.
Güvenilirlik işinde bu şu şekilde daha hızlı yinelemeye dönüşür:
Bunlar hızlandırıcıdır; ama işin kendisi değildir.
Olaylar nadiren planlandığı gibi gider. On-call mühendisleri belirsiz sinyaller, kısmi hatalar ve saat işleyen baskı altında ödünleşmelerle uğraşır. AI muhtemel nedenleri öne sürebilir ama başka bir ekibi çağırmak mı, bir özelliği devre dışı bırakmak mı yoksa kısa vadeli müşteri etkisini kabul edip veri bütünlüğünü korumak mı gerektiğine güvenilir şekilde karar veremez.
Dağıtım güvenliği başka bir insan sorumluluğudur. Araçlar rollback, feature flag veya kademeli dağıtım önerebilir ama ekipler iş bağlamını ve blast radius’u düşünerek en güvenli yolu seçmelidir.
AI zaman çizelgeleri taslağı oluşturabilir ve chat, ticket ve monitoring verilerinden ana olayları çekebilir. İnsanlar hâlâ kritik kısımları yapar: “iyi”nin ne olduğunu tanımlamak, düzeltmeleri önceliklendirmek ve tekrarları önleyen değişiklikleri yapmak (sadece aynı semptomu düzeltmek değil).
AI’yı ops dokümantasyonu ve örüntü bulmada yardımcı pilot olarak kullanırsanız—olay komutanı olarak değil—hız kazanırsınız ama hesap verebilirliği teslim etmezsiniz.
AI istenildiğinde kavramları açık ve anlaşılır şekilde açıklayabilir: “CQRS nedir?”, “Bu deadlock neden oluyor?”, “Bu PR’ı özetle.” Bu ekiplerin daha hızlı ilerlemesine yardımcı olur. Ancak iş yerindeki iletişim sadece bilgi aktarımı değil—güven inşa etmek, ortak alışkanlıklar oluşturmak ve insanların güvenebileceği taahhütler vermektir.
Yeni geliştiriciler sadece cevaplara değil; bağlam ve ilişkilere ihtiyaç duyar. AI modülleri özetleyerek, okuma yolları önererek ve jargonları çevirebilir. İnsanlar hâlâ öğretmelidir: “burada ne önemlidir”, ekip hangi ödünleşmeleri tercih eder, kod tabanında iyi olan nedir ve bir şey yanlış hissettirdiğinde kimi aramalısın.
Proje sürtüşmesi genelde roller arası ortaya çıkar: ürün, tasarım, QA, güvenlik, destek. AI toplantı notları taslaklayabilir, kabul kriterleri önerebilir veya geri bildirimi daha nötr bir dille yeniden ifade edebilir. İnsanlar hâlâ öncelikleri müzakere etmeli, belirsizliği çözmeli ve bir paydaşın “kabul ettiğini” ama aslında kabul etmediğini fark etmelidir.
Ekipler sorumluluk belirsiz olduğunda başarısız olur. AI kontrol listeleri oluşturabilir ama hesap verebilirliği uygulayamaz. İnsanlar “tamam”ın ne anlama geldiğini (testler? dokümantasyon? rollout planı? izleme?), merge sonrası kimin neyi sahiplenmesi gerektiğini tanımlamalıdır—özellikle AI üretilen kod karmaşıklık gizlediğinde.
Araçların yürütebildiği işleri (task) ekiplerin hesap vermesi gereken sorumluluklardan ayırır.
Çünkü ekipler “görevler” değil, sonuçlar gönderir.
Bir asistan kodu ya da testleri taslak olarak hazırlasa bile, ekibiniz yine de şunlardan sorumludur:
“Replace” sınırlı, doğrulanabilir, düşük riskli işler içindir; hataların kolayca yakalanabildiği yerlerde güvenlidir.
İyi adaylar:
Hataları belirgin ve ucuz kılan guardrail’ler kullanın:
Çünkü profesyonel mühendislikte çoğu iş gizli kısıtlar içerir ve model bunları güvenilir şekilde çıkaramaz:
AI çıktısını bir taslak olarak ele alın; sisteminize uyarlamak sizsiniz, otorite AI değil.
AI’yi sonuca varmak için değil, hipotezler ve kanıt planı üretmek için kullanın.
Pratik döngü:
Bir öneriyi doğrulayamazsanız, yanlış olduğunu varsayın ta ki kanıt gelene dek.
AI, sorunları daha çabuk fark etmenize yardımcı olabilir; ancak hangi değişikliklerin gönderileceğine insan karar verir.
Yararlı AI inceleme istemleri:
Sonra insan eliyle niyet, sürdürülebilirlik ve sürüm riski açısından (hangi sorunlar release-blocker) karar verin.
AI birçok testi taslak hâlde üretebilir, ama hangi kapsamanın önemli olduğunu seçemez.
İnsanların sorumluluğunda kalmalı:
AI’yı iskelet ve kenar-durum beyin fırtınası için kullanın; kalite sahibi insanlardır.
Çünkü bu kararlar iş bağlamına ve uzun vadeli hesap verebilirliğe dayanır.
AI yapabilir:
İnsanlar yine de karar vermeli:
İçerik olarak gizli bilgileri veya müşteri verilerini promptlara yapıştırmayın.
Pratik kurallar:
