Yapay zeka süreçlerinizi daha hızlı hale getirmeyecek gibi görünüyor
(frederickvanbrabant.com)- Süreç optimizasyonu akışı içinde yapay zekaya dair gerçekçi olmayan beklentiler yayılıyor, ancak yalnızca yapay zekayı devreye almak işlem hızını tek başına artırmıyor
- Yazılım geliştirmenin uzun sürmesinin asıl nedeni kod yazma hızı değil, muğlak gereksinimleri net problem tanımlarına dönüştürme süreci
- Yapay zeka ile kod üretimi de aynı upstream sorunu ile karşı karşıya ve doğru sonuçlar için alan ve ürün uzmanlarının derin katılımı şart
- Yapay zeka kullanımını karşılaştıran örneklerde sıkça atlanan handholding süreci, gerçek üretkenlik farkını yaratıyor; insan geliştiriciler de aynı ayrıntı düzeyindeki belgeleri aldığında üretkenlikleri ciddi biçimde artıyor
- Süreçleri gerçekten hızlandırmak için The Goal'un verdiği ders doğrultusunda önce "darboğaza öngörülebilir ve yüksek kaliteli girdi sağlamak" gerekiyor
Piyasa durgunluğunda süreç optimizasyonu ve yapay zeka beklentisi
- Piyasa durgunlaştığında çoğu organizasyonun en azından kısmen süreç optimizasyonuna odaklanma eğilimi var; son dönemde buna yapay zeka unsuru ve gerçekçi olmayan beklentiler de eklenmiş durumda
- The Toyota Way ve The Goal, birçok süreç optimizasyonu yaklaşımının neye odaklanması gerektiğini kolayca yanlış anlayabildiğini hatırlatıyor
- Uzun süren bölüm iyileştirmeye başlamak için bir işaret olabilir, ancak sorunun gerçekten orada ortaya çıktığı kesin değildir
- Sadece daha fazla insan eklemek ya da yapay zekanın hızı büyük ölçüde artıracağını varsaymak, işin neden geciktiğini görmeyi engeller
- Süreci hızlandırmak için önce çalışanların işe gerçekten başlayıp bitirebilmesi için gerekli girdilere ve koşullara sahip olup olmadığına bakmak gerekir
Görsel darboğaz (The visual bottleneck)
- Gantt şeması örneği üzerinden en uzun süren aşamanın yazılım geliştirme olduğu görsel olarak doğrulanabiliyor
- Normalde BPMN kullanmak yaygındır, ancak açıklamayı kolaylaştırmak için burada Gantt şeması kullanılıyor
- Hedef proje throughput'unu iyileştirmekse, en uzun süren aşamaya önce bakma yaklaşımı kendi başına doğrudur
- Sorun, insanların bunu çözme biçiminde
- Probleme daha fazla insan yüklemek
- Yapay zekanın bunu çok daha hızlı yapacağını varsaymak
- Asıl olarak "bu aşama neden uzun sürüyor?" sorusuna bakılmıyor; daha da önemlisi, uzun sürmesi sorunun kaynağının mutlaka bu aşamada olduğu anlamına gelmiyor
Sorunu upstream tarafta çözmek
- Örnek olarak yazılım geliştirme ele alınıyor, ancak bu yaklaşım istediğinizden uzun süren tüm süreçler için aynı şekilde geçerli
- Yazılım geliştirme sadece yazma hızını artırarak hızlanmaz; öyle olsaydı herkes daktilo dersi alıyor olurdu
- Yazılım geliştirmenin özü, bir problemi bilgisayarın otomatik olarak çözebileceği bir çözüme çevirmek, mümkünse bunu güvenli ve ölçeklenebilir bir şekilde yapmaktır
- Bunun için probleme dair bütünlüklü bir anlayış gerekir
- Daha çok waterfall yaklaşımı varsa özellik dokümanı veya kapsam dokümanı gerekir
- Agile yaklaşımda ise alan uzmanlarıyla sürekli iteration gerekir
- Geliştirmeyi gerçekten yavaşlatan şey, başlıktan ibaret muğlak bir feature talebinin ne anlama geldiğini çözme süreci
- "Satış tamamlandığında kullanıcıya e-posta gönder (send mail to user once sale is completed)" talebi de doğrudan uygulanabilir bir gereksinim değildir
- E-posta gönderilebilir, ama e-postada ne yer almalı
- Satış sürecinde sorun yaşandıysa hata e-postası gönderilmeli mi
- Satışın "tamamlandığı" an tam olarak ne zaman
Her şeyi yapay zekaya bırakma iddiası
- Sık duyulan iddia, yapay zeka ile kod üretimi sayesinde geliştirme aşamasının atlanabileceği ve yazılım geliştiricilerin yalnızca proje yöneticisi rolüne kayacağı yönünde
- Birçok kişi mevcut uzun yazılım geliştirme aşamasının yaklaşık 3 günlük bir yapay zeka geliştirme aşamasıyla değiştirileceğini bekliyor
- İnsanların zihninde yapay zeka geliştirmeye dair bir sonuç resmi var, ancak pratikte bu şekilde işlemiyor; aynı upstream sorunlarıyla doğrudan karşılaşıyor
- Yapay zekanın kodu hızlı üretebildiği doğru (bunun iyi bir şey olup olmadığı ayrı bir tartışma), ancak hızlı üretim doğru kod üretimi demek değil
- İnsan vs yapay zeka geliştirme karşılaştırmalarında sürekli göz ardı edilen şey, yapay zekanın düzgün çalışması için gereken handholding süreci
- Bu yöntem mevcut yaklaşımdan daha hızlı olabilir, ancak adil bir karşılaştırma değil
- Yapay zeka ile geliştirme ancak alan uzmanları ve ürün uzmanlarının çok daha derin katılımıyla çalışır
- Her özelliğin en küçük ayrıntısına kadar yazılması gerekir
- Her hata düzeltmesinde de istenen sonucun ne olduğunun ayrıntılı biçimde tanımlanması gerekir
- Bu, yazılım geliştiricilerin mesleğin başından beri sürekli talep ettiği şeydir: yani probleme ve nihai çıktıya dair ayrıntılı bir genel çerçeve sağlanması
- İnsan geliştiricilere de aynı hacimde feature/scope dokümanı verilirse üretkenlikleri muhtemelen aynı ölçüde sıçrayacaktır
Süreç hızını gerçekten artırmanın yolu
- Süreç hızını artırmak için işi yapması gereken kişilerin o işi gerçekten yapabilmek için ihtiyaç duyduğu tüm araçlara sahip olduğundan emin olmak gerekir
- Hukuki onay süreci yavaşsa, önce hukuki onay sürecini başlatmak için ne gerektiğine bakılmalı
- Eksik belgeler yüzünden beş kişinin peşinde koşmak gerekiyorsa, departmana daha fazla avukat eklemek hızı artırmaz
- The Goal'un büyük derslerinden biri, darboğazın öngörülebilir ve yüksek kaliteli girdiler alması gerektiğidir
- "bottlenecks should receive predictable, high-quality inputs"
- Süreç otomasyonunun ilk çıkış noktası, darboğazın kendisi değil, darboğazın alacağı girdi kalitesini ve öngörülebilirliğini artırmak olmalı
1 yorum
Hacker News görüşleri
Yazılım geliştirmede en başından beri istenenin “problemi ve istenen sonucu ayrıntılı biçimde anlatmak” olduğu söylenir ama, aslında bunun kendisi yazılım mühendisliğidir
2026’da bile yeterince ayrıntılı gereksinim ve spesifikasyon varsa tek seferde kusursuz bir çözüm üretilebileceği fikrinden vazgeçmek gerekir
Benim deneyimimde yapay zeka sayesinde özellikleri ve fikirleri çok daha hızlı yineleyebilir olduk; artık sürtünmenin çoğu diğer ekiplerle hizalanma ve koordinasyonda yaşanıyor
Süreci hızlandırmak için koordinasyon maliyetini azaltmak ve bireylerle ekiplerin karar alma ve uygulama yetkisini artırmak gerektiğini düşünüyorum
Anthropic’in elinde kusursuz spesifikasyon, referans implementasyon ve yıllar içinde insanlarca yazılmış binlerce test vardı; buna rağmen çalışan bir C derleyicisi gibi basit bir şeyi bile yapamadı
Mevcut modeller, kusursuz spesifikasyon ve kusursuz testler olsa bile, dikkatli bir insan gözetimi olmadan önemsiz olmayan üretim yazılımları geliştirecek kadar yeterli değil
Kusursuz spesifikasyon ve insanlarca yazılmış kusursuz test paketi yoksa iş daha da zorlaşıyor; belki 2027 civarında mümkün olabilir
Öğleden sonra ürün sorumlusunun aklına gelmiş işleri sık sık alıyorum; onlar sadece mutlu yolu düşünüyor, bazen onun bile sadece bir kısmını düşünüyor
Küresel bir şirket olduğumuz için her ülkenin düzenlemelerine ve yasalarına uymamız gerekiyor; özelliği uyguladıktan sonra “aslında faaliyet gösterdiğimiz pazarların %90’ında bunu yasal olarak yapamayız” deniyor ve sonra kapatma mekanizması eklemek zorunda kalıyoruz
Ardından “bu pazarların bazılarında regülasyon süreci tamamlanırsa yapılabilir, ona göre uygulayın” diye geri dönüyorlar
Son teslim tarihi kapıya dayandığı için sonuçta çözümü apar topar yamamak zorunda kalıyoruz
Bu yazılım mühendisliği değil; yazılımın kendisiyle de ilgili değil
Yazılım mühendisinin işi, bir gereksinim listesi alıp o gereksinimleri nasıl karşılayacağını bulmaktır; gereksinim toplama ise yazılım mühendisliği problemi değildir
Yazılım uygulamadır, ürün ise davranıştır; yapılacak şeyin davranışı ciddi biçimde geliştirmeye başlamadan önce bilinmelidir
Biri bir hafta erteleyip gereken incelemeyi yapsaydı, ölçeklenebilir, genişletmesi kolay, bakımı kolay ve geleceği daha rahat hale getiren bir yapı tasarlanabilirdi
İlk programımı yazalı 40 yılı geçti ama önce spesifikasyonun tamamlandığı, sonra yazılımın yazıldığı ve her şeyin iyi gittiği bir durum hiç görmedim
Önemsiz olmayan mühendislikte en zor kısım problemi anlamaktır ve yazılımın ilk sürümleri bu anlayışa ulaşma biçimidir
Bu yüzden yapay zeka tabanlı “yazılım fabrikalarının” asla iyi çalışmayacağını düşünüyorum
Sonuçta yeniden şelale geliştirmeye dönülüyor; mimar UML diyagramları çiziyor ve programcı ekibine özünde basit implementasyon işi veriyor ama aslında yanlış şeyi implement ettiriyor
Yapay zeka, yanlış olan ilk sürümden daha az yanlış ikinci sürüme hızlı geçmekte çok iyi
Ama asıl görevin çözülmeye çalışılan problemi anlamak olduğunu unutmamak gerek
Bana sadece ayrıntılı spesifikasyon verilse, o zaman yalnızca bir kodlama robotu olurum; öyle işleri de junior’lara veririm
Eskiden olduğu gibi benim işim, bu gereksinimleri okuyup anlamak ve bildiğim gerçeklikle karşılaştırarak doğrulamak
Kod için de aynısı geçerli
Son en az 20 yıldır yazılım mühendisliğinin özü kimseye güvenme anlayışı oldu; bu değişmedi ve hâlâ çok zaman ile emek istiyor
LLM’ler ilk çıktığında insanlar sanırım “bana bir Facebook klonu yap” demenin yeterli olacağını düşünüyordu
Şimdi ise gereksinimleri daha net ve daha iyi tanımlamak gerektiğini fark ediyorlar
Bu her zaman yazılımın darboğazı olmuştu
Eskiden çalışırken gerçekten “veriyi al ve kullanıcıya ver” gibi gereksinimler alıyordum
Hangi veri olduğu, nerede tutulduğu, hangi formatta döneceği belli değildi; bu yüzden ürün sorumlusuyla uzun zaman geçirip aslında ne istediklerini ortaya çıkarmamız gerekiyordu
LLM’den iyi sonuç almak için de benzer bir şey gerekiyor; belirsiz gereksinimler belirsiz sonuçlar doğuruyor
Sorunun ne olduğu ve neden olduğu; örneğin backend’de X alanı varken frontend’de neden olmadığı gibi ayrıntılarla şablonlar dolduruluyor, verinin nereden nasıl alınacağı ve kabul kriterlerinin ne olduğu bile yazılıyor
Eskiden ya üşengeçlikten ya da “geliştirici çözer” düşüncesiyle yapılmayan şeylerdi bunlar
Sonrasında geliştirici bu Jira ticket içeriğini istediği LLM ajanına kopyalayıp yapıştırabiliyor ya da Atlassian MCP ile LLM’in bunu otomatik okumasını sağlayabiliyor
Bu geliştiriciler için çok faydalı oldu ve gereksinimleri de çok daha net hale getirdi
Dürüst olmak gerekirse, ilk aşamaya bakınca PM’ler sanki özellik implementasyonunun yarısına kadar gelmiş gibi; gelecekte PM’ler her şeyi kendileri yapar da bazı geliştiriciler tam implementer olmaktan çok SDET gibi kalır mı diye düşünüyorum
Orada vibe coding’in temel özelliklerini ve şu anda yaşadığımız deneyimi oldukça isabetli biçimde anlatıyor
Dikkatle seçilmiş birkaç alanda ilk başarıların ardından, bunun o alanların dışına genişlemesiyle makul ama devrimsel olmayan verimlilik artışları ortaya çıkacağını söylüyor
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Hiç “bana bir Facebook klonu yap”a yakın bir prompt kullanmadım; onun yerine nasıl çalışması gerektiğini anlattım
Örneğin
/etc/hostsdosyasını okuyacak,.confiçinden belirli host değerlerini bulacak, her yapılandırmayı adlandıracak, mevcut ortamı belirleyecek, Ubuntu 22 varsayılan GNOME’da sağ üstte bir simge oluşturacak, tıklanınca yapılandırma adlarını listeleyecek ve seçim yapıldığında/etc/hostsdosyasını yedekleyip yalnızca belirli host adı satırlarını değiştirecek bir Python betiği istedimBununla neredeyse tek seferde basit bir GNOME uygulama göstergesi ortam değiştiricisi çıktı ve birkaç satır düzeltince çoğunlukla çalıştı
LLM’e düzgün bir spesifikasyon verirseniz iyi üretir; hatta ne istediğinizi anlatmak için uydurma bir DSL kursanız bile onu da anlıyor
Önceki sürecin işlememesinin nedeni, gereksinimi yazan kişinin iş niyetini anlamaması ya da dikkatsiz davranıp belirsiz veya kötü gereksinimler üretmesiydi
LLM aynı belirsiz ya da kötü gereksinimleri sadece makul görünür hale getiriyor; biraz derine inince sorun ortaya çıkıyor
“Veriyi almak ne demek?” gibi sorular gelir
LLM ise sadece “Elbette! Veriyi alıp kullanıcıya veren tamamlanmış kod burada” deyip geçer
Bu yazı, yapay zekanın yalnızca geliştirme aşamasını etkilediğini varsayıyor ama bu kesinlikle doğru değil
Fikir üretimi, hukuk, dokümantasyon, geliştirme ve dağıtım dahil tüm aşamaları hızlandırabilir
Fikir üretiminde fikir alışverişi yapılabilir, bilgi tabanıyla karşılaştırma yapılabilir ve tasarım dokümanları hazırlanabilir; dokümantasyonda ise dokümanın büyük bölümleri üretilebilir
Geliştirme zaten malum; dağıtım tarafında da deployment manifest’leri, test araçları ve bulut platformu bilgisi üretilebilir
Tüm aşamalar yapay zekayla daha iyi ve daha hızlı olabilir; hepsi değilse bile büyük kısmı mümkün
Geliştirmede de benzer şekilde, problemi herkesten iyi anlayıp çözüm üretilen kısımlar var ama tamamen angarya olan kısımlar da var
Bir düğmenin X yapması gerektiğini biliyorsanız, o düğmeyi tasarlamak, yerleştirmek, hover ve press durumlarındaki istisnaları düşünmek ve backend’e bağlamak angaryadır ve neredeyse her aşamada aynı ilke geçerlidir
Yeni ve önemli bir özellik eklemek istediğinizde genelde iş birimleriyle günlerce, haftalarca hatta aylarca toplantı yapıp işlerin sistem X, Y, Z arasında nasıl aktığını ve kritik istisnaları anlamanız gerekir
Örneğin A alt kümesi şöyle işlenir, B böyle işlenir ama son aşamada iki grup birleştirilir; yalnız C için özel süreç 97 gerekir gibi şeyler olur
Bu anlayışın ardından, birden fazla sistemi kapsayan bir sistem çözümü tasarımı gelir; iç sistemlerle tedarikçi sistemleri karışır ve her sistemin özelleştirilebilirlik seviyesi farklı olduğu için nihai çözümün şeklini farklı yönlere iter
Kodlama hızını artırmanın değeri kesinlikle var ama bu yapbozun yalnızca bir parçası; mevcut LLM’ler alan bilgisini toplamak ve çözümü tanımlamak konusunda yardımcı olmuyor
Bir ek nokta daha var: artık daha fazla roldeki insan, eskiden fiziksel prosedürlerle zorlayarak çözdükleri sorunlar için yazılım araçları üretebiliyor
Biz küçük bir üreticiyiz; derin yazılım mühendisliği deneyimi gerektiren dev kurumsal projeler yapmıyoruz ama basit yazılım araçları süreçleri ve verimliliği her yerde iyileştiriyor
Sevkiyat sorumlusu eskiden çok sayıda insan-saat harcayarak çözdüğü bir sorunu özel bir araçla çözebilir hale geldiğinde gerçekten etkileyici sonuçlar çıkıyor
Yazılım geliştirmede yapay zekayı çok kullanıyoruz ama daha hızlı yayın yapmıyoruz; hatta benzer ya da farklı nedenlerle daha yavaş olduğumuzu bile düşünüyorum
Sanki ütopya gelecekmiş gibi garip bir his var ama gelmiyor ve sorunun tam olarak nerede olduğunu da işaret etmek zor
Hatta bu tür görüş ayrılıkları ve güvensizlik, piyasada fırsatlar ve çıkış noktaları yaratır
Eğer projedeki kişilerin ortalama IQ’su 140 ise, IQ’su 150 olan bir yapay zeka hattaki her bireyi kopyalayabilir
Yapay zekanın şunu yapamayacağını, bunu yapamayacağını söyleyenler, bu IQ farkının tek yönlü biçimde büyüdüğü gerçeğini kabul etmek zorunda
Bir yandan bu yazı, büyük organizasyonlarda teknik iş yapan birçok kişinin düşündüğü ve sahada gördüğü şeyleri tam isabetle anlatan düzgün bir metin
Yazara %110 katılıyorum; keşke başkaları da bu yazının anlattıklarını anlasa
Öte yandan, hem HN’de hem gerçek iş hayatında son dönemde bu konuşmayı onlarca kez yapmışım gibi hissediyorum
Liderlerin, yapay zekanın gerçekten işleri hızlandıracağına inanıyormuş gibi davranmak için sosyal ve finansal teşvikleri var; bu yüzden tek bir blog yazısıyla ikna olmayacaklar
Bu yüzden artık sadece onların yapay zeka projelerinin başarısız olmasını ya da mevcut projeler kadar yavaş gitmesini bekleyip bir şeyler öğrenmelerini umuyorum
Şirkette böyle yazıları paylaşmaya bile çekinir oldum; statükoyla uyuşmayan şeyler pek iyi karşılanmıyor gibi
Görseller ve Gantt şemaları, tam olarak PM’lerin anlayabildiği PM dilidir diye düşünüyorum
C-level yöneticiler ve yatırımcılar “yenilik sinyali verme” işini sürdürdükçe bu hemen çözülmez ama böyle şeyler de sonsuza kadar devam edemez
O yüzden bugünlerde bahçeyle uğraşıyor, ajan tabanlı araçlarla kişisel kodlama projelerine kafayı takmış halde zaman geçiriyorum
Sıfırdan yüksek performanslı bir OLTP veritabanı yapmak, yeni bir mantıksal ilişkisel kalıcı programlama ortamı kurmak, tuhaf matematik tabanlı bir synthesizer ve FPGA soft processor geliştirmek gibi işler
Yani sıradan insanların yaptığı sıradan işler
Bu yüzden bu araçların tek bir kişinin elinde neler yapabildiğini biliyorum ve gerçekten etkileyici
Ama şirkette çalışan arkadaşlarımdan minimum token kotası koyduklarını, “yıldız yapay zeka kodlayıcı” liderlik tabloları yaptıklarını, “kod review yapmayın”, “elle kod yazmayın” dendiğini duyunca insanın başını sallayası geliyor
Kışın biraz sözleşmeli iş yaptım; fena değildi ama kurucu her hafta sonu tüm yeni projeyi vibe coding ile kurarken, kod review işi LLM’lerin birbirine kapıştığı bir gösteriye dönüştü
Bu araçlar ekip çalışması ya da gerçek ekip yazılım mühendisliği için pek uygun değil
Sektör toparlanana kadar biraz geri çekilip izlemeyi düşünüyorum
Çalışması güzel yerler, ancak “yavaş ol!” diyebilen ve bunu dediklerinde ayakta kalabilecek kadar yaşlı ve bilge insanların olduğu yerler olacak
Bu arada Ontario, Hamilton bölgesinde kesilmiş ravent demeti 5 dolar
Kuşkonmaz da var, hem de bolca
İlginç bir ikilik var
LLM’ler zaten iyi olduğum işlerde nispeten az etki yaratıyor ama iyi olmadığım işlerde muazzam bir oyun değiştirici oluyor
Büyük şirketler bir proje için gereken rollerin çoğunu işe alabildiği için toplam etki görece küçük olacaktır
En fazla bir kişinin beş kişilik işi vasat biçimde yapmasını sağlayıp iş gücü maliyetini düşürürsünüz; karşılığında da daha kötü bir ürün alırsınız
Kısa vadeli kazanç ile uzun vadeli maliyet birleşiminin nasıl sonuçlanacağı tahmin edilebilir
Ama küçük stüdyolar ya da bağımsız geliştiriciler için LLM büyük bir değişim
Beş kişilik işi vasat da olsa yapabilmek, o roller olmadan ayakta kalmaya çalışmaktan, üçüncü taraf varlıklara ya da başka içeriklere dayanmak zorunda olmaktan ya da daha kötüsü tamamen doğaçlama korkunç işler çıkarmaktan çok daha büyük bir sıçrama
Programcı tarafından tasarımcı olmadan yerleştirildiği belli olan neredeyse tüm program arayüzlerine bakmanız yeterli
Ya da Dribbble’dan bir şeyler kopyalamaya çalışan ama beceremeyen örneklere
Yapay zekayla birden her şeyi ve herkesi makul görünecek kadar kopyalayabiliyorsunuz; aslında yapay zekanın neredeyse tüm çalışma biçimi de bu
Bana ders kitabı tanımı gibi geliyor
Kişisel olarak bende tam tersi
LLM ancak ne yaptığımı zaten tam olarak bildiğimde faydalı oluyor
İnsanlar, önemsiz olmayan yazılım geliştirmenin %50’sinin bile kodlama olmadığını pek anlamıyor
Kodlama aşaması genelde en kolay kısım ve junior geliştiricilere veriliyor
Büyük organizasyonlarda ürün değişikliklerinin çoğu, birçok sistem ile insanların yürüttüğü operasyonların içinden geçiyor
Senior ve mid-level kişiler zamanlarının çoğunu, yerel öncelikleri mevcut sibernetik varlık içinde yeni bir düzene oturtmaya ve kendi öncelikleri olan diğer ekiplerden bu yeni vizyon için onay almaya harcıyor
Bunun içinde doğal olarak çok sayıda ödünleşim ve siyaset var
Senior mühendisler, sorumlu oldukları sisteme “ağırlık” eklememek ve kapsam genişlemesini ya da hedeflenen yönün dışına çıkılmasını engellemek için güçlü biçimde direniyor
Bu yüzden uzlaşma gerekiyor ya da öncelik seçimi için yönetime eskalasyon yapılması gerekiyor
Yapay zeka bunu da çözebilir mi bilmiyorum ama bu çok daha zor bir iş
Artık birer araç çağırıcısı durumundalar; yani kodlama ajanları lint, type-check ve test çalıştırabiliyor, çıkan hataları düzeltebiliyor, Sentry gibi gözlemlenebilirlik platformlarını kurcalayıp kök nedeni bulabiliyor, benchmark çalıştırıp yavaş kodu ya da hot path’leri bulabiliyor, kullanılan kütüphanelerin yeni major sürümlerine ait migration dokümanlarını okuyup uygulayarak sistemi güncel tutabiliyor
Eğer bunlar ajana geri basınç uygulayacak ve sistemi daha iyi anlamasını sağlayacak şekilde kurulmamışsa, evet sadece aptal bir LLM kod yazarı olarak kalır
Ama modeller ve onları saran harness’ler hızla gelişirken bunun çok daha ötesine gidebileceği açık
Bu yazı genel olarak doğru ve yapay zekanın süreci hızlandırması için nereye odaklanılması gerektiğine dair ipucu veriyor
Örneğin bir ürün yöneticisi, paydaşlarla yapılan toplantı bittiğinde interaktif prototip ortaya çıkmıyorsa bunun başarısızlık sayılacağı bir gelecek hayal ettiğini söylemişti; bence yön doğru
Bir başka beklentim de vibe coding’in “Excel 2.0” haline gelmesi
Böylece etkileşimli uygulamalar oldukça self-servis şekilde üretilebilecek ve IT, bunları daha iyi güvenlik garantileri, uygun erişim kontrolü ve loglama, ölçeklenebilirlik, değişiklik yönetimi gibi özelliklerle dönüştürmeye çalışan bitmeyen bir savaşa girecek
Daha geniş tarihsel açıdan bakınca, her devrimsel geçiş başlangıçta bir “buharlı at” üretir
Buhar makinesi icat edildiğinde insanlar ulaşımın geleceğini, mevcut arabaları çeken buharla çalışan at biçimli şeyler olarak hayal etmişti
Ancak daha sonra ulaşımın işlevini biçiminden ayırarak anlayabildik
Ben aslında buharlı at benzetmesini ilk MOOC’lar için duymuştum; MOOC tam anlamıyla tipik bir buharlı at fikriydi
Prototip üretmek için kod gerekmez
Tıpkı bir sahneyi anlatmak için illa oyuncu ve kameraya değil, birkaç eskize ihtiyaç duyulması gibi
Verilen Gantt, şelale modelinin ya da yazılımın nihai bir varış noktası olduğunu varsayan başka bir metodolojinin örneği
Günümüzde yazılımın %99,999’u böyle yapılmıyor
Modern yazılım geliştirmede bir varış noktası yok
Her 2 haftada bir iş birimi, yazılımın ne yapması gerektiğini değiştiriyor
Yeni özellikler, yeni entegrasyonlar, değişen özellikler, yükseltilen veya değiştirilen bileşenler, daha büyük ölçek, farklı hosting seçenekleri durmadan geliyor
Birkaç yıl sonra yazılım temelden dönüşmüş oluyor; kalite ve test de pencereden dışarı uçuyor
Sadece yama niteliğinde değişikliklerle baş etmek değil, entropiyle verilen bitmek bilmeyen bir mücadele yaşanıyor
Yazılım yaralanan, yaşam tarzı değişen ve yaşlanan canlı bir varlığa dönüşüyor
Şirket de sanki depresif bir hayvanı yaşatmaya çalışan hayvanat bahçesi bakıcısı gibi bu canavarı ayakta tutan bir koruyucuya dönüşüyor
İnsan alışkanlıklarının esiri olduğu için, yapay zeka kullansak da aynı sorunların hepsi ortaya çıkacaktır
Sadece her şey biraz hızlanır ve kod review kodu biraz daha iyi hale getirebilir
Aynı anda iyi testlerin eksikliği ve daha hızlı yayınlama isteği de her şeyi biraz daha kötü yapar
Bu itiş kakışın sonucunda yazılım kalitesi aşağı yukarı aynı kalır ama sistem biraz daha hızlı hareket eder
Sonuç olarak daha hızlı bir süreç olacaktır ama geri kalan her şey hâlâ eziyet olduğu için kimse bunu çok hissetmeyecektir
Muhtemelen herkes sadece daha hızlı tükenmişlik yaşayacaktır
Karmaşıklığın bir nedeni vardır; o nedeni ortadan kaldırmadan karmaşıklığı kaldıramazsınız
İş problemlerini araçlarla çözemezsiniz
“Yapay zeka kodu hızlı üretebilir ama bu, doğru kodu ürettiği anlamına gelmez” sözüne karşılık, pratikte kod neredeyse her zaman doğru oluyor
Benim hoşuma gitmeyen genelde kodun sisteme eklenme biçimi
Kod tabanını yeterince iyi tanıyorsanız nereye ekleme yapılacağı, nasıl adlandırılacağı, yorumların ne kadar ve nereye yazılacağı gibi ritüeller vardır
Ajan bunları düzgün yapamazsa benim gibi biri sinir oluyor ve görünüşe göre AGENTS.md içine yazmak bile yetmiyor
“İnsan geliştiricilere de aynı miktarda özellik/kapsam dokümanı verilse üretkenlikleri fırlar” sözüne gelince, BT’de neredeyse 20 yıldır çalışıyorum ve bunun gerçekleşebileceğine asla inanmıyorum
Olsa bile o kadar nadirdir ki tartışmaya değmez
Bunun için, zaten yazılmış bir sistemi kopyalamanın maliyetiyle o sistemi sıfırdan yaratmanın maliyetini karşılaştırmanız yeterli
Özellikle girdi bir bug ya da performans sorunu olduğunda sık sık halüsinasyon görüyor ve elinden tutmazsanız yanlış teşhis koyuyor
Yine de ne yaptığını izleyip doğru yöne iterseniz kök neden analizi ve analiz işlerinde iyi sonuç veriyor, verimliliği de artırabiliyor
İnsanların, makinelere kıyasla bilgiyi sindirme ve analiz etme hızında sınırları olduğu için üretkenlik artışının da bir tavanı olduğunu düşünüyorum
Yapay zekanın süreci baypas etmesi gerekmiyor ama yine de hızı artırabilir
Refactoring, boilerplate kod yazımı, daha önce görülmemiş hataları bulma ve linter’ın yakalayamadığı şeylerde yardımcı olabilir
Birçok yorum, ya yaygın kabul görmüş standart süreçleri kullanmıyor ya da yapay zeka kullanınca artık o standartlara uymaya gerek olmadığını varsayıyor gibi görünüyor
Daha fazla kod ve özellik yayınlayabilir misiniz? İyi gereksinimler ve yeterli test varsa elbette evet
Yapay zekanın yazdığı her kod review ve testten geçmeli; ayrıca ayrı commit’lere ve pull request’lere bölünmeli
Binlerce satırlık PR açan kişi başlı başına bir uyarı işaretidir
Bunu yapay zeka olmadan da yapmazdınız; o halde yapay zeka kullanınca neden yapasınız
Bilinen tek istisna büyük çaplı rewrite ya da refactoring işleri ama orada bile değişim sürecini görebilmek için geri alınabilir ayrı commit’ler olması daha iyi değerlendirme yapmayı sağlar diye düşünüyorum
Bana devasa tek parça bir commit ya da PR gösterirseniz reddederim
Her şey sıradan bir geliştiricinin denetleyebileceği parçalara bölünmeli