Darboğaz Asla Kod Değildi
(thetypicalset.com)- Codex, .txt'in bir yılı aşkın süredir ertelediği yapılandırılmış üretim algoritması deneyinin ilk çalışan sürümünü birkaç saat içinde oluşturdu; ancak asıl değişim, bireysel kodlama hızından çok işbirliği darboğazının görünür hâle gelmesiydi
- Uygulamayı ajanlar üstlendiğinde, ekibin hızını yavaşlatan şey kodu yazan kişi değil; ajanların doğrudan çalıştırabileceği kesin spesifikasyonlar üretmek oluyor: yol haritası, kabul kriterleri ve tasarım dokümanları gibi
- Kod yazma maliyeti düştüğünde, daha önce yapılmayacak prototipler ve iç araçlar çoğalıyor; ancak kullanıcıların hazmedebileceği hız aynı kaldığı için, neyin yapılmayacağını belirleyen odak disiplini daha da önemli hâle geliyor
- Ajanlar Slack, PR'lar, issue'lar, commit'ler ve tasarım dokümanlarından örtük kararları ve teamülleri çıkararak bir bilgi tabanı oluşturabiliyor; ancak insanların doğrudan biriktirdiği ortak bağlamı tamamen geri getiremiyor
- Önümüzdeki 10 yılda avantajın, en iyi modele sahip olandan çok; 50, 200 ya da 2.000 kişi ölçeğinde bile giderek daralan karar kümesine hizalanan örgütsel tutarlılığı koruyabilen şirketlerde olması muhtemel
Kodlama ajanlarının değiştirdiği darboğaz
- .txt'te bir yılı aşkın süredir ertelenen deney; yapılandırılmış üretim algoritmalarını ve açık kaynak alternatiflerini test etmeyi, ayrıca yalnızca “bu string'i kabul ediyor mu” değil, daha çok “doğru token dağılımını üretiyor mu” türünden bir sorunu doğrulamayı içeriyordu
- Bu deney yol haritasında sürekli yer alıyordu; ancak Codex'e yaklaşımı yaklaşık 30 dakika anlattıktan sonra, birkaç saat içinde çalışan ilk sürüm ortaya çıktı
- Kodlama ajanları bireylerin kod yazma biçimini şimdiden ciddi biçimde değiştiriyor; ancak bireysel üretkenlik artışının doğrudan yazılım sektörünün tamamında hız artışına dönüşeceğini söylemek zor
- Etkili yazılımlar çoğu zaman birden fazla kişinin işbirliğiyle ortaya çıkar; bu yüzden analiz için daha ilginç birim, bireysel üretkenlik değil işbirliğidir
- Yazılım, insanların sistemin ne yapması gerektiği üzerine pazarlık ettikten sonra geriye kalan sonuca daha çok benzer; kod önemlidir ama daha zor işin artığıdır
Sınır hâline gelen yol haritası
- Uygulamayı ajanların üstlendiği ekiplerde hızı yavaşlatan şey, ajanların doğrudan alıp çalıştırabileceği kadar kesin spesifikasyonlar üretmektir
- Yol haritası, kabul kriterleri ve “aslında ne istediğimiz”; test suite'leri, ticket'lar ve tasarım dokümanları gibi biçimlerde açıkça yazılmalıdır
- Özellikler çok hızlı uygulanır ve mühendisler başka mühendisleri beklemek yerine, sıradaki doğru yazılmış spesifikasyonu bekler hâle gelir
- Darboğaz, kodu yazan kişiden hangi kodun var olması gerektiğine karar veren kişiye kayar; bu da sonuçta bir yönetim problemidir
Ucuzlayan kod daha fazla uzlaşı gerektiriyor
- Kod yazma maliyeti düştüğünde, aynı sonuca %10 emekle ulaşmak yerine; daha önce yapmaya değmeyecek sonuçlara aynı emeği harcamaya başlarsınız
- Üç ay önce “zaman kaybı” sayılacak bir prototip tek bir öğleden sonra içinde yapılabilir; net bir talebi olmayan iç araçlar üretilebilir ve sonra unutulabilir
- Kullanıcıların özümseyebileceği özelliklerin hızı, ekip 10 özellik de yayımlasa 50 özellik de yayımlasa büyük ölçüde aynı kalır
- Steve Jobs'un 1997'de söylediği gibi, “odaklanmak, hayır diyebilmektir”; Apple da o yıl ürün grubunun yaklaşık %70'ini ayıkladı
- Ajanlarla birlikte yeni özellik yayımlamak daha kolay hissettirdiği için, yalnızca neyin yapılacağına değil, neyin yapılmayacağına karar verme disiplini de zorlaşır
Bağlam temel kaynak hâline geliyor
- Pazarlık ve uzlaşı, organizasyon içindeki ortak bağlam üzerinde işler
- Bağlam; neyin inşa edildiğini, neden önemli olduğunu, nelerin denendiğini, kimin neye karar verdiğini, neyin öz neyin kalıntı olduğunu kapsar
- Ekipteki insanlar aynı odada bulunarak, aynı Slack kanallarını okuyarak ve gece 2'de aynı arızayı debug ederek bağlamı doğal biçimde biriktirir
- Bu bağlamın büyük kısmı dokümante edilmez; kıdemli bir mühendis PR incelemesinde “bu migration'ı bozacak” dediğinde de çoğu zaman belgelenmemiş bağlama dayanır
- Ajanlar böyle bir ozmoz yaşayamaz; odada bulunarak, planlama konuşmalarını yarım kulak dinleyerek ya da geçmiş kesintilerin hafızasını taşıyarak bağlam edinemez
- Prompt'lara, dosya ağacına, araçlara ve açık talimatlara konulamayan bağlam, ajanların güvenilir biçimde sahip olduğu bir şey değildir
- Bağlam olmadan ajan, biraz yanlış soruya kulağa makul gelen bir cevap üretebilir
- .txt'te ajanların faydalı işler yaptığı durumda bile, aslında bağlam çalışmasını önceden insanlar yapmıştır; bu resim otomatik olarak sonraki 10 mühendise geçmez
- Organizasyonların hep örtük biçimde dayandığı bağlam, artık hızı sınırlayan bir girdiye dönüşmüştür; insanlar da onun açık sürümünü okuyacak bir hedef olmadığı için bunu örtük bırakma eğilimindedir
Ajanların bağlam ürettiği döngü
- İnsanların kolayca tüketebileceği bağlamı üretmek, insanların sevmediği bir iştir
- Ajanlar; PR yorumlarını, kapatılmış issue'ları, commit mesajlarını, eski tasarım dokümanlarını ve Slack arşivlerini eksiksiz okuyup kimsenin belgelemediği örüntüleri çıkarmakta güçlüdür
- .txt'te kod tabanını, issue'ları, PR'ları ve thread'leri tarayarak örtük kararları, teamülleri ve “neden böyle yapıldığını” bilgi tabanına dönüştüren ajanlar inşa edilmeye başlandı
- Bu bilgi tabanı yalnızca “bu modül var” demekle kalmaz; “migration mevcut davranışı korumak zorunda olduğu için bu modül tuhaf” ya da “bu benchmark önemli çünkü önceki optimizasyon dağılımı sessizce değiştirmişti” gibi bağlamları da içerir
- Başka ajanlar, kod tabanında eyleme geçmeleri gerektiğinde bu bilgi tabanını kullanır
- İnsanların gayriresmî biçimde yürüttüğü ozmoz, hem ajanların hem insanların okuyabileceği bir biçimde dışsallaştırılır
- Bağlamı tüketen ajanlar için bağlamı üreten ajanlar gerekir; bu döngü çalıştığında organizasyon, kendi başına üretmeyeceği dokümante edilmiş bir temele sahip olur
- Yine de bu döngünün ürettiği şey her zaman kısmi bir resimdir
- Michael Polanyi'nin dediği gibi, “söyleyebildiğimizden daha fazlasını biliriz”; bazı kritik bağlamlar hiç yazıya dökülmedikleri için vardır ve yazıya geçirildiklerinde değişebilirler
- İnsanların yüz yüze etkileşimle biriktirdiği ozmoz katmanı, yalnızca dokümante edilmiş yan ürünlerle tamamen yeniden kurulamaz
- Ortaya çıkan sonuç tam bir yeniden kurulumdan çok, faydalı bir başlangıç noktasına benzer; bunun birikimli etki yaratmaya yetip yetmeyeceği ise hâlâ deneysel bir sorudur
Yeni hendek teknolojide değil, organizasyonda
- Önümüzdeki 10 yılın kazananları mutlaka en iyi modele ya da en iyi ajan altyapısına sahip şirketler olmayabilir; bunun yerine, 50 kişiden 200'e, 2.000'e büyürken bile giderek daralan karar kümesine hizalanmış kalıp kişi başına daha fazla çıktı üreten şirketler öne çıkabilir
- Bu tür şirketler, ajanlar gelmeden önce de en zor problemin tutarlılık olduğunu bilen organizasyonlardır
- Bu bir kültür ve yönetim meselesidir; her zaman da öyle olmuştur
- IDE'ler, sürüm kontrolü, CI, mikroservisler ve DevOps gibi önceki nesil araçlar; koordinasyonu daha iyi araçlarla çözeceklerini vaat etti, ama pratikte zaten var olan örgütsel tutarlılığı büyüttüler
- Küçük ekipler tutarlılığı neredeyse bedavaya elde ettiği için bu büyütme etkisi çoğunlukla olumludur; ajanları güçlü biçimde destekleyen seslerin küçük ekiplerden sık gelmesinin nedeni de, kendi bağlamlarında çoğu zaman haklı olmalarıdır
- Belli bir ölçeğin ötesinde tutarlılık inşa edilmeli ve korunmalıdır; büyütme etkisi de iki yönde keskinleşir
- İyi organizasyonlar daha iyiye giderken, kötü organizasyonlar daha hızlı dağılır
- Ajanlar önceki araçlardan çok daha güçlü bir büyütücüdür; bireylerin daha hızlı kod yazmasını sağlama aracı olarak abartılırken, organizasyonun bildiklerini dışsallaştırma aracı olarak küçümsenir
Şirket kültürünün uzantısı olarak ajanlar
- Ajanlar, kişinin kendi düşüncesinin bir uzantısı gibi hissettirebilir ve bu his güçlüdür
- Daha zor görev, ajanları şirket kültürünün bir uzantısı hâline getirmektir
- Bunun için yazma kültürü, kişinin hâlâ bağlam darboğazı olduğu noktaları tespit edecek kadar düşünceli bir yönetim ve tutarlılığı korunması gereken gerçek bir çıktı olarak ele alan insanlar gerekir
- Yeni olan şey, bunların en azından bir kısmının artık inşa edilebilir olmasıdır
- Okuyan ve çıkarım yapan döngü bunun bir biçimidir; başka biçimler de ortaya çıkabilir
1 yorum
Hacker News görüşleri
Kariyerleri boyunca takım toplantıları, agile ritüelleri, issue tracker'lar, backlog'lar, Slack, e-posta ve tasarım incelemeleri gibi, sözde en temel ve en kutsal faaliyetleri olan saatler süren kod yazma akış halini bozan her şeye söylenen mühendislerin, makineler kodu kendilerinden daha hızlı yazmaya başlayınca birden utanmadan işbirliği faaliyetlerinin önemini ve kodun/kodlamanın önemsizliğini vaaz etmeye başlaması komik geliyor
Yanlış değil, ama daha bir yıl öncesine kadar herhangi bir takımda en asosyal ve işbirliğine en kapalı kişilerin sergilediği bu apaçık ikiyüzlülük yine de şaşırtıcı
Her hâlükârda ikisi aynı anda doğru olabilir: kod yazmak darboğaz değildir, bu yüzden özellikleri dağıtıma hazır hızdan daha hızlı geliştirebilirsin; ama derin odak gerektiren bir iş yaparken bölünmek de sinir bozucudur ve akışı keser
https://en.wikipedia.org/wiki/Group_attribution_error
Müşteriyle kod yazarı arasındaki senkronu gerçekten artıran toplantılar nadir ve değerlidir. Büyük organizasyonlarda yanlış sebeplerle ritüelleşmiş toplantılar çoğalır. İnsanlar müşteriyle kod yazan kişi arasındaki sürece kendilerini sokarak varlık göstermeye çalışır
Ben şahsen müşteri, son kullanıcı, UX tasarımcısı ve gerçek paydaşlarla yapılan toplantıları severim. Kurum içi nüfuz uğruna bant genişliğini tüketen şirket politikacısı meşgul insanlarla yapılan toplantılardan nefret ederim. Kullanıcımla benim arama bir orta kademe yönetici daha girmesine gerek yok
Tersine, kod yazmanın çok hızlandığı ve asıl zor kısmın ulaşılması gereken iş/teknik gereksinimleri anlamak olduğu yeni dünyada, aynı kişi bu ritüellere daha fazla öncelik verebilir ve AI ajanları kod yazarken bölünmeyi tolere edebilir
Durumun olguları değiştiğinde fikrini değiştirmek ikiyüzlülük değildir
Şirket dışında biriyle yaratıcı bir proje yapacak olsan, aklına ilk gelen şeyin Scrum ritüelleri ya da Jira olmamasının birçok nedeni var. İşbirliğine önem verip bunları eleştirmek gayet tutarlı
Takım işin çok fazla olduğundan ve bu yüzden hiçbir şey yapamadığından şikâyet ediyor, bu yüzden yönetici beni görevlendiriyor. Sonra birden kimse hiçbir şeyi devretmek istemiyor. Şu anda da tam bunun ortasındayım
Takım “tamamen boğulduklarını” söylerken, benim üstlenebileceğim neredeyse her işi en iyi kendilerinin yapacağını ve yardıma ihtiyaçları olmadığını iddia edecek enerjiyi de buluyor. Bana uyar, oturup para alırım. Ama kokusu hep aynı
A: Kendilerinin değiştirilebilir olduğunu ve yaptıkları işin o kadar da benzersiz olmadığını, B: darboğazın süreç ya da iş yükü değil kendileri olduğunu kabul etmek istemiyorlar
Kıdemli mühendisler, hız sorununun gerçek nedeninin her zaman teknikten çok organizasyonla ilgili olduğunu zaten biliyor gibiydi
İşin odağında olan üretken bir yol haritasını tanımlayamamak, yazılım mühendisliğinin uzun süredir devam eden sorunu. ROI'si neredeyse olmayan bir sonraki parlak şeye sürekli atlanırken sistemik teknik borcun ele alınamaması, çalıştığım birçok şirkete uzun vadede zarar verdi
Bir yıl boyunca C++ kullanıp hâlâ std::unique_ptr'yi anlayamayan junior mühendisler tanıyorum; bu tür insanlar takım genelinde hep en yavaş olanlar
Eskiden junior mühendis performans değerlendirmesi yazarken, performans gerçekten de büyük ölçüde hıza bağlıydı ve kabaca belirli bir sürede yazılan hatasız kod satırı sayısıyla ölçülürdü. İyi junior'lar açıkça tanımlanmış bir özelliği alır, hızlıca iyi kod yazardı; iyi olmayanlar ise aynı işi ya yavaş yapar ya da hızlı ama hatalı kod yazar, böylece çok daha fazla debug ve yeniden yazım işi çıkarırdı
İş gerekçesini, kapsamı, girdileri ve istenen çıktıyı net biçimde anladığında veri modeli, sistem tasarımı ve kod neredeyse kendiliğinden ortaya çıkar ya da en azından çok daha netleşir
— Melvin E. Conway, 1967
Önce Chinchilla gibi scaling law'ların ne olduğunu ve doğrulama içeren reinforcement learning'in temelde nasıl çalıştığını anlayıp anlamadığını düşünmek gerekir
Temel sınırın, iş tarafının kendini ve stratejisini tutarlı biçimde ifade edip edememesi olduğuna tamamen katılıyorum
Ama şu anki avantaj, prototipleri neredeyse bedavaya üretebilmemiz. Eskiden mühendislik kapasitesine yatırım yaparken aşırı temkinli olmak gerekiyordu; şimdi aynı zaman kısıtı içinde çok daha fazla şeyi deneyebiliyorsun
Hangi özelliğin ve hangi bug fix'in ne zaman çıkarılacağı, ürünün genelinin nasıl geliştirileceği ve yönetileceği her zaman asıl zorluktu; bu stratejinin önemli bir kısmı da AI'ın hızlıca üretemeyeceği geri bildirim döngülerine dayanır
Aynı zamanda, iş tarafındaki liderlerin kendi kötü kararlarının sorumluluğunu almak yerine çoğu zaman mühendislik hızını günah keçisi yaptığını da düşünüyorum
Genelde darboğaz koddur ama kod yazma değil, kodun kendisidir. Kariyerimde yavaş uygulamalar yüzünden yaşanan sayısız gecikme oldu
Eclipse tabanlı editörler kullanmak zorundayım; yavaşlar, periyodik olarak donar ya da çöker. Build işleri 15-20 dakika sürer. Normalde en fazla 50 ms sürmesi gereken işleri sonsuza dek yapan web uygulamalarıyla da sık karşılaşıyorum
Böyle örnekler sonsuza kadar uzar. Her gecikme, odağımı paramparça eden bir kesintidir. Şimdi yönetici rolünde onlarca kişi ve idari kesintilerle uğraşıyorum ama hâlâ şirkette kod yazıyorum
Yazılım yavaşsa, benim en düşük önceliğim hâline gelir. Kimi etkilediği umurumda olmaz. Gerçekten önemli olsaydı, hepimizi aşağı çeken bu yavaş yazılım şurubuna rehin kalmazdık
Kod borçtur
Kodu bir varlık olarak görmek kolay olabilir ama özünde borçtur. Yeni koda giden bazı “darboğazlar”, ortaya çıkan çıktının artan borçtan büyük olmasını garanti etmek için vardır. Daha hızlı daha çok kod üreten ajanlar, daha hızlı daha çok borç üretir
Kodlama ajanları etrafındaki heyecan ve şüpheciliğin büyük kısmı, anlık verimlilik artışının — yani yeni özellikler, yeni ürünler ve yeni gelir gibi anlık çıktının — uzun vadeli borç artışını dengeleyip dengelemeyeceğiyle ilgili. Cevabı ancak önümüzdeki 1-3 yıl içinde göreceğiz ve alanlara göre değişecek
Bu bakış açısından, bu tür darboğazları doğrudan ajan tabanlı workflow'nun içine koyma girişimi bir ölçüde mantıklı. Tutarlı bir proje vizyonunu önemseyen ve yeni özelliklere ya da sınırsız süreçlere itiraz edebilecek ek bağlamı kodlama ajanına vermek değerli olabilir
Yazının demek istediği bu mu? Bazı ajanların ürün yönetimi sorumluluğunu üstlenip mümkün olduğunca çok şeyi tutarlı bir ürün vizyonunda sentezlemeye çalışması ve sonra bu vizyonu kodlama ajanlarına mümkün olduğunca katı şekilde hatırlatması mı?
Bu tür ajanlar yeni önerileri ve yeni pull request'leri “büyük resme uygunluk” açısından mı incelemeli? Buna bağlam dersin, vizyon dersin ya da başka bir ad verirsin
Bu tür ajanlar bağlamı sentezleme ve takım değerleriyle vizyonuna dilsel olarak uyan tutarlı bir yol haritası sunma konusunda çok iyi olabilir. Ama iyi bir yönetici ya da iyi bir takımın sahip olduğu sağduyuya sahip olacaklarından şüpheliyim. Belirli bir yol haritasını hızlı ve ikna edici şekilde onaylamak faydadan çok zarar da getirebilir
Fazladan karmaşıklık yaratmadan iş gereksinimlerini çözen minimum kod, bakım borcu taşıyan bir varlıktır. Tıpkı bakım gerektiren bir çiftçi traktörü gibi; ihmal edilirse bit çürümesiyle değer kaybeder
Gereksiz karmaşıklık üretmek için yazılan kod ise saf borçtur
Doğru, ama kod yazmak her zaman bir şey öğretir
Kurucu ölçeğindeki startup'larda da yüz milyarlarca dolarlık halka açık şirketlerde de çalıştım; fakat spesifikasyona göre uygulandığında sorunu çözecek çözümü gerçekten tarif eden bir ürün spesifikasyonu, pitch deck ya da PRD hiç görmedim. Onu gerçekten yapmaya başladığında nasıl çalışması gerektiğini öğrenirsin
Yazılım karmaşık ve etkileşimli bir ortam. Sorunu anlamak ve çözmek isteyen insanlarla birlikte kod içinde yineleme yapmak, değerli ürünlerin ortaya çıkmasının tek yolu oldu. Toplantılar ve diyagramlar yardımcı olur ama çalışan yazılımı yazmadan elinde gerçekten bir şey olup olmadığını bilemezsin
“Amaç, yapılandırılmış üretim algoritmamızı ve onun open source karşılıklarını test etmek, naif ‘bu string'i kabul ediyor mu?’ sorusunu gerçek soruna daha yakın olan ‘doğru token dağılımını üretiyor mu?’ sorusuyla değiştirmekti… Geçen ay Codex'e 30 dakika boyunca yöntemi anlattım. Birkaç saat sonra çalışan ilk sürüm çıktı. Hepsi buydu”
Bu, darboğazın gerçekten kod olduğunu kanıtlıyor. Şimdi sadece o kodu AI yazdı
“Darboğaz kod değildi” diye düşünen kişi zaten hedefleri konuşmuş ve bunları zihninde tutarlı bir şekilde netleştirmişti
Kodun darboğaz olduğunu söylemek ille de “bu özelliği istiyordum ama kodlaması aylar sürdü” anlamına gelmez. “Bu özelliği 2 yıldır istiyordum ama oturup onu koda dökmenin ve 5-10 gün harcamanın yarattığı sürtünme yüzünden erteledim” de buna dahildir
Eğer kod darboğaz olmasaydı, kişi oturup onu kendisi yazardı. Ama kendisi kodlamanın gerektirdiği emek ve zamanı vermek istemedi ve bunun LLM kadar az zahmetli olmayacağını da biliyordu
Nihai spesifikasyonun net olmadığı durumlarda bile, keşif amaçlı kod yazma, doğrulama, atma ve yeni tasarımı yeniden deneme süreci LLM kullanınca daha hızlı. Çünkü tam da “kod” kısmı hızlanıyor
Başka bir deyişle, darboğaz koddu
Bu yazının kendisi de klişelerden kaçınma talimatı verilmiş AI üretimi bir yazı gibi duruyor; bu yüzden hâlâ okuması sıkıcı
Yazıda “Jevons Paradox: Bir şey ucuzladığında onu daha az değil, daha çok kullanırsın” denmiş ama bu, Jevons paradoksunu bozuyor
O cümle paradoks değil, gayet doğal bir etki. Bir şey ucuzlarsa kullanımının artması beklenir
Jevons paradoksunun aslında anlattığı şey, bir kaynağın kullanımının daha verimli hâle gelmesiyle belirli bir iş için gereken miktar azalmasına rağmen, o kaynağın toplam kullanımının yine de artması durumudur
Ama kaynak kullanımı daha verimli hâle gelince, o “kullanım”ın fiyatının düşmesi de normal değil mi?
Dolayısıyla verimlilik arttığında kullanımın artması da doğaldır. Buna paradoks denmesinin sebebi, bazı insanların verimlilik artışının tüketimi azaltmanın iyi bir yolu olduğunu naifçe düşünmesidir
“Paradoks” denen şeylerin neredeyse hepsi bu kadar bariz
Ya da bir süreç daha etkili, yani daha kısa zaman alır hâle geldiğinde, bizim o sürece daha fazla zaman harcamamız da olabilir
Hangi şey için darboğaz? Daha fazla özellik mi?
Yazılım miktarının bir şirketin başarısını belirlediğini sanmıyorum. Bağlam miktarını yakalamanın da o kadar önemli olduğunu düşünmüyorum
Önemli olan bağlamın kalitesi. İnsanlar ne kadar iyi akıl yürütebiliyor?
Sonra tutum gelir. İnsanlar kötü durumlara ne kadar iyi tepki veriyor?
Sonra kaynak yönetimi gelir. Şirket insanı ve parayı ne kadar iyi yönetiyor?
Son olarak da şans. Kontrolümüz dışındaki ne kadar çok şey bizim lehimize işliyor?
Bunlar bir şirket için oldukça iyi darboğazlar. Ajanların bunları yakında çözeceğini sanmıyorum
Yazılım dışı bir işletmenin kullandığı yazılım uygulamalarını daha iyi hâle getirmenin darboğazı, yazılımın gerçekten işletmeye fayda sağlayan bütün yazılım işlerini yaptığından emin olmaktır
Zaman kazandıran, insanları daha üretken kılan, insan hatasını azaltan, işletmeyi daha verimli yapan ve kâr marjını yükselten şeyler bunlardır
Bunların hepsini öngörmek ve nicelleştirmek epey zor. İşletmeye yardımcı olabilecek bir fikirle başlayabilir, tasarlayabilir, prototip çıkarabilir ve test edebilirsin. Sonunda bir yazılım uygulaması yapar ya da geliştirir ve işletmeyi ne kadar iyileştirdiğini ölçmeye çalışırsın
Tüm bu süreçte, yazılımın doğru sorunu doğru şekilde ele aldığından ve sonuçta işletmeyi gerçekten daha iyi hâle getirdiğinden emin olmak zor bir problemdir. Yazılım yapmanın ne kadar hızlı ve kolay hâle geldiğinden bağımsız olarak
Yine de hız gerçekten yardımcı olabilir. Prototip çıkarabilir, test edebilir ve geri bildirim döngülerini iyileştirebilirsin
AI kodlama yardımcıları kullanıldığında, eskiden junior geliştirici işi sayılan şeyler artık hızlı bir prompt ve arka planda çalışan ajanlarla uygulanıyor
Bu tür junior geliştirici işleri artık kodlama yardımcıları tarafından neredeyse insan müdahalesi olmadan kolayca teslim ediliyor. Backlog, yeni öğe eklenme hızından daha hızlı boşalıyor. Ve işleme kapasitesi artık sorun olmaktan çıktıkça yeni öğeler de giderek daha fazla ekleniyor
Artık mesele değişim hacmini yakalayabilmek. Bunu kendi organizasyonumuzda doğrudan görüyoruz
Başka darboğazlar düşünebiliyor olman, kod üretiminin darboğaz olmadığı ya da artık olmadığı anlamına gelmez. Backlog kavramının kendisi bile bunun bir darboğaz olduğunu gösterir
“Yazılım, bir grup insanın sistemin ne yapması gerektiği konusunda birbiriyle pazarlık ettikten sonra geriye kalan şeydir”
Bu ifadeyi sevdim. Özellikle bağlam konusunda katılıyorum. Uzun süre birlikte kalan deneyimli takımların ödüllendirildiği yer tam da burası
Onlarca yıl boyunca böyle takımlar yönettim. Sonunda departmanımız birleştirildiğinde, kıdemi en düşük mühendis bile 10 yıllıktı
Bir takım bu kadar uzun süre birlikte olunca iletişim overhead'i neredeyse önemsiz seviyeye iner
Bu yüzden günümüzdeki kısa ömürlü çalışma süresi kültürü bana özellikle üzücü geliyor
Şimdi çoğunlukla tek başıma çalışıyorum. Verimliliğim çok yüksek ama kapsamım gerçekten sınırlı
İyi bir takımın parçası olduğum günleri özlüyorum
Ne tür projelerde çalışıyorsunuz ki yöneticilerin istediği özellikleri anlamak tek zor kısım olsun da geri kalanı sadece “yazıp çıkarmak” ya da artık LLM'e devretmek olsun?
Yaptığınız iş buysa, HN'deki birçok kişinin LLM'lerin kendilerini yerinden edebileceğini düşünmesi de şaşırtıcı değil
Böylece yine aynı daireyi dönüp kaygılarımızı dile getiriyor, birbirimizi ıskalayan şeyler söylüyor ve 30 dakika sonra bir sonraki yorum fırsatını bekliyoruz
Çoğu, offshore ve işten çıkarma döngüleri yüzünden kod kalitesi açısından alev alev yanan çöp yığını gibi