- Mühendislik üretkenliği, gösterge paneli metrikleri ya da yeni özellik sayısıyla doğru şekilde ölçülemez
- Çoğu şirket, mühendisliğin özündeki "yapı yönetimi" yerine yalnızca çıktıları (yeni özellikler, dağıtım hızı vb.) takıntılı biçimde yönetir
- Yapay zeka kodlama araçları göze hoş görünen çıktılar üretmeyi kolaylaştırır, ancak gerçek sistemin temelini, karmaşıklığını ve bağlamını doğru şekilde ele alamaz
- Deneyimli mühendis ekiplerini yapay zeka ya da düşük maliyetli iş gücüyle değiştirdiğinizde, kısa vadede sorun yokmuş gibi görünse de zaman geçtikçe temel yapı çökmeye başlar
- "Sağduyu (common sense)" eksikliğiyle yapılan yönetim ve yapay zeka benimsemesi ciddi riskler doğurabilir; sonuçta hem teknoloji hem iş tarafında gerçek anlayış kritik önem taşır
Gösterge panelleri ve metriklerin kaçırdığı gerçek mühendislik
- "Big Agile" ortamında mühendislik, yalnızca yeni özellikler, dağıtım hızı gibi gözle görülen çıktılarla değerlendirilir
- Milyarlarca dolarlık üretkenlik gösterge panelleri ve araçlar vardır, ancak gerçekte öz olan şeyi ölçemezler
- Gerçek mühendislik, sistem kurma, sürdürme ve geliştirme gibi karmaşık ve birbirine bağlı bir iştir
- Yapısal bağımlılıklar, kaynak tahsisi, mimari yönetimi gibi "görünmeyen işler" kurumun hayatta kalması için kritik önemdedir
- Ancak yönetimlerin ve metriklerin çoğu bu temel faaliyetlere yokmuş gibi davranır
Teknik borç ve yönetimin kör noktası
- Teknik borç, çoğu zaman "geliştiricilerin yapmak istediği şey" gibi görülür
- Gerçekte teknik borcun giderilmesi gerekiyorsa, bunun yeni özelliklerin içine ustaca yedirilmesi gerekir ki onay alsın
- Böylece çekirdek yapı yönetimi arka plana itilirken, bütün organizasyon çıktı odaklı biçimde çarpılır
Çıktı odaklı yapay zeka benimsemesinin riskleri
- Yapay zeka ile kod üretimi, yüzeysel işlevleri hızlıca ortaya çıkarmada çok başarılıdır
- Yüzeysel işler (arayüz uygulamak vb.) kolay görünür, ama gerçekte önemli olan sistemin yapısı ve bağlamıdır
- "Ev inşa etmek", yalnızca basit işlerin (duvar kâğıdı, klozet montajı vb.) birleşimi değildir
- Yapay zeka bu özsel bağlantı yapısını bilmez; yanlış bağlayabilir ya da mantıksal kopukluklar yaratabilir
- Yapay zekanın hallucination (halüsinasyon) sorunu: kulağa inandırıcı gelir ama gerçekte tamamen yanlış olabilir
Yapıyı görmezden gelen yönetimin kısa vadeli yanılsaması
- Deneyimli ekipleri işten çıkarıp yerlerine yapay zeka / düşük maliyetli iş gücü koysanız bile, kısa vadede sorun görünmez
- Çünkü ortada zaten iyi kurulmuş bir yapı (temel) vardır; bu yüzden anında bir çöküş yaşanmaz
- Ancak zamanla temel çözülmeye başlar ve o noktaya gelindiğinde geri dönüş artık mümkün olmaz
- Kritik altyapı, bakım bilgisi ve bağlamın tamamı kaybolur
Mühendisliğin taşıdığı toplumsal risk
- Mühendislik artık tüm toplumsal altyapının temelidir (sağlık, finans, medya, devlet, savunma vb.)
- İnsanların ve liderlerin çoğu bu yapısal özü gerçekten anlamaz
- Yanlış yapay zeka benimsemesi ve "Big Agile"ın yüzeysel yaklaşımı, kritik sistemler için risk yaratabilir
"Sağduyu" eksikliği ve bunun yıkıcılığı
- Örneğin, yapay zeka temizlik robotu bulaşık makinesine kâğıt tabak koyarsa, sıradan biri sorunu hemen fark eder
- Ancak yazılım sistemlerinde yöneticiler, liderler ve geliştirici olmayanlar bu temel sağduyuya sahip değildir
- Pratiği hiç yaşamamışlardır ve yönetimi yalnızca "t-shirt size", "poker planning" gibi biçimsel terimlerle yaparlar
- Bunun sonucunda 200 milyar dolarlık verimsiz bir sektör ve kendini yeniden üreten bir bürokrasi ayakta kalır
Yapay zeka çağında gerçek rekabet gücü: sezgisel anlayış ve sağduyu
- Yapay zekayı doğru kullanmak için ilgili alan hakkında gerçek anlayış ve sağduyu şarttır
- Yüzeysel metriklere ve çıktılara değil, gerçek yapıya ve bağlama bakabilmek gerekir
- Buna sahip olmayan liderler ve organizasyonlar, sonunda ya kendi kendine çökecek ya da rakiplerinin gerisinde kalarak ortadan kaybolacaktır
- Sonuç olarak, AI ve araçlardan daha önemli olan şey sağduyu ve özsel anlayıştır
2 yorum
Yazı iştah açıcı.
Hacker News görüşü
SWE'den ürün yöneticiliğine ve artık makalede bahsedilen yönetim kurulu odasındaki çizgi film kötü adamı rolüne kadar uzanan bir geçmişim var. Bu yazıda en çok katıldığım nokta, yazılım mühendislerinin kendi işlerinin en karmaşık ve en anlaşılmaz iş kolu olduğuna inanması. “Teknik olmayan liderlerin çoğu, büyük bağımlılıkları güncellemenin, bir refactor'u tamamlamanın ya da yeni bir dil öğrenmenin gerçekte ne anlama geldiğine dair ciddi bir deneyime hiç sahip olmadı; çünkü yazılım ve sistem yönetiminin gerçek işine hiç gerçekten dahil olmadılar” cümlesine katılıyorum. Teknoloji şirketlerindeki her işlevin gizli bir karmaşıklığı var ve bunların çoğu, mühendislikten çok daha fazla, insani ve kişiler arası karmaşıklık da taşıyor. Aslında mühendislik, yalnızca bilgisayar denen deterministik bir sistemle uğraştığı için nispeten daha basit. Bu yüzden birçok mühendis, uğraştıkları karmaşıklığın risklerini iş tarafına anlaşılır biçimde aktarmayı öğrenmiyor. Birlikte çalışmanın insani gerçeklerini görmezden gelip, satış kökenli CEO'nun kendi varlıklarını anlamadığından yakınmaları da çok yaygın
Söylediğine kısmen katılıyorum ama yorumun, eleştirdiğin davranışın tersini yapıyor gibi. Sen de kendi rolünün yani ürün yöneticiliğinin dışarıdan bakılınca karmaşık ve anlaşılmaz olduğunu söylemiş oluyorsun. SWE'den PM'e geçmiş biri olarak, mühendislere (1) kendi karmaşıklıklarının riskini iş tarafına nasıl aktaracaklarını, (2) başkalarıyla ve ekipler içinde çalışmanın insani gerçeklerini, (3) satışçı kökenli bir CEO'nun neden onları anlayamadığını öğretmek için ideal bir konumdasın. Teknoloji şirketlerindeki tüm fonksiyonların gizli bir karmaşıklığı var
Bence karmaşıklığın farkına varmak da başlı başına insani bir mesele. Karmaşıklık fraktal; onu ancak yeterince yaklaştığında hissediyorsun. Ayrıca mühendislerin yalnızca bilgisayar karmaşıklığıyla uğraştığı iddiasına da katılmıyorum. Tam tersine, organizasyonun ve tüm müşterilerin karmaşık ihtiyaçlarını katı bilgisayarlara aktarma ve yorumlama işi mühendisin omzunda. Her eklenen istisna ve vaka, tüm sistemi etkiliyor. Bu yüzden kıdemli mühendislerimden iş terminolojisini kendilerinin öğrenmesini ve bu mesajı doğrudan iletebilmelerini bekliyorum. Artık bunun mühendisin temel araç setinin parçası olduğunu düşünüyorum
Çoğu mühendis, şirket için gerçekte neyin değer yarattığını derinlemesine düşünme eğiliminde değil. Build pipeline'ın akıcı olması ya da test coverage'ın geniş olması, ancak ürün riskini azalttığı ölçüde değerlidir. Kullanıcısı o kadar az olan bir yazılım varsa ki kimse umursamıyorsa, ekibime onu bakımda bile tutmamalarını önerdiğim oldu. Buna karşılık, kullanıcıların %90'ının kullandığı küçük bir özelliği kusursuz hale getirmeye takıntılı olmalarını istediğim zamanlar da oldu
Bu bana babamın hep anlattığı bir hikâyeyi hatırlattı. Bir gün vücuttaki organlar hangisinin daha önemli olduğunu tartışıyormuş. Beyin, “Ben önemliyim, ben ölürsem herkes ölür” demiş; kalp de “Ben durursam hepiniz hemen ölürsünüz” diye bağırmış. Böbrek, karaciğer, deri ve omurga da katılmış, tartışma sürüp gitmiş. Ama göt deliği kapanınca sonunda kimse konuşamaz hale gelmiş
Bence yazı, diğer fonksiyonel alanlarda gizli karmaşıklık yok demiyor. Daha çok, mühendislik/programlama tarafındaki gizli karmaşıklık göz ardı edildiğinde türlü sorunlar ve acılar ortaya çıktığını anlatmaya çalışıyor. Ama üslubu biraz saldırgan
Patronunuzun/CEO'nuzun/yöneticinizin size LLM araçlarını düşüncesizce kullanmanızı dayatması, geliştiricilerin yerini almasını beklemesi ya da “vibe coding”in gelecek olduğuna dair saçma bir fikre sahip olması durumunda, yapmanız gereken akıllıca şey hızla kaçıp yeni bir iş bulmaktır. Hâlâ LLM'leri yerinde kullanan ama geliştirici değiştirme ya da 10x verimlilik gibi hayallere kapılmayan çok sayıda şirket var. Bu saçmalığı zorlayan şirketlerin başında gerçek liderler değil aptallar vardır
AI'nin Jira'yı hacklemesi konusuyla ilgili olarak, Atlassian'ın yakın zamanda çıkardığı MCP adlı yeni ürünün; hassas verilere erişim, herkese açık issue'lar üzerinden güvenilmeyen veri açığa çıkışı ve dış iletişim olasılığı olmak üzere üç şeyin birleşimi nedeniyle veri sızdırma saldırılarına açık olduğu ortaya çıktı. Ayrıntılı bug raporu burada, benim kişisel notlarım ise burada
AI araçları yüzünden job security konusunda endişelenen birine vereceğim tavsiye “iş tarafına bağlanmak” olur. Birçok mühendis havalı ve zor problemlere kapılıp yalnızca teknolojiye odaklanıyor; ama iş problemlerini, özellikle de stratejik olanları anlayıp teknolojiyi bunları çözmek için kullanan kişi daha çok öne çıkar ve daha değerlidir. Bu problemler genellikle tek bir teknik alanı aşar ve işbirlikçi, sosyal yönleri de güçlüdür; dolayısıyla alışmak zaman alır. Ama IC'lerin önündeki yolun bu olduğunu düşünüyorum
Ama mülakatlarda “iş tarafına bağlanma” gibi yetenekler pek sorulmuyor; dolayısıyla gerçekte çok değer yaratabilecek olsanız bile system design mülakatını geçemezseniz işe alınmıyorsunuz. Distributed systems, software engineering, databases, leadership derken zaten bilinmesi gereken çok şey var; bir de iş tarafını bilmek gerekiyorsa, insan gerçekten ne yapacağını ve bunların hepsini ne zaman öğreneceğini sorguluyor. Elbette her alanda iyi olan çok az sayıda insan var ama herkes öyle değil
“İş tarafına bağlanın” tavsiyesi gerçekten altın değerinde. Bu sayede mühendis olarak gerçek problemleri çözmeye odaklanabilir ve yaptığınız şeyin gerçekten gerçek bir problemi çözdüğünden emin olabilirsiniz
Yazının ana mesajı fena değil ama insan uzmanlığını görmezden gelmenin AI ile zarara yol açabileceği noktasının ötesinde, fazla “biz ve onlar” çerçevesi kuruyor ve “Agile Industrial Complex” ifadesiyle mühendis olmayan alanlardaki insanlara biraz tepeden bakıyor gibi. “Kimse geleceğin nasıl olacağını bilmiyor” noktasına değinmemesi de eksik kalmış. Yazılımın karmaşıklığını iyi biliyor olmak, belirsizliğin sadece bize ait olduğu anlamına gelmiyor. HN'ye bakınca bile yazılım geliştiriciler arasında AI hakkında umut ve beklentilerin keskin biçimde ayrıldığını görüyorsunuz. Uzmanlar olarak bizim, en azından kamuoyunun kaygısını yatıştırma gibi bir sorumluluğumuz da yok mu?
“Big Agile” içindeki mühendisliğin yalnızca yeni özellik geliştirmek olduğu anlayışı nedeniyle, herkesin neden ‘agile’dan nefret etmeye başladığına şaşırıyorum. ‘Agile’ ortaya çıkmadan önce de yöneticiler hep yeni özellikler isterdi. T-shirt sizing diye bir kavram yokken de yöneticiler belirli zaman aralıklarıyla (gün, ay, kısa, uzun) tahmin ister, rastgele tarihlere dayanarak söz verir ve mühendisleri fazla mesaiye zorlardı. Agile'ın 8. ilkesinde de (“sürdürülebilir tempo korunabilmelidir”) görüldüğü gibi, yöneticiler çok önceden beri geliştiricilerin hayatları boyunca koşmalarını istiyordu. O halde, ‘scrum master’ diye yeni bir meslek yaratmanın ötesinde, ‘agile’ın kendine özgü zararı tam olarak neydi?
Bence Agile, yöneticilere her işi önceden biletlere bölüp kabaca da olsa tahmin edilebileceği ve o işin 2 hafta içinde bitebileceği yanılsamasını verdi
İnsanların agile'dan nefret etmesinin nedeni bence iş saatlerinin büyük kısmının neredeyse anlamsız toplantılarla (standup, retrospective, sprint planning, refinement vb.) tüketilmesi. Mühendis açısından o zamandan elde edilen somut fayda çok az
Benim deneyimimde Agile, sadece olan biteni “sayısallaştırmak” için yeni bir yöntem daha ekledi. Yöneticilere ya da yatırımcılara ilerlemeyi anlatırken işe yarıyor ama mühendis açısından yalnızca idari yükü artırıyor. Agile'ın asıl günahı verimlilik yanılsaması yaratması olabilir. Gerçekte mühendise dayatılan gereksiz bir accountability aracı. Finans sektöründe çalışırken bu, sonsuz büyüme zihniyetiyle birleşmişti; her şey ölçülüyor, gelecekte daha iyi sonuçlar zorlanıyor ve maaş bile metriklere göre değişiyordu. Elbette her yerde böyle olmayabilir
Bu yazıyı okurken, “Atlassian AI'yi Jira'ya entegre etmeye çalışırken AI Jira'ya başkaldırsa nasıl olurdu?” diye eğlenceli bir hayal kurdum. Film konusu bile olur
Sonunda AI'nin yavaş Jira'dan bıkıp kendi kendine hafif ve hızlı bir issue tracker geliştirmesi bile mümkün olabilir diye düşündüm
Yakında build bot'lar ile bug tracker'lar sendikalaşıp açık issue sayısı 0 olana kadar yeni binary yayımlamayı reddedecek gibi görünüyor
Roko’s basilisk de belki böyle doğar
Yazının ima ettiği gibi, asıl sorun geliştirici verimliliği için güvenilir sektör standardı metriklerinin olmaması. Bu yüzden C-suite kendi işine gelen metrikleri seçip “AI First stratejimiz muazzam işe yarıyor” diyebiliyor, mühendisler de kendi deneyimlerine veya ölçümlerine bakıp AI'nin aslında işe yaramadığını savunuyor. Sonuçta iki taraf da kendi pozisyonunun kazandığını düşünüyor ve gerçek önemsizleşiyor; siyasi bakış daha önemli hale geliyor. Bu durum, geliştiricilerin ilgisiz olduğu ve sadece laf çevirdiği algısını, yöneticilerin ise cahil olduğu ya da mühendisliğin gerçeklerinden habersiz olduğu yönündeki güvensizliği artırabilir. Daha önce outsourcing gibi araçlar da iki tarafa “kazanç” ve “kayıp” imgeleri vermişti, ama AI her iki tarafın damak tadına göre ortak hata/kazanç/kayıp anlatıları üretebildiği için siyasi açıdan felakete dönüşebilir. Bir başka ilginç nokta da şu: Büyük teknoloji şirketleri eskiden hep 10* engineer peşindeydi ve bu stratejinin başarı getirdiğine inanıyordu; şimdi ise AI'ye yatırım gerekçesiyle bu stratejiyi küçümsemeye başlıyorlar. Artık soru şu: AI'ye yaslanıp mevcut çalışanları ikame etmek ya da kitlesel işten çıkarmalar yapmak, gerçekten sürdürülebilir ve sorunsuz mu? Twitter ve Musk'ın işten çıkarma örneğine bakınca backend hâlâ çalışıyor gibi görünüyor. Büyük teknolojide yıllarca geliştirici çıkarıp onları AI ile değiştirme deneyinin “kanarya”sı kim olacak? Bir başka olasılık da, maintainability kavramının ortadan kalkması; C-suite AI'nin otonom değişikliklerine daha çok izin verirse codebase insan gözüyle anlaşılamayacak kadar karmaşık hale gelebilir ve onu anlamak için yeniden AI'ye ihtiyaç duyulabilir. Uzun vadede generative AI, tüm insan etkileşimlerinin ara katmanını işgal edebilir. İşe alım tarafında bile şimdiden özgeçmişleri AI filtreliyor, adaylar da AI ile özelleştirilmiş CV'ler hazırlıyor; bir “AI vs AI” düzeni filizleniyor. Bu durumun giderek toplum genelinde standart hale geleceğini düşünüyorum
Bir gün AI'nin e-posta kutularını ve Google Meet'i hackleyip C-suite'i ve yöneticileri de yerinden etmesini umuyorum. Claude CEO/CTO/CFO/VP/direktör ajanlarının mevcut yöneticilerden daha rasyonel ve daha kararlı stratejiler üretmesi fikri eğlenceli geliyor
Reddit'te şunu görmüştüm: “CEO'yu AI ile değiştirmenin 8 kat daha fazla maliyet tasarrufu sağlayacağını söyleyin.” İronik olan şu ki, böyle bir öneri AI tartışmalarında neredeyse hiç gerçekten gündeme gelmiyor. Bir açıdan bakınca elitleri AI ile değiştirmek karar kalitesini çok da düşürmeyebilir ve toplamda çok daha ucuz olurdu (hesap verme düzeyi de aşağı yukarı aynı). Ama kimse kendi koltuğunu AI ile değiştirmeye yanaşmaz; karar yetkisi de zaten kendilerinde
Bu iddianın içinde şaka payı var ama aslında CEO'nun temel rolü “sorumluluğu üstüne çekmek” olduğu için, LLM bir sorun çıktığında sorumluluğu yükleyip kapının önüne koyabileceğiniz bir şey değil; bu yüzden pratikte anlamsız. Yine de AI sayesinde organizasyon yapısının
log(n_employees)gibi küçülüp katmanların ortadan kalktığı şirketler görebiliriz ve bazı katmanlar tamamen AI ile değiştirilebilir. Ayrıca LLM'lerin sorumluluk alamama sorununu aşmak için, çeşitli loncaların ve bağımsız yüklenicilerin LLM koordinasyonunda birlikte çalıştığı örgütlenme biçimleri de mümkün olabilir. O durumda sorumluluk tek tek bileşenlerde kalırHatta AI'nin bu şekilde kullanılması en iyi kullanım örneklerinden biri olabilir; yakında teknoloji kooperatiflerinin bu fikri denemeye başlayacağını tahmin ediyorum