[Bottleneck Shift] Kod neredeyse ücretsiz olduğunda, yazılım mühendisliğinin darboğazı nereye gitti? AI Çağı Yazılım Mühendisliği Değişimi — Yavaşça AI Öğren173
Kod neredeyse ücretsiz olunca, darboğaz ihtiyaçlara, entegrasyona, doğrulamaya ve hizalamaya kaydı
Kod üretimi neredeyse ücretsiz olunca, yazılım teslimatının darboğazı “kod yazma” yerine başka yerlere kaydı: doğru soruyu tanımlamak, parçaları çalışır bir bütüne birleştirmek, bunun gerçekten doğru olduğunu doğrulamak ve organizasyonu hizalamak. Bu, yazılım endüstrisindeki Kısıtlar Teorisi’nin (Theory of Constraints) bir yeniden canlanışıdır. Üretim sektörü 40 yıl önce bu yolu zaten geçti: Bir aşamanın maliyeti düştüğünde, darboğaz kaybolmaz, sadece en pahalı sonraki aşamaya taşınır. Bunun farkına varırsanız, yaygın bir kafa karışıklığını açıklayabilirsiniz: AI kodlama araçları şirket çapında yayıldı, kod yazma hızı açıkça arttı, ancak teslimat hızı neredeyse değişmedi.
Bir üretim grubunun CIO’su, geçen altı aylık verilerini gösterdi. IT ekibi 80 kişiden fazlaydı ve tümü AI kodlama araçlarını kullandı; kod üretimi açısından bakıldığında, kişi başı commit sayısı ve merge hızı %30’un üzerinde arttı. Ancak iş birimlerinin deneyimi tamamen farklıydı: Bir akıllı üretim planlama fonksiyonu, proje başlatılmasından canlıya alınmasına kadar hâlâ 3 aydan az sürmedi. O, araçların 2 kat hızlanma sağlayacağını sanmıştı, ancak sadece “kodun daha hızlı yazıldığını” satın almıştı. Sözleri çok açık: “Milyonlarca dolarlık lisans aldım, aldığım şey geliştiricilerin daha meşgul olması ve iş birimlerinin daha acele etmesi.”
O, darbo proceso kliūtį neteisingai nustatė. Tikroji kliūtis buvo kita: kiekvienas naujas funkcijos elementas privalo prasiprojenuoti per MES, ERP, kokybės kontrolės sistemą, gamybos terminalą ir dar vieną reguliavimo ataskaitų sistemą; integracija ir testavimas suėmė daugiausia laiko; o AI sugeneruotas kodas neturi jokios oficialios patikros etapo, kuris būtų užkirstas kelią tarp jo ir gamybinės aplinkos. Net jei kodą rašai greičiausiai, tu tiesiog eiliuojiesi už neteisingos kliūties. # I. Gamybos pramonė: 40 metų atgal žinojo, kad kliūtys keliauja
Norint suprasti dabartį, pirmiausia pažvelkime į gamybos pramonės 40 metų senumo akinius. 1984 m. izraelietis konsultantas, fizikas Eliyahu Goldratt, parašė romaną „Tikslas“ (The Goal), kuris pasakoja, kaip beveik bankrotavęs gamybos vadovas išgelbėjo fabriką. Visos knygos esmė – viena sakinys: bet kurios sistemos išvestis nustatoma jos siauriausiu elementu (apribojimu, arba kliūtimi). Išplėtus nekliūtį, bendras išvestis nepakyla; tik išplėtus pačią kliūtį, visa sistema tampa greitesnė. Ir kai tik išplėtėte kliūtį, ji nedelsdama persikelia į kitą siauriausią vietą. Tai vadinama apribojimų teorija (Theory of Constraints, TOC).
Üretimden sonraki 40 yıllık otomasyon tarihi, neredeyse bir “sıkışma noktalarının yer değiştirmesi tarihidir.” CNC tezgâhlar kesim işlemlerini ucuzlaştırdığında, sıkışma noktaları kalıp değiştirme ve kalite kontrol’e taşındı; esnek üretim hatları kalıp değiştirmeyi hızlandırdığında, sıkışma noktaları üretim planlaması ve tedarik zinciri koordinasyonuna kaydı; MES sistemleri üretim planlamasını daha doğru hale getirdiğinde, sıkışma noktaları talep tahmini ve çoklu fabrika koordinasyonuna yükseldi. Her bir bölüm otomatikleştirildiğinde, bir sonraki bölüm yüzeye çıkıyordu. Otomasyon sıkışma noktalarını asla ortadan kaldırmaz, sadece onların yerini değiştirir. Bu kural sadece üretimin özelidir. 2026 yılının Temmuzunda, a16z’in “Software in the Age of Agents” adlı podcast’inde, eski Microsoft Windows başkanı Steven Sinofsky, kurumsal yazılım örnekleriyle bağımsız olarak aynı sonuca vardı. Onun tam ifadesi şuydu:
“The long tail got no shorter. It just got longer in a different way.”
O, Amazon müşteri hizmetleri örneğini verdi: Telefon hizmetini kaldırdı, chatbot’un doğrudan ürün yeniden göndermesini sağladı — görünürde insan kaynakları tasarrufu sağlıyordu; ancak arka planda hemen “benzer sorunların tekrar önlenmesi” için kök neden analizi ihtiyacı doğdu, bu da telefonla konuşmaktan daha karmaşık hale geldi. Giderlerin ödenmesi süreci de aynı: OCR otomatik muhasebe kaydı yaptıktan sonra, maliye departmanının yapması gereken şey, seyahat verimliliği optimizasyonu ve dinamik fiyat karşılaştırması oldu — iş yok olmadı, sadece “giriş” seviyesinden “analiz ve karar verme” seviyesine taşındı. Bir Microsoft eski çalışanı ve a16z ortağı, Goldratt’ın teorisini kullanmadan, 40 yıl önce imalat sektöründe ortaya çıkan aynı sonuca vardı. Birisi fabrika zemininden, diğeri kurumsal yazılımdan geldi; iki bağımsız yol, aynı kurala ulaştı.
Ancak bu kurala bir sınırlama eklemek gerekir, aksi takdirde mutlak bir gerçekmiş gibi yorumlanabilir. Gerçekten de kalıcı olarak yok olan darboğazlar var: sekreterler, telefon operatörleri, kurşun harf diziciler — bu meslekler “yukarı taşınmadı”, tamamen ortadan kalktı. Bir işin taşınacak mı yoksa yok olacak mı olduğunu belirleyen anahtar, otomasyonun serbest bıraktığı kapasitenin yeni talepleri mi yarattığını (ekonomide bu, Jevons paradoksu olarak bilinir), yoksa sadece o talebi mi küçülttüğünü görmektedir. Kurumsal sistemlerin etrafındaki çoğu iş, ilk kategoriye girer: Hesaplar ne kadar hızlı hesaplanırsa, yönetici o kadar çok ve detaylı analiz görmek ister. Bu yüzden buradaki sonuç “otomasyon kaç işi kaldıracak” değil, “insanları ve bütçeyi, otomasyonla yerini alan seviyeden, yeni ortaya çıkan seviyeye taşımak”tır. (Kurumsal yazılım perspektifinden uzun kuyruk taşınması — ek not: “Kurumsal Yazılım Yapışkanlığı” tam olarak ele alınmıştır.)
Bu olay, düşündüğünüzden çok daha yakın bir mesafede yazılım ile ilgili. 2013’te Gene Kim, Goldratt’ın fabrika hikayesini neredeyse aynen IT operasyonlarına aktararak The Phoenix Project‘ı yazdı: Bir CIO’nun, bir şirketin tamamını alt üst edecek kadar zayıflamış bir IT departmanını kurtarmak için kısıt teorisini nasıl kullandığı. Dolayısıyla “yazılımı üretiminin darboğazları açısından görmek” geçici bir benzetme değil, zaten doğrulanmış bir yol. # II. Yazılıma Dönüş: Kod Yazmak Artık En Ucuz Aşama Haline Geliyor Üç sayı, “kod üretiminin maliyetinin sıfıra yaklaşması” fikrini açıkça ortaya koyuyor.
- Copilot: GitHub’ın kendi araştırmalarına göre, Copilot’un etkinleştirildiği dosyalarda yaklaşık %46’sı Copilot tarafından tamamlanıyor. Bu oranın neyi ölçtüğünü dikkate alın: bu, GitHub’taki tüm kodların %46’sı değil, Copilot’un etkinleştirildiği dosyalar içindeki kodun %46’sıdır.
- Stripe: İçinde geliştirilen kodlama ajanı “Minions”, haftada 1.300’den fazla PR üretip birleştiriyor (başlangıçta 1.000, sürekli artıyor). Burada unutulmaması gereken kritik bir detay var: her bir PR, birleştirilmeden önce insan tarafından inceleniyor. Stripe, “yazma” işlemini otomatikleştirdi, ancak “onaylama” işlemini insana bıraktı. Bu nokta dördüncü bölümde kullanılacak.
- NVIDIA: Jensen Huang, NVIDIA’nın tüm mühendislerinin Cursor gibi AI programlama araçlarını kullandığını açıkça açıkladı ve “AI kullanmadan çalışmak” NVIDIA’da artık kabul edilemez hale geldi.
Bu üç veriyi bir araya getirdiğinizde sonuç net: bir satır kod üretmenin birim maliyeti, sıfıra hızlıca yaklaşmakta. Bu durumda sert bir soru ortaya çıkar: Eğer kod yazmak neredeyse ücretsizse, neden yazılımlar hâlâ bu kadar pahalı, yavaş ve teslimi zor? Cevap, Kısıt Teorisi’nden geliyor: “Kod yazma” aşamasını genişlettiniz, ama darboğaz sadece yer değiştirdi. Nereye?
Üç: Sıkışma Noktaları Dört Yere Yayıldı
Bu sefer, sıkışma noktaları dört aşamada yoğunlaştı. Her biri, AI’nın kısa vadeli olarak ulaşamayacağı bir alandır.
İlk: Doğru soruyu tanımlamak.
AI, “söylediğiniz o fonksiyonu” saniyeler içinde yazabilir, ancak “gerçekten ihtiyacınız olan fonksiyonu” yazamaz. Çoğu yazılım projesinin başarısız olmasının kök nedeni, yapılan şeyin kimse tarafından kullanılmamasıdır—başlangıçta çözülmesi gereken soru netleştirilmemiştir. Kod üretiminin maliyeti düştükçe, “bulanık bir işsel sorunu, net, çözülebilir ve çözülmesi değerli bir spesifikasyona dönüştürmek” (problem formulation) en nadir ve en pahalı yetenek haline geldi. Üretim sektöründeki meslektaşlarımız bunu iyi bilir: üretim süreci ve mühendislik çizimleri yanlış belirlenirse, fabrika ne kadar verimli çalışırsa çalışsın, sadece defolu ürünleri büyük miktarlarda üretir.
İkinci: Sistem entegrasyonu.
AI, “bir kod parçası”, “bir fonksiyon”, “bir sayfa” üretmekte ustasdır. Ancak canlıya geçirilebilir bir sistem, yüzlerce parçanın entegrasyonudur; bu parçalar birbirleriyle veri paylaşmalı, sınır durumlarını işlemeli, tutarlı kalmalı ve istisnai durumlara dayanmalı. Parçaları üretmek ucuzdur, ancak bu parçaları güvenilir bir bütüne birleştirmek pahalıdır. Bu maliyetin kökeni, organizasyon ve mimari uyumundadır—tam da Conway Yasası ve takım topolojilerinin ilgilendiği konudur (bu serinin ilk iki yazısına bakınız). Başlangıçtaki bu üretici CIO’ya dönelim: Onun zamanı kod yazmada değil, MES, ERP, kalite kontrol ve raporlama sistemlerinin birbirleriyle senkronizasyonunda harcanmıştır.
Üçüncü Engel: Doğrulama. Kod miktarı patlıyor, güvenilirlik değişken. Kim “bu doğru” diye karar verecek? Test, kod incelemesi, gözlenebilirlik, gradüel yayın — bu “doğrulama” faaliyetlerinin ağırlığı azalmıyor, artıyor. Bu, en az değer verilen engel ve imalatın en derin aynası. Bu konuyu dördüncü bölümde ayrıntılı ele alacağız.
Dördüncü Engel: Örgütsel Hizalama. Takımda AI ajanları eklendiğinde, kim ne yapacağını karar verecek, kim inceleyecek, kim sonuçlardan sorumlu olacak? Bu, Conway Yasası ve takım topolojisinin bir uzantısı; örgütsel hizalama kendisi bir engel haline geldi. Serinin 11. makalesinde ayrıntılı olarak ele alacağız: Örgütsel düğümler insanlardan oluşmadığında, yönetişim nasıl temel bir rekabet avantajına dönüşür.
# IV. En Derin Kesim: Doğrulama ve Toyota'nın "Jidoka"sı Bize Ne Öğretiyor?Dört engelden en çok yanlış anlaşılanı doğrulama. Birçok kişi bunu “AI hızlı yazıyor, o yüzden daha fazla test yapalım” olarak yorumluyor. Bu sadece yarım doğru. Doğrulamanın neden pahalı hale geldiğini anlamak için, en çok yanlış anlaşılan ve en çok yanlış kullanılan kavramı düzeltmek gerek: Jidoka.
Yaygın bir yanlış anlayışı düzelteyim. Jidoka, “AI veya makineyle insanın yerini alma” anlamına gelmez; aynı zamanda “insanı makine gibi yapmak ve sürekli çalıştırma” da değildir. Bu iki yön de tamamen tersine çevrilmiştir.
Ji-dō-ka’nın kelime kelime anlamı zaten cevabı saklıyor. Japonca’da “otomasyon” genel otomasyon anlamına gelirken, Toyota özel olarak “自働化” terimini kullanır; buradaki “働” karakteri, “insan” anlamına gelen “人” kısmını içerir ve “insanlı otomasyon” (automation with a human touch) vurgusunu yapar. Tam tanımı şudur: Makine veya üretim hattı bir anomali tespit ettiğinde, otomatik olarak durur ve insan müdahale ederek kök nedeni çözer, ardından üretimi yeniden başlatır. Bu sistemde iki mekanizma paralel çalışır: Makine kendi içinde anomali algılama sistemiyle kendini durdurur; üretim hattındaki herhangi bir çalışan bir sorun fark ettiğinde, bir “andon” ipini çeker ve hemen tüm hat durur. Kalite, son aşamada kontrol edilmez; her üretim aşamasında yerinde tespit edilir ve hemen çözülür.
Burada karşıt bir sonuç var ve bu, yazılıma doğrudan karşılık geliyor: Otomasyon ne kadar derinleşirse, kalite kontrol noktaları ve insan müdahalesi miktarı da sadece artar. Ji-dō-ka, insanları “tekrarlayan görevlerden” kurtarır ve onları “anomaliyi tespit etmek, hattı durdurmak, kök nedeni çözmek” pozisyonuna yeniden yerleştirir. Toyota, üretim hattındaki işçilerin tüm hattı durdurma yetkisini vermesinin nedeni, otomasyon ne kadar güçlü olursa olsun, sorun çıktığında durdurma yetkisine sahip bir insanın olması gerektiğini biliyor olmasıdır. İşte “robotlara akıl vermek” sloganının gerçek anlamı budur: Makinelere, insanları çağırmak için durma yeteneği kazandırmak. İnsan her zaman orada kalır ve kök nedeni çözmekle yükümlüdür.
Yazılım, bu yolu tekrarlıyor ve çok hızlı ilerliyor. GitClear’in AI destekli kod kalitesi üzerine yaptığı araştırmalar, tekrarlanan kod bloklarında artış ve kısa süreli churn kodlarında yükseliş gözlemledi: AI hızlı yazıyor, ancak yazdığı kodlar “tümüyle doğru gibi” görünüyor. Büyük miktarda kod, kimse tarafından satır satır yazılmadığında, geleneksel “geliştiricinin içsel anlayışı” temelindeki güven mekanizması çöker. Bu noktada ihtiyacınız olan, yazılım dünyasının bir Anand绳 ve üretim durdurma mekanizmasıdır:
- Testler (birim, entegrasyon, end-to-end) “yapmaya çalış” hâline gelip, geçmeyenlerin birleştirilmesi yasaklanır;
- Code review odak noktası, “yazım tarzını kontrol etmek”ten “niyeti ve sınırları kontrol etmeye” dönüşür: Bu kod tam olarak neyi çözmek istiyor, sınır durumlarını kapsıyor mu?
- Gözlenebilirlik (izleme, günlük, izleme) standart hale gelir, çünkü canlı davranışlar kodun kendisinden daha çok şey söyler;
- Gri yayın / özellik bayrağı (feature flag), AI tarafından üretilen şeyleri küçük bir kitlede test etmeye ve sorun yoksa yayını genişletmeye olanak tanır.
İkinci bölümdeki Stripe’in 1.300 PR’ine geri dönersek: yazım agent tarafından yapılır, ancak birleştirme aşaması tamamen insan incelemesine bırakılır. İşte yazılımda otomasyonun gerçek bir örneği: üretim otomatikleştirilir, onaylama ise insana bırakılır ve insana “bunu durdurma” yetkisi verilir. Üretim ucuzlaştı, kalite kontrolü pahalılaştı — bu 40 yıldır değişmeyen bir kural.
Beşinci: “Problem Tanımlama” Ücreti: Prompt’tan Daha Değerli Beceri
Doğrulama en çok altında değerlenen darboğazsa, “problem tanımlama” tamamen altında değerlenen bir beceridir. Prompt mühendisliği bir süre popüler oldu ve birçok kişi “prompt yazabilmek”in temel beceri olduğunu sanıyor. Ancak prompt sadece “soruyu ifade etme” tekniğidir. Gerçekten kıymetli olan, bundan bir adım ileriye gitmektir: problem formulation — belirsiz bir iş sorununu, net, çözülebilir ve çözülmesi değerli bir soruya bölmektir. Bu adım, AI kısa vadeli olarak yapamaz; çünkü önce sizden “sorunun ne olduğunu” öğrenmesi gerekir.
Üretim sektöründeki deneyimli ustalar bu adımdaki ağırlığı en iyi anlar. Bir mühendislik çizimi ya da üretim süreci yanlış tanımlanırsa, alt katmanlardaki işleme ve montaj ne kadar verimli olursa olsun, hatalı ürünleri büyük ölçekli üretmiş olursunuz. Yazılım da aynı: Gereksinim spesifikasyonu yanlışsa, AI size on kat hızla kimse istemeyeceği bir sürü şey üretir.
Bunu değerlendirmenin çok basit bir yolu var: “Kod yazma hızını” değil, “soruyu bölme netliğini” geliştirin. Bir organizasyonda bu, “gereksinim tanımlama” ve “doğrulama/kabul” süreçlerini resmi pozisyonlar haline getirmek anlamına gelir; geliştiricilerin bunları yan görev olarak yapmasına izin vermeyin. AI, uygulamayı ucuzlaştırdıktan sonra, bu iki pozisyonun getirisi en hızlı artanlardır.
Altıncı: Dört sektörün gerçek darboğazları nasıl görünür?
“Darboğazın kayması” kavramını dört sektöre uyguladığınızda, her sektörün darboğazı kod yazmakta değildir.
Üretim. Ana hat, başta bahsedilen CIO’dur. Akıllı üretim planlaması, kalite izlenebilirliği, enerji tüketimi optimizasyonu gibi fonksiyonlar teknik olarak zor değil; çoğu model zaten mevcut. Sıkışma noktası, MES/ERP/kalite kontrol/raporlama sistemlerinin entegrasyon ve senkronizasyonu ile üretim hattındaki terminal cihazlarda gerçek dünya doğrulamasıdır. Bu tür projelerin kodu genellikle hızlı yazılır, ancak MES/ERP sistemlerinin entegrasyonu, kod yazmaya kıyasla birkaç kat daha fazla zaman alır; hataların üretim aşamasında ortaya çıkmadan önce, kabul süreçlerini üretim hattı terminali ve entegrasyon aşamalarına yerleştirmek gerekir.
Telekom / Operatörler. Bir abonelik değişikliği ya da kurumsal özel hat açılma süreci, kanal, faturalandırma, CRM, ağ açılımı ve kurulum planlaması gibi birkaç alana geçiş yapar. AI, her alandaki geliştirme hızını artırdı, ancak çapraz alanda end-to-end entegrasyon ve tutarlılık doğrulaması, projenin ana zaman tüketicisidir. Operatörlerin bir başka benzersiz sıkışma noktası ise uyumluluk ve hesaplaşmadır. Faturalandırma hatası bir kuruş bile bir kaza sayılır; doğrulama yükü, diğer tüm sektörlerden daha ağırdır. Kurumsal özel hat açılma örneğini alalım: AI tüm alanlardaki geliştirme hızını artırsa da, end-to-end entegrasyon ve faturalandırma hesaplaşması hâlâ projenin büyük bir kısmını tüketir.
Finans. Bir kredi risk yönetimi veya para aklama önleme kuralının değişimi, bir uygulamadan diğerine, çekirdek sistemlere, risk algılama motorlarına, veri platformuna ve düzenleyici raporlamalara kadar yayılır. Burada doğrulama ağırlığı çok yüksektir, çünkü bir hata bile uyumluluk ihlali demektir. Sıkışma noktası açıklayabilirlik, denetlenebilirlik ve izlenebilirlik‘tir: AI tarafından yazılan kurallar ne kadar doğru olursa olsun, düzenleyicinin “Neden böyle karar verdiniz?” sorusunu cevaplayamazsa, hiçbir zaman canlıya alınmaz. Para aklama önleme kurallarının güncellenmesi tipik bir örnektir: AI kuralların yazımını hızlandırır, ancak modelin açıklanabilirlik denetimi ve düzenleyici raporlamalarla uyumlu hale getirilmesi, genellikle tüm döngünün büyük bir kısmını tüketir.
E-ticaret. Bir kampanya veya büyük bir satış etkinliği, ürün, işlem, pazarlama, stok ve müşteri hizmetleri arasında geçiş yapar. AI, sayfaları ve arayüzleri çok hızlı yazmayı sağlar, ancak sıkışma noktası yük testi, stok tutarlılığı, risk önleme (kumarbazlık), ve hesaplaşma‘ya kayar. Büyük satış gecesi çökenler, hızlı yazılmamış kodlar değil, test edilmemiş sınırlar olur. Büyük satış hazırlığı bir özet gibidir: AI, kampanya sayfalarını çok hızlı oluşturabilir, ancak uçtan uca yük testi ve stok tutarlılığı doğrulaması, genellikle hazırlık sürecinin büyük bir kısmını alır.
Dört sektörün ortak noktası açık: AI, “yazmayı” hızlandırır, ancak “birleştirmeyi”, “doğrulamayı” ve “uyum sağlamayı” engeller. Tasarruf edilen geliştirme kapasitesini bu üç alana yatırmak, gerçek verimlilik sağlar.
Yedi: Yanlış karar vermek ne demek: En yaygın üç uyumsuzluk
İlk: “Hızlı kod yazmak”ı “teslimatın hızlanması” olarak algılamak. Bu en yaygın yanılsamadır. Kod, teslimat zincirinin sadece bir parçasıdır; onu genişletmek zincirin tamamını hızlandırmaz, sadece darboğazın arkasında daha fazla yarı mamul birikir. Kısıt Teorisi bunu stok olarak adlandırır, yazılımda ise onaylanmamış PR’ler ve entegrasyonu tamamlanmamış branch’lerdir. Sonuç olarak geliştiriciler daha meşgul, iş birimleri daha aceleci ve çıktı değişmez — tam olarak girişteki CIO’nun durumu budur.
İkinci: Üretimi hızlarken kalite kapılarını kaldırmak. Bu, jidoka’ya aykırı tipik bir hataıdır. Bazıları “AI hem hızlı hem iyi kod yazıyor, code review’u basitleştirebilir, testleri çıkarabilir” diye düşünür. Tam tersine, üretim ne kadar hızlıysa,安灯绳 (andon cord) o kadar sıkı tutulmalıdır. Kabul kapılarını kaldırmak, hiçbirinin gözlemlediği bir üretim hattını tam hızda boşuna çalıştırmak demektir; hatalar üretim ortamına daha hızlı bir şekilde akar.
Üçüncü: Darboğaz olmayan yerlere para harcamak. Entegrasyon darboğazsa, daha fazla AI programlama lisansı alıyorsunuz; doğrulama darboğazsa, daha fazla geliştirici istihdam ediyorsunuz. Kısıt Teorisi bunu açıkça açıklamıştır: Darboğaz olmayan yerlere ek kaynak yatırımı, toplam çıktıya sıfır katkı sağlar, sadece mali tabloları daha kötü hale getirir. Doğru sıra önce darboğazı tanımlamak, sonra kaynakları darboğaza odaklamaktır.
Sekiz: Karar vericilere dair çıkarımlar
İlk Öğreti: Araç satın almadan önce bir darboğaz haritası çizin. Son üç teslimatınızda takıldığınız noktaları inceleyin: Zaman nerede harcanıyor? Kod yazamıyor musunuz, parçaları birleştiremiyor musunuz, kimse test etmiyor mu, yoksa gereksinimler net mi değil? Belirleyemiyorsanız, teknik katmanda rastgele tahminler yapıyorsunuz demektir. Darboğaz haritası, herhangi bir araç satın alma listesinden daha değerlidir; büyük şirketlerin en az yüzde 50’sinin etkisiz IT yatırımlarını önler.
İkinci Öğreti: Tasarruf ettiğiniz kapasiteyi gereksinim ve doğrulamaya yatırın. AI, geliştirme sürecini hızlandırıyor, bu da insan kaynakları serbest bırakıyor demektir. Bu kişileri resmen “gereksinim tanımlama” ve “doğrulama kabul” pozisyonlarına yerleştirin; onları daha fazla kod yazmaya devam etmeye zorlamayın. Bu iki pozisyonun getirisi, AI çağında en hızlı artan getiridir.
Üçüncü Öğreti: Yazılıma bir Andon İpini takın. Otomasyonun en doğrudan uygulaması, CI/CD sürecinize katı sınırlar koymaktır: testler geçmezse birleştirme yapılmaz, inceleme mutlaka niyeti ve sınırları kontrol eder, gri sürüm önce küçük bir kitleye salınır, gözlenebilirlik standart hale gelir. Üretim ne kadar otomatikleşirse, bu kapı o kadar sağlam olmalı. Bu, “kod ücretsiz” olmanın “kazalar ücretsiz” olmasına yol açmasını engellemektir.
Dördüncü Öğreti: İnsanları yeniden yerleştirin, onları çıkarmayın. Otomasyon aynı sonuca işaret eder: Otomasyon ne kadar derinleşirse, insanlar “karar verme, kabul etme, kök nedeni çözme” pozisyonlarına daha da yerleştirilmelidir. İnsanları tekrarlayan işlemlerden kurtarın ve doğrulama ile uyum sağlama görevlerine yeniden yönlendirin; bu, AI çağındaki organizasyon tasarımı için temel harekettir ve bu serinin sonraki bölümlerinde detaylandırılacaktır.
IX. Muhtemelen soracağınız sorular
“我们只是在局部试点 AI，有必要画出全公司的瓶颈图吗？”
甚至试点之前，也得先看清楚：你试点的这个环节，真的是瓶颈吗？如果真正的卡点在集成或验证环节，那在“写代码”这个环节试点 AI，就是在非瓶颈上砸钱——这正好踩中了第七节讲的第三种错配。先做一次小范围的瓶颈诊断，工具的钱才花得值。
“验证关卡会不会拖慢交付？”
短期会有摩擦，长期却是加速。没有验收关卡的“快”，是把缺陷推向生产环境的快，返工成本至少翻十倍。自働化经验表明：在源头解决一个缺陷的成本，只是让它流到下游再处理的零头。
“这和我们正在做的 AI 转型有什么关系？”
关系非常直接。AI 转型最常见的误区，就是假设瓶颈在“写代码 / 产能”上，然后买一堆工具去加宽这一环。先做瓶颈诊断，再决定钱花在哪。这也是我把“能力评估”和“价值场景识别”放在《AI 转型 7 步教练框架》靠前位置的原因：先看清瓶颈在哪，再谈工具。
Tersine Kontrol (Cevap verirken güzelleştirmeyin): Son kez takıldığınız teslimatta, zamanınız kod yazmaya mı harcandı, yoksa parçaları birleştirmeye, kontrol etmeye, uyum sağlamaya mı? AI araçlarınızın ürettiği kodlardan, kararlı bir şekilde üretimde çalışan ve kullanıcıların gerçekten kullandığı kaç tanesi var? CI/CD sürecinize “testler geçmezse birleştirme yapma” diye katı bir kapı koydunuz mu? Bu üç sorudan birine bile çekingen cevap veriyorsanız, daha fazla AI aracı almadan önce önce kendi darboğazınızı bulun.
Bir Sonraki Adım
Bu, “AI Çağındaki Yazılım Mühendisliği Değişimi” serisinin 15 bölümden üçüncüsü. Conway (organizasyonun mimariyi belirlemesi) ve Takım Topolojisi (organizasyonu nasıl tasarlayacağınız) konularından, darboğazın nereye kaydığına (kod neredeyse ücretsiz hale geldiğinde darboğaz nereye gitti?) geçtik. Bir sonraki bölüm (4. bölüm), daha pratik bir bakış açısı sunacak: Ana akım AI programlama araçları nasıl seçilir? Ancak sonuç muhtemelen sezgiye aykırı olacak: Seçim aslında bir organizasyon kararıdır; “kimin yazdığı kod en şık” diye değil, kendi olgunluk ve yönetim düzeyinize göre seçmelisiniz.
Seri Açıklaması: Bu seri, AI programlama araçları, organizasyon yapıları ve yazılım mühendisliği paradigmalarının en son gelişmelerini takip edecektir; örneğin 2026’da AI ajanları çağında Conway Yasası’nın yeni hali veya en yeni araç ekosisteminin olgunluk seviyesi gibi. Seriyi takip ederek sürekli güncellenen görüşleri edinin.
Bu Seri Hakkında
“AI Döneminde Yazılım Mühendisliğindeki Değişim”, telekomünikasyon, finans, imalat, e-ticaret gibi sektörlerdeki CIO’lar, CDO’lar, CTO’lar ve dijitalleşme sorumluları için yazılmış, 15 bölümden oluşan derinlemesine bir araştırma serisidir. 200’den fazla akademik makale ve endüstri raporuna dayanarak, kanıt seviyesi etiketli karar alma rehberleri sunar.
Ben eski IBM mühendisi, ICF sertifikalı koçum ve operatörler ile büyük şirketlerde AI/dijitalleşme projelerinin uygulanmasında yer aldım. Burada yazdıklarım, şirketlerin zorluklarla başa çıkarken benimle birlikte geçtiği pratik deneyimlerden kaynaklanır.
Kaynaklar (Tümü doğrulandı)
- a16z (2026). Software in the Age of Agents. The a16z Podcast. (Önceki Microsoft Windows Başkanı Steven Sinofsky’nin sözü: “The long tail got no shorter, it just got longer in a different way”; kurumsal yazılım perspektifinden TOC darboğazının yer değiştirmesi yasasını bağımsız olarak doğrular; birinci kaynak — podcast orijinal sesi. Durum notu: a16z ortağı / eski Microsoft yöneticisi, VC pozisyonu. Konuşmacılar doğrulandı: a16z Kurumsal Takımı ortağı Seema Amble, eski Microsoft Windows Başkanı Steven Sinofsky (board partner), a16z yazarı Elena Burger; yayınlandı 2026 Temmuz.)
- Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Constraint Theory (TOC)’in orijinal kaynağı; birinci kaynak; imalat fabrikası senaryosu üzerine kurulmuş bir roman.)
- Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Goldratt’in TOC’unu IT operasyonlarına tamamen aktarır; imalat → yazılım köprüsü; birinci kaynak.)
- Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = “人” li otomasyon; hata durumunda üretim durur + insan müdahalesiyle kök neden çözülür; Andon sistemi; birinci kaynak.)
- GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot, “etkinleştirilmiş dosya içi” ölçümüne göre yaklaşık %46 kodu tamamlar; birinci kaynak.)
- Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ raporu haftada 1.300+ PR, tamamen insan tarafından inceleme (birinci + ikinci kaynak)
- NVIDIA / Jensen Huang. “100% mühendislerin Cursor gibi AI programlama araçlarını kullandığı” açık ifadesi (birinci el ifade)
- GitClear (2025). AI-Assisted Code Quality Research. (AI destekli ortamda tekrarlayan kod / kısa vadeli churn artışı gözlemlendi; “doğrulama maliyetinin artması” hipotezini destekler; ikinci kaynak.)
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Teslim performansı, bireysel kodlama hızı değil; kültür, akış hızı ve geri bildirimle belirlenir; birinci kaynak.)
buymeacoffee
![[Bottleneck Shift] Kod neredeyse ücretsiz olduğunda, yazılım mühendisliğinin darboğazı nereye gitti? AI Çağı Yazılım Mühendisliği Değişimi — Yavaşça AI Öğren173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
