Bu Filmi Daha Önce Gördüm

Gelecek Tanıdık Görünüyordu

1995 yılında yazılım geliştirici olduğunuzu hayal edin.

Hantal bir tüplü monitörün karşısında oturuyorsunuz. Bilgisayarınızın işlem gücü bugünkü bir akıllı telefonun küçük bir kesri kadar. İnternet henüz her takıldığınızda şöyle bir bakıverdiğiniz bir şey değil.

Yine de olağanüstü bir şey oluyor.

Bir düğmeyi pencereye sürüklüyorsunuz, çift tıklıyorsunuz, birkaç satır kod yazıyorsunuz ve bir anda çalışan bir grafik arayüzlü uygulamanız oluyor.

Bütün arayüzü sıfırdan yazmaya gerek yok. Bir düğmenin nasıl çizileceğini ya da bir fare tıklamasının nasıl işleneceğini satır satır yönetmeye gerek yok.

O işin büyük kısmını geliştirme ortamı sizin yerinize hallediyor.

Devrim gibi hissettiriyor.

Şimdi 2026’da geliştirici olduğunuzu hayal edin.

Bir yapay zekâ kod asistanını açıp şunu yazıyorsunuz:

“Kullanıcı girişi, PostgreSQL veritabanı ve REST API’si olan bir gösterge paneli yap.”

Birkaç saniye sonra kod akmaya başlıyor. Bileşenler, rotalar, veritabanı modelleri, testler, belki bir de deploy yapılandırması.

Devrim gibi hissettiriyor.

Aralarında otuz yıldan fazla olan bu iki âna bakınca şunu düşünmeden edemiyorum:

Bu filmi daha önce gördüm.

Yapay zekâ ile Hızlı Uygulama Geliştirme (RAD) aynı teknoloji olduğu için değil. Değiller.

Ama vaat şaşırtıcı derecede tanıdık geldiği için.

Daha çok üret. Daha az yaz. Daha hızlı ilerle. Karmaşıklığı araçlara bırak.

Bu vaadi daha önce duyduk.

Beni asıl ilgilendiren, yazılım geliştirmenin ne kadar kolaylaştığı değil.

Bir şeyi yapmak neredeyse zahmetsiz hale geldiğinde bize ne olduğu.

1. Yapay Zekâdan Önce Visual Basic Vardı

Mayıs 1991’de Microsoft, Windows için Visual Basic’i duyurdu.

Bugün programlama öğrenen birine, bir formun üzerine düğme koymak fikri son derece sıradan gelebilir.

O gün için büyük bir kırılmaydı.

Geleneksel Windows uygulama geliştirme; işletim sisteminin API’leri, mesaj işleme, kaynaklar ve uygulama yapısı hakkında ciddi bilgi isteyebiliyordu.

Visual Basic farklı bir deneyim sunuyordu.

Arayüzü çiziyor, kontrolleri görsel olarak yerleştiriyor, özelliklerini ayarlıyor ve olaylara karşılık kod yazıyordunuz.

Bir düğmenin olay işleyicisi şu kadar basit olabilirdi:

Private Sub Command1_Click()
    MsgBox "Hello, World!"
End Sub

Görünür bir davranış yaratmak için bu yeterliydi.

Visual Basic programlamayı ortadan kaldırmadı. Geliştiricinin emeğini nereye harcadığını değiştirdi.

Arayüz altyapısının büyük kısmını elle kurmak yerine, geliştiriciler uygulamanın kendisine odaklanabiliyordu.

Güçlü bir fikirdi bu.

Kimin yazılım yapabileceğini de değiştirdi.

Küçük işletmeler, öğrenciler, meraklılar ve profesyonel geliştiriciler, her sorunu düşük seviyeli bir sistem programlama alıştırmasına dönüştürmeden işe yarar Windows uygulamaları yazabiliyordu.

Giriş eşiği alçaldı.

Ve eşikleri alçaltmak, teknolojinin yapabildiği sahiden değerli şeylerden biridir.

1998’de duyurulan Visual Basic 6.0, bu yaklaşımı daha zengin veritabanı entegrasyonu, bileşenler ve kurumsal uygulama yetenekleriyle bir adım öteye taşıdı.

Ama temel fikir en baştan beri ortadaydı:

Geliştiricinin kurmak zorunda olduğu makine ne kadar azsa, bir fikir o kadar doğrudan uygulamaya dönüşür.

Tanıdık geldi mi?

2. Sonra Delphi Geldi

14 Şubat 1995’te Borland, Delphi 1’i piyasaya sürdü.

Delphi; görsel, bileşen tabanlı uygulama geliştirmeyi, Object Pascal’ı, genişletilebilir bir Görsel Bileşen Kütüphanesi’ni (VCL), veritabanı araçlarını ve yerel kod üreten bir derleyiciyi bir araya getiriyordu.

Önemli bir tarihî ayrıntı: Delphi 1, 16 bit Windows 3.1 uygulamalarını hedefliyordu. 32 bit Windows 95 desteği 1996’da Delphi 2 ile geldi.

Delphi’yi çekici yapan şey, görsel geliştirmeyi ciddi uygulama mantığını ifade edebilen bir programlama ortamıyla birleştirmesiydi.

Arayüzü hızla kurabiliyordunuz; ama aynı zamanda sınıflar tasarlayabiliyor, nesne ömürlerini yönetebiliyor, veritabanlarıyla çalışabiliyor ve karmaşık uygulamalar yazabiliyordunuz.

Örneğin bir Delphi düğmesi şöyle bir olay işleyiciye bağlanabiliyordu:

procedure TForm1.Button1Click(Sender: TObject);
begin
  ShowMessage('Hello, World!');
end;

Görünürde deneyim basitti.

O basitliğin arkasında ise hatırı sayılır bir yazılım sistemi vardı.

Bileşenlerin ömürleri vardı. Olayların yürütme yolları vardı. Uygulamalar işletim sistemi davranışına, kütüphanelere, veritabanlarına ve kurulum ortamlarına bağımlıydı.

Geliştirici bütün o makineyi yazmak zorunda değildi.

Ama onu yeterince anlamak hâlâ önemliydi.

Bu ayrım giderek daha da önem kazanacaktı.

Visual Basic ile Delphi ne aynı araçlardı ne de aynı teknik ödünleri vermişlerdi.

Ama temel bir hırsı paylaşıyorlardı: fikir ile çalışan uygulama arasındaki mesafeyi kısaltmak.

Ve başardılar.

3. Hiç Kolaylaşmayan Kısım

Grafik geliştirme devriminin çözmediği bir şey var.

Dakikalar içinde güzel bir form yapabiliyordunuz.

Peki iki kullanıcı aynı veritabanı kaydını aynı anda güncellemeye kalkınca ne oluyordu?

Bir işlemin ortasında ağ bağlantısı kopunca ne oluyordu?

Bin kullanıcıda düzgün çalışıyormuş gibi görünen bir uygulama, olayların alışılmadık bir bileşiminde çökünce ne oluyordu?

Görsel bir geliştirme ortamı uygulamayı kurmayı kolaylaştırabilirdi.

Bu alttaki soruları yok edemezdi.

Aynı şey sonraki çatılar, kod üreteçleri, paket yöneticileri ve bulut platformları için de geçerliydi.

Her kuşak bir katmanı daha otomatikleştirdi.

Ama mühendisliğin zor kısımları yer değiştirmeye devam etti.

Belli türde tekrar eden kodu yazmayı bıraktık.

Durumu, eşzamanlılığı, güvenliği, kaynak sahipliğini, hatayı ve doğruluğu anlamaya ihtiyaç duymayı bırakmadık.

Korumamız gerektiğini düşündüğüm bir ayrım bu:

Programlama, talimat üretmektir. Yazılım mühendisliği, o talimatların sonuçlarını anlamaktır.

İyi araçlar gereksiz işi azaltır.

Zor kararları kendiliğinden ortadan kaldırmaz.

4. 2026’da Form Tasarımcısı İngilizce Anlıyor

Şimdi arayüz bir kez daha değişti.

Bir düğmeyi formun üzerine sürüklemek yerine, ne istediğimizi doğal dille anlatıyoruz.

Her bileşeni elle bağlamak yerine, uygulamanın yapısını ve davranışını üretmesini bir yapay zekâ asistanından istiyoruz.

Modern kod ajanları daha da ileri gidebiliyor. Yeteneklerine ve izinlerine bağlı olarak depoları inceleyebiliyor, birden çok dosyayı düzenleyebiliyor, komut çalıştırabiliyor, test koşturabiliyor ve kendi işini gözden geçirebiliyor.

Bu, RAD’dan gerçek bir teknolojik fark.

Visual Basic ve Delphi önceden tanımlı bileşenler ve programlama soyutlamaları sunuyordu.

Üretken yapay zekâ; açıklamalardan, örneklerden ve bağlamdan yeni kaynak kodu sentezleyebiliyor. Ajan sistemleri, geliştirme eylemlerinden oluşan dizileri koordine edebiliyor.

Geliştirici artık yalnızca bileşen seçmiyor.

Uygulama sürecinin parçalarını devredebiliyor.

Bu ciddi bir değişim.

Ama eski sorular yerinde duruyor.

Sonucu kim doğruluyor?

Bozulduğunda ne olduğunu kim anlıyor?

Mimarinin mantıklı olup olmadığına kim karar veriyor?

Basit bir talimat düşünün:

“Yeniden denemeleri güvenli biçimde yöneten bir ödeme API’si yaz.”

Bir yapay zekâ asistanı, testleriyle birlikte ikna edici bir kod üretebilir.

Peki istekler tekrarlandığında idempotentliği koruyor mu?

Eşzamanlı iki istek çift işlem yaratabilir mi?

Veritabanı başarıyla commit ettiği halde yanıt istemciye hiç ulaşmazsa ne olur?

Bunlar yalnızca çalışan bir uç nokta üretilerek cevaplanan sorular değil.

Sistemin davranışını bilmeyi gerektiriyorlar.

Yapay zekâ, bir uygulamayı ne kadar hızlı üretebildiğimizi değiştiriyor.

Hızlı üretildi diye o uygulamayı doğru yapmıyor.

Ve bu beni daha rahatsız edici bir soruya getiriyor.

5. Her Şey Kolaylaşınca Neden Bazen Yapmayı Bırakıyoruz?

Teknolojik ilerlemenin en çok ilgimi çeken kısmı burası.

İnsanlık tarihinin büyük bölümünde bilgiye ulaşmak ciddi çaba istiyordu.

Kitaplara, öğretmenlere, kütüphanelere, laboratuvarlara ya da o bilgiye zaten sahip insanlara erişmeniz gerekiyordu.

Bir şey öğrenmek yavaş olabiliyordu.

Bir şey inşa etmek daha da yavaş.

Sonra bilgisayarlar bilgiyi saklamayı ve işlemeyi kolaylaştırdı.

İnternet bilgiye ulaşmayı kolaylaştırdı.

Arama motorları bulmayı kolaylaştırdı.

Ve yapay zekâ, bir açıklamayı, bir çözümü, hatta bitmiş bir ürünü doğrudan istemeyi mümkün kılmaya başladı.

Her adım bir sürtünmeyi kaldırdı.

Bu pek çok açıdan harika.

Ama bir paradoks var.

Bilgiye ulaşmak kolaylaştıkça onu aklımızda tutmaya daha az eğilimli olabiliriz. Bir şeyi yapmak kolaylaştıkça onu nasıl yapacağımızı öğrenmeye daha az eğilimli olabiliriz.

Navigasyonu düşünün.

Bir navigasyon uygulaması tam olarak nereden döneceğimizi söylediğinde, tanımadığımız bir şehrin zihinsel haritasını artık kendimiz kurmak zorunda kalmıyoruz.

Bu, navigasyon teknolojisinin kötü olduğu anlamına gelmiyor. Zaman kazandırıyor, belirsizliği azaltıyor, yolculuğu daha erişilebilir kılıyor.

Ama neyi pratik ettiğimizi değiştiriyor.

Aynı ilke programlamaya da uygulanabilir.

Tanımadığımız her fonksiyon anında üretilebiliyorsa, onu anlamak için neden bir öğleden sonra harcayalım?

Bir yapay zekâ asistanı bir algoritmayı hemen açıklayabiliyorsa, neden önce problemle kendimiz boğuşalım?

Bir uygulamanın tamamı tek bir komuttan yaratılabiliyorsa, alttaki mimariyi neden öğrenelim?

Bazen bu soruların gayet iyi cevapları var. Zamanımız sınırlı ve her iş derin bir inceleme hak etmiyor.

Ama bazen kolaylık, anlayışın gelişeceği etkinliğin ta kendisini ortadan kaldırıyor.

Bir ihtimal daha var.

Bir şeyi yaratmak aşırı kolaylaştığında, onu yaratma eylemi daha az anlamlı gelmeye başlayabilir.

On tane uygulama fikriniz olduğunu düşünün.

Eskiden bunlardan birini bile yapmak, sizi zor kararlara zorlayacak kadar yatırım isterdi. Neyin önemli olduğunu, neyi ertelediğinizi, neyi bitirmeye değer bulduğunuzu seçmek zorundaydınız.

Şimdi onunun da prototipini üretmek mümkün olabilir.

Kulağa ilerleme gibi geliyor. Çoğu zaman öyle.

Ama o prototiplerden herhangi birinin özenle tasarlanmış, işe yarar, bakımı yapılan bir ürüne dönüşeceğini garanti etmiyor.

Daha çok tamamlamadan daha çok üretebiliriz.

Daha çok anlamadan daha çok keşfedebiliriz.

Ve makinelerden olasılık üretmelerini istemekle o kadar çok vakit geçirebiliriz ki, hangi olasılığın bağlılığımızı hak ettiğine hiç karar vermeyiz.

Bunun kolaylığa verilen kaçınılmaz bir insan tepkisi olduğunu düşünmüyorum.

Fark edilmeye değer bir risk olduğunu düşünüyorum.

Erişim, anlamak değildir. Çıktı, başarı değildir. Ve sınırsız olasılık, amaçla aynı şey değildir.

6. Araçların Bizim Yerimize Düşünmesinin Bilimi

Psikologlar bu olgunun önemli bir kısmını bilişsel yük aktarımı (cognitive offloading) adıyla inceliyor.

2016 tarihli bir derlemede Evan F. Risko ve Sam J. Gilbert, insanların bir işin bilişsel yükünü azaltmak için eylemleri ve dış kaynakları nasıl kullandığını anlattı.

Bir şeyi aklında tutmak yerine yazmak bunun bir örneği.

Hatırlatıcı uygulaması kullanmak bir başkası.

Bilişsel yük aktarımı özünde zararlı değil. Eldeki kaynakların akıllıca kullanımı olabilir.

Hatta uygarlık, bilgiyi tek tek zihinlerin dışında saklayabilmemize dayanıyor.

Ama neyi devrettiğimize dair seçimlerimiz, bir işle nasıl ilişki kurduğumuzu etkiliyor.

2025’te Microsoft Research ve iş birliği yaptığı kurumlardan araştırmacılar, 319 bilgi işçisi ve 936 üretken yapay zekâ kullanım örneğini kapsayan bir çalışma yayımladı.

Yapay zekâya duyulan güven arttıkça, bildirilen eleştirel düşünme çabasının azaldığını; kişinin kendi yeteneğine duyduğu güven arttıkça ise arttığını buldular.

Yapay zekâ destekli işin, bilişsel çabayı malzeme üretmekten uzaklaştırıp çıktıları doğrulamaya, bütünleştirmeye ve denetlemeye kaydırabildiğini de gözlemlediler.

Bu, öz bildirime dayalı bir çalışmaydı. Yapay zekânın kalıcı bir bilişsel gerilemeye yol açtığını kanıtlamadı.

Yine de değerli bir soru ortaya koyuyor:

İşi makine yapıyorsa ve insan onu kontrol etmekten sorumlu hale geliyorsa, insan o kontrolü yapmak için gereken uzmanlığı nasıl geliştirecek?

Daha eski bir paralel var.

1983’te araştırmacı Lisanne Bainbridge, Ironies of Automation (“Otomasyonun İronileri”) başlıklı yazısını yayımladı; otomasyonun insan operatörleri sıradan işleyişten uzaklaştırırken zor durumların sorumluluğunu nasıl onlara bıraktığını inceliyordu.

Bağlam endüstriyel otomasyondu, yapay zekânın ürettiği kod değil.

Ama altta yatan kaygı bugün de geçerli.

Rutin işler otomatikleştirildiğinde, olağandışı bir şey olduğunda müdahale etmesi yine insanlardan beklenebiliyor.

Ve olağandışı durumlar, çoğu zaman tam da deneyim isteyen durumlar oluyor.

Yürütmeyi ne kadar çok devredersek, hata üzerine akıl yürütme becerisini korumak o kadar önem kazanır.

7. Hızlı, Her Zaman Verimli Değildir

Otomasyonun bir başka ilginç sorunu var.

Toplam faydalı iş artmamışken bile bizi verimli hissettirebiliyor.

Kod üretmek görünür.

Sonuçlarını anlamak daha az görünür.

Bir komut yazıp yüzlerce satırın akışını izlemek anında bir ilerleme hissi yaratıyor.

Ama o satırların hâlâ gözden geçirilmesi, test edilmesi, bütünleştirilmesi, belgelenmesi ve bakımının yapılması gerekebiliyor.

METR’in 2025’te yaptığı rastgele atamalı bir çalışma, deneyimli açık kaynak geliştiricilerini aşina oldukları kod tabanlarında inceledi.

O özel ortamda, 2025 başındaki yapay zekâ araçlarını kullanan geliştiriciler, işleri araçsız çalıştıkları duruma göre yaklaşık %19 daha uzun sürede tamamladı.

İlginç olan şu: yapay zekânın onları hızlandırdığına inanıyorlardı.

Bu sonuç her geliştiriciye, her işe ya da her yapay zekâ sistemine genellenmemeli.

METR’in Şubat 2026’da bildirdiği sonraki araştırma, daha yeni araçların daha fazla fayda sağlayabileceğine işaret etti; ama aynı zamanda yeni verimlilik etkisinin güvenilir bir tahminini engelleyen yöntemsel sınırlar da ortaya koydu.

Asıl ders, yapay zekânın geliştiricileri yavaşlattığı değil.

Daha hızlı ilerleme hissi ile gerçek verimliliğin ölçümü, farklı şeylerdir.

RAD döneminde benzer bir sorunla karşılaşmıştık.

Bitmiş görünen bir form, bitmiş bir uygulama demek değildi.

Üretilmiş bir API, güvenilir bir servis demek değil.

Ve etkileyici bir demo, bakımı yapılabilir bir sistem demek değil.

Önemli olanı ölçmeliyiz.

Üretilen satır sayısını değil.

Tamamlanan komut sayısını değil.

Prototipin ne kadar hızlı belirdiğini bile değil.

Yazılımın sorunu çözüp çözmediğini, doğru çalışıp çalışmadığını ve zaman içinde işe yarar kalıp kalmadığını.

8. Genç Geliştiricilerin Bilmesi Gerekenler

Yapay zekâ çağında mesleğe giren genç bir geliştiriciyseniz, size yapay zekâdan uzak durmanızı öğütlemem.

Tam tersi.

Kullanın.

Keşfedin.

Tek başınıza yapmanın zor ya da pratik olmadığı şeyleri yapın.

Olağanüstü yeteneklere erişiminiz var.

Ama bir yeteneğe erişmek ile onun arkasındaki anlayışa sahip olmayı karıştırmayın.

Yapay zekâdan bir sıralama algoritması yazmasını istemek ile o algoritmanın neden çalıştığını açıklayabilmek arasında fark var.

Bir veritabanı işlemi üretmek ile izolasyon seviyelerini anlamak arasında fark var.

Yapay zekâya çok iş parçacıklı bir C++ programı yazdırmak ile onun dayandığı bellek ve senkronizasyon garantilerini anlamak arasında fark var.

Her aracı yeniden icat etmeniz ya da her uygulama ayrıntısını öğrenmeniz gerekmiyor.

Hiçbir geliştirici kuşağı bunu yapmadı.

Ama araçların ne zaman yanıldığını fark edecek kadar bağımsız bir anlayış geliştirmelisiniz.

Korumaya değer bulduğum beş alışkanlık:

1. Çözümü istemeden önce problemi anlamaya çalışın.

Birkaç dakikalık bağımsız düşünme bile gerçekte neye ihtiyacınız olduğunu netleştirebilir. Komutu yazmadan önce varsayımlarınızı ara sıra not edin.

2. Yapay zekâdan yalnızca sonuç değil, kararlarını açıklamasını isteyin.

Neden bu mimari? Hangi alternatifler var? Hata modları neler? Hangi varsayımlar bu çözümü geçersiz kılar?

3. Ara sıra anlamlı bir problemi yardımsız çözün.

Her şeyi elle yapmak ahlaken üstün olduğu için değil; pratik, gelişmiş araçları daha faydalı kılan zihinsel modelleri geliştirdiği için.

4. Anlamadığınız kısımları test edin.

Tanımadığınız bir kütüphane, bir eşzamanlılık mekanizması ya da bir güvenlik varsayımı, araştırmak için bir fırsattır. Üretilmiş testler faydalıdır; ama kapsamlarının ve iddialarının da değerlendirilmesi gerekir.

5. Süreçte sahiden sizin olan bir şey tutun.

Bir tasarım kararı. Bir deney. Bir hipotez. Peşine düştüğünüz zor bir hata. İlk ilkelerden açıklayabildiğiniz bir sistem.

Otomasyonu yeteneğinizi genişletmek için kullanın; merakınızı teslim etmek için değil.

Deneyimli geliştiriciler için de ders iki yönlü.

Deneyim değerlidir; ama eski araçlara aşinalık, yenilerini anlamanın yerini tutmaz.

Ne geçmişe tapmalıyız ne de bugünü küçümsemeliyiz.

İkisinden de öğrenecek çok şey var.

9. 1995 ile 2026 Arasındaki Gerçek Fark

Visual Basic ve Delphi, geliştiricilerin daha yüksek bir soyutlama seviyesinde çalışmasına yardım etti.

Yapay zekâ bu süreci, doğal dildeki açıklamaların uygulamayı, mimariyi ve geliştirme iş akışlarını etkilemesine izin vererek daha ileri taşıyor.

İki yaklaşım da sürtünmeyi azaltıyor.

Ama yapay zekâ; üretilen kararların güvenilirliği, otomatik doğrulamanın sınırları ve geliştiricinin niyeti ile ortaya çıkan sistem arasındaki ilişki hakkında yeni sorular getiriyor.

Ayrım önemli.

Bir RAD form tasarımcısı, işinizin geniş bir tarifini yorumlayıp kendi başına bir veritabanı şeması icat etmez.

Bir yapay zekâ sistemi tam olarak bunu deneyebilir.

Fırsat daha büyük.

Makul görünen çıktı ile gerekçeli mühendislik kararını ayırt etme ihtiyacı da öyle.

Bu gelişme beni heyecanlandırıyor.

Tekrar eden tesisat kodu yazmaya daha az, zor problemleri anlamaya daha çok zaman harcamayı tercih ederim.

Her satırın elle yazılması gerekiyormuş gibi yapmaktansa güçlü bir asistan kullanmayı tercih ederim.

Ama kaybetmemizi istemediğim bir şey var.

Bir şeyin neden çalıştığını sorduran merak.

Çalışmadığında araştırma sabrı.

Ve daha önce imkânsız görünen bir şeyi anlamanın verdiği tatmin.

Bu deneyimler, bitmiş ürüne giden yoldaki engeller değil.

Daha iyi mühendis olmamızın bir parçası.

10. Filmin Sonu Farklı Olabilir — Biz Seçersek

1990’ların başında yazılım geliştirme, geleneksel bir Windows uygulaması yazmayı aklından bile geçirmeyecek insanlara açılmaya başladı.

Visual Basic bunu mümkün kılmaya yardım etti.

Delphi, verimli görsel geliştirmenin güçlü yerel kod programlamayla bir arada var olabileceğini gösterdi.

Sonraki kuşaklar web çatılarını, yönetilen çalışma zamanlarını, bulut servislerini, açık kaynak ekosistemlerini ve sayısız başka soyutlamayı getirdi.

Şimdi yapay zekâ, geliştirme sürecini yeniden şekillendiriyor.

Her kuşak, dünün zor işini kolaylaştıran araçları devralıyor.

Bu ilerlemedir.

Ama araçlarımızdaki ilerleme, anlayışımızdaki ilerlemeyi kendiliğinden garanti etmez.

Ve belki de yapay zekâ çağının en ilginç sorusu şu değil:

Makinelere bizim için ne kadar çok şey yaptırabiliriz?

Şu:

Zorunda olmadığımızda bile neyi hâlâ kendimiz öğrenmeyi, anlamayı ve yaratmayı seçeceğiz?

Çünkü teknolojinin nihai amacının insanı her şeyden çıkarmak olduğuna inanmıyorum.

Amaç, insan zekâsına keşfetmek, sorgulamak, hayal etmek ve anlamlı şeyler başarmak için daha fazla alan açmak.

Otomasyon angaryayı kaldırıp daha derin problemleri araştırmamıza izin veriyorsa, olağanüstü bir şey kazanıyoruz.

Herhangi bir şeyi anlama güdüsünü kaldırıyorsa, kolaylığın beklemediğimiz bir bedeli olduğunu keşfedebiliriz.

Zahmetsiz yazılım geliştirme vaadini daha önce görmüştüm.

Bu sefer araçlar sahiden farklı.

Ama sorumluluk tanıdık.

Yapay zekâ çağının en önemli becerisi, bir makineye nasıl kod yazdırılacağını bilmek olmayabilir.

Makineye sormayı ne zaman bırakıp kendimiz düşünmeye başlayacağımızı bilmek olabilir.

---

Kaynaklar ve Ek Okuma

1. Microsoft (1991). The History of Microsoft — 1991. 20 Mayıs’taki Windows için Visual Basic duyurusunun resmî tarihçesi. Microsoft Learn

2. Microsoft (1998). Microsoft Introduces Visual Basic 6.0. Resmî duyuru, 15 Haziran 1998. Microsoft News

3. Embarcadero. Delphi Innovation Timeline. Delphi 1 (1995) ve Delphi 2 (1996) için tarihî ayrıntılar. Delphi History

4. Risko, E. F., & Gilbert, S. J. (2016). Cognitive Offloading. Trends in Cognitive Sciences, 20(9), 676–688. DOI: 10.1016/j.tics.2016.07.002

5. Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779. DOI: 10.1016/0005-1098(83)90046-8

6. Lee, H.-P., vd. (2025). The Impact of Generative AI on Critical Thinking. Proceedings of CHI 2025. DOI: 10.1145/3706598.3713778

7. Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. Araştırma raporu

8. METR (2026). We Are Changing Our Developer Productivity Experiment Design. 24 Şubat 2026. Araştırma güncellemesi