Yazılım Anlayışımızdan Daha Hızlı Büyüdüğünde

Bir kodlama ajanına görev veriyorsunuz. Kısa süre sonra özellik çalışıyor, testler geçiyor. Değişiklikler onlarca dosyaya yayılıyor, yeni yapılar ekliyor ve siz açıkça istemediğiniz birkaç sorunu da düzeltiyor.

Sonuç iyi görünüyor. Birkaç denemede belirgin bir sorun çıkmayınca sonraki göreve geçiyorsunuz.

Fakat bazı sorular yanıtsız kalıyor. Neden bu uygulama seçildi? Hangi davranışlar sizin gereksinimlerinizden, hangileri ajanın tercihlerinden doğdu? Sistemin bu bölümünü yeniden değiştirdiğinizde nelerin korunması gerekiyor?

Yazılım ilerledi. Sizin anlayışınız ise başladığınız yerde kaldı.

1. Yazılım değişirken onu anlamaya devam etmek

Yazılım kod ve çalışan süreçler olarak var olur; aynı zamanda onu şekillendiren insanların zihnindeki anlayışta da yaşar. Ne işe yarıyor? Neden böyle çalışıyor? Hangi kararlar korunmalı, hangileri değişebilir? Yazılımı zaman içinde şekillendirmeyi sürdürmemizi sağlayan bu anlayıştır.

Bu anlayışın uygulamanın her ayrıntısını kapsaması gerekmez. Tek tek işlevleri tanımıyor olsanız da yazılımın neye dönüşmesi gerektiğini bilebilir, bir değişikliğin niyetinize hizmet edip etmediğini değerlendirebilir ve etmediğinde müdahale edebilirsiniz.

Geleneksel geliştirme süreçlerinde karmaşıklık ve ekipteki değişimler, anlayış ile uygulamayı birbirinden uzaklaştırabilir. Yine de tasarlamak, kod yazmak, hata ayıklamak ve gözden geçirmek, çalışırken anlayışımızı kurup düzeltmemiz için tekrar tekrar fırsat verir.

Kodlama ajanları tempoyu değiştiriyor. Eskiden doğrudan katılımımızı gerektiren birçok adımı atlayıp kendi başlarına kapsamlı uygulamalar ortaya koyabiliyorlar. Yazılım değişmeye devam ediyor. Bizim anlayışımız aynı hızda değişmeyebilir.

Önce özellik geliyor; onu anlamak sonraya kalan bir göreve dönüşüyor. Değişiklikleri okuyun. Nedenini sorun. Başka neleri etkilediğini çözün. Bu işler, kod yazmaktan kazanılan zamanın bir bölümünü dolduruyor. Ajan üretmeye devam ettikçe anlamamız gereken şeylerin birikimi de büyüyebiliyor.

Daha zor bir uyum süreci de var: Yazılım tam istediğiniz gibi ilerlerken size giderek yabancılaşabilir. Gününüzü görevler vererek, soruları yanıtlayarak ve sonuçları kontrol ederek geçiriyorsunuz. Her ajan ilerliyor, fakat bu değişikliklerin birbirine nasıl uyduğunu anlamak yine size düşüyor. Bir şeyi kendiniz geliştirirken oluşan, onun nerede durduğunu ve sonra nasıl değiştirileceğini bilme duygusu, görevler tamamlanınca kendiliğinden gelmiyor.

Kendi çalışmanız size yavaş yavaş yabancı gelmeye başlıyor. Ne istediğinizi hatırlıyorsunuz; ama sonucun neden böyle olduğunu, önceki kararların hâlâ geçerli olup olmadığını veya sıradaki değişikliğin neleri etkileyeceğini açıklamak zorlaşıyor. Ne geliştirdiğinizi, neden böyle çalıştığını ve nasıl değiştirileceğini bilmenin sürekliliği bozulmaya başlıyor. Onu şekillendirmeyi sürdürmek de zorlaşıyor.

2. Daha iyi yapay zekâ karar verme hakkını ortadan kaldırmaz

Doğal bir tepki, modelleri daha güvenilir hâle getirmektir: daha iyi kod, hataları daha iyi saptama, daha kapsamlı doğrulama. Model yeterince iyi olursa insanların yaptıkları işin neye dönüşmesi gerektiğini anlamasına ve buna karar vermesine hâlâ ihtiyaç var mı?

Kendi işimize yön verme hakkımız, yapay zekânın hata yapmaya devam etmesine bağlı değildir.

“Yapay zekâ kodu yazabilir ama mimariyi yine insanlar tasarlamalı.” Bu yanıt, rolümüzü şu anda üstün olduğumuz bir beceriye bağlıyor. Ya modeller mimarlıkta da çok iyi hâle gelirse? Doğrulamaya veya sistemi anlamaya çekilmek aynı soruya çıkar: Model bunda da iyileştiğinde katılmak için gerekçemizi kaybeder miyiz?

Bu düşünceyi sonuna kadar götürelim. Yapay zekânın genel zekâya ulaştığını varsayın. Karmaşık sistemleri anlıyor, mükemmel teknik kararlar veriyor ve uygulamaları bizden daha kapsamlı kontrol ediyor. O zaman yarattığımız şeye ilişkin her kararı ona mı devretmeliyiz?

Bir kişi kendi niyetine göre yaratmak ve işinin yönünü seçmek istediği sürece bu soru geçerliliğini korur.

Daha iyi karar verebilmek, tek başına, başkası adına karar verme hakkı tanımaz.

Belirli bir kararı kendinize ayırırken birçok değerlendirmeyi yapay zekâya devretmeyi seçebilirsiniz. Tavsiye alabilir, fikrinizi değiştirebilir veya önceki bir kararınızın yanlış olduğunu kabul edebilirsiniz. Önemli olan, yazılımın çoktan değiştiğini sonradan öğrenmek yerine bilgiye dayanarak seçim yapmanızdır.

Kendi işinize yön verme hakkınız, yapay zekâdan daha yetenekli olmanıza bağlı değildir. Bu hakkı kullanmak isteyen insan sayısına da bağlı değildir. Neredeyse herkes her şeyi devretmekten memnun olsa bile, bunu istemeyen kişinin yazılımının neye dönüşeceğine karar verme hakkı sürer.

İşinin yazarı olarak kalmak isteyen tek bir kişi olduğu sürece niyetinin nasıl geçerli kalacağı sorusuna yanıt bulmamız gerekir.

3. Yazılımınızı şekillendirmeyi sürdürmek için gerekenler

Yazarlık, ilk fikir çalışan yazılıma dönüştüğünde bitmez. Önemli tercihleri anlayabilmeniz, yön değiştirebilmeniz, niyetinizle çelişen sonuçları reddedebilmeniz ve çalışmayı gözden geçirmeyi sürdürebilmeniz gerekir. İşe yön verme hakkının pratik yeteneklere dönüşmesi gerekir.

Ajan işini bitirdiğinde sonucun içerdiği önemli tercihleri bilmeden yalnızca “Kabul Et” düğmesine basabiliyorsanız kontrolünüz sınırlıdır. Bir sonucu reddedebiliyor ama nasıl değiştireceğinizi bulamıyorsanız veya dün açıkça belirttiğiniz gereksinim bugünkü uygulamada sessizce geçersiz hâle geliyorsa durum aynıdır. Çalışmayı onaylamaya devam ederken onu niyetinize göre şekillendirme yeteneğinizi kaybedebilirsiniz.

Bu yeteneği korumak, bazı somut soruları yanıtlayabilmek demektir:

• Yazılımın neye dönüşmesi gerektiği hâlâ açık mı?
• Mevcut uygulamanın gereksinimlerinizi nasıl karşıladığını görebiliyor musunuz?
• Sizin önemli kararlarınızı ajanın tercihlerinden ayırabiliyor musunuz?
• Yön değiştirirken olası etkileri anlayıp müdahale edebiliyor musunuz?
• Sonraki uygulama değişikliğinden sonra açıkça verdiğiniz kararlar geçerliliğini koruyacak mı?

Açık bir gereksinimi olan kişisel bir yazma aracı düşünün: içeriği yerel cihazda tutmak. Dosya düzenini, depolama uygulamasını ve birçok iç ayrıntıyı ajana bırakıyorsunuz. Daha sonra araç cihazlar arasında daha kolay kullanılsın diye ajan bulut eşitlemesi öneriyor.

İçeriğin cihazdan çıkıp çıkamayacağı, daha önce verdiğiniz bir karara dokunur. Bu tercihin görünür olması ve onu kabul ya da reddetmeden önce neleri değiştirdiğini anlamanız gerekir. Bir sonuç, özgün gereksinimden uzaklaşırken daha kullanışlı ve daha güvenilir olabilir.

Testler, yazılımın belirli bir şekilde davrandığını göstermeye yardımcı olur. Yine de bu davranışın kabul edilebilir olup olmadığına ve korumak istediğiniz kararlara uyup uymadığına sizin karar vermeniz gerekir.

Ajan eşitlemeyi uygulayabilir, verilerin doğru aktarıldığını kontrol edebilir ve hataları düzeltebilir. Fakat içeriğin cihazdan çıkması gerekip gerekmediği, bu değişikliği kabul etmek için hangi kanıtların yeterli olduğu ve bir şey ters giderse sorumluluğun kimde olduğu, uygulamanın ötesinde açık yanıtlar gerektirir. Değerlendirmeniz, yalnızca her şey bittikten sonra atılan bir imza olmak yerine çalışmanın nereye gideceğini ve ne zaman duracağını belirlemelidir.

Bu iddiaları Noea'da pratik olarak incelemek için Açıklamaları ve kanıtları okuyun bölümüne bakın. Kılavuz, uygulama açıklamalarını, destekleyici kanıtları ve hâlâ sizin değerlendirmenizi gerektiren tercihleri birbirinden ayırır.

4. Tüm kodu okumak yazarlığı koruyabilir mi?

Kod incelemesi doğrudan bir yanıt sunar. Kodu ajan yazar; insan onu okuyup ne yaptığını kontrol eder.

Kod, modelin raporunda hiç değinmediği davranışları, bakım işini etkileyen yapıları ve ancak uygulamayı yakından inceleyerek değerlendirebileceğiniz sorunları içerebilir.

Fakat üretim hızlandıkça her değişikliği okumak, kontrolü elde tutmanın sürdürülebilir bir yolu olabilir mi?

Satır satır okumasanız da gününüz dolu olabilir: belirsiz gereksinimleri netleştirmek, sonucun nerede amaçtan uzaklaştığını fark etmek, doğruluğu hangi kanıtların göstereceğine karar vermek ve ajanı yeniden yönlendirmek. Her adım deneyim ve yoğun dikkat ister. Hem çok az kod okumak hem de yoğun çalışmak mümkündür.

Kod okumak, anlayış geliştirme fırsatıdır da. Bir çalışma arkadaşının değişikliklerini incelemek, ekibin sistemin artık ne yaptığını, neden böyle tasarlandığını ve gelecekteki değişikliklerde nelere dikkat edilmesi gerektiğini öğrenmesine yardımcı olur. Daha az kod okuyacaksak bu anlayışı geliştirmenin başka yollarına ihtiyacımız var.

Öte yandan değişiklikler biriktiğinde ve insanlar onaylamadan önce ancak göz gezdirebildiğinde, inceleme sürecini korumak anlayışı da mutlaka korumaz. Sınırlı dikkatimizi değerlendirme gerektiren yerlere yöneltmeliyiz: sonuçları önemli tasarım ödünleşmeleri, geniş etkili değişiklikler ve hâlâ belirsiz kalan sonuçlar.

Hangi tercihleri zaman içinde anlamaya devam etmemiz gerekiyor? Hangi uygulama ayrıntılarını ihtiyaç doğduğunda araştırabiliriz? Gerçekten bizim kararımızı gerektiren konuları kaçırırken bütün dikkatimizi ayrıntılara harcamaktan nasıl kaçınırız?

5. Kodu uzun şartnamelerle değiştirsek ne olur?

Başka bir yanıt, çalışmamızı doğal dile taşımaktır. Yazılımın nasıl davranması gerektiğini anlatıp şartnameyi bir ajana uygulatabiliriz. Ya da ajandan kodu açıklamasını isteyerek sistemi daha kolay okunabilen bir belgeye dönüştürebiliriz.

Açık gereksinimler yanlış anlamaları azaltır. Belgeler bağlamı korur. İyi bir açıklama, yabancı olduğumuz koda yaklaşmayı kolaylaştırır. Fakat doğal dil, okumanın maliyetini ortadan kaldırmaz.

Yazılım çok sayıda davranış ve ödünleşme içeriyorsa bunların hepsini anlatan belge uygulamayla birlikte büyüyebilir. Okunacak çok fazla koddan okunacak çok fazla düzyazıya geçebiliriz. Her cümle karşılık gelen koddan daha kolay anlaşılsa bile toplamı yine zamanımızı ve dikkatimizi aşabilir.

Üstelik ajan şartnameyi genişletmeye devam ederken biz yalnızca onay veriyorsak ona insan tarafından onaylanmış belge demek, içindeki her kararın bir insan tarafından anlaşıldığını göstermez.

Yazılımın gerçekte ne yaptığı, ajanın ne yaptığını söylediği ve bizim gerçekten anlayıp arkasında durmayı seçtiğimiz şey birbirinden farklı üç konudur.

Eksiksiz bir kayıt ve kapsamlı bir açıklama bile yazılımı nasıl şekillendirmeye devam edeceğimiz konusunda bizi belirsizlik içinde bırakabilir. Önemli olanı bulabilmeli, bunun mevcut uygulamada nasıl karşılandığını anlayabilmeli ve sonraki değişiklikte hangi seçeneklere sahip olduğumuzu görebilmeliyiz.

Niyeti yararlı tutmak her ayrıntıyı belgelemeyi gerektirmez. Önemli bir niyet yazın, kalıcı gereksinimleri ifade etmeyi ve bunları mevcut çalışma turunun görevlerinden ayırmayı gösterir.

Yazarlığı insanların elinde tutmak

Uygulamanın maliyeti düştükçe daha çok insan fikirlerini yazılıma dönüştürebilir. Yarattıklarını anlayabilmeli ve şekillendirmeye devam edebilmeliler.

Bu özgürlük yazılımın ötesine uzanır. Her yaratıcı işte, o işi yaratan kişi neyi yapay zekâya devredeceğini ve neye kendisinin karar vereceğini seçebilmelidir.

Finite Ground'un amacı, insanların kendi niyetlerine göre yaratmasına ve yapay zekâ olanakları genişletirken işlerini şekillendirmeyi sürdürmesine yardımcı olmaktır.

Noea bu amacı yazılıma taşır; uygulama değişmeye devam ederken insanların niyetinin geçerliliğini korur.

Bir gün yapay genel zekâ insan yaşamının her alanını devralır ve herkes özerkliğinden vazgeçerse bu soru artık geçerli olmayacak. Finite Ground'un da var olmak için nedeni kalmayacak.

Özerkliğinden vazgeçmek istemeyen tek bir kişi olduğu sürece devam etmek için bir neden var.

Yapay zekâ daha fazla fikri dünyaya taşıyabilir. Bu fikirlerin neye dönüşeceğine karar verme hakkı, bu hakkı korumayı seçen insanlara aittir.

Tek bir incelemeyle başlayın

Mevcut bir projede tek bir kural seçin ve İlk incelemeniz kılavuzunu izleyin: gereksinimi yazın, uygulamayı ve kanıtları inceleyin, gelecekteki değişiklikler için bir karar kaydedin.

Noea'yı ve bir ajanı henüz hazırlamadıysanız Kurun ve hazırlanın kılavuzuyla başlayın.