Copilot Yanılgısı - The Copilot Delusion

• Yapay zeka kodlama araçlarının gerçekten geliştirici üretkenliğini artırdığı inancı bir yanılgıdır
• Bu araçlar programlamanın keyfini ve insanın derin kavrayışını zedeler
• Yapay zeka tekrarlayan kod üretiminde işe yarasa da bağlam, performans ve nüans konularında zayıftır
• Aşırı bağımlılık, geliştiricinin öğrenme ve keşfetme isteğini ve kod kalitesini düşürür
• Programcılık mesleğinin özü, yapay zeka kolaycılığı yüzünden yavaş yavaş ortadan kalkmaktadır

---

Giriş: Yapay zeka kodlama araçlarına dair yanılgı

• Bu yazı, Mayıs 2025 itibarıyla yapay zeka kod üretim araçlarının gerçek durumunu ele alıyor
• Yapay zekanın yetersizliği hakkındaki tartışmalar zamanla zayıflayabilir; ancak programlamanın özünün ve keyfinin aşınması sorununun daha da ağırlaşması bekleniyor

1. Bölüm: İş arkadaşım, programcı

• Yazar, gerçekte sorumsuzca kod kopyalayıp yapıştıran profesyonel olmayan geliştiricilerle çalışma deneyimini örnek vererek, bu tür ekip arkadaşlarının geride bıraktığı performans düşüşü / hata bombaları / mimarinin hiçe sayılması sorunlarını vurguluyor
• Bu tür kişiler sürekli olarak test, profiling ve bağlam anlayışı olmadan kodu değiştiriyor; sonunda da ekibin motivasyonunu ve öğrenme isteğini törpülüyor
• "Captain Obvious" şeklindeki ters köşe itirafla, aslında bu tasvirin GitHub Copilot, Claude Codex gibi yapay zeka kodlama araçlarına yönelik bir taşlama olduğu açıklanıyor
• Gerçek bir uçak yardımcı pilotu (copilot), tüm sistemi anlar, iş birliği yapar ve sorumluluk taşır. Buna karşılık yapay zeka Copilot'lar, özsel kavrayış olmadan yalnızca yüzeysel kod bırakır
• "Copilot" adını ödünç alarak, üretkenlik ve inovasyon görüntüsü altında her geliştiricinin IDE'sine zorla sokuluyor

2. Bölüm: Copilot'un avantajları

• Yapay zeka kodlama araçları da tamamen işe yaramaz değildir
• Yeni başlayanlar için C++ gibi dillerin karmaşık söz dizimini öğrenmede ya da kavramlara hızlıca göz atmada faydalıdır
• Beyin fırtınası, bağlamı toparlama, tekrar eden şablon kodlar gibi işlerde bir insan stajyerden daha hızlı olabilir ve daha az hata yapabilir
• Performans ve verimlilik konusunda hiçbir kaygı taşımaması, çevresel denetim olmadan bırakıldığında üretim kalitesinde felakete yol açma riskini açıkça barındırır
• Bağlamdan yoksun scaffold/taslak kodu hızlıca sunabilir; ancak tam tasarım ve ince ayar insan geliştiricinin işidir

3. Bölüm: Geliştirici olarak ben ve yapay zeka

• Yazar, "kod yazmanın kendisinden alınan keyfi" ve bir şeyi kendi eliyle üretmenin tatminini önemser
• Tekrarlayan kodu (boilerplate) yapay zekaya bırakıp kütüphane/makro yazmayı da terk ederseniz, sonunda geliştiricinin yaratıcılığı ve içsel motivasyonu ortadan kalkar
• FOMO (geri kalma korkusu) yüzünden Copilot'a bel bağlayarak kaba ve doğrulanmamış kodu hızla üretme eğilimi ortaya çıkıyor
• Yapay zekaya bağımlılık, gerçek öğrenme ile düşük seviye performans ve yapı anlayışı ve kod kalitesi yönetimi fırsatlarını elinizden alır
• "Copilot" adı, eşit bir çalışma arkadaşından çok, kısa deneyimli bir oyuncunun uçağı kullanabileceğini sanması gibi bir yanılsamadır

4. Bölüm: Bilgisayar bir makinedir

• Makinenin (donanımın) gerçekliği, yapısı ve performans özelliklerini anlama yeteneği insana özgüdür
• Yapay zekanın gerçek cache miss'ler, memory layout, profiling ve performans darboğazları konusunda doğrudan sezgisi ya da deneyimi yoktur
• Yapay zekanın verdiği yanıtlar bağlamdan kopuktur ve somut optimizasyon gerektiren alanlarda işe yaramaz
• Ne kadar sıradan bir CRUD uygulaması geliştiriyor olursanız olun, geliştirici kullanıcıya ve sisteme karşı özenli ve dürüst olmalıdır
• Uzmanlık ve zanaatkârlık, doğrudan deneyim, zorluk ve tekrarlanan iyileştirme ile oluşur

5. Bölüm: Sonuç

• Yapay zeka kodlama araçları ve bunların erişilebilirliği, hacker ruhunun silinmesine yol açıyor
• Gerçek kod, yapı ve performansla ilgilenmeyen pasif kullanıcıların sektörde kalıcı hâle gelmesi ihtimalinden endişe ediliyor
• Geçmişte gece boyunca IRC, donanım deneyleri, düşük seviye keşifler gibi şeylerle saf merak ve yaratıcılık doluydu
• Şimdi ise geriye yalnızca "AI patch inceleme" etrafında dönen mekanik iş ve ilgisizlik kalıyor
• Bağlam anlayışı ve gerçek yetenekten yoksun kod üretiminin sektör standardı hâline gelmesi ve gerçekten yetkin kişilerin dışlanması tehlikesine karşı uyarıyor

Metin düzenleme geçmişi

• Yazım tarihine ilişkin bir açıklama eklendi
• HN görüşleri yansıtılarak performans eleştirisinin kapsamı (karmaşık sistemler vs CRUD) hakkındaki tutum netleştirildi
• Okunabilirliği artırmak için cümle üslubu ve bazı simgelerin kullanımı kısmen düzenlendi

[roxie]

Yazı eğlenceli ama, çok fazla yazının “yapay zekayı kullanmamak her derde deva değil ama öte yandan ona körü körüne güvenip ona göre şekillenmek de iyi değil” diye özetlenebiliyor olması biraz yorucu geliyor..

[ifmkl]

LLM'ler ve yapay zeka zaman geçtikçe gelişiyor. Sadece birkaç ay önce, söylendiği gibi kodun tutarlılığı gibi şeyleri beklemek neredeyse zordu; ama artık o çalışma alanında AI'dan ilk kurulum için istenen kodları dosya olarak yüklemesini isteyip, yeni kod yazarken her zaman mevcut kod stiline uyarak yazması yönünde talimat vererek kullanınca oldukça tutarlı kod üretebildiğini gördüm.

[crawler]

> Yazanın önceki gönderilerine bakınca oyun geliştiricisi gibi görünüyor.
> Oyun geliştirme bilgisi ya da kaynakları LLM’ler tarafından büyük ölçekte öğrenilemediği için, CRUD uygulama vakalarından farklı olarak metnin yazarı LLM’in sınırlarını daha net hissediyor gibi.

Baştan sona okudum; sonuçta tam da bu yüzden yazarın biraz önyargılı bir bakış açısına sahip olduğunu düşünüyorum.
Elbette, metindeki gibi yapmak neredeyse ders kitabı niteliğinde bir yaklaşım olduğu için doğru,
ama yapay zekanın öğrenecek çok veriye sahip olduğu CRUD ve frontend tarafında zaten fazlasıyla iyi iş çıkardığını düşünüyorum.
Kendi alanınız içinde onu mümkün olduğunca iyi kullanmak gerekiyor gibi görünüyor.

[superscv]

Yazarın kastettiği anlamı anlamada biraz yanlış anlama yok mu diye düşünüyorum.
Yazarın odağı, yönettiği projenin performansı, kararlılığı ve bakımının kolay olması için uygun mimari ile kod tutarlılığı gibi konular; özellikle de mimari ve kod tutarlılığı, mevcut LLM'lerin gerçekten çok kötü olduğu alanlardan biri.

Özellikle web tarafı, geliştirici girişinin çok olduğu ve "nasıl olsa çalışsın yeter" anlayışının güçlü olduğu bir alan olduğu için, çok düşük kaliteli kodlar fazlasıyla dağıtıma çıkmış durumda. LLM'ler de bunlar üzerinden eğitildiğinden, ürettikleri çıktının kalitesi şaşırtıcı derecede düşük oluyor.

Basitçe, GPT'ye "bunu web frontend'e koyacağım, bana js ile quicksort algoritmasını yazar mısın" diye istekte bulunun. Çıktıdaki sorunları fark edemiyorsanız, bu konuşmanın çok da bir anlamı olmadığını düşünüyorum.

[ohnul]

Merhaba. Merakımdan "web front-end'e koyacağım ama bana js ile quicksort algoritmasını biraz uygular mısın" diye sordum. Ancak benim görebildiğim kadarıyla sorunun ne olduğunu anlamak pek kolay değil. Söyleyebilirseniz çok yardımcı olur. Şimdiden teşekkürler. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd

[ohnul]

Sanırım bağlantı düzgün çalışmıyor, o yüzden yeniden deniyorum. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e

[superscv]

Eklediğiniz ikinci quickSortInPlace() de yavaş bir implementasyon.

Aşağıdaki kodu çalıştırın.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});

[superscv]

Temelde koleksiyonların oluşturulması, işletilmesi ve birleştirilmesinin yüküne hiçbir empati göstermeyen bir kod olduğu söylenebilir. C++ açısından bakarsak, yaklaşık 10 yıl önce bile MoveConstructor için öneriler/uygulamalar ortaya çıkmıştı ve bellek kopyalamayla ilgili yük konusunda her zaman son derece hassas olmak en temel ilkelerden biridir. quick sort, mekanizması gereği tüm değerlerin index'ini belirleyebilen bir algoritmadır ve her alan için random access sağlanması daha iyidir.

Maniak düzeyde optimizasyon yapmadan bile yalnızca yukarıdaki noktaları uygularsanız, paylaştığınız bağlantıdaki yöntemle arasında 2 kattan fazla performans farkı oluşur.

[dudlf016]

Doğrudan çalıştırıp denedim; biraz daha yavaş olma eğilimi var ama 2 kat kadar değil gibi görünüyor.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left >= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j < right; j++) {  
        if (arr[j] < pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length <= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i < arr.length - 1; i++) {  
        if (arr[i] < pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length <= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el < pivot) left.push(el);  
        else if (el > pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo >= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Tail‑recursion elimination: önce daha büyük partition'ı stack'e ekle  
        if (pivotIndex - 1 - lo > hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) >= 0 ? a  
        : (b - a) * (c - b) >= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) >> 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] < pivotValue) lo++;  
        while (arr[hi] > pivotValue) hi--;  
  
        if (lo >= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i < arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i < repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i < repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // Virgülden sonra 2 basamağa kadar  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();  

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3

[superscv]

Ah.. ne demek istediğinizi anladım. Neyi neyle karşılaştırmak gerektiğini anlayamamışsınız.... quick sort algoritmasının quicksort ve in-place olmak üzere iki farklı uygulama biçimi yoktur......

Benim asıl sorun ettiğim şey, en baştan Array birleştirme yerleşik olan, yukarıdaki kodda yer alan quickSortGPT() ve quickSort()'u (ikisi de GPT'nin ürettiği koddur) yazıp bunu yapay zeka kullanıcılarına sunmalarıydı.

[dudlf016]

GPT’nin yanıtında hem quickSort hem de quicSortInPlace var ve yorumlarda [...,quickSort(left), ...equal, ...quickSort(right)] kısmına dikkat çekildiği için, quickSortun quickSortlarla, quickSortInPlace’in de quickSortInPlacelerle karşılaştırılması gerektiğini anlamıştım ama öyle değilmiş sanırım.

[superscv]

“quickSort, quickSort’larla olur” sözü karşısında insanın ense kökü tutuluyor.

[superscv]

Yazıyı okurken lütfen bağlamı mutlaka kontrol edin.

Şu anda kendi kodlama becerimle övünmüyorum. Şu anda örnek olarak kullanılan quickSort() gibi vasat kodların GPT tarafından yüksek öncelikle üretiliyor olmasını eleştiriyorum.

GPT’de birkaç kez arama yaptığınızda, yalnızca quickSort() fonksiyonu sonucunu veren durumların çok olduğunu görürsünüz; ayrıca quickSort() sadece bir örnektir. İş amaçlı olarak GPT’den kod istediğinizde kalite seviyesi çok düşük kodlar sıkça üretiliyor (ücretli kullanıcı deneyimime göre). Geliştiricinin bunu ayırt edebilme yeteneği eksikse, projenin bozulacak bir yöne gitme olasılığının yüksek olduğu yönündeki asıl yazı yazarının görüşüne katıldığım için bu bağlama kadar geldik.

Şimdiden çevremde bu tür vasat kodlarla sıvanmış projelerin sayısı durmadan artıyor.

[superscv]

Elbette karşılaştırma, quickSort() ve quickSortInPlace() fonksiyonlarının performans karşılaştırması olmalı........

[superscv]

???? Sonuçlarda 2 katı aşan, hatta 3-4 kata varan farkların olduğu bir çıktıyı paylaşıp sonra da bunun 2 kata kadar bile olmadığını söylemek ne demek?

[superscv]

return [...quickSort(left), ...equal, ...quickSort(right)];

Kodun bu kısmını iyice durup düşünün.

[roxie]

Çok şey öğreniyorum

[ohnul]

Cevabınız için teşekkürler!

[crawler]

Öncelikle, benim söylediğim "alan içinde yapay zekadan yararlanma" konusunda tasarım ve koordinasyonun insan tarafından yapılması zaten son derece doğal...
Aslında bu, eskiden olsa neyse de artık herkes LLM'lerin sınırlarını bildiği için o kadar bariz bir nokta ki ayrıca söylemeye bile gerek yok sanırım.

Bir de bahsettiğiniz, geliştirme bilgisi olmayan sıradan insanların LLM kullanması durumu var.
Bunu ne ana yazı, ne Hacker News, ne de ben söylemiş gibi görünüyoruz ama her hâlükârda bu durumda da kullanıcıların sonuçtan memnun kalacağı bir seviyeye gelinmiş durumda.
Aksi olsaydı Bolt.new, v0 ve hatta Cursor bugünkü değerlendirmeyi alıyor olmazdı diye düşünüyorum.

[superscv]

Özet,

Yazar: Geliştiriciler yeteneklerini kendileri geliştirmeli ve korumalıdır. Hatta yapay zeka o kadar da iyi çalışmıyor.

crawler: Ha? Bende gayet iyi çalışıyor?

superscv: Çok sorun var...

crawler: İyi ayarlayıp kullanmak lazım

superscv: Sanırım en başta yazarın vermek istediği mesajdan fazla uzaklaşıldı..

[crawler]

Yazarın alanından neden bahsettiğimi ve kişinin kendi domaini denince ne kastedildiğini pek anlamamışsınız gibi görünüyor.
Kendi düşüncesi olmadan tüm kararları yapay zekaya devretmek de akıllıca görünmüyor,
ama bunun tam karşısında duran insanları da pek anlayamıyorum.

Son olarak sormak istediğim şu: superscv, kodlama yaparken LLM'i nasıl kullanmanın iyi olacağını düşünüyorsunuz, merak ediyorum.

[superscv]

Normalde pek yorum yazmam ama özellikle bu yazıya yorum bırakmamın nedeni, yazarın düşüncelerine oldukça katılıyor olmam. Önemli olan AI ya da LLM’ler değil; hangi ortam gelirse gelsin, geliştirici olarak "ben"in hazırlıklı olması gerektiğini düşünüyorum.

LLM’ler, eğitildikleri kaynakların doğası gereği, çoğunlukla dünya geneline yayılmış çevrimiçi verilerin ortalamasına yakın çıktılar sunuyor. (Az önceki js quicksort örneği bunu kanıtlıyor.) Bu yüzden genelde onları, fikir/tasarım açısından genel bakışla ne kadar örtüştüğünü ya da nerede ayrıştığını görmek ve şimdiye kadar kime soracağımı bilemediğim şeyleri sormak için çok kullanıyorum.

[superscv]

Ek olarak daha fazla konuşmanın ne anlamı olduğunu pek bilmiyorum.

En başta, yapay zekanın ürettiği kodun bazı risk unsurları taşıyabileceği için onu iyi süzüp uygun şekilde kullanmanın iyi olacağı yönünde bir görüşse, yazarın yazısında hangi düşüncenin yanlı olduğunu açıklamanız yeterli olur diye düşünüyorum. Özet metinde de "bağlamdan yoksun scaffold/taslak kodu hızlıca sağlayabilir, ancak tam bir tasarım ve ince ayar insan geliştiricinin sorumluluğudur" şeklinde benzer bir anlam taşıyan içerik var.

[superscv]

Yazarın mesajı biraz sert olma eğiliminde olsa da, yazıyı dikkatlice okursanız bunun "AI kullanmayın" demek olmadığını görürsünüz. AI’ın nasıl kullanılacağına dair öneriler var ve asıl vurgu, geliştiricinin kendi yetkinliğinin eksik olmaması gerektiği mesajında.

Yazarın mesajı neden sert geliyor diye bakarsak, copilot ile geliştirme yapılabilir hale gelecek (yani copilota geliştirme açısından yüksek düzeyde bağımlılık taşıyan bir nüans) şeklindeki bakışa karşı geliştirilmiş bir perspektiften bu mesaj kurulmuş. Bu yüzden geliştiricilere, kendi varlık değerlerine zarar veren bir tutum benimsemeyin şeklinde mesajını şekillendirmiş.

Yazarın mesajı da "AI kullanmayın" olmadığı için, sonuçta AI’dan yararlanılacaksa bu bir yerlerde uzlaşma noktasına varacaktır; dolayısıyla az önce verdiğiniz yanıtla genel mesaj kabaca benzer hale gelmiş gibi görünüyor.

Ancak ilk yazdığınız içerikteki "önyargılı bakış açısı" ifadesine katılmakta zorlandığım için önce yanıt verme gereği duydum.

[GN⁺]

Hacker News görüşleri

• Eğer kalp pili, füze güdüm sistemi ya da M1 tankına girecek yazılım gibi kusursuz derecede sağlam olması gereken yazılımlar yapmak istiyorsanız, AI kodlama ajanlarını bir kenara bırakıp işi kendiniz öğrenmeniz gerekir
  Ama çoğumuz böyle şeyler yapmıyoruz; şeması biraz farklı, entegrasyon biçimi biraz değişik, neredeyse aynı gereksinimlere sahip CRUD uygulamaları üretiyoruz
  Aslında çoğumuzun yaptığı yazılımda yeni bir şey yok
  Çoğu zaman mevcut bilgiyi yeniden kullanmak en iyi seçenek
  Benim için kodlama ajanları, geçmişteki kod yeniden kullanımının devasa bir versiyonu
  Ek olarak, ironik biçimde bu yazının kendisi de AI yazmış gibi hissettirdi

  • Ben zaten görev açısından kritik düşük seviye kod yazmak istemiyorum
    AI araçlarının yazarın düşündüğü kadar koşulsuz faydalı olduğunu düşünmüyorum ama “C ile sistem programlama yapmıyorsan programcı değilsin” tarzı tartışmalardan da bıktım
    Frontend kodlama yapmayı seviyorum
    Düşük seviyeli grafik kütüphanelerini kendim yazmak da istemiyorum
    Gece yarısı aydınlanma yaşayıp hack yapan tiplerden değilim ama işime tutkuyla bağlıyım ve gurur duyuyorum
    Herkesin yazar gibi bu kadar uç bir yaklaşım benimsemesi gerektiğini düşünmüyorum
    Yazılım pazarında çeşitlilik olması gerektiğine inanıyorum

  • Yazarın iddialarına karşı çıkmak sorun değil ama bu yazının AI tarafından yazıldığını söylemek ağır kaçıyor
    Yazar; canlı anlatım, güçlü benzetmeler ve gerçekten komik mizahı kendi üslubuyla metnin tamamına yedirmiş
    Böyle bir yazıyı bugün bir LLM'in yazması gerçekten zor
    Bu AI değil, iyi yazılmış bir metin
    Argümanlarına katılın ya da katılmayın, kalemi güçlü

  • Orijinal metinde şöyle bir bölüm de var
    “Uçakları havada tutan kodu, insan hayatıyla doğrudan ilgili kodu muhtemelen siz yazmayacaksınız. Çoğu insan da yazmayacak. Ama sadece basit CRUD uygulamaları yamalayıp duran bir enterprise ortamında çalışıyor olsanız bile, kullanıcıya karşı saygı ve onuru koruma sorumluluğunuz var.”
    Ne kadar basit olursa olsun yazılımın asgari düzeyde sorumluluk gerektirdiğini vurguluyor

  • Aslında yazar da AI'ın faydalı olduğu bazı örnekleri kabul ediyor
    Yazarın asıl derdi, AI'a “copilot” dememiz ve yeni başlayanların buna gereğinden fazla güvenebilmesi
    Gerçek bir copilot deneyimli ve eşit düzeyde bir ekip arkadaşı olmalı, ama AI şu anda yarı yarıya berbat bir ekip arkadaşı
    “Şu anda merakı ve inisiyatifi sistemin dışına koyuyoruz. Normalde gelişme potansiyeli olan insanlar AI patch set'lerini inceleyerek heveslerini kaybediyor. Terminal bir spreadsheet'e, debugger da bir tabuta dönüşüyor.”
    Ama AI da sonuçta bir soyutlama türü
    İnsanlar otomasyon GC (garbage collector) gibi olağan hale geldiğinde temel bilgilerin kaybolacağından nasıl endişe ediyorsa, AI için de en temel programlama/öğrenme becerilerinin zayıflayabileceği kaygısı var
    Web geliştiricileri soyutlamalar sayesinde stack'in derin yapısını bilmeden de çoğu zaman iyi siteler yapabiliyor
    Ama AI'ın soyutlaması çok delikli; gerçekten temel bilginiz olmadan da bir şeyleri bir ölçüde çalıştırmanız mümkün
    Sorun şu ki bir noktada ciddi hataların gizlendiğini fark ediyorsunuz ve debugging, problem çözme, kendi başına öğrenme gibi alanlarda AI insanın yerini alamıyor
    Bu yüzden AI ile öğrenmek kolaylaşırken önemli temel yetkinliklerin atlanabileceği endişesi var
    Sonuçta gerçek öğrenme; tekrar ederek ve doğrudan uğraşarak gelişmekten geliyor
    AI eğer “öğrenme”nin kendisini bile soyutlarsa, uzun vadede geliştirici yetkinliğini zayıflatabilir
    Elbette sadece AI kullanıyor diye herkes aptallaşacak değil; kendi inisiyatifiyle öğrenen insanlar yine olacaktır
    Ama genel olarak bu oranın düşmesi muhtemel
    Çünkü özellikle yeni başlayanlar için “kendi düşünerek üretme” deneyiminin kendisi ortadan kalkabilir
    Ve AI denen bu soyutlama sonuçta çok kusurlu
    Yeni başlayan birinin gözünde AI her şeyi yapıyor gibi görünse de, özünde programlama ve debugging yeteneği yine gerekiyor
    O yüzden AI'ın ürettiği koddaki sorunları gerçekten yakalamak istiyorsanız, mutlaka beceri biriktirmeniz gerekiyor
    Ben de AI kodlama yardımcılarını oldukça iyi kullanıyorum
    Ama eksileri de var; bu yüzden her şeyi sadece iyi tarafıyla görmek doğru değil, benim vardığım sonuç bu

  • Google Whisk ile kendi kısa komedi videomu yapıp TikTok'a yüklemeyi denedim; bir baktım, ortalık AI üretimi içerik ve birbirini kopyalayan videolarla dolu
    “Orijinal yaratıcılık”ta gerçekten özel bir şeyler olduğuna inanmak istedim ama sonunda çok kolay yeniden üretilebilen varlıklar olduğumuz ortaya çıkıyor
    Biz her gün kodlama videoları çekip TikTok'a atsak bile, sonsuza dek aynı uygulamaların tekrarını görürüz
    Elon Musk'ın dediği gibi artık geriye gerçekten Mars'a gitmek kalmış gibi
    İki yıl önce de LLM'lerin o kadar çok “halüsinasyon” üretmediğini söylemiştim; insanlar hâlâ insana kesin ihtiyaç olduğuna inanıyor ama ben bunun giderek daha az doğru hale geldiğini düşünüyorum
    Bu konuşmayı 2 yıl sonra yeniden hatırlatmak isterim

• “Makine gerçektir. Silikon da gerçektir, DRAM de, L1 cache ve false sharing de, branch predictor'ın yazı tura atması da gerçektir. İlginiz varsa hepsiyle uğraşabilirsiniz.”
  Böyle cümleleri gerçekten çok uzun zamandır bu kadar güzel bulmamıştım

  • Ben de aynısını hissettim
    Yazarın Dave Barry tarzında neşeli yazması yüzünden birkaç kez kahkaha attım
    Copilot hakkındaki katıldığım düşünceleri mizahla çok iyi ifade etmiş olması hoşuma gitti

• Yazılım geliştirme tartışmalarında sık sık kaçan nokta şu: mesele sadece “yazılmış kodun çıktısı” değil
  Sayısız trade-off içinden geçerek sonuca varılan yolculuğun kendisi de çok önemli
  Bir junior ile biraz karmaşık bir codebase içinde tek bir özellik geliştirmeye çalışsanız bile, deneyimli bir mühendis olarak bilinçsizce hangi trade-off'ları yaptığınızı hemen hissedersiniz
  AI'ın da bu trade-off kavramına dair bir anlayışı var ama çoğu zaman gözlemden öğrenilmiş bir düzeyde
  “Daha iyi kod yazmaya yardımcı oluyor” demek doğru ama sonuçta karar verme ve düşünme işi insana ait
  LLM'ler “düşünmüyor”
  Ve AI geliştikçe insanların daha az düşünmeye başlaması gibi bir risk var

• Copilot'ın artıları da eksileri de bana çok tanıdık geliyor
  Ama hacker ya da çocukluk döneminin “zanaatkârlık ruhu”ndan farklı olarak, mühendisler her zaman mühendisti
  Bugünün temel teknolojilerinin zorlukla ortaya çıkmasının sebebi, o dönemde bu engellerin mutlaka aşılması gerekmesiydi
  Böylesi dramatik bir tarihi “eskiden işler böyle yapılırdı” diyerek genellemek, yanlı bir bakış açısı yaratabilir

  • 20 yılı aşkın süredir zor yoldan yazılım geliştiren bir mühendis olarak, yüksek zorluktaki problemleri çözmek benim için hem ayrıcalık hem tatmin kaynağı
    Basit CRUD güncellemeleri tekrar eden ve sıkıcı işler olsa da, arada çıkan kafa yoran problemler, üniversitede öğrendiğim bilgileri kullanabildiğim anlar ve özyinelemeli algoritmalar gibi istisnai durumlar kariyerimin mücevherleri gibi
    Gelecekte AI odaklı yazılım mühendislerinin de bu deneyimleri daha kıymetli görmesini isterim
    AI mantıklı cevaplar da üretebilir ama bazen tamamen alakasız ve tehlikeli biçimde yanlış olabilir; bu yüzden gerçekte ne yapılması gerektiğini bilen insanlara ihtiyaç var
    AI'lar “halüsinasyon” gördüğünde ya da bağlam eksik olduğunda, sonunda sorunu çözmek zorunda kalacak bir insan her zaman olacaktır

• Benim karşılaştırma ölçütüm pair programming değil, yurtdışı outsource geliştiriciler
  Açıkçası Copilot, Cursor ve diğer AI araçlarının çok daha iyi gelmesinin nedeni şu: artık Zoom görüşmelerinde belirsiz iletişim sorunları, dil bariyeri ya da karşılıklı yanlış anlama yüzünden vakit kaybetmiyorum
  Mesela “root node ile ilgili isChild(boolean döndüren) diye bir fonksiyon eklenmiş ama parent varlığı kontrolüyle ilgisi yok” ya da “API parametresi bir anda artık array kabul etmiyor” gibi outsource işlerde sık görülen durumlar oluyor
  AI ile çalışırken böyle bir sorun çıksa bile, sadece yanlış olduğunu söyleyip nedenini açıklıyorum ve hızla düzeltiyor
  İnsanlarla çalışırkenki kadar iletişim kazası, yanlış anlama ya da zaman kaybı neredeyse yok
  AI'ın Jira ticket'larıyla kolayca bağlandığı an geldiğinde, geliştirmenin yaklaşık %80'i ticket yazma ve denetim işine dönüşecek
  Elbette bu, mühendisin rolünün ortadan kalkacağı anlamına gelmiyor — Biz tarafının iyi ticket yazması zaten pek olası değil ve sonuçta birilerinin nihai sorumluluğu taşıması gerekecek
  Yine de birçok organizasyon bunu unutacak ve bunun sonucunda ciddi kazalara açık bir ortam doğacak

• Bu yazıdan benim çıkardığım en temel nokta şu oldu
  “Yazılımın bugünkü geri, şişkin ve aşırı soyutlanmış halini en yüksek ideal gibi öveceğiz. Performansı sonuna kadar sıkıştırma ya da ince, keskin ve berrak sistemler kurma kültürü bir gün sadece eski hikâyeler olarak kalacak.”
  2023 öncesinde oluşturulmuş kütüphanelerin ve mimari kalıpların, bundan sonra LLM'lerin eğitim verisinin omurgası haline gelerek katılaşacağı kaygısı var
  Sürekli yenilik üretmek yerine, son 30 yılda birikmiş bağımlılıkların ve kirli kodun sonsuza kadar sürmesi mümkün olabilir
  Javascript'in bile sonsuza dek yaşayacak olmasından endişe ediyorum

• Son dönemde liderlik kademesinden her gün “AI'ı yeterince kullanmıyoruz”, “AI ile mevcut takvimleri yarıya indirebiliriz” baskısını doğrudan hissediyorum
  Yeni AI araçlarını devreye almak KPI'ları tutturmak için zorunlu tutuluyor; uyum sağlayamazsan ekip küçültme bile konuşuluyor
  Dünya iyice delirmiş gibi geliyor
  AI her zaman sadece “başkasının işini ikame edecek araç” gibi pazarlanıyor
  Oysa AI'ın iyi görünmesinin sebebi çoğu zaman, başkasının yaptığı işi aslında yeterince bilmeden değerlendirdiğiniz anlar
  Yönetim eline AI adlı çekici almış ve dünyadaki her şeye çivi muamelesi yapıyor gibi

  • Gerçekten de yönetim katmanını bir şekilde küçültüp zamanı gerçekten üretken işlere ayırmanın yolunu bulmamız gerek
    AI kullanmaktan çok gerçek iş ve teslimata odaklanan bir kültür umuyorum

  • Aslında bu sadece AI sektörünün tipik “hype cycle” örüntüsü
    Ortalık durulduğunda işe yarayan araçlar ve teknolojiler kalacak, çoğu ise kaybolacak
    Gerçekte neyin kalıcı olacağını akıllıca görüp bu değişimi etkileme şansı yakalayabilirseniz, hayatta kalma yolu orada; bence buna çabalamak gerekiyor

  • Şu anki “hemen benimseyin” baskısı, benim bildiğim mühendislik/tasarım/teknisyenlik özünün tam tersi
    Normalde bir araç, dil ya da servisin benimsenip benimsenmeyeceği dikkatle değerlendirilirdi; neden bizim kullanım senaryomuza uygun olduğu, artıları ve eksileri gerekçelendirilirdi
    “Buna neden ihtiyacımız var, bu servis neden daha mantıklı” gibi politika karar süreçleri sağlıklı olan buydu
    Gerçekten benimsenmesi gereken bir teknoloji olup olmadığı test edilir, ardından da performansı ve benimseme verimliliği değerlendirilirdi
    Bugünün şirketleri bu sağlıklı yaklaşımdan uzaklaşıyor

  • “AI her zaman başkasının işini ikame edebilen bir araçtır” yanılsaması fazlasıyla yaygın
    Evet, basit tekrar eden işler var ama çoğu işi iyi yapabilmek için o işe özgü incelikler ve nüanslar gerekir; otomasyon sürecinde kaybolma riski taşıyan şeyler de tam olarak bunlar
    “AI ile %80'i yeter” lafına katılmıyorum
    Hatalar tüm sistemi etkileyebilir ve değerlendiren kişiler de çoğu zaman sahadaki deneyimden yoksun olur

  • Bence çok yakında yöneticilik pozisyonları daha hızlı ortadan kalkmaya başlayacak
    O zamana kadar birbirimize destek olalım

• Yazar belli ki bir C++ geliştiricisi gibi duruyor
  Gerçekten de AI kodlama asistanlarının C++ tarafında düzgün çalıştığı durumlar nadir; verimli kullananların çoğu bunu script dillerinde ya da CRUD uygulamalarında yapıyor

  • Yazarın eski yazılarına bakınca oyun geliştiricisi gibi görünüyor
    Oyun geliştirme bilgisi ve kaynakları LLM'ler tarafından büyük ölçekte öğrenilmiş değil; bu yüzden CRUD uygulamalarından farklı olarak metnin yazarı LLM'lerin sınırlarını daha net hissediyor olabilir

• Bu yazının bazı kısımları, TV dizisi Silicon Valley'deki ‘Bertram Gilfoyle’ karakterinin sesiyle okunuyormuş gibi geliyor
  Bunu sadece ben mi hissettim merak ediyorum

• Asıl mesele şu: her zaman “teleskop” becerisine sahip olmak
  Kodlama ajanları sayesinde daha üst seviye işlerle uğraşmak sorun değil ama gerektiğinde her an kodun derinine inip onu gerçekten anlayabilmeli ve düzeltebilmelisiniz; güvenli olan da bu