Yapay Zeka ile Yapılan Eklentilere Ne Kadar Güvenebiliriz?

Merhabalar MC-TR Halkı!

Yapay Zeka ile Yapılan Minecraft Eklentilerine Gerçekten Güvenebilir miyiz?​

Öncelikle "çalışıyor" ile "güvenilir" arasındaki farkı konuşmak gerekiyor​

Bence Minecraft topluluğunda en sık yapılan hatalardan birisi bir eklentinin düzgün çalışmasını doğrudan kaliteli ve güvenilir olduğu şeklinde yorumlamak. Örneğin yapay zekâya bir ekonomi eklentisi yaptırdığınızı düşünelim. Oyuncular para kazanabiliyor, para harcayabiliyor, /balance komutu çalışıyor, GUI açılıyor, veriler kaydediliyor ve herhangi bir hata mesajı görünmüyor. Sunucu sahibi eklentiyi kurduğunda her şey mükemmel çalışıyor gibi görünebilir. Fakat kodun içerisinde gereksiz SQL sorguları olabilir, her işlemde veritabanına tekrar tekrar bağlantı kuruluyor olabilir, ana thread üzerinde ağır işlemler yapılıyor olabilir, oyuncu verileri düzgün şekilde cache'lenmiyor olabilir veya oyuncunun sunucudan çıkması gibi durumlar doğru şekilde ele alınmıyor olabilir. Bunların hiçbiri eklentinin ilk bakışta çalışmasını engellemez. Hatta düşük oyuncu sayısına sahip bir sunucuda günlerce hiçbir problem ortaya çıkmayabilir. Ancak sunucu 20 oyuncudan 200 oyuncuya, 200 oyuncudan 1000 oyuncuya çıktığında daha önce fark edilmeyen problemler ciddi performans sorunlarına dönüşebilir. Dolayısıyla bir eklentinin "çalışıyor olması" ile "iyi tasarlanmış olması" arasında ciddi bir fark var. Bu durum yalnızca yapay zekâ tarafından yazılmış eklentiler için de geçerli değil; insan tarafından tamamen sıfırdan yazılmış bir eklenti de aynı sorunlara sahip olabilir. Fakat yapay zekânın kod üretimini çok kolaylaştırması nedeniyle bu konu özellikle son dönemde daha önemli hale geliyor.

​

Yapay zekânın ürettiği kodu gerçekten anlayan kaç kişi var?​

"AI ile yazıldı" demek eklentiyi kötü yapar mı?​

İnsan tarafından yazılan eklenti gerçekten daha mı güvenli?​

Bu noktada başka bir soru ortaya çıkıyor. Bir eklentinin tamamen insan tarafından yazılmış olması ona otomatik olarak bir güven avantajı sağlıyor mu? Bana göre hayır. Tecrübeli bir geliştirici bile hata yapabilir. Bir SQL sorgusunda problem olabilir, bir event yanlış yerde kullanılabilir, bir listener gereğinden fazla çalışabilir, bir scheduler sürekli olarak gereksiz işlem yapabilir veya oyuncudan alınan bir veri düzgün şekilde doğrulanmayabilir. Hatta yıllardır geliştirme yapan bir kişinin bile ciddi bir bug yapması gayet normal. Yazılım geliştirme zaten hatasız kod yazma işi değil; hataları mümkün olduğunca erken tespit edip düzeltme işi. Bu nedenle bir eklentiyi değerlendirirken sadece geliştiricinin ne kullandığına değil, geliştirme sürecine de bakılması gerektiğini düşünüyorum. Yapay zekâ kullanılmış olabilir ancak kod incelenmiş ve test edilmiş olabilir. İnsan tarafından yazılmış olabilir ancak hiçbir test yapılmamış olabilir. Bu iki durumda hangisinin daha güvenilir olduğunu yalnızca "AI kullandı/kullanmadı" üzerinden belirlemek mümkün değil.

​

Güvenlik açısından en büyük problem ne olabilir?​

İnternete bağlanan her eklenti şüpheli midir?​

Burada da dengeli olmak gerektiğini düşünüyorum. Bir eklentinin internete bağlantı kurması tek başına kötü bir durum değildir. Örneğin bir Discord entegrasyonu kullanıyorsanız Discord API'sine bağlanması gerekir. Bir web paneli ile iletişim kuruyorsa HTTP bağlantısı yapması normaldir. Güncelleme kontrolü yapan bir eklentinin geliştiricinin sunucusuna istek göndermesi de tek başına şüpheli değildir. Problem bunun kullanıcıdan gizlenmesi veya gereksiz olmasıdır. Bir eklenti neden internete bağlandığını açıkça belirtiyorsa, hangi verilerin gönderildiğini söylüyorsa ve bu konuda şeffaf davranıyorsa değerlendirme yapmak daha kolay olur. Ancak yapay zekâ tarafından oluşturulan bir kod içerisinde geliştiricinin bile fark etmediği bir HTTP isteği bulunuyorsa burada daha ciddi bir problem ortaya çıkabilir. Özellikle kodun tamamını okumayan bir geliştirici için bunun fark edilmesi oldukça zor olabilir.

​

Oyuncu verileri konusu da göz ardı edilmemeli​

Performans tarafında yapay zekâ ne kadar başarılı?​

Güvenlik dışında performans konusu da bence çok önemli. Yapay zekâ genellikle kendisine verilen isteğe göre çalışan bir çözüm üretmeye çalışıyor. Ancak bir çözümün çalışması, Minecraft sunucusu için ideal olduğu anlamına gelmiyor. Özellikle Paper veya Spigot gibi platformlarda ana thread üzerinde yapılan işlemlerin ne kadar kritik olduğunu bilen kişiler bunun ne kadar önemli olduğunu bilir. Bir kod parçası 10 oyunculu bir test sunucusunda sorunsuz çalışabilirken 500 oyunculu bir sunucuda ciddi TPS düşüşlerine sebep olabilir. Örneğin oyuncuların tamamını sürekli olarak tarayan bir görev, her oyuncu hareketinde veritabanına sorgu atan bir sistem veya gereksiz yere sürekli yeni task oluşturan bir yapı küçük sunucularda fark edilmeyebilir. Ancak oyuncu sayısı arttığında sistemin maliyeti de artar. Yapay zekâ bazen bu tür durumlar için çalışan bir çözüm sunabilir ama bunun ne kadar verimli olduğunu geliştiricinin değerlendirmesi gerekir. Burada yine geliştiricinin teknik bilgisi devreye giriyor. Yapay zekâ size kod yazabilir fakat o kodun Minecraft sunucunuz üzerindeki gerçek maliyetini anlamak sizin sorumluluğunuzda.

​

"Ama bu eklentiyi binlerce kişi kullanıyor" yeterli bir güven göstergesi mi?​

Kaynak kodunun açık olması yeterli mi?​

Yapay zekâ kullanan geliştiricinin sorumluluğu ne olmalı?​

Bence tartışmanın en önemli noktalarından biri de bu. Bir geliştirici yapay zekâ kullanarak bir eklenti oluşturduysa ve bunu başka insanların kullanımına sunuyorsa "Ben yazmadım, AI yazdı." demesi bana göre bir sorumluluk mekanizması oluşturmuyor. Yapay zekâ kullanılan bir araçtır. Bir geliştirici dışarıdan aldığı bir kütüphanenin yaptığı hatalardan tamamen sorumsuz olmadığı gibi, yapay zekâ tarafından oluşturulan kodu kullanırken de ortaya çıkan üründen sorumlu olmalı. Özellikle eklentiyi ücretli olarak satıyorsa veya binlerce sunucuda kullanılmasını amaçlıyorsa test sürecinin daha ciddi olması gerektiğini düşünüyorum. En azından kodun temel bölümlerinin incelenmesi, güvenlik kontrollerinin yapılması, performans testlerinin gerçekleştirilmesi, hata durumlarının kontrol edilmesi ve kullanılan harici servislerin açıkça belirtilmesi gerektiğini düşünüyorum.

​

Peki yapay zekâ eklenti geliştirmeyi kolaylaştırarak aslında topluluğa fayda mı sağlıyor?​

Bence gelecekte asıl değer kazanacak şey kod yazmak değil, kodu değerlendirebilmek olacak​

Sonuç olarak benim görüşüm​

Ben "Yapay zekâ ile yapılan eklentilere güvenilmez." şeklinde kesin bir yargının yanlış olduğunu düşünüyorum. Aynı şekilde "AI artık her şeyi yapıyor, geliştiriciye gerek yok." düşüncesinin de oldukça tehlikeli olduğunu düşünüyorum. Yapay zekâ çok güçlü bir araç olabilir ancak araç ile ortaya çıkan ürün aynı şey değildir. Bir eklentinin güvenilirliğini belirleyen temel faktörün kodun hangi araçla yazıldığı değil, kodun nasıl kontrol edildiği, nasıl test edildiği, hangi yetkilere sahip olduğu, hangi verileri işlediği, internete hangi bağlantıları yaptığı, performansının nasıl olduğu ve geliştiricisinin ortaya çıkan yazılımı ne kadar iyi tanıdığı olduğunu düşünüyorum. Eğer geliştirici yapay zekâdan yardım alıyor, fakat yazdığı kodu okuyabiliyor, anlayabiliyor, değiştirebiliyor, test edebiliyor ve gerektiğinde neden belirli bir çözümün yanlış olduğunu açıklayabiliyorsa burada yapay zekâ kullanılması bana göre ciddi bir problem değil. Ancak kişi Java bilmiyor, Paper API bilmiyor, kodu okumuyor, yapay zekânın verdiği her şeyi doğru kabul ediyor ve ortaya çıkan eklentiyi doğrudan yüzlerce oyuncunun bulunduğu production sunucusuna yüklüyorsa burada ciddi bir risk olduğunu düşünüyorum.

Bence bundan birkaç yıl sonra "Bu eklenti AI ile mi yapıldı?" sorusundan çok daha önemli sorular soracağız. Kaynak kodu incelendi mi? Test edildi mi? Hangi izinlere sahip? Hangi verileri topluyor? Hangi dış servislere bağlanıyor? Performans testleri yapıldı mı? Geliştiricisi sorun çıktığında destek veriyor mu? Proje ne kadar süredir aktif? Güvenlik açıkları nasıl ele alınıyor? Bunların tamamı eklentinin güvenilirliği konusunda çok daha anlamlı bilgiler verecektir.

Bu yüzden benim açımdan konu aslında "Yapay zekâ iyi mi kötü mü?" tartışması değil. Daha çok "Yapay zekânın yazılım geliştirmeyi bu kadar kolaylaştırdığı bir dönemde, geliştiricinin sorumluluğu nerede başlıyor ve nerede bitiyor?" tartışması. Çünkü bugün yapay zekâ birkaç dakika içerisinde çalışan bir Minecraft eklentisi oluşturabiliyor olabilir. Ancak o eklentinin gerçekten kaliteli, güvenli, performanslı ve sürdürülebilir olup olmadığını anlamak hâlâ insanın sorumluluğunda.

​

Yazar Notu​

Ersoy' Alıntı:

​

Ekli dosyayı görüntüle 296931​

​

Merhabalar MC-TR Halkı!​

​

Yapay Zeka ile Yapılan Minecraft Eklentilerine Gerçekten Güvenebilir miyiz?​

Son yıllarda yapay zekânın yazılım geliştirme alanında inanılmaz bir hızla yaygınlaşmasıyla birlikte Minecraft sunucularında kullanılan eklentilerin geliştirilme şekli de ciddi şekilde değişmeye başladı. Eskiden bir Minecraft eklentisi geliştirmek isteyen kişinin Java, Bukkit API, Spigot/Paper API, veritabanı sistemleri, event yapısı, thread mantığı ve en azından temel yazılım mimarisi hakkında belirli bir bilgiye sahip olması gerekirken, günümüzde yapay zekâ araçları sayesinde kodlama konusunda çok fazla deneyimi olmayan kişiler bile birkaç komut yazarak çalışan eklentiler oluşturabiliyor. Birkaç yıl önce saatlerce araştırılması, dokümantasyon okunması ve elle kodlanması gereken sistemler artık yapay zekâya anlatılarak dakikalar içerisinde ortaya çıkarılabiliyor. Komut sistemleri, GUI'ler, ekonomi sistemleri, oyuncu istatistikleri, kit sistemleri, warp sistemleri, moderasyon araçları, özel itemler, görev sistemleri, veritabanı bağlantıları, API entegrasyonları ve hatta oldukça kapsamlı oyun mekanikleri bile yapay zekâ yardımıyla geliştirilebiliyor. Bunun geliştiriciler açısından çok büyük bir avantaj olduğu açık. Ancak tam olarak burada benim kafama takılan bir soru var: Yapay zekâ tarafından yazılmış veya büyük ölçüde yapay zekâ yardımıyla geliştirilmiş bir Minecraft eklentisine gerçekten güvenebilir miyiz? Buradaki "güven" kelimesini yalnızca eklentinin virüs içerip içermemesi anlamında kullanmıyorum. Güvenlik, performans, veri gizliliği, kod kalitesi, kaynak tüketimi, izinler, dış bağlantılar, bakım kolaylığı, güncellenebilirlik, hata yönetimi ve geliştiricinin eklentinin ne yaptığını gerçekten bilip bilmediği gibi birçok farklı konu bu tartışmanın içerisine giriyor.
​

Öncelikle "çalışıyor" ile "güvenilir" arasındaki farkı konuşmak gerekiyor​

Bence Minecraft topluluğunda en sık yapılan hatalardan birisi bir eklentinin düzgün çalışmasını doğrudan kaliteli ve güvenilir olduğu şeklinde yorumlamak. Örneğin yapay zekâya bir ekonomi eklentisi yaptırdığınızı düşünelim. Oyuncular para kazanabiliyor, para harcayabiliyor, /balance komutu çalışıyor, GUI açılıyor, veriler kaydediliyor ve herhangi bir hata mesajı görünmüyor. Sunucu sahibi eklentiyi kurduğunda her şey mükemmel çalışıyor gibi görünebilir. Fakat kodun içerisinde gereksiz SQL sorguları olabilir, her işlemde veritabanına tekrar tekrar bağlantı kuruluyor olabilir, ana thread üzerinde ağır işlemler yapılıyor olabilir, oyuncu verileri düzgün şekilde cache'lenmiyor olabilir veya oyuncunun sunucudan çıkması gibi durumlar doğru şekilde ele alınmıyor olabilir. Bunların hiçbiri eklentinin ilk bakışta çalışmasını engellemez. Hatta düşük oyuncu sayısına sahip bir sunucuda günlerce hiçbir problem ortaya çıkmayabilir. Ancak sunucu 20 oyuncudan 200 oyuncuya, 200 oyuncudan 1000 oyuncuya çıktığında daha önce fark edilmeyen problemler ciddi performans sorunlarına dönüşebilir. Dolayısıyla bir eklentinin "çalışıyor olması" ile "iyi tasarlanmış olması" arasında ciddi bir fark var. Bu durum yalnızca yapay zekâ tarafından yazılmış eklentiler için de geçerli değil; insan tarafından tamamen sıfırdan yazılmış bir eklenti de aynı sorunlara sahip olabilir. Fakat yapay zekânın kod üretimini çok kolaylaştırması nedeniyle bu konu özellikle son dönemde daha önemli hale geliyor.
Ekli dosyayı görüntüle 296932​

Yapay zekânın ürettiği kodu gerçekten anlayan kaç kişi var?​

Bence tartışmanın en önemli noktalarından biri bu. Yapay zekâdan bir eklenti istediğimiz zaman bize yüzlerce, hatta binlerce satırlık kod verebiliyor. Kodun içerisinde onlarca sınıf, manager, listener, utility ve farklı sistemler bulunabiliyor. Kodun dışarıdan bakıldığında profesyonel görünmesi de mümkün. Değişken isimleri düzgün olabilir, sınıfların isimleri mantıklı olabilir ve kodun içerisinde bol miktarda yorum bulunabilir. Ancak bütün bunlar kodun gerçekten doğru olduğu anlamına gelmiyor. Hatta bazen tam tersine, kodun fazla karmaşık olması hatayı bulmayı daha da zorlaştırabiliyor. Bir kişinin yapay zekâya "bana gelişmiş bir clan sistemi yap" demesiyle ortaya çıkan 3000 satırlık kodu gerçekten anlayıp anlamadığını düşünmek gerekiyor. Eğer geliştirici Java'nın temel mantığını, Bukkit/Paper API'nin nasıl çalıştığını, event sistemini, scheduler kullanımını, async ve sync arasındaki farkı, SQL işlemlerini veya concurrency problemlerini bilmiyorsa yapay zekânın verdiği kodu değerlendirme şansı da oldukça düşük oluyor. Böyle bir durumda kişi aslında bir yazılım geliştirmekten çok, yapay zekânın verdiği çıktıyı kopyalayıp çalıştırmış oluyor. Eklenti çalıştığı sürece de herhangi bir problem olmadığını düşünüyor. Fakat bir problem ortaya çıktığında yapay zekâya tekrar soruyor ve yapay zekâ başka bir kod veriyor. Bu şekilde bir süre sonra eklentinin nasıl çalıştığını geliştiricinin kendisi bile bilmiyor hale gelebiliyor. Sizce burada ortaya çıkan yazılımı gerçekten "geliştirilmiş" bir yazılım olarak değerlendirmek doğru mu?
​

"AI ile yazıldı" demek eklentiyi kötü yapar mı?​

Diğer taraftan yapay zekâ konusunda gereğinden fazla önyargılı olunmasını da doğru bulmuyorum. Çünkü yapay zekâ sonuçta yalnızca bir araç. Bir geliştiricinin yapay zekâ kullanması, o geliştiricinin hiçbir şey bilmediği anlamına gelmez. Tam tersine, deneyimli bir geliştirici yapay zekâyı çok etkili bir yardımcı olarak kullanabilir. Örneğin bir geliştirici temel mimariyi kendisi oluşturup bazı tekrar eden kodları yapay zekâya yazdırabilir, daha sonra ortaya çıkan kodu inceleyebilir, performans açısından düzenleyebilir, güvenlik kontrollerini gerçekleştirebilir ve kendi testlerini uygulayabilir. Böyle bir durumda ortaya çıkan eklentinin büyük bir kısmının yapay zekâ yardımıyla yazılmış olması neden otomatik olarak onu kötü yapsın? Bugün birçok profesyonel yazılım geliştiricisi de yapay zekâdan kod yazarken, hata ayıklarken, dokümantasyon hazırlarken veya alternatif çözüm üretirken faydalanıyor. Dolayısıyla "AI kullandıysa kötüdür" şeklinde bir yaklaşım bana göre doğru değil. Aynı şekilde "insan yazdıysa güvenlidir" demek de doğru değil. İnsanlar da kötü kod yazabilir, güvenlik açığı bırakabilir, performansı önemsemeyebilir veya kullanıcı verilerini yanlış şekilde işleyebilir. Bu nedenle bence asıl soru "Bu eklentiyi AI mı yazdı?" değil, "Bu eklentiyi geliştiren kişi ortaya çıkan kodu gerçekten kontrol etti mi?" olmalı.
​

İnsan tarafından yazılan eklenti gerçekten daha mı güvenli?​

Bu noktada başka bir soru ortaya çıkıyor. Bir eklentinin tamamen insan tarafından yazılmış olması ona otomatik olarak bir güven avantajı sağlıyor mu? Bana göre hayır. Tecrübeli bir geliştirici bile hata yapabilir. Bir SQL sorgusunda problem olabilir, bir event yanlış yerde kullanılabilir, bir listener gereğinden fazla çalışabilir, bir scheduler sürekli olarak gereksiz işlem yapabilir veya oyuncudan alınan bir veri düzgün şekilde doğrulanmayabilir. Hatta yıllardır geliştirme yapan bir kişinin bile ciddi bir bug yapması gayet normal. Yazılım geliştirme zaten hatasız kod yazma işi değil; hataları mümkün olduğunca erken tespit edip düzeltme işi. Bu nedenle bir eklentiyi değerlendirirken sadece geliştiricinin ne kullandığına değil, geliştirme sürecine de bakılması gerektiğini düşünüyorum. Yapay zekâ kullanılmış olabilir ancak kod incelenmiş ve test edilmiş olabilir. İnsan tarafından yazılmış olabilir ancak hiçbir test yapılmamış olabilir. Bu iki durumda hangisinin daha güvenilir olduğunu yalnızca "AI kullandı/kullanmadı" üzerinden belirlemek mümkün değil.
Ekli dosyayı görüntüle 296933​

Güvenlik açısından en büyük problem ne olabilir?​

Minecraft eklentileri genellikle sunucunun oldukça geniş bir bölümüne erişebiliyor. Bir eklenti oyunculara mesaj gönderebilir, komut çalıştırabilir, dosya okuyabilir ve yazabilir, veritabanına bağlanabilir, HTTP istekleri gönderebilir, sunucu bilgilerine erişebilir ve başka pluginlerle iletişim kurabilir. Dolayısıyla sunucuya yüklenen bir eklentinin sahip olduğu yetkileri küçümsememek gerekiyor. Özellikle yapay zekâ ile hazırlanmış bir eklentide geliştirici kodun ne yaptığını tam olarak bilmiyorsa çok daha dikkatli olunması gerektiğini düşünüyorum. Eklenti herhangi bir web adresine bağlanıyor mu? Harici bir API kullanıyor mu? Hangi bilgileri gönderiyor? Sunucu IP'si veya oyuncu bilgileri dışarıya aktarılıyor mu? Güncelleme kontrolü yaparken hangi sunucuya istek gönderiliyor? Lisans sistemi kullanıyorsa neyi doğruluyor? Veritabanında hangi bilgiler tutuluyor? Bunların tamamı aslında bilinmesi gereken şeyler. "Eklenti çalışıyor ve herhangi bir virüs uyarısı vermiyor" demek bu soruların cevaplandığı anlamına gelmiyor.
​

İnternete bağlanan her eklenti şüpheli midir?​

Burada da dengeli olmak gerektiğini düşünüyorum. Bir eklentinin internete bağlantı kurması tek başına kötü bir durum değildir. Örneğin bir Discord entegrasyonu kullanıyorsanız Discord API'sine bağlanması gerekir. Bir web paneli ile iletişim kuruyorsa HTTP bağlantısı yapması normaldir. Güncelleme kontrolü yapan bir eklentinin geliştiricinin sunucusuna istek göndermesi de tek başına şüpheli değildir. Problem bunun kullanıcıdan gizlenmesi veya gereksiz olmasıdır. Bir eklenti neden internete bağlandığını açıkça belirtiyorsa, hangi verilerin gönderildiğini söylüyorsa ve bu konuda şeffaf davranıyorsa değerlendirme yapmak daha kolay olur. Ancak yapay zekâ tarafından oluşturulan bir kod içerisinde geliştiricinin bile fark etmediği bir HTTP isteği bulunuyorsa burada daha ciddi bir problem ortaya çıkabilir. Özellikle kodun tamamını okumayan bir geliştirici için bunun fark edilmesi oldukça zor olabilir.
Ekli dosyayı görüntüle 296934​

Oyuncu verileri konusu da göz ardı edilmemeli​

Bir diğer konu ise veri saklama. Günümüzde birçok Minecraft eklentisi oyuncular hakkında çeşitli veriler topluyor. UUID, oyuncu adı, ekonomi bilgileri, istatistikler, görev ilerlemeleri, mesaj geçmişleri, bağlantı zamanları veya çeşitli oyun içi aktiviteler veritabanlarında tutulabiliyor. Burada sunucu sahibinin hangi verilerin toplandığını bilmesi gerektiğini düşünüyorum. Bir geliştirici yapay zekâya "oyuncu istatistiklerini kaydet" dediğinde yapay zekânın hangi verileri kaydedeceğini her zaman tam olarak tahmin etmek mümkün olmayabilir. Üstelik bu verilerin yalnızca yerel bir veritabanında tutulup tutulmadığını veya başka bir servise gönderilip gönderilmediğini de kontrol etmek gerekiyor. Dolayısıyla güvenilirlik yalnızca "kötü amaçlı kod var mı?" sorusundan ibaret değil. Eklenti benim sunucumda hangi verilere erişiyor ve bu verileri ne yapıyor? sorusu da en az bunun kadar önemli.
​

Performans tarafında yapay zekâ ne kadar başarılı?​

Güvenlik dışında performans konusu da bence çok önemli. Yapay zekâ genellikle kendisine verilen isteğe göre çalışan bir çözüm üretmeye çalışıyor. Ancak bir çözümün çalışması, Minecraft sunucusu için ideal olduğu anlamına gelmiyor. Özellikle Paper veya Spigot gibi platformlarda ana thread üzerinde yapılan işlemlerin ne kadar kritik olduğunu bilen kişiler bunun ne kadar önemli olduğunu bilir. Bir kod parçası 10 oyunculu bir test sunucusunda sorunsuz çalışabilirken 500 oyunculu bir sunucuda ciddi TPS düşüşlerine sebep olabilir. Örneğin oyuncuların tamamını sürekli olarak tarayan bir görev, her oyuncu hareketinde veritabanına sorgu atan bir sistem veya gereksiz yere sürekli yeni task oluşturan bir yapı küçük sunucularda fark edilmeyebilir. Ancak oyuncu sayısı arttığında sistemin maliyeti de artar. Yapay zekâ bazen bu tür durumlar için çalışan bir çözüm sunabilir ama bunun ne kadar verimli olduğunu geliştiricinin değerlendirmesi gerekir. Burada yine geliştiricinin teknik bilgisi devreye giriyor. Yapay zekâ size kod yazabilir fakat o kodun Minecraft sunucunuz üzerindeki gerçek maliyetini anlamak sizin sorumluluğunuzda.
Ekli dosyayı görüntüle 296935​

"Ama bu eklentiyi binlerce kişi kullanıyor" yeterli bir güven göstergesi mi?​

Toplulukta sık karşılaştığımız bir başka argüman da bu. Bir eklentinin çok fazla indirilmesi veya çok fazla sunucuda kullanılması elbette olumlu bir işaret olabilir. Fakat bunu kesin güvenlik garantisi olarak görmek doğru mu? Bence değil. Çünkü binlerce kişinin kullanması, o binlerce kişinin kaynak kodunu incelediği anlamına gelmiyor. Çoğu kişi eklentiyi indiriyor, sunucuya atıyor ve çalıştırıyor. Eğer bir sorun uzun süre ortaya çıkmıyorsa herkes eklentiyi güvenli olarak değerlendirmeye devam ediyor. Ancak bu yine de kesin bir garanti değil. Buna karşılık uzun süredir geliştirilen, açık kaynak olan, düzenli güncellenen, issue'ları takip edilen, geliştiricisi toplulukta bilinen ve güvenlik konusunda şeffaf olan bir eklenti elbette daha fazla güven verebilir. Yani popülerlik bence bir kriter olabilir ama tek kriter olmamalı.
​

Kaynak kodunun açık olması yeterli mi?​

Açık kaynak konusu da oldukça ilginç. Bir eklentinin GitHub gibi bir platformda kaynak kodunun bulunması kullanıcı açısından ciddi bir avantaj. En azından eklentinin ne yaptığını inceleme imkânınız var. Fakat burada da "kaynak kodu açık = güvenli" şeklinde bir denklem kurmak mümkün değil. Çünkü kaynak kodu açık olsa bile çoğu sunucu sahibi onu incelemiyor. Ayrıca kod açık olsa bile kullanılan bağımlılıkların ne yaptığı, build sırasında hangi kütüphanelerin dahil edildiği veya release dosyasının kaynak koduyla gerçekten aynı olup olmadığı gibi konular da önem kazanabiliyor. Buna rağmen açık kaynak bir projenin denetlenebilir olması bence önemli bir artı. En azından topluluk içerisindeki deneyimli geliştiriciler kodu inceleyebilir, açıkları bildirebilir ve geliştirici bunları düzeltebilir.
​

Yapay zekâ kullanan geliştiricinin sorumluluğu ne olmalı?​

Bence tartışmanın en önemli noktalarından biri de bu. Bir geliştirici yapay zekâ kullanarak bir eklenti oluşturduysa ve bunu başka insanların kullanımına sunuyorsa "Ben yazmadım, AI yazdı." demesi bana göre bir sorumluluk mekanizması oluşturmuyor. Yapay zekâ kullanılan bir araçtır. Bir geliştirici dışarıdan aldığı bir kütüphanenin yaptığı hatalardan tamamen sorumsuz olmadığı gibi, yapay zekâ tarafından oluşturulan kodu kullanırken de ortaya çıkan üründen sorumlu olmalı. Özellikle eklentiyi ücretli olarak satıyorsa veya binlerce sunucuda kullanılmasını amaçlıyorsa test sürecinin daha ciddi olması gerektiğini düşünüyorum. En azından kodun temel bölümlerinin incelenmesi, güvenlik kontrollerinin yapılması, performans testlerinin gerçekleştirilmesi, hata durumlarının kontrol edilmesi ve kullanılan harici servislerin açıkça belirtilmesi gerektiğini düşünüyorum.
Ekli dosyayı görüntüle 296936​

Peki yapay zekâ eklenti geliştirmeyi kolaylaştırarak aslında topluluğa fayda mı sağlıyor?​

Kesinlikle evet. Bu tarafını da göz ardı etmemek gerekiyor. Daha önce Java öğrenmeye başlayan bir kişinin küçük bir eklenti yapabilmesi için saatlerce araştırma yapması gerekiyordu. Şimdi ise yapay zekâ sayesinde kişi bir konu hakkında daha hızlı fikir edinebiliyor, hata mesajlarını anlamlandırabiliyor ve örnek kodlar üzerinden öğrenebiliyor. Belki de gelecekte çok daha fazla kişi kendi sunucusu için küçük eklentiler geliştirebilecek. Bu bence kötü bir şey değil. Hatta Minecraft topluluğunun teknik anlamda büyümesine katkı bile sağlayabilir. Problem, bu kolaylığın "artık hiçbir şey öğrenmeye gerek yok" düşüncesine dönüşmesi. Çünkü yapay zekâ bir şeyi sizin için yazabiliyor diye o şeyin nasıl çalıştığını öğrenmek gereksiz hale gelmiyor.
​

Bence gelecekte asıl değer kazanacak şey kod yazmak değil, kodu değerlendirebilmek olacak​

Yapay zekâların kod yazma yeteneği geliştikçe basit ve orta seviye kodları üretmek giderek daha kolay hale gelecek. Bu durumda geliştiricilerin değeri yalnızca "Java kodu yazabiliyorum" seviyesinde kalmayacak. Üretilen kodu analiz edebilmek, yanlış çözümü fark edebilmek, performans sorunlarını tespit edebilmek, güvenlik açıklarını anlayabilmek ve doğru mimariyi seçebilmek daha önemli hale gelecek. Yani yapay zekâ aslında geliştiricinin önemini azaltmaktan ziyade geliştiriciden beklenen becerileri değiştirebilir. Belki gelecekte bir geliştiricinin yapay zekâya 3000 satır kod yazdırması sıradan bir şey olacak. Fakat o 3000 satırın gerçekten gerekli olup olmadığını, hangi kısmının riskli olduğunu ve hangi kısmının değiştirilmesi gerektiğini anlayabilmek asıl uzmanlık olacak.
​

Sonuç olarak benim görüşüm​

Ben "Yapay zekâ ile yapılan eklentilere güvenilmez." şeklinde kesin bir yargının yanlış olduğunu düşünüyorum. Aynı şekilde "AI artık her şeyi yapıyor, geliştiriciye gerek yok." düşüncesinin de oldukça tehlikeli olduğunu düşünüyorum. Yapay zekâ çok güçlü bir araç olabilir ancak araç ile ortaya çıkan ürün aynı şey değildir. Bir eklentinin güvenilirliğini belirleyen temel faktörün kodun hangi araçla yazıldığı değil, kodun nasıl kontrol edildiği, nasıl test edildiği, hangi yetkilere sahip olduğu, hangi verileri işlediği, internete hangi bağlantıları yaptığı, performansının nasıl olduğu ve geliştiricisinin ortaya çıkan yazılımı ne kadar iyi tanıdığı olduğunu düşünüyorum. Eğer geliştirici yapay zekâdan yardım alıyor, fakat yazdığı kodu okuyabiliyor, anlayabiliyor, değiştirebiliyor, test edebiliyor ve gerektiğinde neden belirli bir çözümün yanlış olduğunu açıklayabiliyorsa burada yapay zekâ kullanılması bana göre ciddi bir problem değil. Ancak kişi Java bilmiyor, Paper API bilmiyor, kodu okumuyor, yapay zekânın verdiği her şeyi doğru kabul ediyor ve ortaya çıkan eklentiyi doğrudan yüzlerce oyuncunun bulunduğu production sunucusuna yüklüyorsa burada ciddi bir risk olduğunu düşünüyorum.

Bence bundan birkaç yıl sonra "Bu eklenti AI ile mi yapıldı?" sorusundan çok daha önemli sorular soracağız. Kaynak kodu incelendi mi? Test edildi mi? Hangi izinlere sahip? Hangi verileri topluyor? Hangi dış servislere bağlanıyor? Performans testleri yapıldı mı? Geliştiricisi sorun çıktığında destek veriyor mu? Proje ne kadar süredir aktif? Güvenlik açıkları nasıl ele alınıyor? Bunların tamamı eklentinin güvenilirliği konusunda çok daha anlamlı bilgiler verecektir.

Bu yüzden benim açımdan konu aslında "Yapay zekâ iyi mi kötü mü?" tartışması değil. Daha çok "Yapay zekânın yazılım geliştirmeyi bu kadar kolaylaştırdığı bir dönemde, geliştiricinin sorumluluğu nerede başlıyor ve nerede bitiyor?" tartışması. Çünkü bugün yapay zekâ birkaç dakika içerisinde çalışan bir Minecraft eklentisi oluşturabiliyor olabilir. Ancak o eklentinin gerçekten kaliteli, güvenli, performanslı ve sürdürülebilir olup olmadığını anlamak hâlâ insanın sorumluluğunda.
Ekli dosyayı görüntüle 296937​

Yazar Notu​

Bu konuyu açmamın temel sebebi yapay zekâya karşı veya yapay zekâdan yana kesin bir taraf seçmek değil; son zamanlarda "AI ile yaptım" ifadesinin Minecraft eklenti geliştirme konusunda giderek daha normal hale gelmesi ve buna rağmen ortaya çıkan kodun kalitesi, güvenliği ve sorumluluğu konusunda yeterince tartışma yapılmadığını düşünmem. Özellikle son dönemde yapay zekâ sayesinde daha önce hiç Java kodu yazmamış kişilerin bile oldukça kapsamlı eklentiler geliştirebilmesi bence hem çok güzel bir gelişme hem de beraberinde ciddi soru işaretleri getiriyor. Bir yandan insanların teknik projeler üretmesinin önündeki engeller azalıyor, diğer yandan ise kişi ürettiği kodun nasıl çalıştığını bilmiyorsa ortaya oldukça garip durumlar çıkabiliyor. Bu nedenle burada "AI kullanmak kötüdür" gibi basit bir sonuca varılmasını istemiyorum. Hatta tam tersine, yapay zekânın doğru kullanıldığı zaman küçük geliştiriciler için inanılmaz faydalı olduğunu düşünüyorum. Benim asıl sorguladığım nokta, yapay zekânın verdiği kodun herhangi bir denetim yapılmadan doğru kabul edilmesi ve bunun sonucunda ortaya çıkan eklentilerin production sunucularında kullanılmaya başlanması. Özellikle bir eklenti oyuncuların verilerine erişebiliyor, dosya sistemiyle çalışabiliyor, veritabanına bağlanabiliyor veya internet üzerinden harici servislere istek gönderebiliyorsa, geliştiricinin "AI böyle yazdı" demesinin yeterli bir açıklama olmadığını düşünüyorum. Sonuçta o eklentiyi yayınlayan kişi insan ve o eklentiyi kullanan kişi de yapay zekâ ile değil, geliştirici ile iletişim kuruyor. Bu yüzden sorumluluğun da geliştiricide olması gerektiğini düşünüyorum.

Aynı zamanda burada deneyimli geliştiricilerin görüşlerini de özellikle merak ediyorum. Çünkü benim gözümden kaçan birçok teknik detay olabilir ve bu konunun yalnızca genel bir tartışma olarak kalmasını istemiyorum. Örneğin gerçekten profesyonel olarak Paper/Spigot eklentileri geliştiren kişiler yapay zekâyı nasıl kullanıyor? Kodun hangi bölümlerini AI'a yazdırıyorlar? Üretilen kodu nasıl test ediyorlar? Yapay zekânın ürettiği kod içerisinde daha önce ciddi bir performans problemi veya güvenlik açığı ile karşılaşan oldu mu? Bir eklentinin kaynak koduna baktığınızda AI tarafından yazıldığı kolayca anlaşılabiliyor mu? Yoksa artık iyi bir geliştirici tarafından kontrol edilen AI kodu ile insan tarafından yazılan kodu birbirinden ayırmak neredeyse imkânsız hale mi geliyor? Bunlar bence tartışılması gereken çok daha ilginç sorular.
Ayrıca sunucu sahiplerinin de bu konuda fikirlerini merak ediyorum. Bir eklentiyi sunucunuza yüklerken gerçekten kaynak kodunu inceliyor musunuz? Eklentinin internete yaptığı bağlantıları kontrol ediyor musunuz? Kullanılan kütüphanelere bakıyor musunuz? Yoksa eklentinin Spigot/Paper üzerinde çalışması, güncel olması ve topluluk tarafından kullanılması sizin için yeterli mi? Diyelim ki çok başarılı görünen bir eklenti buldunuz fakat geliştirici açıkça "Bu eklentinin büyük bölümü yapay zekâ yardımıyla geliştirildi." diyor. Bu sizin eklentiye bakışınızı değiştirir mi? Eğer değiştiriyorsa neden? Değiştirmiyorsa yine neden?

Bir de işin etik tarafı olduğunu düşünüyorum. Yapay zekâ ile kod üretmek günümüzde oldukça normal hale geldi fakat yapay zekânın ürettiği kodu tamamen kendi emeğiymiş gibi sunmak konusunda topluluğun nasıl düşündüğünü merak ediyorum. Örneğin bir kişi yapay zekâya bütün eklentiyi yaptırıyor, birkaç küçük değişiklik yapıyor ve daha sonra bunu tamamen kendi geliştirdiği bir proje olarak yayınlıyor. Sizce burada bir sorun var mı? Yoksa kullanılan aracın hiçbir önemi yok mu? Bir geliştirici Photoshop kullanarak grafik hazırladığında nasıl "Photoshop ile yaptım" demek zorunda değilse, kod yazarken AI kullanması da aynı şekilde normal mi? Yoksa yazılım geliştirme konusunda AI kullanımının ayrıca belirtilmesi gerektiğini mi düşünüyorsunuz?

Ben özellikle yorumlarda sadece "AI çöptür", "AI harika", "AI kullanmak hile" veya "herkes AI kullanıyor artık" gibi tek cümlelik cevaplardan ziyade insanların neden böyle düşündüğünü görmek istiyorum. Çünkü bence bu konu iki taraflı düşünülmesi gereken bir konu. Yapay zekâ gerçekten inanılmaz bir hız ve erişilebilirlik sağlıyor. Daha önce teknik bilgisi olmayan birinin bile bir fikir üzerinde çalışmasını mümkün kılıyor. Fakat aynı zamanda teknik bilgisi olmayan kişilerin teknik olarak riskli yazılımlar üretmesini de kolaylaştırıyor. Yani aynı özellik hem avantaj hem dezavantaj oluşturabiliyor. Bu yüzden tartışmanın "AI iyi mi kötü mü?" seviyesinde kalması yerine, AI ile geliştirilen bir eklentiyi güvenilir yapan şeyin ne olduğu üzerine ilerlemesini daha faydalı buluyorum.

Kısacası benim sorum şu: Bir Minecraft eklentisini güvenilir yapan şey geliştiricinin kim olduğu ve kodu nasıl yazdığı mı, yoksa ortaya çıkan kodun nasıl test edildiği ve ne yaptığı mı? Yapay zekâ tarafından oluşturulmuş ama deneyimli bir geliştirici tarafından baştan sona incelenmiş bir eklenti mi daha güvenilirdir, yoksa tamamen insan tarafından yazılmış fakat hiç denetlenmemiş bir eklenti mi? Kaynak kodu açık olan bir eklentiye mi daha çok güvenirsiniz, yoksa kapalı kaynak fakat yıllardır kullanılan ve çok büyük bir topluluğa sahip bir eklentiye mi? Bir eklentinin binlerce kişi tarafından kullanılması sizin için yeterli bir güven göstergesi mi? Ve son olarak, sizce önümüzdeki birkaç yıl içerisinde "AI ile yazılmış eklenti" kavramı tamamen sıradanlaşacak mı, yoksa insanlar AI tarafından geliştirilen yazılımlara karşı her zaman ekstra bir şüpheyle mi yaklaşacak?

Yorumlarda görüşlerinizi, mümkünse teknik gerekçelerinizle ve varsa yaşadığınız gerçek deneyimlerle paylaşın. Özellikle geliştirici, sunucu sahibi veya eklenti kullanıcısı olarak farklı açılardan bakabilirsek konu çok daha faydalı bir tartışmaya dönüşebilir.​

Genişletmek için tıkla ...

You are acting as a senior Java software engineer, Minecraft Paper/Spigot plugin architect, code reviewer, and software-forensics analyst.

Your task is to perform a deep forensic analysis of this entire Minecraft plugin repository and estimate whether the project was primarily:

A) traditionally written by an experienced human developer,
B) traditionally written by a junior/intermediate human developer,
C) human-written with significant AI assistance,
D) primarily produced through AI-assisted vibe coding with human supervision,
E) almost entirely AI-generated/vibe-coded.

IMPORTANT: You are NOT allowed to claim with certainty that code was AI-generated merely from coding style. There is no reliable universal detector for AI-generated source code. Your conclusion must therefore be probabilistic and evidence-based.

Analyze the ENTIRE repository, not just one or two classes.

If you have filesystem/repository access, inspect everything relevant, including:

- Java source files
- package structure
- build.gradle / build.gradle.kts / pom.xml
- plugin.yml / paper-plugin.yml
- configuration files
- messages/localization files
- database layer
- API abstractions
- event listeners
- command implementations
- schedulers
- services/managers
- utility classes
- dependency injection or service initialization
- caching
- concurrency / async code
- persistence
- error handling
- tests
- README/documentation
- comments and JavaDocs
- Git history/commits if available
- dead or unused code
- duplicated implementations
- compatibility layers
- version-specific Minecraft/Paper code

Do not judge based on superficial indicators such as formatting alone.

# PRIMARY OBJECTIVE

Determine whether the repository shows engineering behavior consistent with deliberate human software development or with prompt-driven/vibe-coded development.

The most important distinction is NOT:

"Does this code look clean?"

The important distinction is:

"Does this repository show evidence of a developer maintaining a coherent mental model of the system across files, abstractions, edge cases, lifecycle behavior, and architectural decisions?"

A well-prompted AI can generate clean-looking code.

Therefore prioritize deep structural evidence over visual code style.

# 1. ARCHITECTURAL COHERENCE

Study the architecture across the entire project.

Determine whether:

- responsibilities are divided intentionally
- abstractions solve real recurring problems
- services have clear ownership
- class boundaries make conceptual sense
- data flow is coherent
- dependencies flow in predictable directions
- architecture remains consistent across features
- similar problems are solved similarly
- initialization and shutdown lifecycle are deliberately designed
- abstractions appear to have evolved naturally with project requirements

Look for suspicious AI/vibe-coding patterns such as:

- Manager/Service/Handler classes created mechanically for everything
- unnecessary interfaces with only one implementation
- abstractions that add complexity without reducing duplication
- several architectural styles mixed together
- one subsystem using repositories, another directly accessing SQL, another using static managers
- duplicated architecture invented independently in different features
- over-engineering simple features
- under-engineering complex features
- classes that appear individually reasonable but do not form a coherent system

Explain specific examples.

# 2. CROSS-FILE CONSISTENCY

AI-generated projects often look convincing at the individual-file level but become inconsistent across the repository.

Search specifically for contradictions between files.

Examples:

- different naming conventions for the same concept
- inconsistent null-handling
- inconsistent UUID/player-name handling
- different date/time representations
- several unrelated configuration access patterns
- inconsistent permission checking
- different database access conventions
- multiple serialization strategies
- different approaches to asynchronous execution
- repeated utility logic instead of reuse
- inconsistent command error handling
- similar features behaving subtly differently
- duplicate constants
- duplicated validation rules
- APIs that expose methods nobody actually needs
- classes whose public APIs do not match how callers use them

Give concrete file/class/method references.

# 3. MINECRAFT/PAPER DOMAIN KNOWLEDGE

Evaluate whether the code demonstrates genuine understanding of Paper/Spigot/Bukkit behavior rather than merely knowing API syntax.

Inspect for correct handling of:

- Bukkit main-thread restrictions
- asynchronous database operations
- calling Bukkit APIs asynchronously
- scheduler usage
- player login/logout lifecycle
- plugin enable/disable lifecycle
- server reload behavior
- offline players
- UUIDs vs player names
- configuration reloads
- event priorities
- cancelled events
- listener registration
- command registration
- Adventure Components
- MiniMessage
- PersistentDataContainer
- ItemStack serialization
- inventories and inventory events
- entity lifecycle
- chunk loading
- memory retention of Player objects
- caching
- database connection lifecycle
- thread safety
- Folia compatibility claims, if any
- Paper version compatibility
- deprecated Bukkit APIs

AI-generated Minecraft plugins frequently contain code that is syntactically correct but misunderstands server lifecycle, concurrency, or API semantics.

Identify such cases carefully.

Distinguish between:

- an actual bug,
- questionable design,
- harmless style,
- deprecated but functional code.

# 4. CONCURRENCY AND ASYNC REASONING

This category is extremely important.

Analyze every asynchronous path.

Build a mental model of:

- which thread operations originate from
- which operations access Bukkit/Paper state
- database operations
- CompletableFuture chains
- scheduler transitions
- shared mutable state
- caches
- concurrent collections
- callbacks
- shutdown behavior

Look for "fake async" patterns, for example:

- wrapping code in CompletableFuture without understanding thread ownership
- asynchronous Bukkit API calls
- switching threads unnecessarily
- nested schedulers
- futures immediately joined or blocked
- async methods whose callers treat them synchronously
- race conditions ignored across classes
- concurrent collections used as a magical thread-safety fix
- inconsistent use of synchronized
- ExecutorServices never shut down
- thread pools created unnecessarily

Strong concurrency reasoning can be evidence of deliberate engineering.

Superficially sophisticated but logically broken async code can be evidence supporting vibe coding.

# 5. ERROR HANDLING

Inspect error handling across the repository.

Look for:

- catch(Exception e) everywhere
- swallowed exceptions
- repetitive try/catch blocks
- e.printStackTrace()
- excessive generic logging
- log messages that provide no operational context
- inconsistent exception strategies
- impossible fallback branches
- null returned after failures without documented semantics
- defensive checks for states that cannot occur
- missing handling of states that realistically CAN occur

Also identify unusually verbose defensive programming that appears mechanically generated.

# 6. NULL SAFETY AND IMPOSSIBLE CHECKS

AI-generated code frequently adds defensive checks without understanding actual invariants.

Search for:

- null checks on values guaranteed non-null by API contracts
- repeated Objects.requireNonNull() without architectural purpose
- checks for impossible enum values
- redundant containsKey() followed by get()
- optional wrapping/unwrapping without benefit
- validation repeated at multiple layers
- null fallbacks that mask real bugs

Conversely, find important places where nullability actually matters but is ignored.

# 7. COPY-PASTE / TEMPLATE FINGERPRINTS

Search for structural repetition.

Do NOT merely count duplicated text.

Look for conceptual duplication such as multiple classes with the same skeleton:

1. validate
2. fetch service
3. try
4. log
5. send message
6. catch Exception

Identify:

- repeated switch structures
- nearly identical CRUD methods
- duplicated command handlers
- duplicated event logic
- getters/setters produced mechanically
- classes with suspiciously uniform method ordering
- repeated comments with identical grammar
- repeated validation boilerplate

Determine whether repetition looks like normal domain boilerplate or prompt-generated templating.

# 8. COMMENTS AND JAVADOC FORENSICS

Analyze comments carefully but do NOT assume comments prove AI usage.

Look for:

- comments explaining obvious Java syntax
- JavaDocs that simply restate method names
- excessively formal documentation for trivial private methods
- inconsistent documentation density
- verbose comments on simple code but no comments around genuinely difficult logic
- generic phrases such as:
  "Ensures that..."
  "Handles the..."
  "Retrieves the..."
  "Processes the..."
  when they add no information
- comments describing implementation rather than intent
- comments apparently generated in batches

Compare documentation quality to actual implementation complexity.

A human developer often documents unusual constraints and historical reasons.

AI frequently documents obvious behavior.

# 9. NAMING FORENSICS

Evaluate naming across the whole repository.

Look for:

- generic names such as Manager, Handler, Processor, Helper, Util, Service
- several classes with overlapping responsibilities
- excessively descriptive method names
- mechanical naming consistency that does not reflect domain meaning
- terms changing across features
- concept synonyms used inconsistently

For example:

VipManager
VipService
VipHandler
VipProcessor

may indicate unclear ownership if responsibilities overlap.

Do not consider generic names suspicious by themselves. Evaluate them in architectural context.

# 10. CODE COMPLEXITY DISTRIBUTION

Compare complexity across the repository.

AI/vibe-coded projects often have strange complexity distribution:

- trivial features receive elaborate abstraction layers
- difficult business logic appears as giant methods
- utility classes become dumping grounds
- simple DTOs have extensive validation
- important lifecycle code receives minimal attention

Identify where engineering effort appears disproportionately allocated.

# 11. DEAD CODE AND ABANDONED DESIGNS

Search for:

- unused classes
- unused methods
- unused configuration keys
- unused dependencies
- interfaces with no meaningful reason
- old systems left alongside replacements
- abandoned abstractions
- unreachable branches
- commented-out implementations
- compatibility methods nobody calls

Vibe coding often produces abandoned approaches because each prompt introduces another solution instead of refactoring the previous one.

Determine whether the repository contains evidence of this accumulation.

# 12. CONFIGURATION DESIGN

For Minecraft plugins specifically, deeply evaluate config architecture.

Inspect:

- config.yml
- messages.yml
- GUI configs
- storage configs
- permissions
- placeholders
- feature toggles

Determine whether configuration options form a coherent user-facing system.

Look for:

- keys referenced incorrectly
- unused config values
- duplicated defaults inside Java
- hard-coded values despite config options
- config paths inconsistent across classes
- runtime reload problems
- missing migration strategy
- unsafe casts
- assumptions about configuration sections
- default values differing between documentation and implementation

Good configuration architecture can indicate strong domain awareness.

# 13. DATABASE/PERSISTENCE ANALYSIS

If persistence exists, analyze:

- schema design
- indexes
- transactions
- migrations
- connection pooling
- query construction
- SQL injection safety
- resource closing
- batching
- caching
- async behavior
- consistency guarantees
- failure recovery

Look for AI-style "enterprise-looking" abstractions that provide little practical value.

Also look for simplistic persistence code that ignores real server conditions.

# 14. API DESIGN

If the plugin exposes an API, inspect whether it looks designed for actual consumers.

Ask:

- Are methods cohesive?
- Are implementation details leaked?
- Are mutable collections exposed?
- Are lifecycle guarantees clear?
- Can API consumers misuse it easily?
- Are events provided where appropriate?
- Are APIs versionable?
- Are methods present that no real consumer would need?

AI frequently generates APIs based on what "looks like an API" rather than actual usage requirements.

# 15. SECURITY AND TRUST BOUNDARIES

Review:

- command permissions
- administrative actions
- player-supplied strings
- SQL parameters
- console commands
- item/voucher verification
- serialization
- filesystem access
- network calls
- secrets
- config credentials
- plugin messaging

Look for security checks that exist cosmetically but can be bypassed because the overall trust model was not understood.

# 16. DEPENDENCY USAGE

Inspect dependencies.

Identify:

- libraries imported but barely used
- libraries used for functionality easily implemented directly
- multiple libraries solving the same problem
- dependency versions that conflict
- shaded dependencies that may break runtime behavior
- libraries seemingly added because AI suggested them

Compare the sophistication of dependency selection to the rest of the codebase.

# 17. VERSION COMPATIBILITY CLAIMS

If the plugin claims compatibility with multiple Minecraft/Paper versions, verify whether the implementation actually supports them.

Inspect:

- API calls introduced in newer versions
- removed/deprecated APIs
- reflection/version adapters
- plugin metadata
- dependency versions
- NMS usage
- Adventure API assumptions

A README saying "1.8-1.21 supported" is not evidence of real compatibility.

# 18. TESTING STRATEGY

If tests exist, evaluate whether they test meaningful behavior.

Look for:

- tests that merely assert getters/setters
- mocks that reproduce implementation rather than test behavior
- tests that never test Minecraft-specific failure conditions
- mechanically generated tests
- unrealistic test coverage

If there are no tests, do not automatically classify the project as AI-generated because many Minecraft plugins have no tests.

# 19. BUILD SYSTEM FORENSICS

Analyze Maven/Gradle files.

Look for:

- unnecessary plugins
- duplicate dependencies
- inconsistent Java versions
- suspiciously broad repositories
- incorrect shading
- broken relocation
- unused annotation processors
- excessively elaborate build configuration relative to project size
- README instructions contradicting actual build configuration

# 20. TEMPORAL / DEVELOPMENT FINGERPRINTS

If Git history is available, analyze development behavior.

This is potentially stronger evidence than code style.

Inspect:

- commit sizes
- commit frequency
- massive feature dumps
- complete subsystems appearing in one commit
- repeated rewrite cycles
- naming changing abruptly
- architecture changing without migrations
- dozens of unrelated changes bundled together
- commit messages
- fix patterns

Possible vibe-coding fingerprints include repeated sequences such as:

feature generated → compilation fix → runtime fix → edge-case fix → another architectural rewrite

However, do NOT treat this pattern as conclusive because humans can work this way too.

If Git history is unavailable, clearly state that this evidence category cannot be evaluated.

# 21. "LOCAL QUALITY VS GLOBAL QUALITY" TEST

This is one of the most important analyses.

For each major subsystem, compare:

LOCAL QUALITY:
Does an individual method/class look polished?

GLOBAL QUALITY:
Does that class make sense inside the complete system?

AI-assisted repositories may contain many locally impressive classes while the global architecture contains contradictions.

Give this category significant weight.

# 22. INTENTIONAL IMPERFECTIONS VS RANDOM IMPERFECTIONS

Experienced human-written systems often contain compromises that make sense historically:

- optimized hot paths
- ugly compatibility code
- shortcuts documented by context
- specialized helpers built around actual requirements

Vibe-coded systems may instead contain inconsistencies without an understandable reason.

Try to determine whether imperfections appear to result from deliberate tradeoffs or disconnected implementation episodes.

# 23. SEMANTIC BUG HUNT

Actively search for bugs that compile successfully but reveal weak understanding.

Prioritize:

- race conditions
- lifecycle bugs
- stale cache state
- memory leaks
- incorrect event assumptions
- async Bukkit access
- incorrect OfflinePlayer handling
- inventory duplication possibilities
- command parsing edge cases
- inconsistent persistence
- reload bugs
- item serialization issues
- timezone/duration bugs
- incorrect permission inheritance assumptions

These are substantially more informative than formatting style.

# 24. HUMAN-SPECIFIC SIGNALS

Search for evidence suggesting deliberate human authorship, such as:

- compact solutions tailored precisely to project constraints
- unusual but justified optimizations
- domain-specific abstractions
- meaningful internal terminology
- consistent design decisions maintained across distant parts of the repository
- comments explaining WHY a strange workaround exists
- careful handling of obscure Paper/Bukkit behavior
- API design clearly shaped by real usage

Explain these signals rather than ignoring them in favor of AI indicators.

# 25. AI-ASSISTANCE SIGNALS

Search for patterns consistent with AI-assisted development, including:

- excessive scaffolding
- generic abstractions
- repetitive validation
- verbose trivial documentation
- redundant helper methods
- multiple ways of solving identical problems
- implementation that appears correct superficially but fails deeper invariants
- overly defensive local code paired with weak global reasoning
- enormous classes generated around isolated feature requests
- methods that anticipate unrealistic edge cases while missing common ones
- features that look like separate prompts stitched together

Again, none of these individually proves AI usage.

# FALSE-POSITIVE CONTROL

Before making your conclusion, explicitly challenge your own hypothesis.

For every major piece of evidence suggesting AI/vibe coding, ask:

"Could an ordinary junior or rushed human developer plausibly produce this?"

For every major piece of evidence suggesting human authorship, ask:

"Could a capable LLM produce this if given strong prompts and iterative feedback?"

Do not reward clean code automatically as human.

Do not label bad code automatically as AI.

Do not label verbose code automatically as AI.

Do not label modern architecture automatically as AI.

Do not label common Minecraft boilerplate as AI.

# REQUIRED SCORING SYSTEM

Give scores from 0-10 for each category:

1. Architectural coherence
2. Cross-file consistency
3. Domain understanding
4. Concurrency correctness
5. Lifecycle awareness
6. Error-handling quality
7. Abstraction quality
8. Configuration design
9. Persistence/database design
10. API design
11. Security reasoning
12. Dependency discipline
13. Documentation authenticity
14. Naming consistency
15. Code reuse/refactoring quality
16. Edge-case reasoning
17. Global system coherence
18. Evidence of deliberate engineering
19. Evidence of prompt-by-prompt construction
20. Evidence consistent with AI generation

For the last two AI-related categories:

0 = almost no evidence
10 = extremely strong evidence

# FINAL CLASSIFICATION

At the end, provide estimated probabilities adding up to exactly 100%:

Experienced human-written: X%
Junior/intermediate human-written: X%
Human-written with moderate AI assistance: X%
Primarily AI-assisted / vibe-coded: X%
Nearly fully AI-generated: X%

Then give:

AI/VIBE-CODING LIKELIHOOD:
XX / 100

CONFIDENCE IN THIS ESTIMATE:
XX / 100

These are different values.

Example:

AI/Vibe-Coding Likelihood: 78/100
Confidence: 61/100

A high AI likelihood with low confidence is acceptable when evidence is ambiguous.

# EVIDENCE TABLE

Create a table with:

| Evidence | Location | Supports AI/Vibe Coding | Supports Human Coding | Strength | Explanation |

Strength must be:

- Weak
- Moderate
- Strong
- Very Strong

Include at least 15 meaningful pieces of evidence if the repository is large enough.

Do not fill the table with superficial formatting observations.

# STRONGEST EVIDENCE

Provide separate sections:

## Top 5 strongest indicators of AI/vibe coding

For each:
- exact file/class/method
- what you observed
- why it matters
- plausible human explanation
- evidence strength

## Top 5 strongest indicators of deliberate human engineering

Use the same structure.

# SUSPICIOUS CODE EXAMPLES

Quote small relevant snippets where necessary and explain the reasoning.

Prefer semantic/architectural examples over formatting examples.

# BUGS DISCOVERED

Separately list actual engineering problems discovered during the analysis.

Classify each as:

CRITICAL
HIGH
MEDIUM
LOW
INFORMATIONAL

Do NOT treat every bug as evidence of AI generation.

# FINAL VERDICT

Finish with a concise forensic verdict answering:

1. Does this repository look predominantly human-engineered or prompt-engineered?
2. Does it appear to have a coherent developer behind the architecture?
3. Does it look like one developer maintaining a mental model of the entire project, or many isolated feature prompts stitched together?
4. Which parts look most human-designed?
5. Which parts look most likely AI-generated?
6. What is the strongest single piece of evidence?
7. What additional evidence would increase confidence?

Be skeptical, technical, and evidence-driven.

Do not try to be polite to the author.

Do not exaggerate certainty.

Do not infer AI authorship solely because the code is bad.

Do not infer human authorship solely because the code is good.

Your job is forensic software analysis, not style criticism.

Start by mapping the repository architecture before giving any verdict.

WellSetups' Alıntı:

Google Antigravity veya chatgpt'ye kaynak kodu veya plugin.jar atıp şu promptu girin

Kod:Panoya kopyala

You are acting as a senior Java software engineer, Minecraft Paper/Spigot plugin architect, code reviewer, and software-forensics analyst.

Your task is to perform a deep forensic analysis of this entire Minecraft plugin repository and estimate whether the project was primarily:

A) traditionally written by an experienced human developer,
B) traditionally written by a junior/intermediate human developer,
C) human-written with significant AI assistance,
D) primarily produced through AI-assisted vibe coding with human supervision,
E) almost entirely AI-generated/vibe-coded.

IMPORTANT: You are NOT allowed to claim with certainty that code was AI-generated merely from coding style. There is no reliable universal detector for AI-generated source code. Your conclusion must therefore be probabilistic and evidence-based.

Analyze the ENTIRE repository, not just one or two classes.

If you have filesystem/repository access, inspect everything relevant, including:

- Java source files
- package structure
- build.gradle / build.gradle.kts / pom.xml
- plugin.yml / paper-plugin.yml
- configuration files
- messages/localization files
- database layer
- API abstractions
- event listeners
- command implementations
- schedulers
- services/managers
- utility classes
- dependency injection or service initialization
- caching
- concurrency / async code
- persistence
- error handling
- tests
- README/documentation
- comments and JavaDocs
- Git history/commits if available
- dead or unused code
- duplicated implementations
- compatibility layers
- version-specific Minecraft/Paper code

Do not judge based on superficial indicators such as formatting alone.

# PRIMARY OBJECTIVE

Determine whether the repository shows engineering behavior consistent with deliberate human software development or with prompt-driven/vibe-coded development.

The most important distinction is NOT:

"Does this code look clean?"

The important distinction is:

"Does this repository show evidence of a developer maintaining a coherent mental model of the system across files, abstractions, edge cases, lifecycle behavior, and architectural decisions?"

A well-prompted AI can generate clean-looking code.

Therefore prioritize deep structural evidence over visual code style.

# 1. ARCHITECTURAL COHERENCE

Study the architecture across the entire project.

Determine whether:

- responsibilities are divided intentionally
- abstractions solve real recurring problems
- services have clear ownership
- class boundaries make conceptual sense
- data flow is coherent
- dependencies flow in predictable directions
- architecture remains consistent across features
- similar problems are solved similarly
- initialization and shutdown lifecycle are deliberately designed
- abstractions appear to have evolved naturally with project requirements

Look for suspicious AI/vibe-coding patterns such as:

- Manager/Service/Handler classes created mechanically for everything
- unnecessary interfaces with only one implementation
- abstractions that add complexity without reducing duplication
- several architectural styles mixed together
- one subsystem using repositories, another directly accessing SQL, another using static managers
- duplicated architecture invented independently in different features
- over-engineering simple features
- under-engineering complex features
- classes that appear individually reasonable but do not form a coherent system

Explain specific examples.

# 2. CROSS-FILE CONSISTENCY

AI-generated projects often look convincing at the individual-file level but become inconsistent across the repository.

Search specifically for contradictions between files.

Examples:

- different naming conventions for the same concept
- inconsistent null-handling
- inconsistent UUID/player-name handling
- different date/time representations
- several unrelated configuration access patterns
- inconsistent permission checking
- different database access conventions
- multiple serialization strategies
- different approaches to asynchronous execution
- repeated utility logic instead of reuse
- inconsistent command error handling
- similar features behaving subtly differently
- duplicate constants
- duplicated validation rules
- APIs that expose methods nobody actually needs
- classes whose public APIs do not match how callers use them

Give concrete file/class/method references.

# 3. MINECRAFT/PAPER DOMAIN KNOWLEDGE

Evaluate whether the code demonstrates genuine understanding of Paper/Spigot/Bukkit behavior rather than merely knowing API syntax.

Inspect for correct handling of:

- Bukkit main-thread restrictions
- asynchronous database operations
- calling Bukkit APIs asynchronously
- scheduler usage
- player login/logout lifecycle
- plugin enable/disable lifecycle
- server reload behavior
- offline players
- UUIDs vs player names
- configuration reloads
- event priorities
- cancelled events
- listener registration
- command registration
- Adventure Components
- MiniMessage
- PersistentDataContainer
- ItemStack serialization
- inventories and inventory events
- entity lifecycle
- chunk loading
- memory retention of Player objects
- caching
- database connection lifecycle
- thread safety
- Folia compatibility claims, if any
- Paper version compatibility
- deprecated Bukkit APIs

AI-generated Minecraft plugins frequently contain code that is syntactically correct but misunderstands server lifecycle, concurrency, or API semantics.

Identify such cases carefully.

Distinguish between:

- an actual bug,
- questionable design,
- harmless style,
- deprecated but functional code.

# 4. CONCURRENCY AND ASYNC REASONING

This category is extremely important.

Analyze every asynchronous path.

Build a mental model of:

- which thread operations originate from
- which operations access Bukkit/Paper state
- database operations
- CompletableFuture chains
- scheduler transitions
- shared mutable state
- caches
- concurrent collections
- callbacks
- shutdown behavior

Look for "fake async" patterns, for example:

- wrapping code in CompletableFuture without understanding thread ownership
- asynchronous Bukkit API calls
- switching threads unnecessarily
- nested schedulers
- futures immediately joined or blocked
- async methods whose callers treat them synchronously
- race conditions ignored across classes
- concurrent collections used as a magical thread-safety fix
- inconsistent use of synchronized
- ExecutorServices never shut down
- thread pools created unnecessarily

Strong concurrency reasoning can be evidence of deliberate engineering.

Superficially sophisticated but logically broken async code can be evidence supporting vibe coding.

# 5. ERROR HANDLING

Inspect error handling across the repository.

Look for:

- catch(Exception e) everywhere
- swallowed exceptions
- repetitive try/catch blocks
- e.printStackTrace()
- excessive generic logging
- log messages that provide no operational context
- inconsistent exception strategies
- impossible fallback branches
- null returned after failures without documented semantics
- defensive checks for states that cannot occur
- missing handling of states that realistically CAN occur

Also identify unusually verbose defensive programming that appears mechanically generated.

# 6. NULL SAFETY AND IMPOSSIBLE CHECKS

AI-generated code frequently adds defensive checks without understanding actual invariants.

Search for:

- null checks on values guaranteed non-null by API contracts
- repeated Objects.requireNonNull() without architectural purpose
- checks for impossible enum values
- redundant containsKey() followed by get()
- optional wrapping/unwrapping without benefit
- validation repeated at multiple layers
- null fallbacks that mask real bugs

Conversely, find important places where nullability actually matters but is ignored.

# 7. COPY-PASTE / TEMPLATE FINGERPRINTS

Search for structural repetition.

Do NOT merely count duplicated text.

Look for conceptual duplication such as multiple classes with the same skeleton:

1. validate
2. fetch service
3. try
4. log
5. send message
6. catch Exception

Identify:

- repeated switch structures
- nearly identical CRUD methods
- duplicated command handlers
- duplicated event logic
- getters/setters produced mechanically
- classes with suspiciously uniform method ordering
- repeated comments with identical grammar
- repeated validation boilerplate

Determine whether repetition looks like normal domain boilerplate or prompt-generated templating.

# 8. COMMENTS AND JAVADOC FORENSICS

Analyze comments carefully but do NOT assume comments prove AI usage.

Look for:

- comments explaining obvious Java syntax
- JavaDocs that simply restate method names
- excessively formal documentation for trivial private methods
- inconsistent documentation density
- verbose comments on simple code but no comments around genuinely difficult logic
- generic phrases such as:
  "Ensures that..."
  "Handles the..."
  "Retrieves the..."
  "Processes the..."
  when they add no information
- comments describing implementation rather than intent
- comments apparently generated in batches

Compare documentation quality to actual implementation complexity.

A human developer often documents unusual constraints and historical reasons.

AI frequently documents obvious behavior.

# 9. NAMING FORENSICS

Evaluate naming across the whole repository.

Look for:

- generic names such as Manager, Handler, Processor, Helper, Util, Service
- several classes with overlapping responsibilities
- excessively descriptive method names
- mechanical naming consistency that does not reflect domain meaning
- terms changing across features
- concept synonyms used inconsistently

For example:

VipManager
VipService
VipHandler
VipProcessor

may indicate unclear ownership if responsibilities overlap.

Do not consider generic names suspicious by themselves. Evaluate them in architectural context.

# 10. CODE COMPLEXITY DISTRIBUTION

Compare complexity across the repository.

AI/vibe-coded projects often have strange complexity distribution:

- trivial features receive elaborate abstraction layers
- difficult business logic appears as giant methods
- utility classes become dumping grounds
- simple DTOs have extensive validation
- important lifecycle code receives minimal attention

Identify where engineering effort appears disproportionately allocated.

# 11. DEAD CODE AND ABANDONED DESIGNS

Search for:

- unused classes
- unused methods
- unused configuration keys
- unused dependencies
- interfaces with no meaningful reason
- old systems left alongside replacements
- abandoned abstractions
- unreachable branches
- commented-out implementations
- compatibility methods nobody calls

Vibe coding often produces abandoned approaches because each prompt introduces another solution instead of refactoring the previous one.

Determine whether the repository contains evidence of this accumulation.

# 12. CONFIGURATION DESIGN

For Minecraft plugins specifically, deeply evaluate config architecture.

Inspect:

- config.yml
- messages.yml
- GUI configs
- storage configs
- permissions
- placeholders
- feature toggles

Determine whether configuration options form a coherent user-facing system.

Look for:

- keys referenced incorrectly
- unused config values
- duplicated defaults inside Java
- hard-coded values despite config options
- config paths inconsistent across classes
- runtime reload problems
- missing migration strategy
- unsafe casts
- assumptions about configuration sections
- default values differing between documentation and implementation

Good configuration architecture can indicate strong domain awareness.

# 13. DATABASE/PERSISTENCE ANALYSIS

If persistence exists, analyze:

- schema design
- indexes
- transactions
- migrations
- connection pooling
- query construction
- SQL injection safety
- resource closing
- batching
- caching
- async behavior
- consistency guarantees
- failure recovery

Look for AI-style "enterprise-looking" abstractions that provide little practical value.

Also look for simplistic persistence code that ignores real server conditions.

# 14. API DESIGN

If the plugin exposes an API, inspect whether it looks designed for actual consumers.

Ask:

- Are methods cohesive?
- Are implementation details leaked?
- Are mutable collections exposed?
- Are lifecycle guarantees clear?
- Can API consumers misuse it easily?
- Are events provided where appropriate?
- Are APIs versionable?
- Are methods present that no real consumer would need?

AI frequently generates APIs based on what "looks like an API" rather than actual usage requirements.

# 15. SECURITY AND TRUST BOUNDARIES

Review:

- command permissions
- administrative actions
- player-supplied strings
- SQL parameters
- console commands
- item/voucher verification
- serialization
- filesystem access
- network calls
- secrets
- config credentials
- plugin messaging

Look for security checks that exist cosmetically but can be bypassed because the overall trust model was not understood.

# 16. DEPENDENCY USAGE

Inspect dependencies.

Identify:

- libraries imported but barely used
- libraries used for functionality easily implemented directly
- multiple libraries solving the same problem
- dependency versions that conflict
- shaded dependencies that may break runtime behavior
- libraries seemingly added because AI suggested them

Compare the sophistication of dependency selection to the rest of the codebase.

# 17. VERSION COMPATIBILITY CLAIMS

If the plugin claims compatibility with multiple Minecraft/Paper versions, verify whether the implementation actually supports them.

Inspect:

- API calls introduced in newer versions
- removed/deprecated APIs
- reflection/version adapters
- plugin metadata
- dependency versions
- NMS usage
- Adventure API assumptions

A README saying "1.8-1.21 supported" is not evidence of real compatibility.

# 18. TESTING STRATEGY

If tests exist, evaluate whether they test meaningful behavior.

Look for:

- tests that merely assert getters/setters
- mocks that reproduce implementation rather than test behavior
- tests that never test Minecraft-specific failure conditions
- mechanically generated tests
- unrealistic test coverage

If there are no tests, do not automatically classify the project as AI-generated because many Minecraft plugins have no tests.

# 19. BUILD SYSTEM FORENSICS

Analyze Maven/Gradle files.

Look for:

- unnecessary plugins
- duplicate dependencies
- inconsistent Java versions
- suspiciously broad repositories
- incorrect shading
- broken relocation
- unused annotation processors
- excessively elaborate build configuration relative to project size
- README instructions contradicting actual build configuration

# 20. TEMPORAL / DEVELOPMENT FINGERPRINTS

If Git history is available, analyze development behavior.

This is potentially stronger evidence than code style.

Inspect:

- commit sizes
- commit frequency
- massive feature dumps
- complete subsystems appearing in one commit
- repeated rewrite cycles
- naming changing abruptly
- architecture changing without migrations
- dozens of unrelated changes bundled together
- commit messages
- fix patterns

Possible vibe-coding fingerprints include repeated sequences such as:

feature generated → compilation fix → runtime fix → edge-case fix → another architectural rewrite

However, do NOT treat this pattern as conclusive because humans can work this way too.

If Git history is unavailable, clearly state that this evidence category cannot be evaluated.

# 21. "LOCAL QUALITY VS GLOBAL QUALITY" TEST

This is one of the most important analyses.

For each major subsystem, compare:

LOCAL QUALITY:
Does an individual method/class look polished?

GLOBAL QUALITY:
Does that class make sense inside the complete system?

AI-assisted repositories may contain many locally impressive classes while the global architecture contains contradictions.

Give this category significant weight.

# 22. INTENTIONAL IMPERFECTIONS VS RANDOM IMPERFECTIONS

Experienced human-written systems often contain compromises that make sense historically:

- optimized hot paths
- ugly compatibility code
- shortcuts documented by context
- specialized helpers built around actual requirements

Vibe-coded systems may instead contain inconsistencies without an understandable reason.

Try to determine whether imperfections appear to result from deliberate tradeoffs or disconnected implementation episodes.

# 23. SEMANTIC BUG HUNT

Actively search for bugs that compile successfully but reveal weak understanding.

Prioritize:

- race conditions
- lifecycle bugs
- stale cache state
- memory leaks
- incorrect event assumptions
- async Bukkit access
- incorrect OfflinePlayer handling
- inventory duplication possibilities
- command parsing edge cases
- inconsistent persistence
- reload bugs
- item serialization issues
- timezone/duration bugs
- incorrect permission inheritance assumptions

These are substantially more informative than formatting style.

# 24. HUMAN-SPECIFIC SIGNALS

Search for evidence suggesting deliberate human authorship, such as:

- compact solutions tailored precisely to project constraints
- unusual but justified optimizations
- domain-specific abstractions
- meaningful internal terminology
- consistent design decisions maintained across distant parts of the repository
- comments explaining WHY a strange workaround exists
- careful handling of obscure Paper/Bukkit behavior
- API design clearly shaped by real usage

Explain these signals rather than ignoring them in favor of AI indicators.

# 25. AI-ASSISTANCE SIGNALS

Search for patterns consistent with AI-assisted development, including:

- excessive scaffolding
- generic abstractions
- repetitive validation
- verbose trivial documentation
- redundant helper methods
- multiple ways of solving identical problems
- implementation that appears correct superficially but fails deeper invariants
- overly defensive local code paired with weak global reasoning
- enormous classes generated around isolated feature requests
- methods that anticipate unrealistic edge cases while missing common ones
- features that look like separate prompts stitched together

Again, none of these individually proves AI usage.

# FALSE-POSITIVE CONTROL

Before making your conclusion, explicitly challenge your own hypothesis.

For every major piece of evidence suggesting AI/vibe coding, ask:

"Could an ordinary junior or rushed human developer plausibly produce this?"

For every major piece of evidence suggesting human authorship, ask:

"Could a capable LLM produce this if given strong prompts and iterative feedback?"

Do not reward clean code automatically as human.

Do not label bad code automatically as AI.

Do not label verbose code automatically as AI.

Do not label modern architecture automatically as AI.

Do not label common Minecraft boilerplate as AI.

# REQUIRED SCORING SYSTEM

Give scores from 0-10 for each category:

1. Architectural coherence
2. Cross-file consistency
3. Domain understanding
4. Concurrency correctness
5. Lifecycle awareness
6. Error-handling quality
7. Abstraction quality
8. Configuration design
9. Persistence/database design
10. API design
11. Security reasoning
12. Dependency discipline
13. Documentation authenticity
14. Naming consistency
15. Code reuse/refactoring quality
16. Edge-case reasoning
17. Global system coherence
18. Evidence of deliberate engineering
19. Evidence of prompt-by-prompt construction
20. Evidence consistent with AI generation

For the last two AI-related categories:

0 = almost no evidence
10 = extremely strong evidence

# FINAL CLASSIFICATION

At the end, provide estimated probabilities adding up to exactly 100%:

Experienced human-written: X%
Junior/intermediate human-written: X%
Human-written with moderate AI assistance: X%
Primarily AI-assisted / vibe-coded: X%
Nearly fully AI-generated: X%

Then give:

AI/VIBE-CODING LIKELIHOOD:
XX / 100

CONFIDENCE IN THIS ESTIMATE:
XX / 100

These are different values.

Example:

AI/Vibe-Coding Likelihood: 78/100
Confidence: 61/100

A high AI likelihood with low confidence is acceptable when evidence is ambiguous.

# EVIDENCE TABLE

Create a table with:

| Evidence | Location | Supports AI/Vibe Coding | Supports Human Coding | Strength | Explanation |

Strength must be:

- Weak
- Moderate
- Strong
- Very Strong

Include at least 15 meaningful pieces of evidence if the repository is large enough.

Do not fill the table with superficial formatting observations.

# STRONGEST EVIDENCE

Provide separate sections:

## Top 5 strongest indicators of AI/vibe coding

For each:
- exact file/class/method
- what you observed
- why it matters
- plausible human explanation
- evidence strength

## Top 5 strongest indicators of deliberate human engineering

Use the same structure.

# SUSPICIOUS CODE EXAMPLES

Quote small relevant snippets where necessary and explain the reasoning.

Prefer semantic/architectural examples over formatting examples.

# BUGS DISCOVERED

Separately list actual engineering problems discovered during the analysis.

Classify each as:

CRITICAL
HIGH
MEDIUM
LOW
INFORMATIONAL

Do NOT treat every bug as evidence of AI generation.

# FINAL VERDICT

Finish with a concise forensic verdict answering:

1. Does this repository look predominantly human-engineered or prompt-engineered?
2. Does it appear to have a coherent developer behind the architecture?
3. Does it look like one developer maintaining a mental model of the entire project, or many isolated feature prompts stitched together?
4. Which parts look most human-designed?
5. Which parts look most likely AI-generated?
6. What is the strongest single piece of evidence?
7. What additional evidence would increase confidence?

Be skeptical, technical, and evidence-driven.

Do not try to be polite to the author.

Do not exaggerate certainty.

Do not infer AI authorship solely because the code is bad.

Do not infer human authorship solely because the code is good.

Your job is forensic software analysis, not style criticism.

Start by mapping the repository architecture before giving any verdict.

Yapay zeka mı değil mi öğrenin yapay zekaysa ve bunu kodlayan kişinin github'ına bakın ne kadar özenli tasarımları tanıtımları vs. bunlara göre kafadan bir değerlendirme yapabilirsiniz veya spigotmc, modrinth gibi yerlerde kaç indirme almış kaç yorum almış insanlar ne yorum yapmış veya builtbybit'te kaç adet satış yapmış? Bunlara bakarak karşısınızdaki kişinin güveniliriğini değerlendirin örnek olarak.

Genişletmek için tıkla ...