Agentic Coding bir tuzaktır
(larsfaye.com)- Agentic coding, insanların gereksinimleri ve planı oluşturduğu, birden fazla kodlama ajanının ise uygulamayı yaptığı bir yaklaşım; ancak üretilen ve commit edilen kod ile insan arasındaki mesafeyi giderek açan bir yapı oluşturuyor
- Bu yaklaşımın başarılı olabilmesi için deneyimli geliştiricilerin mimari düzeyde eleştirel inceleme yapması gerekiyor; ancak yapay zekanın aşırı kullanımı, bunun için gerekli becerileri zayıflatan bir bilişsel borç (cognitive debt) yaratabiliyor
- Anthropic araştırmasının ele aldığı denetim paradoksunda olduğu gibi, Claude'u etkili kullanmak için onu denetleyecek kodlama yetkinliği gerekiyor ve kodlama ajanlarının kullanımı tam da bu yetkinliği zayıflatabiliyor
- LLM'ler, derin anlayış ve sadelikten çok, belli bir sürede üretilen kod miktarını artırma yönünde kullanılmaya daha yatkın; ayrıca belirsiz gereksinimleri varsayımlar veya halüsinasyonlarla doldurarak daha fazla inceleme, düzeltme ve token kullanımına yol açabiliyor
- Claude kesintileri ve token maliyetlerindeki dalgalanma, vendor lock-in ve maliyet belirsizliğini ortaya koyuyor; yapay zekayı uygulamanın yerini alan bir orkestratör yerine, planlama desteği, dokümantasyon, araştırma ve sınırlı yetkilendirme aracı olarak kullanmak anlayış borcunu azaltabilir
Yapısal ödünleşimler
- Kodlama ajanları yararlı ve güçlü, ancak zaten nicel ve pratik olarak değerlendirilmesi gereken ödünleşimler var
- Yapay zekanın deterministik olmamasından kaynaklanan belirsizliği azaltmak için çevre sistemlerin karmaşıklığı artıyor
- Birçok geliştiricinin becerileri körelebiliyor
- Claude Code kesintisinde olduğu gibi, belirli bir sağlayıcıdaki arıza tüm ekibi durdurabiliyor
- Personel maliyeti sabitken token maliyetleri sürekli dalgalanıp artabiliyor
- Bu yaklaşımın başarılı olabilmesi için deneyimli geliştiricilerin mimari düzeyde eleştirel düşünmesi ve binlerce satırlık üretilmiş kod içindeki sorunları büyümeden fark edebilmesi gerekiyor
- Ancak yapay zeka araçları, bunun için gerekli eleştirel düşünme ve bilişsel açıklığı olumsuz etkileyebilir ve bilişsel borç (cognitive debt) büyüyebilir
Sadece yeni bir soyutlama değil
- “Programcıların daha yüksek bir soyutlama katmanına çıkması” yorumu tek başına yeterli değil
- Belirsizliğin artması, otomatik olarak daha yüksek seviyeli bir soyutlama anlamına gelmiyor
- FORTRAN, derleyiciler ve yüksek seviyeli diller ortaya çıktığında da hatalar, kararsızlık, verim düşüşü ve artan “sihir” hakkında endişeler vardı
- Geçmişteki kaygılar çoğunlukla yeni teknolojiyi benimseyince ne kaybedileceğine dair normatif ve teorik endişelerdi; oysa yapay zeka araçları, ortaya çıkmalarından sadece birkaç yıl sonra zaten somut etkiler göstermeye başladı
- Bu etki yalnızca junior geliştiricilerle sınırlı değil; 10 yıldan fazla deneyimi olan geliştiricilerde de görülüyor
- Junior geliştiriciler, kodla doğrudan uğraşma süreci azalırken üretilen kodu inceleyen role itiliyor ve daha dik bir öğrenme eğrisiyle karşılaşıyor
- Kod inceleme önemli, ancak öğrenme sürecinin sadece yarısı; kodu doğrudan yazarken ve debug ederken yaşanan sürtünme ortadan kalktığında öğrenme kapasitesi ciddi biçimde zayıflıyor
- Bu olgunun araştırılması zaman aldığı için anlık durumu anlamada anekdotsal kanıtlar da önemli; ancak MIT Media Lab raporu ve Microsoft ile ilgili haber gibi destekleyici kaynaklar da var
Bu değişim neden farklı
- Bir C++ geliştiricisi Java veya Python'a geçti diye “brain fog” yaşadığını söylemiyordu; bir sistem yöneticisi AWS'ye geçti diye ağ bilgisi anlayışını kaybettiğini de hissetmiyordu
- Kıdemli mühendislerin yönetsel rollere geçip daha az kod yazması ve zamanla paslanması yeni bir durum değil
- Önceki yolda, onlarca yıl kodlama, sürtünme ve problem çözme biriktirmiş mühendisler; sözdiziminden çok mimari kararlara odaklanan rollere geçiyordu
- Şimdi ise geliştiriciler, böyle uzun vadeli deneyim olmadan yapay zeka ajanlarını yönettikleri daha üst düzey iş akışlarına taşınıyor
- Sorun, bu iş akışlarının onlarca yıllık deneyimle kazanılan becerilerin aynısını gerektirmesi
- Kıdemli mühendisler de istisna değil
- Simon Willison yaklaşık 30 yıllık deneyime sahip bir geliştirici olmasına rağmen, uygulamanın ne yapabildiğine ve nasıl çalıştığına dair “sağlam bir zihinsel model” olmadan özellikler eklendikçe akıl yürütmenin zorlaştığını söylüyor
Usta orkestratör paradoksu
- Anthropic'in son araştırması, kodlama ajanlarını sık kullanmanın riski olarak “denetim paradoksu”nu ele alıyor
- Temel nokta şu: Claude'u etkili kullanmak için denetim gerekiyor ve Claude'u denetlemek için de, yapay zekanın aşırı kullanımıyla zayıflayabilen tam da o kodlama becerileri gerekiyor
- LinkedIn'de 50 mühendisi yöneten Sandor Nyako, organizasyon içinde beceri körelmesinin yayıldığını gördüğünü ve ekibinden “eleştirel düşünme ya da problem çözme gerektiren işlerde” yapay zeka kullanmamasını istediğini söylüyor
- Ona göre beceri geliştirmek için zorlanmak ve problemleri derinlemesine düşünme kasını çalıştırmak gerekiyor; eleştirel düşünme olmadan da yapay zekanın doğru olup olmadığını sorgulamak zorlaşıyor
- “Aşırı kullanım” ölçütü de net değil; ancak veri temelli araştırma ve anekdotsal materyal, becerilerin birkaç ay içinde bile hızla zayıflayabildiğini gösteriyor
- Kodlama ajanlarının kullanımı, ajanları iyi yönetmek için gereken becerilerin kendisini zayıflatan bir çelişki yaratıyor
LLM'ler yanlış kısmı hızlandırıyor
- Aslında mutlaka daha hızlı kod yazmak gerekmiyordu
- Özellikle de tamamen anlaşılmamış kodları ya da makul sürede gözden geçirilemeyecek büyüklükteki kod yığınlarını daha hızlı üretmek gerekli değildi
- Yapay zeka öncesinde iyi geliştiricilerin öncelikleri genel olarak şunlardı
- Kod ile kod tabanı arasındaki ilişkiyi anlamak
- Belgelenmiş verimli standartlara uyup uymadığını doğrulamak
- Okunabilirliği korurken hedefe ulaşmak için gereken satır sayısını en aza indirmek
- Çalışma süresini hesaba katmak
- Agentic coding ve LLM'ler bu öncelikleri fiilen tersine çeviriyor
- Bugünkü yetenekler ve kullanım biçimi, belirli bir sürede üretilen kod miktarını artırarak hızı yükseltmeye odaklanma eğiliminde
- Hız, yüksek ustalığın doğal bir yan ürünüdür; ama zorla dayatıldığında doğruluk kaybına yol açar
- LLM'leri derin anlayışı ve sadeliği artıracak şekilde kullanmak mümkün; ancak zorunlu benimseme ve organizasyon genelinde token kullanımına odaklı aşırı hararet, gerçek kullanımın o yönde gitmediğini gösteriyor
Kodlama aynı zamanda planlamadır
- Bazı geliştiriciler kod yazarak daha iyi plan yapıyor ve daha iyi düşünüyor
- Kod üzerinden düşünmek ve çalışmak, anlamsız tekrar işi değil; güvenlik, performans, kullanıcı deneyimi ve bakım kolaylığı gibi konuları teknik düzeyde düşünmeye zorlayan bir süreç
- OpenCode'u yapan Dax, Spec Driven Development üzerine bir röportajda, yeni ya da zor bir iş yaparken ne yapılması gerektiğini bizzat kod yazarak keşfettiğini söylüyor
- Önceden devasa bir spesifikasyon yazmak yerine, tipleri, fonksiyonlar arası etkileşimi ve klasör yapısını bizzat kurcalayarak kavramı oturtmayı tercih ediyor
- İnsanların söylediği şey, gerçek niyetleriyle her zaman aynı değil; LLM'ler de belirsizlikleri varsayımlar veya halüsinasyonlarla dolduruyor
- Sonuç olarak daha fazla inceleme, daha fazla ajan düzeltmesi, daha fazla token kullanımı ve ortaya çıkan ürünle daha büyük bir kopukluk oluşuyor
- Tersine, çok net ve yapılandırılmış prompt'lar yazılsa bile LLM'ler halüsinasyon ürünü metotlar üretebiliyor
- LLM'ler derleyici değil, bir sonraki token'ı tahmin eden motorlar olduğu için deterministik sistemleri olasılıksal sistemlerle değiştirip belirsizliğin sıfırlanmasını bekleyemezsiniz
- Yapay zekayı aktif kullanan kıdemli geliştiriciler bile bu kopukluğu büyüyen bir sorun olarak görmeye başlıyor
Vendor lock-in ve maliyet belirsizliği
- Claude kesintisi sırasında bazı geliştirici ve mühendislik ekiplerinin durduğunu anlatan paylaşımlar yapıldı
- Bazı iş akışları ve kodlama becerileri artık belirli bir yapay zeka sağlayıcısına ciddi ölçüde bağımlı hale gelmiş durumda
- Eskiden yalnızca klavye ve metin editörüyle yapılabilen beceriler, artık yapay zeka model sağlayıcısına abonelik gerektiriyor
-
Token maliyetlerini öngörmek zor
- Model sağlayıcıları büyük ölçüde sübvanse ediliyor ve modellerin kendisi de sürekli değişen bir zeminde duruyor
- Yeni model çıkışları; yüksek benchmark'lar, aşırı heyecan, gerçek kullanım sonrası “nerf'lendi” şikayetleri gibi bir döngüyü tekrar ediyor
- Aynı işi yapmak için 2-3 kat daha fazla token harcandığına dair şikayetler de bunu izliyor
- Personel maliyeti bilinebilirken, token maliyetlerini günlük, aylık ve yıllık ölçekte öngörmek zor
- Tüm ekip varsayılan olarak agentic coding kullanıyorsa, maliyet hesabının çok esnek tutulması gerekiyor
- Primeagen, tam agentic workflow kullanıldığında “model sağlayıcısı fiilen size sahip olur” diyor
- Token tüketiminin maliyetini ödeyerek, eskiden eleştirel düşünme ve problem çözme becerileriyle yapılan işleri yürütmeye dayanan bir sektör yapısı oluşabilir
- Bu yalnızca ürün düzeyinde bir vendor lock-in değil; sektör genelindeki teknik yetkinliklerin sağlayıcılara bağımlı hale gelmesine daha yakın bir durum
- Finansal ve zihinsel temel her an sarsılabilir; yerel LLM'ler ise bu ölçekteki kullanımı karşılayacak kadar hazır değil
- Bu sorun teori değil; zaten haberleştiriliyor ve model sağlayıcıları da bunu doğrudan gündeme getiriyor
- Anthropic'in bir başka araştırması, debug becerilerinin %47 düştüğünü belirtiyor
- Yapay zekayı iş hayatına, özellikle yazılım mühendisliğine agresif biçimde sokmak; hızlı sonuç uğruna yapay zekaya yaslanırken, bir sorun çıktığında gerekli olacak temel debug becerilerinin gelişmemesine yol açabilir
Yapay zekanın rolünü düşüren yaklaşım
- LLM'ler öğrenme ve yetkinlik geliştirme için güçlü araçlar olabilir
- Kavramları ve teknikleri daha derin ve daha geniş biçimde keşfetmeyi, yeni fikirleri eskisinden daha az çabayla denemeyi sağlayabilir
- Kod üretim araçlarının kendisi yeni değil
- Emmet, otomatik tamamlama ve snippet'ler, daha az doğrudan yazıp daha çok üretmek için kullanılan araçlardı
- COBOL da
MOVE,WRITEgibi İngilizce kelimelerle daha az yazımla daha çok komut ifade etmeyi hedefliyordu - jQuery'nin sloganı da “write less, do more” idi
- LLM'ler de bu kod üretim araçlarına yapılmış bir başka ekleme olarak görülebilir
- Asıl önemli fark, LLM'leri ve kodlama ajanlarını yardımcı süreçler olarak kullanmakta yatıyor
- Üretkenlik uğruna kişisel becerileri feda etmeden; planlama aşamasında yapay zekayı beyin fırtınası için kullanıp uygulamaya aktif olarak dahil olmaya devam etmek mümkün
- Yalnızca gerektiğinde yetki devretmek, üretkenlik kazanımı sağlarken anlayış borcunu azaltabilir
Günlük kullanım biçimi
- LLM'leri spesifikasyon ve plan üretmek için kullanıp uygulamayı insanın yönlendirmesi
- Bu, “orkestrasyon” iş akışını tersine çeviren bir yaklaşım; işe göre %20 ile %100 arasında doğrudan kod yazmayı içeriyor
- Model kullanılırken de sık sık sahte kod yazılarak istek ile üretilen kod arasındaki mesafe azaltılıyor
- Model; geçici kod üretimi, etkileşimli dokümantasyon ve araştırma aracı olarak kullanılıyor
- Sorumlu yetki devri aracı gibi kullanılarak soru soruluyor, yineleme yapılıyor, refactor ediliyor ve yaklaşım daha net hale getiriliyor
- Tek seferde gözden geçirilebilecek miktardan fazla kod üretilmiyor
- Gözden geçirmek için fazla geldiyse hız düşürülüyor, iş parçalanıyor ve gerekirse nihai sonucu kapsamlı biçimde anlamak için doğrudan refactor ediliyor
- Daha önce bizzat yapılmamış ya da tek başına yapılamayacak bir implementasyon LLM'lere veya ajanlara bırakılmıyor
- İstisna eğitim veya tutorial amaçları; bu tür çıktılar da sonrasında çoğu zaman atılıyor
- Özetle, yapay zekayı Star Trek'teki Data gibi değil, Ship’s Computer gibi kullanmak gerekiyor
Daha hızlı değil, daha iyi iş
- Modellerin üretkenlik artışı gerçekten var
- Aynı anda, işle doğrudan ve sık temas ederek ortaya çıkan sürtünme ve anlayış da gerçekten önemli
- Kodlamayı anlamadan kodlamayı demokratikleştirme girişimleri tekrar tekrar başarısız oldu
- Kodu anlamak için kodla doğrudan temas etmek gerekiyor
- Kodla sürekli ilgilenmez ve kod yazmayı sürdürmezseniz, o anlayışı ve bağı kaybedebilirsiniz
- Bu anlayış kaybedildiğinde ajanları daha iyi yönetme becerisi de zayıflıyor ve yapay zeka kodlama aşaması tuhaf, gereksiz derecede stresli bir geçiş dönemine dönüşüyor
Daha büyük bir deney olabilir
- Mevcut gidişat, uzun vadeli etkileri yeterince anlamadan kendi üzerimizde yürüttüğümüz bir başka büyük deney gibi görünüyor
- Sosyal medyayı benimserken de uzun vadeli sonuçları tam anlamamıştık; sonrasında yaygın dikkat eksikliği gibi pek çok sorun ortaya çıktı
- Bu kez daha tehlikeli şeyleri riske atıyoruz
- fast.ai'ın kurucusu Jeremy Howard, her şeyini yapay zeka ajanlarına bağlayanların kendi değersizleşmelerini garanti altına aldığını söylüyor
- Tüm düşünmeyi bilgisayara dış kaynak olarak verirseniz, yetkinlik kazanma, öğrenme ve daha becerikli hale gelme sürecini de durdurursunuz
1 yorum
Hacker News görüşleri
Son birkaç yıldır ajanik kodlama ile çalışırken, 35 yıl boyunca elle doğrudan programlama yaptığım zamandan daha fazla şeyi kullandığım dil, sistem ve araçlar hakkında öğrendim.
Sistemleri, teknikleri ve yaklaşımları seçme konusunda hâlâ araçlardan çok daha iyiyim, ama bu araçlar bana türlü ayrıntıları bilen, çok bilgili bir stajyeri hatırlatıyor. Deneyimleri az ve hataları da hevesle yapıyorlar, ama en azından başlangıçta geri bildirimi kabul edip eyleme döküyorlar. Yine de bunu tamamen anlayıp içselleştirmiş değiller; sık sık unutuyorlar.
Üzerinde çalıştığınız her şeyi tamamen bilmeniz gerektiğini söylemek çok safça. İki ya da daha fazla ekipte çalışıyorsanız tam olarak anlamadığınız çok şey olur; eski bir kod tabanındaysanız neredeyse her bölüm yabancı gelebilir. On yıllar boyunca birikmiş dev bir monorepo'da, herkesin sizi uzman gördüğü kısımları bile gerçekten anlıyorsanız kendinizi şanslı sayarsınız.
Bunu söyleyen insanlar genelde ya çok junior oluyor ya neredeyse tek başına çalışıyor ya da 20 yıldır tek bir projeye tutunmuş gibi görünüyor. Ekipte ya da büyük bir organizasyonda çalışan hiç kimse tüm kod tabanını bildiğini söyleyemez; ajanik programlama yapanlar da söyleyemez. Yine de ajana sorarsanız yanıt alabilirsiniz ve hayatı boyunca başkalarının kodunu okumuş biri olarak LLM'in yazdığı kodu da okuyabilirim. Kötü kodu makine mi yazdı insan mı yazdı hiç umurumda değil; en azından makine benim geri bildirimimi alıp harekete geçiyor.
Basit bir sorun için bile düşük seviyeli dil, assembly, daha az yaygın algoritmalar ya da ağ protokolleri gibi ek beceriler gerektiği anda çözemeyip duran pek çok yazılım ekibi gördüm.
Tersi de oluyor: Gördüğünü yorumlayamadığı için değil, özel kütüphane ya da özel işletim sistemi gibi kara kutu bir şey kullandığı için içini kurcalayamıyor ve gerçekte ne yaptığını doğrulamanın yolu olmadığı için tıkanıyor.
Bu yüzden, çok nadir gerekse bile, üzerinde çalıştığınız her şey hakkında her şeyi öğrenebileceğiniz bir ortamın her zaman mümkün olması gerektiğini düşünüyorum.
Önemli olan, sistemin geri kalanını öğrenmekten korkmamak ve bir indeks tutmak.
Her şeyden önce, ne olursa olsun hızlıca kavrayabilmelisiniz. Böylece geniş bir alanda çalışabilirsiniz. Gerektiğinde derine inip gerektiğinde yüksek seviyeden bakarak probleme uygun doğru seviyeyi tutturmanız gerekir.
Üniversitede yıllar önce bilgisayar bilimi öğrencilerine mühendisliğin geneli öğretilirdi. “Kimya mühendisliğini ya da analog kontrol sistemlerini ne zaman bilmem gerekecek?” diye sorulduğunda, “Muhtemelen hiç kullanmayacaksın. Ama kod yazacak kadar hızlı kavrayıp sonra unutabilirsin. Biz sana sağlam bir temel veriyoruz,” denirdi.
Bu, büyük bir kod tabanının içinde de aynen geçerli.
git-ai [0] gibi araçlar LLM oturumlarını yakalıyor, her dosya düzenlemesini belirli bir ajan eylemine bağlıyor ve ajanın belirli bir kod parçası için çevresindeki konuşmayı, yani kullanıcının ne prompt verdiğini ve kodu üreten LLM'in nasıl bir muhakeme yürüttüğünü sorgulamasına izin veriyor. Bu dengeyi değiştirebilir ama henüz yaygın değil.
[0] https://usegitai.com/
25 yılı aşkın deneyimi olan bir senior geliştirici olarak kısa süre önce “5 dakikalığına gelebilir misin?” tarzı bir toplantıya atıldım ve ortasında, hiçbir bağlam olmadan içine çekildiğim bu tip toplantılardan gerçekten nefret ediyorum.
Soru yağmuru tanıtım bile olmadan hızlıca başladı ve konu, onlarca dış entegrasyondan yalnızca biriyle ilgiliydi. Daha kötüsü, o taraf bizimkinden farklı kendi terminolojisini kullanıyordu.
Bu entegrasyonları kurarken modele çok güvendiğimiz için soruları anlamakta çok zorlandım. Son derece sıkıcı bir işti ve elimizde dışarıdan gelen kalın bir spesifikasyon vardı.
Modeli kullanmasaydık 10 kat daha fazla zaman harcasak bile bu entegrasyonlar muhtemelen tamamlanamazdı diye düşünmem hâlâ olumlu. Ama şimdi bu tür rahatsız edici anlar tekrar yaşanmasın diye “aha” noktalarını yeniden belgeleyip belgelememeyi ciddi biçimde düşünüyorum.
Bir toplantıda kendimi hiç bu kadar cahil ve utanç içinde hissetmemiştim; söyleyebildiğim tek şey “ona bakıp döneceğim, buna da, şuna da” oldu.
Bilişsel borç gerçekten var ve kişisel olarak teknik borçtan daha acı veriyor. Teknik borç tüm ekibin paylaştığı bir şey; bilişsel borç ise kişisel ve onu yaratan kişi bizzat bensem daha iyi biliyor olmam gerekir.
Bundan sonra “bu nedir”, “şu nedir” tarzı 5 dakikalık flashcard benzeri Markdown terim listeleri oluşturmadan işin bitmiş sayılmaması gerektiğini düşüneceğim.
Senior geliştiriciyseniz, hoşunuza gitmeyen davranışlara dur demesi gereken kişi sizsiniz. Yetkiniz var. “İlginç bir soru. Kendi bakış açımı verebilmem için daha fazla bağlama ihtiyacım var. Sistem mimarisini kısaca anlatabilir misiniz ya da bu yaklaşımla gerçekte hangi sorunu çözmeye çalıştığınızı açıklayabilir misiniz?” diyebilirsiniz.
Böyle davranıldığında, “Bu soruya düzgün cevap verebilmem için dokümanları ve kodu incelemem gerekiyor” demek tamamen kabul edilebilir ve gayet diplomatik bir yanıttır.
Uzmanlığın inşa edilmesi gereken bir şey gibi değil de sadece yaratıcı bir doğrulama yanlılığını teyit etme aracı gibi görüldüğü toplantılar keyifli olmuyor.
Üretilmiş kodda sorun bulmak için geliştiricinin dikkat etmesi gerekir. Birçok geliştirici, özellikle büyük şirketlerdekiler, işten zaten bir hayli kopmuş durumda ve mümkün olan en az çabayla ticket kapatıp sorumluluğu başkasına atmanın yolunu arıyor.
Böyle geliştiriciler, yetenekleri olsa bile ajanın kaçırdığı sorunları bulacak kadar üretilmiş kodu anlamaya çalışmayacaktır. Özellikle de bugünkü AI odaklı hız çılgınlığı içinde bu daha da geçerli.
Üretilmiş kod dilsel olarak makul görünür ama yaygın kalıpları farkında olmadan tutarsız biçimde taklit ettiği için gerçek hatalar, normal bir insanın hatta kötü bir programcının bile aklına gelmeyecek şekillerde kazara gizlenebilir.
LLM'in içsel bir değerlendirmesi olmadığı için inceleyen kişi bunu satır satır değerlendirip, LLM'in baştan beri sahip olmadığı örtük gerekçeyi ve zımni bilgiyi yeniden kurmak zorunda kalır. Böylece bazen sorun olmayan şeylerin peşine takılıp pahalı zaman harcar.
Bu noktada yatırım, sıfırdan yazmaktan daha büyük hâle gelebiliyor.
Belki de şirketler şu anda çöp AI satın alıyor ve bir sonraki aşamada onun “çözümünü” satın alma sözü alıyor. Kapitalizm tam da beklendiği gibi çalışıyor.
Bu yazı sanki asıl noktayı biraz ıskalıyor.
AI'yi çok kullanırsanız beceri erozyonu yaşanır.
Ama odadaki rahatsız edici fili kabul etmek istiyorum. AI insanları fazla hızlandırıyor. Hızlı çıktıların kendisi kötü demiyorum; ama hızlı çıktı ve kod, onu ortaya çıkaran genel anlayışın ve deneyimin önüne geçiyor. Derin bilgiyle güvenli kararlar alan kişiden çok, iş değeri anlattığını söyleyen kişi ödüllendiriliyor.
AI iyi olabilir ve iyi çözümler de üretebilir, ama sonuçta ne yaptığını bilmiyor ve en iyi ihtimalle bile güçlü bir yönlendirmeye ihtiyaç duyuyor.
Biz şu anda iş güdümlü geliştirme bataklığındayız ve kötü kararlar için yeterince sert itibar cezaları yok.
Başka bir deyişle, beceri erozyonunun gerçekten o kadar büyük bir sorun olduğundan emin değilim. Belki de sadece işimizin doğasının değiştiğinin bir işaretidir. C++ standardını ezbere bilip yüzlerce özelliği doğru kullanmaktan çok, iyi mimari bilmenin daha değerli görüldüğü bir döneme giriyor olabiliriz.
Normal geliştirmede “Bunu gerçekten yapmak istiyor muyuz?” ve “Bunu böyle yaparsak ne ters gidebilir?” soruları arasında daha çok gidip gelinir; ideal olarak da bu PR onayı ya da merge/deploy öncesinde olur. Bunun bir kısmı “Sonra kim şikâyet edecek görelim” aşamasına kayıyor. Dediğiniz gibi, bir dirhem önlem bir okka tedaviden iyidir.
Üstelik kod, o projenin alışıldık C++ tarzında değildi ve LLM mevcut API'leri tamamen yok saymıştı. Düzeltilebilir ve maintainer bunu yakalamalıydı, ama üretilen kod miktarı yüzünden herkes çok fazla enerji harcamak zorunda kalıyor.
Bu tür blog yazıları büyük olasılıkla AI yardımıyla yazılmıştır ve yıllardır hem burada hem de internetin başka yerlerinde yorum konusu oluyor. Beceri aşınması ciddi bir endişe; 2022'den beri AI'ye şüpheyle yaklaşan herkes bunu tekrar tekrar söylüyor ama bazı insanlar ve bazı yerler bunu umursamıyor gibi görünüyor.
Bir noktadan sonra kod içgörüsü olmadan sadece çöp makinesi kolunu çekiyorsanız, patronunuzun neden yılda 50 bin dolardan fazla maaş almanız gerektiğini sorması da meşru olabilir.
Daha hızlı gitmek için AI kullanmak, yanlış şeyi optimize etmek demek. Çalıştığım her yerde “kod yazma”nın kendisi, bir özelliği hayata geçirmek için gereken diğer her şeye kıyasla en az zaman alan iş oldu.
Bir günde kodlayabileceğiniz bir özelliği düşünün. Önce şirketin Agile mı Waterfall mı kullandığına bağlı olarak her şeyi planlama sürecinden geçirmeniz, işi bölmeniz, JIRA ticket'ları açmanız ve kimin yapacağını belirlemeniz gerekir. Bu bile günler ya da haftalar sürebilir. Sonra önerilen tasarımı anlatan bir tasarım dokümanı yazıp ekip arkadaşlarınızdan ve takımınızdan review almanız gerekir; anlamlı bir özellikse buna da bir hafta gider. Birden fazla ekip işin içindeyse onların onayını ve tasarım uzlaşmasını almak için bir hafta daha ekleyin. Bazı yerlerde işe başlamak için onay gerekir ve onay verenlerin takvimi ile müsaitliğine göre birkaç gün daha gider.
Sonra bir gün boyunca kodu yazıp testleri geçirirsiniz.
Ardından code review gelir; ekiple bol bol gidip gelerek birkaç tur dönebilir ve ek review'lar alabilirsiniz. Yine birkaç gün ya da hafta gider. Daha büyük bir şirketteyseniz hukuk, gizlilik, performans, erişilebilirlik, QA gibi başka ekiplerin tüm review süreçlerinden de geçmeniz gerekir. Paralel ilerlese bile temkinli bir tahminle 2 hafta daha ekleyelim. Son olarak staging'e alır ve şirket içi dogfooder'lar arasında bir süre demlenmesini beklersiniz ki çalıştığına güvenebilesiniz. 1 hafta daha. Artık staging'den production'a geçmeye hazırsınızdır ama ciddi bir şirket hiçbir şeyi doğrudan %100 production'a göndermez. Trafiği yavaş yavaş artırır, rollback gerekirse diye geri bildirimleri ve metrikleri kontrol edersiniz. Tam yayına geçmek 2 hafta daha sürebilir.
Yani tasarımdan yayına iki ay süren bir özellikte, biz bir gün süren kısmı 5 dakikaya indirmeye uğraşıyoruz.
Yazılım geliştirirken onun, probleme dair anlayışınızın bir anlık görüntüsü olduğunu unutmamalısınız. Hem başkalarına hem de gelecekteki kendinize yaklaşımınızı, açıklığınızı ve eldeki probleme çözümünüzün ne kadar uygun olduğunu anlatır. Bu yüzden ne söyleyeceğinizi akıllıca seçmelisiniz.
Tasarımdan yayına iki ay süren bir özellikte bir günlük kısmı 5 dakikaya düşürmeye çalıştığımız tespiti gerçekten yerinde.
Bu tarz işler, oturmuş şirketlerde tüm mühendislerin günlük işinin azımsanmayacak bir kısmını oluşturuyordu. Buna “platform engineering” deyin ya da başka bir şey, bu alan öldü.
Ayrıca risk/çaba oranı yüzünden hiç denenmeyen teknik olarak riskli fikirler artık erişilebilir durumda. Bu sadece “daha hızlı gitmek” değil; bir şeyi deneyebilme hızı mühendislik sürecinin doğasını değiştiriyor.
Yazılım mühendisi yeterince ucuzlarsa bu süreçlerin büyük kısmına olan ihtiyaç ortadan kalkar. Bu süreçleri zaten kurmuş şirketler, o bürokrasiyi yıkmanın aşırı zor olması nedeniyle zorlanacaktır; ama baştan böyle süreçleri olmayan ya da kaldırabilen şirketler ciddi rekabet avantajı kazanacaktır.
Bu yeni bir şey değil. Startuplar her zaman kurulu şirketlerle uygulama hızı üzerinden rekabet etti. Yeni olan, bu hızı daha uzun süre koruyabilme yeteneği.
Hukuk, gizlilik, performans, erişilebilirlik, QA gibi review'lar da hedef tahtasında. Şirket bu review'lara bağlı hukuki sorumluluğu dış sağlayıcılara aktarabiliyorsa bunu yapacaktır.
[0] Bu sürecin önemli bir kısmının sonunda zaman kazandırması amaçlanan aynı çalışanların üstüne yıkılması ironisini şimdilik görmezden gelelim.
Big Tech'te böyle gösterişli prosedür çok ama küçük şirketler hızlı ve biraz da kaba hareket edebiliyor.
Kod kalitesi sonuçta size bağlı.
Ajanla tekrar tekrar çalışıp, ortaya doğrudan kendiniz yazmış olsaydınız elde edeceğinizle aynı kalitede bir kod çıkana kadar rafine etmenize engel olan hiçbir şey yok.
Bu yazılar epey sinir bozucu. Yine de yazarın dediği token maliyeti gerçek ve riskli.
AI araçlarını yaklaşım üzerine beyin fırtınası yapmak ve bazen kod üretmek için kullanıyorum ama asıl yazmayı kendim yapıyorum. Böylece zamanla mekanizmaları ve programlama dilini unutma ihtimalim azalıyor.
Açıkçası bütün iş LLM'e kod yazdırıp review etmekten ibaret olsaydı open source maintainer olmayı pek istemezdim. Hiç tatmin edici görünmüyor.
Gerçek bir ücretli işte LLM kullanma biçimimin nasıl değişeceğini merak ediyorum. Yazılım geliştirici olma nedenim bu teknolojiyi gerçekten sevmem. Bir şeyler üretmeyi, beynimi kullanıp fikirleri koda dönüştürmeyi seviyorum. İş sadece LLM'e prompt vermeye dönecekse bu kariyeri sürdürür müyüm bilmiyorum. En azından başka işler bakmaya başlardım.
Bakımını üstleneceğim kodda bu yöntemi kullanıyorum. Yine de model çok fazla yanlış bilgi kattığı için bazen çarpılıyorsunuz. Genelde geçmişte doğru olup şimdi yanlış olan şeyler bunlar.
Atılacak script'ler ya da doğrulaması kolay script'ler için üretmesine izin veriyorum ama aşırı tasarım yapmamasını ya da tüm köşe vakaları yakalamaya çalışmamasını istiyorum. Çünkü script'lerde başarısız olan adımın açıkça hata vermesi, her şeyi örtmeye çalışmaktan daha anlaşılır oluyor.
PowerShell gibi okumayı zor bulduğum dillerden kaçınıyor, ekrana sığacak kadar kısa, tamamını okuyup anlayabileceğim şeyler üretmesini tercih ediyorum. En çok kullandığım script dilleri Python, Bash ve Batch.
AI önerilerinin %50'den fazlasını hâlâ reddediyorum. Ya fazla sıradanlar, ya kodu sebepsiz yere taşıyorlar ya da bazen düpedüz yanlışlar.
Komik olan şu ki bu teknoloji iki şeyden biri gibi görünüyor:
Ya uzmanlık olmadan delege edebildiğiniz ama yanlış mı yoksa imkânsız mı olduğunu anlayamadığınız bir yöneticiler için teknoloji, ya da uzmanlığınızın olup bu uzmanlığı giderek kaybedeceğiniz bir kodcular için teknoloji.
Dolayısıyla gelecek çeyreğe kadar VC'ler ve hissedarlar dışında bunun kimin için olduğunu pek bilmiyorum.
Biraz konu dışı ama yazıda Spec Driven Development'ın gelecek olarak sunulması komik.
Teknik olarak biz Waterfall yaptığımız dönemde zaten böyle çalışıyorduk. İyi dokümantasyonun olduğu günleri biraz özlüyorum. Son 10 yıldır, belki daha da uzun süredir, çoğu zaman tek satırlık JIRA ticket'ları alıyorum ve bunlarda neredeyse hiçbir şey belirtilmediği için insanları aramak zorunda kalıyorum.
Ben hâlâ AI ile çalışmaktan kaçınıyorum. Deney amaçlı birkaç yerel model kullanmayı düşünüyorum ama başkalarının söküp birleştirdiği şeylere para vermeyi reddediyorum. Ve şu ana kadar yerel modeller beklentimin altında kaldı.