Yeni GitHub Copilot araştırması, “kod kalitesi üzerinde aşağı yönlü baskı” tespit etti
(visualstudiomagazine.com)- GitClear’ın Coding on Copilot teknik raporu, yapay zeka destekli kodun üretkenliği artırırken kalite ve bakım yapılabilirlik üzerinde yük oluşturup oluşturmadığını kod değişikliği verileriyle analiz ediyor
- Yazıldıktan sonraki 2 hafta içinde geri alınan veya değiştirilen code churn oranının, yapay zeka öncesi 2021 temel seviyesine kıyasla 2024’te iki katına çıkması bekleniyor
- Copilot’ın yaygınlaşmasının ardından eklenen kod ve kopyala/yapıştır kod oranı arttı; taşınan kodun azalması ise refactoring ve yeniden kullanımın zayıfladığına işaret ediyor
- GitHub’ın 2022 araştırması, Copilot kullanıcılarının işleri %55 daha hızlı tamamladığını ortaya koymuştu; GitClear ise üretkenlikten çok uzun vadeli bakım maliyetine odaklanıyor
- Ocak 2020’den Aralık 2023’e kadar yazılmış 153 milyon satırlık değişen kod analizi, teknoloji liderlerinin yapay zeka benimsemenin etkisini kod kalitesi metrikleriyle değerlendirmesi gerektiğini gösteriyor
GitClear teknik raporunun gözünden yapay zeka destekli kodun niteliği
- Coding on Copilot teknik raporu, yapay zeka destekli kodun bir insanın yazacağı kodla karşılaştırıldığında kalite ve bakım yapılabilirlik açısından nasıl farklılaştığını inceliyor
- Temel soru, yapay zeka destekli kodun özenle işlenmiş kıdemli geliştirici katkısına mı, yoksa kısa süreli bir yüklenicinin kopuk işlerine mi daha yakın olduğu
- GitClear, bulut tabanlı kod inceleme aracı satan bir şirket; bu araştırma ise yapay zeka kullanımından sonra kod değişikliklerinin bileşiminin nasıl değiştiğine odaklanıyor
Bakım yapılabilirlikte görülen olumsuz sinyaller
- GitClear, bakım yapılabilirlik açısından endişe verici bir eğilim tespit etti
- Code churn, yazıldıktan sonraki 2 hafta içinde geri alınan veya güncellenen kod satırlarının oranıdır
- Bu oranın, yapay zeka öncesi 2021 temel seviyesiyle karşılaştırıldığında 2024’te iki katına çıkması bekleniyor
- Eklenen kod ve kopyala/yapıştır kod oranları, değiştirilen, silinen ve taşınan koda kıyasla artıyor
- Bu değişimler nedeniyle yapay zeka tarafından üretilen kod, ziyaret ettiği repository’nin DRY ilkesini ihlal etmeye yatkın gezici katkı sağlayıcılara benzetiliyor
Copilot’ın yaygınlaşmasıyla bağlantılı üç değişim
- GitClear, Copilot’ın benimsenmesinden sonra öne çıkan önemli değişimler olarak churn, taşınan kod ve kopyala/yapıştır kodu gösteriyor
-
Artan churn
- “Copilot kullanımı”nın repository’ye hatalı kod push edilmesiyle güçlü şekilde ilişkili olduğu değerlendiriliyor
- Bu durum, yapay zeka destekli kodun hızla eklenip kısa süre içinde geri alınması veya değiştirilmesi akışıyla bağlantılı
-
Azalan taşınan kod
- Taşınan kodun azalması, refactoring ve yeniden kullanımın azaldığına işaret ediyor
- Kopyala/yapıştır kod artışıyla birlikte bakıldığında, mevcut yapay zeka asistanı uygulamalarının kod yeniden kullanımını yeterince teşvik etmediği şeklinde yorumlanıyor
- Refactoring ile DRY kod oluşturmak yerine, mevcut kodu tek bir tuş vuruşuyla tekrarlama cazibesi sunuyor
-
Artan kopyala/yapıştır kod
- Kopyala/yapıştır kod, uzun vadeli bakım yapılabilirlik üzerinde büyük yük oluşturan bir unsur olarak değerlendiriliyor
- Anahtar sözcükler değil de kod satırları tekrar ettiğinde, önceki implementasyonu değerlendirecek zaman olmadığının bir işareti olarak yorumlanıyor
- Kod yeniden kullanılmadan tekrar eklenirse, sonraki bakımcıların aynı işlevi gerçekleştiren paralel kod yollarını birleştirmesi gerekir
Üretkenlik araştırmalarıyla karşıtlık
- GitHub’ın 2022 araştırması, Copilot kullanan geliştiricilerin kullanmayanlara göre işleri %55 daha hızlı tamamladığını ortaya koymuştu
- Aynı araştırma, üretkenliğin yanı sıra geliştirici memnuniyeti ve zihinsel enerjinin korunması açısından da olumlu etkiler ölçtü
- GitClear teknik raporu ise bu üretkenlik sonuçlarından farklı olarak, yapay zeka kullanıldığında kod değişikliklerinin bileşimi ve bakım yapılabilirlik tarafındaki değişimlere odaklanıyor
İlgili araştırmaların ortaya koyduğu karışık değerlendirmeler
- Exploring the Verifiability of Code Generated by GitHub Copilot: Copilot güçlü bir araç olsa da tek başına “uçağı uçurmaması” gerektiği yönündeki mevcut literatür uzlaşısıyla uyumlu kanıtlar buldu
- Assessing the Quality of GitHub Copilot's Code Generation: Ampirik analiz sonuçlarına göre Copilot umut vadeden bir araç, ancak gelecekte daha kapsamlı değerlendirmeler gerekiyor
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: Üretken yapay zeka prompt etme becerisi arttıkça insan ile yapay zeka arasında kendine özgü ve ayrıştırılması zor bir bağ oluşuyor
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: Gözlemlenen heterojen etkiler, yapay zeka eşli programcının insanların yazılım geliştirme kariyerine geçmesine yardımcı olma potansiyelini gösteriyor
- Study of software developers' experience using the Github Copilot Tool in the software development process: Geliştirici görüşleri bölünmüş durumdaydı; tutumlar genel olarak olumlu olsa da fiili kullanım niyeti yüksek değildi ve güvenlik sorunları endişe olarak öne çıktı
Analiz kapsamı ve kalan sorular
- GitClear, Ocak 2020’den Aralık 2023’e kadar yazılmış 153 milyon satırlık değişen kodu topladı ve analiz etti
- Yapay zekanın popülerliği hızla artarken, kod satırlarının her zamankinden daha hızlı eklendiği bir döneme girildiği değerlendirmesi de sunuluyor
- 2024’teki soru, Copilot’ın geliştiriciliğin anlamını nasıl değiştireceğinden çok, sonrasında ortaya çıkan temizlik işini kimin üstleneceğine daha yakın
1 yorum
Hacker News yorumları
2 ay kullandıktan sonra aboneliği iptal ettim. Üzerime yağan kod kusmuğundaki hataları düzeltmenin zihinsel maliyeti çok yüksekti; önemsiz olmayan işlerde ya da SQL ile ilgili işlerde, önce tüm şemayı versem bile neredeyse işe yaramıyordu.
Ne yazmak istediğimi bildiğim için kendim yazmak çok daha az yorucuydu; botun hatalarını düzeltmektense kendi hatalarımı düzeltmek daha kolaydı. Bu çöplüğün altında kalacak junior’lar için endişeleniyorum.
Copilot yerine ChatGPT kullanıyorum; yapabildiği şeylerin çokluğuna şaşıyorum ama yine de buna “iyi kod” demek zor. JavaScript’i okuyabiliyorum ama son 14 yıldır iOS üzerinde uzmanlaştığım için tarayıcı tarafındaki en iyi uygulamaları pek bilmiyorum; bu yüzden kullanıyorum. Genelde çalışan kod alsam da kötü tercihleri veya tuhaflıkları görebiliyorum.
Mevcut yapay zeka konusunda “iş çoktan bitti” ya da “hiçbir şey değil” şeklindeki iki uçtan kaçınmanın doğru tavır olduğunu düşünüyorum. İkinciler için şöyle bir benzetme gerekiyor: “Bir köpek jonglörlük yapıyor, vergi beyannamesi dolduruyor ve kek pişiriyor; bunu yapabilmesine hayran kalmak yerine topu düşürdüğünden, sayıları yanlış yazdığından ve tarifin pek iyi olmadığından şikâyet etmek gibi.”
Copilot en çok, öngörülebilir bağlam tabanlı kod yazarken yazmayı azaltan bir otomatik tamamlama aracı olarak işe yarıyor. Bir pencerede enum class yazdığınızda, başka bir penceredeki kullanım yerlerini bağlama göre otomatik tamamlayabiliyor; birim testleri paketi yazarken de tek bir Tab ile sıradaki test vakasının iskeletini çıkarıyor.
Özellikle dinamik dillerde Copilot, IntelliSense’i epey iyi tamamlıyor.
Birkaç ay önce seslendirme sektörünün metinden sese modeller tarafından kaçınılmaz biçimde geriye itilmesini dizgi, ciltçilik ve nota dizgisi örnekleriyle birlikte yazmıştım: https://news.ycombinator.com/item?id=38491203
Ama geliştirme işinin kendisi böyle boşalırsa nihai durumun ne olacağını pek bilmiyorum. Çünkü geçmişteki ikameleri de geliştiriciler mümkün kılmıştı. Bir tür toplumsal gerileme ve çöküş de tamamen akıl dışı görünmüyor.
“Bu JSON’u parse edip ilgili alanları veritabanındaki doğru yerlere koy” Copilot ile SQL yazmak için harika bir kullanım senaryosu. ORM eklentisi ya da middleware de kullanılabilir ama MVP veya mock-up için bu aşırı erken optimizasyon olur.
Buna karşılık ChatGPT API’yi sık kullanıyorum ve oldukça pratik. Milyonlarca satırı etkileyen bir SQL update yazdığımda, bunu partilere bölmesini ve her partiden sonra durum log’u basacak şekilde değiştirmesini istedim; Azure DevOps’ta nuget feed erişiminde 401 aldığımda ise yalnızca nedeni değil, düzelten yaml’ı da verdi.
İkisi de biraz araştırmayla kendim yapabileceğim işlerdi ama o araştırma süresini harcamamak gerçekten güzel.
GPT-4 sayesinde iş verimliliğim ciddi biçimde arttı. Çoğunlukla gündelik iş sorunlarını çözen basit PHP CRUD uygulamaları yapıyorum; framework ya da MVC yapısı kullanmadığım için, net talimatlara dayalı GPT-4 üretimi kodu anlamak kolay oluyor ve genelde doğrudan çalışıyor.
Genelde yaklaşık 25 satırlık kod parçalarını belirli bir raporlama işlevine uyacak şekilde değiştirmesini istiyorum; örneğin bu sayfada X’e göre grupla ve Y’yi topla dediğimde tam isabet tepki veriyor. Hızlı bir QA ve testten sonra iş bitiyor; karmaşıklığın düşük, talimatın net olduğu işlerde oyunun kurallarını değiştirecek kadar etkili.
Bu süreç, senior bir programcının işi temel bileşenlere ayırıp junior’a vermesine benziyor. Burada GPT-4 ayda 20 dolarlık junior programcı rolünü üstleniyor ve zaman kazandırdığı için kendi cebimden memnuniyetle ödüyorum.
Ancak çocukken “hesap makinesi varken neden matematik öğrenmeliyim?” diye sorduğum gibi, artık temel bilgileri neden öğrenmek gerektiğini anlıyorum. Temeli bilmiyorsanız onu etkili kullanamazsınız. PHP öğrenirken GPT-4 olsaydı, temelleri bugün anladığım kadar anlayamazdım. Bu araçlar çıkmadan önce öğrenmiş olmanın faydasını görüyorum.
Kod kalitesinin de özellikle daha düşük olduğunu hissetmiyorum; hatta bazen daha cilalı sonuçlar bile çıkarıyor.
Eleştirilerin çoğu için henüz erken olduğunu düşünüyorum; bunu daha çok ek altyapı desteğine ihtiyaç duyan aksak bir ilerleme olarak görüyorum. Derlenmeyen sonuçlar üretmemesini sağlayacak linter entegrasyonu nerede; düşük zorluktaki hataları otomatik bulup düzelten özellik nerede, diye düşünüyor insan.
Üretken yapay zeka geliştirme ortamında testlerin nasıl görünmesi ve nasıl değişmesi gerektiği de açık bir soru. TDD ya da BDD gibi süreç odaklı yaklaşımlarda faydayı en üst düzeye çıkarıp maliyeti azaltan daha iyi bir yöntem olabilir.
Son 1-2 yıl, büyük bir teknolojik değişimin mevcut iş akışlarına öylece fırlatıldığı bir dönemdi. Her araçta sonuç, aracın kendi kabiliyetiyle onu kullanan kişinin deneyiminin birleşiminden çıkar.
Sektörün, geliştirmeye üretken yapay zekayı entegre etme konusunda çok daha fazla deneyim ve bilgelik biriktirmesi gerekiyor; ancak o zaman gerçek net değeri hissedebiliriz. Teknolojinin uyum sağlamasından değil, insanların uyum sağlamasının aldığı süreden dolayı en az 2-3 yıl daha gerektiğini düşünüyorum.
Kendi yaptığım temel CRUD framework’ünün üstüne 20’li yaşlardaki bir ekibin dağlar kadar full-stack spagetti ürettiğini gördüm bile. 60 saniyede “MMO framework” üretebiliyorsanız, sıfırdan TODO uygulaması yapmayı deneme motivasyonu azalıyor.
Bu, 12 yıl önce ilişkisel temelleri öğrenmeden önce Firebase kullanmam ve temellere ulaşmamın yıllar sürmesine benziyor.
Geleceği tam olarak göremesek de kaliteyi algılama biçimimizin değişeceğine inanıyorum
Elektrikli araçlar, sağlık, BT, finans gibi etrafımızdaki her alanda teknolojinin önemli sorunların kurtarıcısı olacakmış gibi bir hava var. Aynı zamanda teknolojinin çoğunlukla piyasaları, hükümetleri, devletleri vb. büyütmek için kullanıldığı ve zaten sızdıran soyutlamaların üzerine bir katman daha ekleyerek işlediği giderek daha açık hâle geliyor. Sorunları çözmekten çok belirtileri eritmeye çalışıyormuş gibi hissettiriyor
Kalite yavaşlığı da içerir; belirti tedavisinin sınırları vardır ve insanların daha fazla soyutlama eklemeye devam etmesiyle zorlukların üstesinden gelinemeyeceği için o yavaşlığa ihtiyaç duyulacağını düşünüyorum
Daha hızlı olmamız gerektiği fikrinin yanlış olduğunu düşünüyorum. İnsan olarak, karşılaştığımız zorluğun temellerini anlamadan yüzeysel kazanımlar uğruna çözmeye çalışma biçiminden kalite çıkacağına inanmıyorum
LLM alanımız için bir felaket. Çünkü gerçek işi yapmadan hedefe ulaşmak isteyen ortalama insan hatasına yaranıyor. Gerçek iş, doğruluğa dair varsayımları uygulayarak gerçekten neyi çözmeye çalıştığını anlamaktır
Neyse ki herkes daha hızlı gitmeye çalışmıyor; bazıları temelleri yeniden öğreniyor, dikkatli kararlar uyguluyor ve uzun süre dayanacak kaliteyi üretmek için düşüncelerini ve araçlarını keskinleştiriyor
Benim deneyimim neredeyse bunun tersi. Dağınık bir API’yi ya da kütüphaneyi kurcalamak zor kısmın önünü kesmek yerine, LLM anlamlı bir işte düşüncem sağlam olmadığında bunu acı verecek kadar açık biçimde ortaya çıkarıyor
LLM ile bir şey yapmak için yazmak gerekir; yazmak için de düşünmek gerekir. Yapmak istediğim şeyi dikkatle cümlelere dökmek, LLM’in beni dürtmesi ve bu süreçte düşüncemdeki boşlukları bulup netleştirdiğim sohbet geçmişine sonradan tekrar bakabilmek çoğu zaman en faydalı kısım oluyor
Özellikle bir uygulamanın başında şekil verirken, o sırada yapılması gerektiğini düşündüğüm şeyleri izlemek ve daha sonra hâlâ öyle olup olmadığını yeniden değerlendirmek için çok yararlı
Kulüpte profesyonel bir performans dinleyip eve dönünce onu taklit etmeye çalışırlar, ama sonunda temelsiz, karmaşık bir yığın ortaya çıkar. Basit şeyler yapmaktan memnun olmayı ve kademeli olarak daha güçlü bir temel inşa etmeyi vurgulamıştı
Bu içgörü, yapay zekânın ürettiği kodu kullanmaya da neredeyse aynen uygulanıyor
IKEA mobilyaları iyi bir örnek. Kendi mobilyanı yaparsan, IKEA’nın kartonumsu eşyalarına kıyasla onun etrafında bulunmak çok daha iyi hissettirir. Ama insanların zihninde maliyet, hız ve kolaylık en önemli şeylermiş gibi görünüyor
Yapay zeka modeli bu doğuştan gelen deneyimi alıp götürür ve yalnızca nihai sonucun kaymağını verir. Gerçek bir ilişki kurup doyuma ulaşmak yerine porno izlemeye benzer
Akıllıca kullanıldığında Copilot türü araçlar yardımcı olur. Boilerplate’i ve sıkıcı kısımları halledip insanın ağır düşünme işine odaklanmasını sağlar
Üstelik hâlâ erken aşamadayız. Hüküm vermek için çok erken ve ortadan kalkacak gibi de görünmüyor
Metodoloji, 2023’teki commit etkinliğini önceki yıllarla karşılaştırırken bunların ne kadarına Copilot’un dahil olduğunu bilmeden değişimi bir varsayım olarak yorumluyor gibi görünüyor. Epey sallantılı bir yaklaşım
Ayrıca “2024 tahmini, OpenAI’nin gpt-4-1106-preview Assistant’ı ile mevcut verilere ikinci dereceden regresyon uygulanarak yapıldı” deniyor; sklearn, R, Excel gibi basit regresyon araçları yerine GPT’ye 4 veri noktasıyla regresyon mu yaptırdılar diye merak ediyorum. Doğru yapmış olsalar bile 4 veri noktası ve ilk endişe de hesaba katıldığında ikna gücü zayıf
İkinci dereceden regresyon denince kulağa makul geliyor ama iki veri noktası varsa aslında “çizgiyi aynen uzatmak”tan ibaret. Bu yüzden 2024 tahmini özünde neredeyse anlamsız
Asıl araştırmanın yazarıyım. Pek çok kişinin uzun vadeli kod kalitesi konusunda kafa yorduğunu görmek sevindirici. 2023’te churned code ve tekrarın, yani kopyala-yapıştır kodun artması ve moved code’un azalması bizim beklediğimizden de büyüktü.
Geliştirme ekiplerinin ve AI Assistant üreticilerinin, yeni eklenen kod yerine yeniden kullanılan kodu teşvik eden ölçümler ve teşvikler benimsemesini umuyorum. Özellikle performans değerlendirmesine LoC konması gerektiğine inanan yöneticilerin altındaki ekipler risk altında. GitHub araştırmasına göre yaklaşık üçte biri böyle; mevcut nesil kod yardımcı araçları da Tab’a basıp commit ederek geleceğe teknik borç ekmeyi fazlasıyla kolaylaştırıyor. Adam Tornhill’in Twitter’da söylediği gibi, “AI destekli programlamanın temel zorluğu, en başta yazılmaması gereken kodu topluca üretmenin çok kolaylaşmasıdır.”
Ancak mevcut çalışmanın anlamlılığı, AI’ın yazdığı kodu doğrudan ölçmemesi gibi bir sınırlamaya sahip. Yalnızca son 4 yılda kod kalitesi ile AI Assistant’ların yaygınlaşması arasındaki korelasyonu çizdik. GitHub ya da başka bir AI Assistant şirketi sonraki çalışmalara katkı verip “tamamen AI tarafından önerilen kod”, “AI önerisine insanın düzeltme yaptığı kod” ve “sıfırdan yazılan kod” arasındaki kalite farklarını doğrudan ölçebilse iyi olurdu.
Bir sonraki çalışmada AI kullanımına göre hata sıklığının nasıl değiştiğini de doğrudan ölçmek istiyorum. Ölçülse iyi olur dediğiniz başka fikirler varsa lütfen önerin. Yaklaşık 2 ayda bir yeni araştırma makalesi yayımlamaya çalışıyorum.
Kod yeniden kullanımı bir kod tabanı içinde güçlü olabilir, ancak kod tabanları arasında gidip geldiğinde karmaşa yarattığını da gördüm. Faydalı da olabilir, uygunsuz ve kafa karıştırıcı da; sonuç çoğunlukla muhakemeye bağlı.
Geliştiricileri yazılımın sonuçlarına göre değerlendirmek daha iyi bence. Örneğin kaynak kullanımına kıyasla kurumsal etki, bağımlı servislerden ya da altyapıdan kaynaklanmayan servis hataları gibi şeyler.
Modern programcı yalnızca koddan sorumlu biri değil; kalite mühendisi/test uzmanı, teknik ürün yöneticisi, proje yöneticisi, programcı, performans mühendisi ve altyapı mühendisinin bilinçli biçimde harmanlanmış hâli. Araştırmanın kendisini küçümsemek istemiyorum; kod kalitesini derinden önemseyen birinin olmasına sevindim ve değerlendirme biçimini farklı düşünmemiz gerektiğine inanıyorum.
Değişen teknoloji ekonomisi gibi başka olası açıklamaların kontrol edilip edilmediğini de merak ediyorum.
Bu makale, gerçek koddaki refactoring görevlerinde en popüler LLM’lerin performansını kıyaslamış ve AI’ın işlevsel olarak doğru refactoring sunduğu durumların yalnızca %37 olduğunu söylüyor.
AI destekli kodlama gerçekten yararlı, ama deneyimli insanları döngüde tutmaya devam etmek ve pazarlama abartısının ötesinde gerçekçi beklentiler oluşturmak gerekiyor.
Benim iş akışım genelde belgeleri gözden geçirmek, prototip yapmak, kodu biraz toparlamak, test eklemek, taşımak, bozmak, yeniden çalışmak, belgeleri incelemek, daha fazla refactoring yapmak ve ancak ondan sonra problemi yeterince anlayıp kodun %80’ini atarak düzgün biçimde yeniden yapmak şeklinde.
Copilot prototip aşamasında yeterince çalışan kod verip beni doğrudan sonrasına geçmeye iterse, bütünü doğru yapılandıracak kadar derin bir anlayış geliştiremiyorum. İş akışının %90’ını atlamamı sağlıyor ama bunun bir bedeli oluyor. Elbette geliştirmenin son aşamasında Copilot çok yardımcı olabilir.
Araştırma sonucu doğruysa şaşırtıcı değil. Kötü kod yetersiz anlayıştan çıkar ve Copilot benim sağladığımın ötesinde bir anlayışa sahip olamaz. Ortalama bir programcıdan daha iyi kod yazabilir, ama sonuç girdiden daha iyi olamaz. İnsanlar “prompt engineering”e bu kadar odaklanırken, VSCode’un kötü “prompt”unun kötü sonuç üretmesine neden şaşırıyorlar anlamıyorum.
Benim deneyimime göre Copilot başlamak için harika. Kod bazen iyi oluyor, bazen sıradan ya da tamamen bozuk.
Yine de düşünmeye başlamayı sağlaması açısından değerli. Kullanmadan önce çok daha fazla zaman harcıyordum. Beyin devrelerim biraz tuhaf olduğu için de olabilir.
Junior seviyedeyim ve VSCode’a Codeium kurdum; çoğu durumda çok dikkat dağıtıcı. Neden bu kadar çok kişinin bu tür yardımcı araçları kullandığını pek anlayamıyorum.
Phind gibi şeyler işe yarıyor. Anlamadığım bir şey olduğunda, yaklaşık %60 oranında sorunu kavramama yardımcı oluyor. Yorgun olduğum ya da dalgınlıkla görmediğim küçük hataları bulmak gibi.
Öte yandan Codeium, framework boilerplate’i üretirken faydalı olabilir; ama scraper’lar, basit veri pipeline’ları ve saf JS+HTML/CSS kullandığım küçük deneyimlerimde öneriler arasında gezinmek çok sinir bozucu. Özellikle çoğu zaman çalışmıyor; bir argümanın eksik olması gibi küçük nedenler olsa bile sonunda debug için zaman harcamam gerekiyor.
Ayrıca JavaScript’te metotları ve anonim fonksiyonları sonsuz bir papatya zinciri gibi birbirine ekleyen yaygın bir stil var; ben bunu gerçekten zor buluyorum. Satırları bölmeyi, fonksiyonlara ve değişkenlere isim vermeyi tercih ediyorum. Kod önerileri de sık sık bu stili izliyor; eğitim verisi böyle sanırım. Codeium bunun üzerinden öğrendiğini söylüyor ve bazen gerçekten öyle de oluyor.
Beni en çok endişelendiren şey, junior biri olarak kodu bu yardımcı araçlara bırakırsam nasıl öğreneceğim. Phind’e bağlam ve soru vermek öğrenmeye yardımcı oluyor ya da internette kendi başıma nereye bakacağımı gösteriyor; ama sadece Tab’a basarak nasıl öğrenebilirim, bilmiyorum.
Birkaç gün önce, geliştiriciler dahil pek çok insanın LLM’leri daha iyi olmak için bir araç olarak değil, çabanın yerine geçen bir şey olarak kullandığını fark ettim. Şirketlerin yerimizi alması korkusundan bağımsız olarak, öz değerlendirme açısından da korkutucu değil mi diye düşünüyorum.
Kod yazmak hayatımın tutkusu değil ama seviyorum. Çünkü bir şeylerin gerçekleşmesini ve karmaşıklıkla uğraşmayı sağlıyor. Neler olduğunu anlamazsanız bir şey de inşa edemezsiniz; karmaşıklığın sizi ne zaman yutacağını da fark edemezsiniz.
Böyle devam edin; değiştirmezseniz iyi yerlere gideceksiniz. Kesinlikle doğru yoldasınız.
Önemli olan şu: kariyerim boyunca elle o kadar çok API spesifikasyonu yazdım ki 1) sorunu anında görebildim ve 2) ek yardım almadan düzeltebildim. Prompt’u iyileştirmektense modeli elle düzeltmek daha hızlıydı.
İyi bildiğim bir alanda, tüm sabahı alacak bir işi 30 saniyede yaptığını görmek şaşırtıcı. Ama nasıl yapacağımı bilmediğim bir işi yapay zekaya yaptırmıyorum. Bunun yerine üzerinde çalıştığım şeyle ilgili trade-off’lar, olası güvenlik sorunları vb. konularda yapay zekayla çok konuşuyorum.
Kullandığım dilde doktora yapmış bir junior mühendis gibi. Pek çok şeyi anlamıyor; ama anladığı şeyleri derinden anlıyor gibi görünüyor.
Bazı geliştiriciler, özellikle JS geliştiricileri, tek satırda tutmak dışında hiçbir getirisi olmasa da chaining’i seviyor. Bu bir getiri değil. Şimdiki gibi devam edin; bu aptalca deyimin zihninizi enfekte etmesine izin vermeyin.
Bu teknolojinin şaşırtıcı olduğu an, benim stilime ve tercihlerime uyduğu an. İsimlendirmeyi istediğim şekilde yapması, az önce yazdığım metodu tekrar implemente etmek yerine doğru şekilde kullanması gibi.
Boş ya da küçük projelerde pek denemedim; ama çevredeki bağlama dayanarak zaten kullandığım tarza güçlü biçimde eğilmiyorsa, çok daha az ideal hissettireceğini düşünüyorum.
Yapay zeka yardımcılarının en büyük kullanım alanı test yazmak ve “buna benzer ama biraz farklı” türü tekrar eden değişiklikleri hızlandırmaktı. IntelliJ + GitHub’da, yeni bir parametrenin birden fazla metoda ve dosyaya yansıması gereken işlerde bile ilk iki üç varyasyonu elle yazınca sonrası genelde enter + tab ile ilerliyor. Bağlam gerisini dolduruyor.
VSCode’daki Codeium’da yapay zekanın kendisi de daha yetersiz görünüyor; eklenti de öneri ve kabul tuşları sık sık araya girecek şekilde yazılmış gibi. Tekrarlı işlerde hâlâ yardımcı oluyor; ama hedefe nasıl ulaşılacağını önerme konusunda daha zayıf.
ChatGPT ile Django/Python tabanlı bir Yourls klonu yapmayı denemeye karar verdim. Özel kısa URL’lere izin vermesini ve trafiği de izlemesini özellikle söyledim; ama mantıkta ya da veri modelinde bunu doğru dürüst hesaba katmadı. Sonradan düzeltmek için yeniden ayrıntılı talimat vermem gerekti.
Yapay zeka araçları, işi yapan bir junior geliştiriciye benziyor. Sadece çok daha hızlı.
Ne yaptığınızı bilmiyorsanız, yalnızca hata yapma hızınızı artırır.
Yakın zamanda bir SELECT sorgusundaki kolon alias’larına tablo adı öneki eklemem gerekiyordu; böyle bir özellik olmadığı için ChatGPT’ye şema tanımını ve sorguyu verip yaklaşık 40 kolondan oluşan seçim listesini uzun uzun yazmasını istedim.
Birden fazla RDBMS’te bunu otomatikleştirmenin iyi bir yolunu bulamadım; regex ya da başka metin manipülasyonlarıyla da yapılabilirdi, ama problemi anlatıp gereken çıktıyı almak hoş derecede basitti.
Bunun dışında LLM’leri otomatik tamamlama gibi kullanıyorum. İyi fonksiyon adları seçmeye de itiyor; çünkü yalnızca bu kadar bilgiyle bile LLM çoğu zaman makul bir başlangıç noktası veriyor. Özellikle çok kullanmadığım API’lerde veya dillerde, karşılaştığım problem zaten binlerce kez çözülmüş bir şey olduğunda faydalı. StackOverflow’u da neredeyse hiç kullanmaz oldum.
Bu yüzden Copilot satın aldım ve ChatGPT’yi de çok kullanıyorum. LLM’ler; IntelliSense gibi iyi otomatik tamamlama, OpenAPI spesifikasyonu ya da EF/JPA kod üretimi, ER modeline dayalı DB migration/tablo oluşturma, container’lar ve JetBrains gibi akıllı IDE’lerle birlikte en sevdiğim şeylerden biri.
Şirketler daha fazla kodu daha hızlı isteyecek; bu girdabın içinden ne yaptığını gerçekten bilen daha az insan çıkacak gibi görünüyor.
Makalenin tamamı burada: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
“Yapay zeka” yardımcı araçları piyasaya çıkmadan önce bile DRY codea karşı zaten bir tepki vardı ve ne yazık ki 2019-2022 arasında Twitter kullandığım dönemde bu büyüyen bir akımdı
Bazı genç geliştiricilerin, benim öğrendiğimden çok farklı bir kod anlayışı var. Gang of Four’a ve tasarım desenlerine inanılmaz bir küçümsemeyle bakıyorlar; sevdikleri framework’lerin tam da bu desenlerle dolu olduğunun farkında değiller gibi. DRY, özellikle de SOLID gibi ilkeleri alaya alıyorlar
Twitter gibi yerlerde, ne kadar alaycı olup karşı tarafı hedef alan şeyler söylerseniz etkileşim o kadar artıyor. Epey kaygı verici bir akım
Kurumsal codebase’lerde olanlara ben de büyük bir küçümsemeyle bakıyorum. SOLID guruları ne derse desin, sınıflarla katman katman dolaylılık oluşturmak iyi bir şey değil. Best practice’ler, DRY, SOLID sadece bahane olarak kullanılıyor
Java tarzı nesne yönelimli düşünceden çıkan keyfî bir ilkeler listesinin, yazılım modellemenin gerçeğiymiş gibi ele alınmasına katlanamıyorum. SOLID’in nasıl anlaşılması gerektiğine dair bitmek bilmeyen tartışmalardan da bıktım
CAP teoremi hakkında insanlar böyle kavga etmiyor; çünkü o, havalı bir kısaltma oluşturan keyfî fikirler demeti değil
DRY de kötüye kullanılabilir; tepki yalnızca insanların onu kusursuzmuş gibi ele almasına
Örneğin DRY’nin önemli ilkesi kodu tekrar etmeyin değil, fikri tekrar etmeyin idi. Sistemdeki herhangi bir kavram için ideal olarak tek bir doğruluk kaynağı olmalı; o kavramla ilgilenirken anlaşılması ya da değiştirilmesi gereken yer de tek olmalı
Bu yüzden anlamlı bir soyutlama yerine hatırı sayılır miktarda kodu kopyalayıp yapıştırmak çoğu zaman kötüdür. Aynı zamanda, bir fikri tekrar ettiğiniz anda farklı temsilleri senkronize etmeniz gereken sürekli bir borç yarattığınıza dair bir uyarıdır. Bu; şemayı tanımlayan DB migration’ları ile ayrı ORM sınıfları, backend API ile frontend client, retained mode UI’daki form değerleri ile iç durum, hem tiplerde hem de unit test’lerde ifade edilen veri modeli invariant’ları için de geçerlidir
Farklı fikirlerin tesadüfen benzer bir implementasyonu var diye zorla birleştirilmesinin ileride bakım riski yaratacağını söyleyerek buna karşı çıkanlar haksız değildi. Ancak onlar, DRY’nin asıl meselesi olmayan bir korkuluğa saldırıyorlar
Şimdi sorun şu: Yeni geliştiriciler bu ilkeleri nerede ve ne zaman doğru biçimde öğrenecek? Bilgisayar bilimi geçmişi olanlar var ama herkes böyle değil; akademik CS programlarının pratik geliştirme becerilerini çokça öğretmesi de gerekmez
Ben başladığımda senior’lar junior’lara pratik ve ciddi bir eğitim verirdi; ama günümüzdeki sık iş değiştirme kültürü ve junior’ları uzun vadeli yatırım olarak işe almaya isteksizlik ortamında bunun çok daha azaldığı görülüyor. Resmî kurslar birey için pahalı olsa da şirket ölçeğinde neredeyse maliyet sayılmaz; buna rağmen şirketlerin gerçekten gönderdiği yeni geliştirici sayısı çok azdır
Okunmaya değer kitaplar da var, ama 2024’teki 20’li yaşlardaki insanların kesilmiş ağaç parçalarına mürekkeple basılmış eski bir formatla uğraşmak isteyip istemeyeceğini bilmiyorum. Bugün gelişmekte olan geliştiriciler bu fikirlerin çoğunu bloglardan ve YouTube’dan öğreniyor gibi; oralarda da harika kaynaklar var ama sorun her zaman, doğru anlamamış ya da şüpheli biçimde paketlenmiş çöpün arasından onları bulmak
Dolayısıyla bir kalp atımı süresinde kabaca çalışan 12 satır kod üreten sihirli bir araç ortaya çıktığında, genç geliştiricilerin o kodun daha derin sorunlarını pek bilmeden onu harika sanmaları şaşırtıcı değil. Birinin suçu demek zor, ama bu açık bir sorun ve ne yapılması gerektiğini bilmeyi isterdim