Önceki bir makalede, DALL-E ve Imagen gibi modellerin fikirleri teknikten nasıl ayırdığını yazmıştım. Geçmişte, herhangi bir alanda iyi bir fikriniz varsa, bu fikri ancak onu destekleyecek ustalığa ve tekniğe sahipseniz gerçekleştirebilirdiniz. DALL-E ile bu artık doğru değil. “Bana bir ata saldıran bir aslanın resmini yap” diyebilirsin ve bu, mutlu bir şekilde bir tane oluşturacaktır. Belki bir sanat müzesindeki kadar iyi değil ama tuval, boya, fırça hakkında hiçbir şey bilmenize, kıyafetlerinizi boyatmanıza gerek yok.
Ancak bu, bazı önemli soruları gündeme getiriyor. Uzmanlık ve fikir arasındaki bağlantı nedir? Teknik, fikir oluşturmanıza yardımcı olur mu? (Viktorya dönemi sanatçısı William Morris’in “Malzemelerde direnç olmadan sanata sahip olamazsınız” dediği sık sık alıntılanır, ancak yalnızca daktilolara olan nefretinden söz etmiş olabilir.) Ve ne tür kullanıcı arayüzlerinin işbirlikleri için etkili olacağı. insanlar ve bilgisayarlar arasında, bilgisayarların tekniği sağladığı ve bizlerin fikirleri sağladığı yer neresidir? DALL-E’nin olağanüstü bir şey yapmasını sağlayacak komutları tasarlamak, pigmentleri ve fırçaları anlamaktan çok farklı yeni bir tür teknik gerektirir. Bu yeni teknik ne tür yaratıcılığı mümkün kılıyor? Bu çalışmaların öncekilerden ne farkı var?
Daha hızlı öğrenin. Daha derin kaz. Daha uzağa bakın.
Sanat hakkında konuşmak ne kadar ilginç olsa da, bu soruların daha acil olduğu bir alan var. GitHub Copilot (GPT-3’ten türetilen Codex adlı bir modele dayanarak), kullanıcının yazdığı yorumlara dayalı olarak bir dizi programlama dilinde kod üretir. Diğer yöne giden GPT-3, kodu açıklama konusunda şaşırtıcı derecede iyi olduğunu kanıtladı. Yardımcı pilot kullanıcılarının hala programcı olmaları gerekir; Copilot’un sağladığı kodun doğru olup olmadığını ve onu nasıl test edeceklerini bilmeleri gerekir. İstemlerin kendileri gerçekten bir tür sözde koddur; Programcıların dilin sözdiziminin ayrıntılarını veya kitaplık işlevlerinin adlarını hatırlamaları gerekmese bile, yine de programcılar gibi düşünmeleri gerekir. Ama bunun trend olduğu yer belli. Geleceğin programcılarından ne kadar “teknik” isteyeceğimizi kendimize sormalıyız: 2030’larda veya 2040’larda insanlar geleceğin bir Yardımcı Pilotuna bir programın ne olmasını istediklerini söyleyebilecekler mi? Daha da önemlisi, gelecekteki programcıların ne tür üst düzey bilgiye ihtiyacı olacak? Başarmak istedikleri şeyin doğasına daha fazla ve kod yazmanın sözdizimsel ayrıntılarına daha az odaklanabilecekler mi?
Pek çok yazılım uzmanının “Elbette C. Veya Java bilmeniz gerekir. Veya Python. Veya Scala.” Ama bu doğru mu bilmiyorum. Daha önce burada bulunduk. 1950’lerde bilgisayarlar makine dilinde programlandı. (Ve ondan önce kablolar ve fişlerle.) Şimdi hayal etmek zor, ancak ilk programlama dillerinin –Fortran, COBOL ve benzerlerinin– piyasaya sürülmesi, makineyi anlamanız gerektiğini düşünen programcıların direnişiyle karşılaştı. Artık neredeyse hiç kimse makine dilinde veya montajcıda çalışmıyor. Makine dili, işletim sistemi içindeki bazı özel alanlarda çalışması gereken veya bazı tür gömülü sistem kodu yazması gereken birkaç kişi için ayrılmıştır.
Başka bir dönüşüm için ne gerekli olurdu? Copilot gibi araçlar, ne kadar kullanışlı olursa olsun, devralmaya hazır değil. Hangi yeteneklere ihtiyaçları olacak? Bu noktada, programcılar yine de Copilot tarafından oluşturulan kodun doğru olup olmadığına karar vermelidir. (Genellikle) bir C veya Java derleyicisinin çıktısının doğru olup olmadığına karar vermek zorunda değiliz ve aynı kaynak kodu verildiğinde derleyicinin aynı çıktıyı üretip üretemeyeceği konusunda endişelenmemize gerek yok. Yardımcı pilot bu garantiyi vermez – ve yapsa bile, modelde yapılacak herhangi bir değişiklik (örneğin, yeni StackOverflow sorularını veya GitHub depolarını dahil etmek için) çıktısını büyük olasılıkla değiştirecektir. Bir dizi Yardımcı Pilot isteminden bir program derlemeyi kesinlikle hayal edebiliyor olsak da, kaynak kodunda değişiklik yapılmadan yeniden derlenirse çalışmayı bırakması muhtemel bir program hayal edemiyorum. Belki de tek istisna, bir kez geliştirilebilen, daha sonra test edilen, doğrulanan ve değişiklik yapılmadan kullanılabilen bir kitaplık olabilir – ancak bir hata veya güvenlik açığı bulunduğunda geliştirme sürecinin sıfırdan yeniden başlaması gerekir. Bu kabul edilebilir olmazdı; hiçbir zaman hatası olmayan veya asla yeni özelliklere ihtiyaç duymayan programlar yazmadık. Çoğu modern yazılım geliştirmenin arkasındaki temel ilke, hataları düzeltmek veya özellikler eklemek için değiştirilmesi gereken kod miktarını en aza indirmektir.
Programlamanın tamamen yeni kod oluşturmakla ilgili olduğunu düşünmek kolaydır. değil; Her profesyonelin çabucak öğrendiği bir şey, işin çoğunun eski kodu korumaya gitmesidir. Yeni nesil programlama araçları bunu hesaba katmalıdır, yoksa Copilot gibi bir aracın yeni kod yazmak için kullanılabileceği garip bir durumda kalırız, ancak programcıların yine de bu kodu ayrıntılı olarak anlaması gerekir çünkü yalnızca elle muhafaza edilmelidir. (Programcıların yazılım tedarik zincirlerini araştırmasına, güvenlik açıklarını keşfetmesine ve hatta muhtemelen düzeltmeler önermesine yardımcı olacak yapay zeka tabanlı araçlara sahip olmamız mümkün – hatta büyük olasılıkla –.) Yapay zeka tarafından oluşturulan sanat hakkında yazan Raphaël Millière, “Hiçbir istem üretmeyecek. iki kez aynı sonuç”; sanat eseri için arzu edilebilir, ancak programlama için yıkıcıdır. İstikrar ve tutarlılık, yeni nesil programlama araçları için bir gerekliliktir; geri adım atamayız.
Daha fazla kararlılık ihtiyacı, Copilot gibi araçları serbest biçimli İngilizce dil istemlerinden bir tür daha resmi dile yönlendirebilir. DALL-E için hızlı mühendislik hakkında bir kitap zaten var; bir bakıma, bu, görüntü oluşturmak için resmi bir dili tersine mühendislik yapmaya çalışıyor. İstemler için resmi bir dil, muhtemelen bir farkla birlikte, geleneksel programlama yönünde bir geri harekettir. Mevcut programlama dilleri, bilgisayarın ne yapmasını istediğinizi adım adım ayrıntılı bir şekilde açıklamakla ilgilidir. Yıllar geçtikçe, kademeli olarak daha yüksek soyutlama seviyelerine geçtik. Bir dil modelini bir derleyiciye inşa etmek, programcıların sadece ne yapmak istediklerini tanımladıkları ve makinenin kararlılık garantisi verirken uygulama hakkında endişelenmesine izin verdiği daha basit bir dilin oluşturulmasını kolaylaştırabilir mi? Web’den önce, grafik arayüzlerle uygulamalar oluşturmanın ve bu uygulamaların İnternet hakkında iletişim kurmasının mümkün olduğunu unutmayın. Web (ve özellikle HTML), programlama gerektiren görevleri kapsayan yeni bir resmi dil ekledi.
Şimdi bir veya iki seviye yukarı çıkalım: kod satırlarından işlevlere, modüllere, kitaplıklara ve sistemlere. Copilot ile çalışan tanıdığım herkes, kullandığınız programlama kitaplıklarının ayrıntılarını hatırlamanız gerekmese de, neyi başarmaya çalıştığınızın daha da farkında olmanız gerektiğini söyledi. Ne yapmak istediğinizi bilmelisiniz; aklında bir tasarım olmalı. Yardımcı pilot, düşük seviyeli kodlamada iyidir; Bir programcının yüksek seviyeli tasarım hakkında düşünmek için düşük seviyeli kodlama zanaatıyla temas halinde olması gerekir mi? Şimdiye kadar bu kesinlikle doğruydu, ancak büyük ölçüde zorunluluktan: Daha küçük sistemler inşa etmeyen birinin büyük bir sistem tasarlamasına izin vermezdiniz. (Dave Thomas ve Andy Hunt’ın The Pragmatic Programmer’da tartıştığı gibi) farklı programlama dillerini bilmenin size sorunları çözmek için farklı araçlar ve yaklaşımlar sağladığı doğrudur. Yazılım mimarisi zanaatı, programlama zanaatından farklı mıdır?
Yazılım tasarımını tanımlamak için gerçekten iyi bir dilimiz yok. UML gibi girişimler en iyi ihtimalle kısmen başarılı olmuştur. UML hem fazla hem de az tanımlanmış, fazla kesin ve yeterince kesin değildi; UML diyagramlarından kaynak kod iskelesi oluşturan araçlar mevcuttur, ancak bu günlerde yaygın olarak kullanılmamaktadır. Daha sonra programcılar tarafından uygulanabilecek iskele tanımlı arayüzler, sınıflar ve yöntemler. Bir sistemin yapısını otomatik olarak oluşturmak kulağa iyi bir fikir gibi gelse de, pratikte işleri daha da zorlaştırmış olabilir: eğer üst düzey spesifikasyon değiştiyse, iskele de değişti ve iskele ile uygulamaya konan herhangi bir işi geçersiz kıldı. Bu, derleyicinin farklı bir anahtara modüle edilmiş kararlılık sorununa benzer. Bu, AI’nın yardımcı olabileceği bir alan mı?
En azından UML’nin öngördüğü gibi, hala kaynak kod iskelesi istemediğimizden şüpheleniyorum; bu, sistemin tanımındaki herhangi bir önemli değişiklikle değişmek zorundadır. İstikrar sorun olmaya devam edecek. Ancak, bir sistemin gereksinimlerinin sözlü bir tanımını alabilen ve daha sonra Copilot gibi büyük bir yazılım sistemleri kitaplığına dayalı, ancak daha yüksek bir düzeyde bir tür tasarım üretebilen AI tabanlı bir tasarım aracına sahip olmak değerli olabilir. O zaman sorun, bu tasarımı, bazıları Copilot gibi bir sistem tarafından oluşturulabilecek (veya en azından önerilebilecek) tasarımın uygulamalarıyla bütünleştirmek olacaktır. Karşılaştığımız sorun, yazılım geliştirmenin iki düzeyde gerçekleşmesidir: üst düzey tasarım ve orta düzey programlama. İkisini entegre etmek, ikna edici bir şekilde çözülmemiş zor bir problemdir. Üst düzey bir tasarım almayı, ona açıklamalarımızı eklemeyi ve orta düzey ayrıntılara sahip üst düzey tasarımdan doğrudan yürütülebilir bir programa geçmeyi hayal edebilir miyiz? Bu programlama ortamı, büyük bir projeyi daha küçük parçalara ayırma yeteneğine ihtiyaç duyacaktır, böylece programcı ekipleri işbirliği yapabilir. Bu açıklamaları uygulayan nesneler ve yöntemler üzerindeki çalışmayı kesintiye uğratmadan, üst düzey açıklamalarda değişikliklere izin vermesi gerekir. Kod satırları için olduğu gibi İngilizce açıklamalar için de etkili olan bir sürüm kontrol sistemi ile entegre edilmesi gerekir. Bu, istikrar garantisi olmadan düşünülemezdi.
Programlamadan “zanaat” olarak bahsetmek bir süre modaydı. Bence moda azaldı, muhtemelen daha iyisi için; “Code as craft” bana her zaman biraz değerli gelmiştir. Ancak “zanaat” fikri hala faydalıdır: zanaatın nasıl değişebileceğini ve bu değişikliklerin ne kadar temel olamayacağını düşünmek bizim için önemlidir. Sadece birkaç uzmanın C veya Java veya Python gibi dilleri bilmesi gereken bir dünyadan çok uzakta olduğumuz açık. Ancak Copilot gibi gelişmelerin bize bir sonraki adımın ne olabileceğine dair bir fikir vermesi de mümkün. Alan Kay, 1960’lardan bu yana pek değişmeyen programlama araçlarının durumundan şikayet ederek Quora’ya şöyle yazdı: “programlamanın ulaşması gereken bir sonraki önemli eşik, programların ve programlama sistemlerinin hem ne denediklerini çok daha derinden anlamalarıdır. yapmaları ve gerçekte ne yaptıkları.” Hedeflememiz gereken hedef, sözdizimsel ayrıntılara daha az ve inşa ettiğimiz sistemlerin neyi başarmaya çalıştığını anlamaya odaklanan yeni bir programlama sanatıdır.