Codex ile Kod Öğrenmek Yerine Kod Anlamak

Kod öğrenmek gereksiz mi?

AI kod yazabildiği için artık kod öğrenmek gereksiz mi? Ben böyle düşünmüyorum.

Bence artık öğrenmenin şekli değişiyor. Eskiden bir şeyi yapmak için syntax ezberlemek daha önemliydi: bir döngünün nasıl yazıldığını, bir fonksiyonun hangi parametreleri aldığını, bir yapılandırma dosyasının hangi anahtarları beklediğini hatırlamak gerekiyordu. Şimdi ise sistemin nasıl çalıştığını anlamak daha önemli hale geliyor.

Bu fark küçük görünüyor ama öğrenme planını baştan değiştiriyor. Sözdizimi ezberi, bir arama ya da bir araç ile saniyeler içinde tamamlanabilen bir iş. Ama “bu veri neden burada tutuluyor”, “bu bileşen niçin ayrı bir dosyada” ya da “sayfa neden yavaş açılıyor” sorularının cevabı, ezberden değil anlayıştan geliyor. Bu yazıda, Codex gibi yapay zekâ destekli kodlama araçlarını kullanırken kodu nasıl okuduğumu, hangi soruları sorduğumu ve öğrenmeyi nasıl kalıcı hale getirmeye çalıştığımı anlatıyorum.

Ezberden anlayışa geçiş

Syntax bilgisi değersiz değil; sadece önceliği değişti. Bir kod parçasını okuyup ne yaptığını çıkarabilmek için sözdizimine aşina olmak hâlâ gerekiyor. Ama sıfırdan yazarken her ayrıntıyı hatırlamak zorunda olmak, artık öğrenmenin ana engeli olmuyor.

Bunun yerine ön plana çıkan beceriler şunlar:

• Okuyabilmek. Başkasının ya da aracın yazdığı kodu izleyip ne yaptığını açıklayabilmek.
• Parçalara ayırabilmek. Bir sistemi girdi, işlem ve çıktı olarak bölebilmek.
• Soru sorabilmek. Doğru soruyu sormak, çoğu zaman doğru cevabı bulmaktan daha belirleyici.
• Doğrulayabilmek. Bir iddiayı çalıştırıp, test edip ya da dokümantasyonla karşılaştırıp kontrol edebilmek.

Bu becerilerin hiçbiri, aracın yerine geçemeyeceği şeyler. Araç yazabilir; ama yazılanın projenize uyup uymadığına, gerçekten doğru çalışıp çalışmadığına, gelecekte bakımı kolay olup olmayacağına sizin yargınız karar verir.

Hangi soruları sormalı?

Bir kod parçasıyla karşılaştığımda, onu ya da aracı sorgularken kullandığım temel sorular şunlar:

• Bir fonksiyon neden var?
• Bir component diğerine nasıl bağlanıyor?
• Bir API ne yapıyor?
• Bir veri neden burada tutuluyor?
• Bir performans problemi neden oluşuyor?

Bunları anlamadan AI'ye güvenmek riskli. Çünkü cevabını bilmediğiniz bir şeyi araçtan istediğinizde, gelen cevabın doğru olup olmadığını ayırt edemezsiniz.

Bu soruları biraz açalım, çünkü her biri farklı bir anlama katmanına işaret ediyor.

“Bu fonksiyon neden var?” sorusu amacı sorgular. Bir fonksiyonun adı ve içeriği ne yaptığını gösterir, ama neden ayrı bir fonksiyon olduğunu göstermez. Belki aynı işlem üç yerde kullanılıyor, belki test edilebilirlik için ayrılmış, belki sadece okunabilirliği artırmak için. Amacı anlamak, kodu değiştirirken neye dikkat edeceğinizi söyler.

“Bir bileşen diğerine nasıl bağlanıyor?” sorusu veri akışını sorgular. Bir bileşene veri nereden geliyor, bir tıklama olayı hangi yoldan yukarı çıkıyor, ortak durum (state) nerede tutuluyor? Bağlantıları çizebiliyorsanız, değişikliğin nerelere dokunacağını da öngörebilirsiniz.

“Bir API ne yapıyor?” sorusu dış dünyayla sözleşmeyi sorgular. Hangi girdiyi bekliyor, hangi çıktıyı veriyor, hata durumunda ne oluyor? API'yi anlamadan onu çağıran kodu yazmak ya da değerlendirmek mümkün değil.

“Bu veri neden burada tutuluyor?” sorusu veri modelini sorgular. Aynı bilginin iki farklı yerde tutulması, zamanla tutarsızlık üretir. Verinin tek doğru kaynağının nerede olduğunu bilmek, birçok hatanın önüne geçer.

“Bu performans problemi neden oluşuyor?” sorusu ise ölçmeyi gerektirir. Tahmin etmek yerine, sayfa yükleme süresine, ağ isteklerine, dosya boyutlarına bakmak gerekir. Performans konusu 3D içerik taşıyan siteler için ayrıca kritik; bu dengeyi 3D web sitesinde tasarım ve performans yazısında ele aldım.

Okuyarak öğrenmek

Üretilen kodu çalıştırıp geçmek yerine okumak, öğrenme açısından çok değerli bir alışkanlık. Bir kodu satır satır anlamaya çalışmak, bilmediğim kavramları fark etmemi sağlıyor; sonra o kavramı ayrıca araştırıp denemek hem hızlı hem kalıcı bir öğrenme yöntemi.

Bu alışkanlığı sistematik hale getirmek için kullanabileceğiniz bir sıra var:

1. Önce kendiniz okuyun. Kodu araca açıklatmadan önce, ne yaptığını tahmin etmeye çalışın. Tahmininiz yanlışsa, tam da öğrenme fırsatını yakalamışsınız demektir.

2. Bilmediğiniz kelimeleri işaretleyin. Bir fonksiyon adı, bir anahtar kelime ya da bir kütüphane çağrısı gözünüze yabancı geliyorsa not alın.

3. Araçtan açıklama isteyin. “Bu satırı bir başlangıç seviyesine anlatır gibi açıkla” ya da “bu dosyadaki veri akışını özetle” gibi istekler işe yarar. Açıklamayı kodla karşılaştırın.

4. Küçük bir değişiklik yapın. Bir değeri değiştirin, bir satırı yorum satırı yapın, sonucun nasıl değiştiğini izleyin. Kod, değiştirilince anlaşılır.

5. Açıklamayı kendi cümlelerinizle yazın. Bir şeyi kendi kelimelerinizle anlatabiliyorsanız anlamışsınızdır. Anlatamıyorsanız eksik bir parça var.

6. Resmi kaynaklara bakın. Araç bir özelliğin nasıl çalıştığını anlattığında, resmi dokümantasyonda doğrulayın. Dokümantasyon okumak, aracın kısa yoldan söylediği şeyin sınırlarını da gösterir.

Kodu anlamak, AI ile geliştirme sürecinin kontrol tarafını da güçlendiriyor. Çünkü neyi neden değiştirdiğinizi bilen biri, araçtan gelen öneriyi kabul ya da reddederken daha sağlam karar veriyor.

Küçük bir senaryo: bir hata mesajını okumak

Varsayımsal bir örnekle ilerleyelim. Diyelim ki sitenizde bir sayfa açılırken tarayıcı konsolunda “bir şey tanımsız (undefined)” türünde bir hata görüyorsunuz ve araçtan düzeltmesini istiyorsunuz.

“Düzelt” demek yerine şu yolu izleyebilirsiniz:

• Hata mesajının hangi dosyayı ve hangi satırı gösterdiğine bakın.
• O satırda hangi değişkenin tanımsız olduğunu bulun.
• Bu değişkenin değerinin nereden geldiğini izleyin: bir istekten mi, bir dosyadan mı, bir başka fonksiyonun çıktısından mı?
• Değerin neden o anda boş olabileceğini düşünün: veri henüz yüklenmemiş olabilir, bir anahtar adı yanlış yazılmış olabilir, beklenen biçimde veri gelmemiş olabilir.
• Şimdi araca gidin ve bulduğunuz bilgiyle soru sorun: “Bu değişken şu fonksiyondan geliyor, bazen boş dönüyor olabilir; neden olabilir ve nasıl güvenli ele alırım?”

Bu sorgulama biçimi, aracın cevabını kabul etmenizi değil değerlendirmenizi sağlar. Araç “boş kontrolü ekle” derse, bunun semptomu mu örttüğünü yoksa sebebi mi çözdüğünü ayırt edebilirsiniz. Bazen bir kontrol eklemek yeterlidir, bazen asıl sorun verinin hiç gelmemesidir ve kontrol sadece hatayı gizler.

Anlamadan güvenmenin riskleri

Anlamadan AI'ye güvenmenin pratikte nasıl sorun çıkardığını birkaç başlıkta toplayabilirim.

• Çalışıyor ama neden çalıştığı belli değil. Bir sonraki değişiklikte bozulursa, nerede arayacağınızı bilmezsiniz.
• Gereğinden karmaşık çözümler. Basit bir iş için gereksiz bir kütüphane ya da soyutlama eklenebilir. Anlamayan biri bunu normal sanır.
• Sessiz hatalar. Kod hata vermeden yanlış sonuç üretebilir; örneğin bir bağlantı yanlış sayfaya gider ya da bir yerelleştirme eksik kalır. Bunu kodu anlayan biri fark eder.
• Güvenlik açıkları. Kullanıcıdan gelen veriyi doğrulamayan ya da gizli bilgileri yanlış yerde tutan kod, çalışıyor göründüğü halde risk taşır. Bu tür şeyleri fark etmek temel bir anlayış gerektirir.
• Bağımlılık hissi. Her küçük şey için araca dönmek zorunda hissetmek, zamanla kendi yargınızı köreltir.

Bunların hiçbiri aracın kötü olduğunu göstermiyor; sadece anlayışın bir sigorta görevi gördüğünü gösteriyor. Daha geniş bir kontrol perspektifi için AI ile üretirken neden güvenmemek gerekiyor yazısına bakabilirsiniz.

Hızlandırıcı olarak AI

Ben AI araçlarını daha çok “hızlandırıcı” olarak görüyorum. Öğrenmeyi bırakmak için değil, öğrenirken daha hızlı denemek için.

Bunun somut bir anlamı var: denemenin maliyeti düşüyor. Eskiden bir fikri denemek için bir saat harcamam gerekiyorsa, şimdi bir iskeleti kısa sürede çıkartıp üzerinde inceleme yapabiliyorum. Ama o iskeleti anlamak yine zamanımı alıyor ve almalı. Hızlanan şey deneme-yanılma döngüsü; anlama kısmı kısaltılamaz.

Hızlandırıcı yaklaşımının pratik bir yan faydası daha var: öğrenme sürecimi belgeleyebiliyorum. Bir şeyi anladığımda kendi cümlelerimle not almak, ileride aynı konuya döndüğümde zaman kazandırıyor. Bu notların sitede kalıcı bir kayıt olarak durması fikrini öğrenme sürecini web sitene kaydetmek yazısında anlattım.

Başlangıç seviyesinde olanlara öneriler

Henüz kod yazmaya yeni başlıyorsanız, araçları nasıl kullanacağınız önemli. Aşağıdakiler genel ve herkese uyabilecek öneriler:

• Küçük bir projeyle başlayın: tek sayfalık bir site, basit bir hesaplayıcı, bir kişisel not listesi.
• Araçtan kod istediğinizde, aynı zamanda her bölümün ne yaptığını açıklamasını isteyin.
• Çalışan bir örneği bozup tekrar düzeltmeyi deneyin. Hata ayıklamak, yazmaktan daha çok öğretir.
• Aynı şeyi iki farklı yoldan yaptırın ve farkları karşılaştırın; neden farklı yazıldığını sorun.
• Resmi dokümantasyonu okumaya alışın. Araç bir özelliği anlattığında, orijinal kaynakta doğrulayın.
• Sürüm kontrolü kullanmayı erken öğrenin. Denemeler serbest hale gelir, çünkü geri dönüş her zaman var.
• Her gün ya da hafta sonunda, öğrendiğiniz bir şeyi kendi cümlelerinizle yazın.

Bu öneriler, sözdizimini ezberleme yükünü azaltırken sistemi anlama alışkanlığını güçlendiriyor. Bir alandan başka bir alana geçerken de işe yarıyor: 3D işlerde de aynı mantıkla, önce nasıl çalıştığını anlıyor, sonra aracı hızlandırıcı olarak kullanıyorum. Bu yaklaşımı 3D çalışmalarda yapay zekâ kullanımı yazısında ayrıntılandırdım.

Bir kod tabanını tanımak için kısa bir yol haritası

Tanımadığınız bir projeye ilk kez baktığınızda, her dosyayı okumaya çalışmak yerine yukarıdan aşağıya inen bir sıra izlemek daha verimli. Bu sırayı araçla birlikte uygulayabilirsiniz, ama her adımda sonucu kendi gözünüzle de doğrulayın.

1. Giriş noktasını bulun. Proje çalıştırıldığında ilk hangi dosya devreye giriyor? Bir web projesinde bu genellikle ana sayfa şablonu ya da uygulamanın başlatıldığı dosyadır.

2. Proje yapılandırmasına bakın. Paket tanımı dosyası hangi komutları sunuyor, hangi bağımlılıklar kullanılıyor? Bu, projenin hangi araçlarla ayakta durduğunu hızlıca gösterir.

3. Klasör düzenini çıkarın. Sayfalar, bileşenler, stiller, veri ve statik dosyalar hangi klasörlerde? Bir klasör haritası çizmek, sonraki her okumayı kolaylaştırır.

4. Tek bir akışı baştan sona izleyin. Örneğin bir sayfanın açılmasından ekranda görünmesine kadar olan yolu takip edin. Tüm sistemi değil, bir damarı anlamak, geri kalanı çözmenin anahtarıdır.

5. Çalıştırıp gözlemleyin. Projeyi yerelde başlatın, bir şeyi değiştirin ve sonucu görün. Okuduğunuzla gördüğünüzü eşleştirmek, anlamayı sağlamlaştırır.

6. Anlamadıklarınızın listesini tutun. Bu liste, öğrenme planınızın kendisi olur. Araca sorarak değil, önce araştırıp sonra araçla doğrulayarak kapatın.

Bu sıranın iyi yanı, aracı bir cevap makinesi değil bir rehber olarak konumlandırması. “Bu projeyi anlat” demek yerine “şu dosyadan başlayarak sayfanın nasıl oluşturulduğunu adım adım açıkla, ben de kodda takip edeceğim” demek, hem daha doğru hem daha öğretici sonuç veriyor.

Anlamanın değeri neden azalmıyor?

Araçlar gelişirken “yakında bunu da anlamaya gerek kalmaz” düşüncesi akla gelebilir. Bence anlamanın değeri azalmıyor, çünkü bir üretim sürecinde hep birilerinin sorumluluğu var. Yayına alınan bir sayfa, bir müşteriye verilen bir söz ya da bir ziyaretçinin kişisel verisini işleyen bir form söz konusu olduğunda, “araç yazdı” cevabı yeterli olmuyor.

Ayrıca anlamak, doğru istekte bulunmayı da belirliyor. Neyin mümkün olduğunu, neyin pahalı olduğunu, neyin riskli olduğunu bilen biri, araçtan çok daha iyi sonuç alıyor. Bilmeyen biri ise ya fazla basit ya da gereksiz karmaşık bir şey istiyor. Bu anlamda, anlayış hem kalkan hem de yönlendirme aracı.

Sık sorulan sorular

Sonuç

Kod öğrenmek gereksiz hale gelmedi; öğrenmenin ağırlık noktası değişti. Sözdizimi ezberi yerini sistemi anlamaya, doğru soru sormaya ve çıktıyı doğrulamaya bırakıyor. Okuyarak, küçük değişiklikler yaparak ve öğrendiğini kendi cümleleriyle yazarak ilerleyen biri, araçları gerçekten hızlandırıcı olarak kullanabiliyor.

Çünkü AI bir şeyi yazabilir. Ama o şeyin gerçekten doğru olup olmadığını değerlendirmek hâlâ sana kalır.