DevOps Pioneer Uyarıyor: AI Ajantı Kabulü, Sadece Araçlar Değil Sistem Düzeyinde Değişiklikler İstiyor

Agent tarafından üretilen kodu daha fazla düzeltmeyin, kodu üreten sistemi düzeltin.

Yazan: InfoQ

Bir geliştirici Agent’i nasıl kullanırsa kullanımsa, sorun geliştiricide değil, şirketin Agent için çalışır bir sistem hazırlamamış olmasındadır.

Birçok şirketin所谓的 AI dönüşümü, geliştiricilere Cursor, Claude Code gibi araçlar satın almak, birkaç eğitim düzenlemek ve ardından herkesin kendi başına keşfetmesini beklemekle sınırlı kalıyor. Sonuçta Agent'in performansı yetersiz olursa, sorumluluk tekrar kullanıcıya düşüyor.

Ancak DevOps terimini ortaya atan Patrick Debois, “Geliştiricilerin önemli bir zihniyet değişikliği yapması gerekiyor: Agent, beklentinize göre görevi tamamlayamadığında, ürettiği kodu değiştirmek yerine, yalnızca Prompt’u değil, tüm sistemi iyileştirmelisiniz.”

Debois'e göre, bu, yazılım mühendisliğinin belirli sistemlerden belirsiz, olasılıksal sistemlere ve iş akışlarına geçiş sırasında yaşanan bir değişimdir. Bu sadece teknolojiyi değil, geliştiricileri, takımları ve tüm organizasyonun çalışma biçimini de yeniden şekillendirecektir. Ancak bu değişim, yalnızca bir mühendis tarafından değil, yalnızca tek bir takım düzeyinde kalmadan, DevOps gibi ölçeklenebilir şekilde uygulandığında gerçek anlamda sağlanabilir.

Sorunun özü, geliştiricilerin Agent kullanıp kullanmayacağında değil, şirketin Agent etrafında ekiplerini, platformunu ve iş birliği biçimini yeniden organize edip edemeyeceğinde.

Temel noktalar şunlardır:

• Agent tarafından üretilen kodu daha fazla düzeltmeyin, kodu üreten sistemi düzeltin.
• Takımınızda hâlâ "YOLO" tarzı rastgele kodlama yapanlar varsa, hemen durdurmalısınız. Mühendislik uygulamaları, sisteminizi korumak için değil, Agent'in sürekli iyileşmesi için de kritik öneme sahiptir.
• Karanlık fabrika tamamen karanlık olmayabilir, biraz ışık korunabilir (dim factory), bu da hangi fonksiyonlar için ne kadar risk alacağınızı belirlemenizi gerektirir; tüm fonksiyonlar tamamen özerk olmak için uygun değildir.
• AI'yi uçuracak, sağlam mühendislik becerilerine sahip ve paylaşmaya ve işbirliği yapmaya istekli olan, bunları birleştiren kişi sizin aradığınız kişidir.
• Sizin koruma alanınız, şu anda skill'e, Context'e ve hatta Harness kısıtlamalarına aktardığınız iş bağlamalarını içeren birikmiş bilgileri yakalamaktır.

2009 yılında, birçok kişi bana sürekli teslim fikrinin çılgınca olduğunu söyledi.

2009 yılında endüstride genellikle aylık büyük sürüm güncellemeleri uygulanıyordu; herkes, yayın sıklığı arttıkça riskin de artacağını varsayıyordu. Geliştirme ve operasyon arasında katı bariyerler bulunuyordu, konteyner ve bulut gibi otomasyon altyapıları henüz olgunlaşmamıştı ve standartlaştırılmış pipeline araçları eksikti. Geleneksel test ve değişiklik onay mekanizmaları, yazılımın üretim ortamına çıkarılmadan önce tüm hataları gidermeyi amaçlıyordu. Sürekli teslimat ise yüksek sıklıkta, artımlı ve her zaman yayınlanabilir bir yaklaşım sunarak, yazılım dağıtımındaki risk ve süreç kontrolüne dair yaygın algıyı devrildi; bu nedenle çoğu şirket için bu fikir neredeyse masal gibi görünüyor ve çok çılgınca geliyordu.

Şu anda, Dark Factory tam olarak aynı direnişle karşılaşıyor.

Çevirmen notu: Karanlık Fabrika, insanlar yalnızca SPEC girdiğinde, AI'nın kodlama, test ve yayın işlemini kendi başına tamamladığı, insanın kodun satır satır incelenmesine gerek olmayan otonom yazılım üretim modelidir; bu, hâlâ büyük ölçüde mühendis katılımına ihtiyaç duyan geleneksel yazılım fabrikalarından farklıdır.

Farklı durumlarda aynı cümleyi tekrar tekrar duyuyorum: “Bu şey burada çalışmaz.” Ancak bu cümle aslında teknik olarak mümkün olmadığını değil, “hazır değiliz” mesajını iletmektedir. Bu şeyi yapmak istemiyor değil, ancak şu anda organizasyonun yapısı bu modeli destekleyemiyor.

Şu anda birçok kişi, Agent’ı döngüsel olarak optimize etme ve Harness kurma yöntemlerini anlatıyor; bu harika. Ancak benim söylemek istediğim, sonunda hepimiz bu teknik seviyeye ulaşacağız ve bir gün bunlar standart bir ürün haline gelecek, hatta bir ön uç laboratuvarı tarafından hizmet olarak paketlenecek. O gün teknik engeller ortadan kalkacak. Gerçek farklılaşma, organizasyonunuzun bunun etrafında işbirliği yöntemlerini nasıl yeniden yapılandırdığından kaynaklanacak.

Bu yüzden, tümümüzün karanlık fabrika yönünde ilerlediğimizi varsayıyorum. Tessl ve diğer şirketlerde gözlemlediğim şey, insanlar bu teknolojileri benimsemeye başladığında işbirliği dinamiklerinin tamamen değişmesidir. Conway Yasası'na aşinaysanız, organizasyon yapısı ve araçlar arasında karşılıklı bir şekillendirme ilişkisi olduğunu bilirsiniz—insanları nasıl düzenlerseniz, o şekilde sistemler oluşturursunuz. Ancak bugün, Agentlerinizi nasıl daha iyi hale getireceğinizi anlatmak yerine, bunun takım dinamiklerinizi, platformunuzu ve tüm organizasyonunuzu nasıl değiştirdiğini anlatmak istiyorum.

Sanırım buradaki çoğu kişi tek başına değil, bir ekip içinde çalışıyor; ekip çalışması, bir kişinin Claude Code'a tek başına yazmakla tamamen farklı bir şey.

Şu anda herkes bir ifadeyi konuşuyor: Geliştiriciler nihayetinde bir şef, bir Agent’in düzenleyicisi haline gelecek. Bu ifadeye hiçbir şey yok, gerçekten de bu yolda ilerliyoruz. Agent’larla olan ilişkileri yönetmek için giderek daha çok bir Agent yöneticisi gibi davranıyoruz.

Ancak sorun şu ki, birçok geliştiricinin özel olarak söylediğine göre: Biz ilk başladığımızda bunu yapmak için girmedik, Prompt'ları optimize etmek ve daha iyi SPEC yazmak için çok zaman harcamayı düşünmedik. Biz mühendisiz, teknikle uğraşırız; bu bize bir kimlik çatışması hissi veriyor ve sürekli kendimize soruyoruz: Bu gerçekten yapmak istediğim rol mü?

Daha sonra "Bağlam Mühendisliği" adlı bir kavram ortaya çıktı ve bu, geliştiricilere bir çıkış yolu sundu. Bu kavram, sadece Prompt çağırmanın ötesinde, Prompt'ları test etmenizi, değerlendirmenizi, dağıtmamanızı ve optimize etmenizi gerektirdiğini söylüyor, bu nedenle gerçekten bir mühendislik boyutu taşıyor. Ancak dürüst olmak gerekirse, birçok geliştirici hala Prompt ve SPEC ile sınırlı kalmanın boş olduğunu hissediyor ve kendilerini mühendis yerine "prompt yöneticisi" haline geldiğini düşünüyor.

Ancak uygulamada ilginç bir dönüşüm gözlemledim: Harness ve döngüleri tanıtmaya başladığımızda ve tüm organizasyonu daha yüksek bir otonomi seviyesine taşıdığımızda, tamamen yeni bir teknik yol açıldı. Aniden geliştiricilerin Agent için araçlar oluşturması gerekti; bu, bir grup insanı yeniden motive etti. Daha önce “Bu benim işim değil” diyen geliştiriciler anında ilgi gösterdi. “Evet, bunu yapabiliriz! Bu bilgiye sahibiz! Bu sistemi programlama yoluyla daha iyi hale getirebiliriz.” dediler. Bu yüzden ilginç bir şekilde, sürekli “soyutla, soyutla, soyutla” dediğimizde, “el becerisi” duygusu tamamen farklı bir yerde yeniden ortaya çıktı ve daha teknik mühendislik çalışmalarına yeni bir alan kazandırdı.

Sık sık sorulur: Şüpheli olan insanları nasıl ikna edersiniz? Cevabım her zaman aynı: Bu insanlar aslında hazinenizdir. Çünkü zihinlerinde büyük miktarda gizli bilgi ve yargı birikimi vardır; bunları Agent’e aktarmalısınız. Onlara şunu diyebilirsiniz: “Tüm bilginizi ve eleştirilerinizi ortaya koyun.” Bu, Agent ve Harness’in daha iyi olmasına yardımcı olur. Günlük olarak “Bu şeyin ürettiği kod kalitesi çok kötü” diye şikayet edenleri bulursanız, onları yakıt olarak kullanın; bu öfkeyi ve şüpheleri, sistemi geliştirmek için bir güç haline getirin.

Şimdi şirketin geliştiricilerine bir öneri sunayım: Agent tarafından üretilen kodu düzeltmek yerine, bu kodu üreten sistemi düzeltin. Birkaç yıl önce kimse şöyle demişti: “O şeyi yapma, o şeyi üreten şeyi yap.” Şimdi tam olarak bu soyutlama seviyesindeyiz; Context, Harness ve döngüler aracılığıyla “şeyleri üreten şeyleri” oluşturuyoruz. Hâlâ “İnsanın Döngüde Olması”, otomatik tamamlama ve Prompt çağırma aşamasında kalan birçok kişi, kendi düşünme düzeyini sistem düşüncesine yükseltmeyi düşünmelidir.

Yapmamız gereken şey, insan müdahalesini en aza indirmek için iyi mühendislik uygulamalarını kullanmaktır. Başlangıçta herkes “vibe coding”in harika olduğunu düşünüyordu, bir Prompt atıp bir sonuç alıp devam etmek. Ancak artık giderek daha net bir şekilde anlıyoruz ki, Agentlere sadece Prompt ile talimat vermiyoruz; aslında şunu söylüyoruz: Testlerle birlikte kod yaz, belgeleri güncelle, kod kurallarına uygula. Daha önce iyi bir mühendise söylediklerimizi şimdi Agentlere tamamen aynen söylüyoruz. Takımınızda hâlâ “YOLO (önce çalıştırıp sonra bak)” tarzı bir “vibe coding” yöntemi kullanan varsa, hemen durdurmalısınız. Mühendislik uygulamaları, sadece sisteminizi korumak için değil, Agent’in kendisinin sürekli iyileşmesi için de kritik öneme sahiptir.

Önde gelen bazı takımlarda, hâlâ planlama ve gözden geçirme toplantıları yapıyorlar ancak tartışılan içerik tamamen değişti. Gözden geçirme toplantılarında artık “kodda ne sorun var?” yerine “sistemde ne sorun var?” sorusu soruluyor.

Plan toplantısında ilginç bir bölünme de gördüm. Çok net tanımlanmış ve yeterince belirli olan görevler doğrudan Agent'e verilebiliyor, çünkü Harness giderek daha iyi hale geliyor ve bu net görevleri kolayca işleyebiliyor. Sınırı bulanık, görüşülmesi gereken konular ise hâlâ insana bırakılıyor. Bu nedenle plan toplantısında doğal bir iş bölümü ortaya çıktı: Bu kartlar doğrudan Agent akışına giriyor, bu kartları biz tartışıyoruz.

Geliştiriciler genellikle bir öğrenme döngüsünden geçer: önce Prompt öğrenir, ardından daha iyi bir SPEC, ardından Context, Harness ve döngü; tüm sektör bu döngüde ilerler. Ancak takım lideri yapabileceği şey, bu süreci ritimlendirmek ve sınırlar koymaktır; örneğin, “Prompt’u daha fazla ayarlamayın, Context’i yeniden kullanılabilir hale getirin.” “Tamam, bu adım tamamlandı, bir sonraki adıma geçelim.” Takım liderinin değeri, tam olarak bu ritmi belirlemektedir; sadece “Kendiniz keşfedin” demek yeterli değildir.

Bir diğer etki: Takımınızın verimliliği ani bir artış göstermeye başladığında, GTM (Go to Market) gibi alt akıştaki kişiler hatta kullanıcılar bile bu hızla yetişemeyebilir. Bu nedenle onlara yardımcı olmak için otomasyon kullanmalısınız; çerçeveniz kodlama aşamasında kalmamalı, onların tarafına kadar uzanmalıdır. Aynı mantık, üst akıştaki talep girdileri için de geçerlidir; eğer talepler yeterince hızlı gelmezse takım tıkanır ve bu aşamalar da yeni iş akışına dahil edilmelidir.

Şu anda piyasada Token harcaması gibi bir sürü endikatör var. Ancak artık üretkenliği gerçekten ölçen iki endikatöre daha çok inanmaya başladım. İlk: Bir Agent’in bir şeyi doğru yapması için kaç kez insan müdahalesine ihtiyacınız olduğunu sayın. Bu sayı sürekli azalmalıdır. Harness’iniz ne kadar iyiysa, bağlamınız ne kadar iyiysa, rehberleriniz ne kadar netse, bu sayı o kadar düşük olur. İkinci endikatör, bireysel çalışmadan paylaşılan bir sisteme geçtiğinizde ortaya çıkan çarpıcı bir etkidir. Bir şeyi bir yerde düzelttiğinizde, herkes bundan faydalanır. Bu, bir kişinin verimliliğinin on katına çıkması demek değil; Agent sisteminde yapılan bir optimizasyonun tüm kullanıcılar üzerinde çarpıcı bir etki yaratmasıdır.

Bir depoda ya da küçük bir ekip içinde başlayabilir, Context'i paylaşarak Harness'i birlikte geliştirebilirsiniz. Ancak gerçekten yapmak istediğiniz şey, bu etkiyi tüm organizasyona yaymaktır. Bu noktada, platform ekibinden bahsetmek zorundayız.

Platform ekibi tipik bir paylaşım tabanlı organizasyondur ve şu anda altyapı, bulut hizmetleri, MCP ağ geçidi gibi şeyler üzerinde çalışıyorlar; Agent konusuna fazla odaklanmıyorlar. Ancak yeni bir dizi şey ortaya çıkıyor ve bunları devralmaları gerekiyor: beceri kayıt merkezi (herkes kendi köşesinde aynı becerileri icat etmesin), Context değerlendirme sistemi (bu Context gerçekten işe yarıyor mu? Ölçülebilir mi?), özellikle coding agent'lar için güvenlik ve kimlik yönetimi (Agent kimin kimliğiyle kod gönderiyor? Yetki sınırları nerede?). Bu nedenle platform ekibine, onları bu yeni merkezi rolüne taşıyacak şekilde destek veren biri gerekiyor.

Bu oldukça zor bir iş; bunu ilerletebilmek için net bir sorumlu gerekir. Ancak bu kim olmalı? Platform ekibi mi? Geliştirici deneyimi ekibi mi? İlki genellikle geliştirme düzeyindeki şeylere dokunmaz, ikincisi ise altyapıyla pek ilgilenmez; bu nedenle bir sentez gereklidir, ancak bu sentez otomatik olarak gerçekleşmez. Bu merkezi çalışmayı ilerletecek bir sorumlu olduğundan emin olmalısınız; aksi halde ekibiniz sadece kendi alanlarında dolaşır ve “Paved Road (kaplı yol)” ortaya çıkmaz.

Neden her takım kendi kimlik doğrulama sistemi entegrasyonunu kendi başına icat ediyor? Bu, paylaşılan bir bileşendir ve kayıt merkezine dahil edilmelidir. Neden herkes kendi Harness’ini kuruyor? Eğer hekimiz aynı linter’i ve aynı güvenlik tarama araçlarını kullanırsak, bu tekrar kullanılabilir bir bileşen olur. Bence bu, eski zamanlardaki bulut altyapısı yolu gibi, zamanla platform kayıt merkezine doğru birleşecektir.

Ancak sorun, herkesin bu merkezi depoya rastgele şeyler ekleyebilmesi durumunda hızla çaprasa hale gelmesidir. Örneğin, bir beceri yüklendiğinde, kim onu bakım altına alıyor? Başka biri benzer bir beceri çatallıyor, o zaman hangisini seçmeliyim? Bu nedenle, her bir alanın açıkça birine ait olması gerekir; bu kişi, öğenin test edilebilir ve modüler olduğundan emin olmalı ve diğerleri bu temel üzerinde Context veya Harness içindeki güvenlik tarama bölümünü genişletebilmelidir. Bu işlemi organizasyon içinde rastgele geçirmek yerine merkezi bir şekilde yapmalısınız.

Anlaşmak zordur. Bu, tabs ve boşluklar arasındaki çatışma kadar ünlü değildir, ancak bazen aynı hissi verir. İki geliştirme ekibini çalışma yöntemleri konusunda uzlaştırmak için büyük ölçüde iletişim ve aracılık gerekir. Sonuçta, sadece bir asfalt yol değil, üç veya dört yol olur ve bunlardan birini seçebilirler. Eğer kendi sistemlerini kurmak isterlerse, bunu yapabilirler, ancak bu kendi bütçelerinden yapılır. Merkezi olarak bakılan yol, "kolay yol"dur ve insanları bu yola çekmek için kullanılır.

Herkes bu paylaşılan yetenekleri körükçe kullanıyorsa, maliyetleri göstermelisiniz. Harcamaları görselleştirdiğinizde, doğal olarak iyileştirmek isteyeceklerdir. Bu, platform ekibinin sorumluluğudur: ne kadar harcandı? Ne kadar fayda sağlandı? Agent yinelemelerini azaltabiliyorsam, bu bir iyileştirmedir. Ancak bu metriği göremiyorsam ve yalnızca sonucu görüyorsam, hiçbir şey yapamam; görselleştirme, tüm iyileştirmelerin temelidir.

Bu nedenle temel argümanım şudur: Tek başına çalışan geliştiricilerden, takım düzeyinde paylaşılan bağlam ve paylaşılan bileşenlere geçmeli, nihayetinde tüm organizasyon içindeki “çok oyunculu oyun sistemi”ne ulaşmalıyız. Burada çarpıcı etki patlar, çünkü bir döngüye sahipsiniz ve iyileştirmeler aynı anda birçok yöne yayılır.

Daha üst seviyede, VP Mühendislik Bölümü bu konuyu nasıl düşünüyor? Kurumunuzda neler olacağını tahmin edebiliyorum: bir hackerthon veya öğle yemeği paylaşımı, başarılı vaka çalışmaları paylaşımı, ortak bir Slack kanalı oluşturulması, bir şampiyonlar programı başlatılması. Bunlar tüm dönüşüm süreçlerinde kullanılan genel yöntemler. Agile dönüşümü bunu yaptı, DevOps da bunu yaptı, hiçbir şey yeni değil.

Öte yandan, "lisans vermek, eğitim vermek, herkesin serbestçe hareket etmesine izin vermek ve binlerce çiçeğin açmasını sağlamak" stratejisinin asla başarılı olmadığını biliyoruz. Bin çiçek sonucu genellikle bin çalı olur; binlerce çiçek açar ama hiçbiri meyve vermez. Bu nedenle, organizasyon tarafında ekip liderlerine ve platform ekiplerine bu işi yapma yetkisi verilmesini savunuyorum. Bu, tek bir süper birey tarafından yapılamaz; bunu ilerletmek için resmen yetki verilmiş biri olmalıdır.

İş aramak da zor bir iştir. Şu anki pozisyon başlıkları tamamen karışık: AI ürün mühendisi, forward deployed mühendis, agentic mühendis, AI mühendisi... Bu terimlerin aslında hiçbir gerçek anlamı yok. Tüm endüstri henüz olgunlaşmadığı için, unvanla birinin olgunluğunu ölçemezsiniz. Ancak iş ilanı verirken bu terimler, ilgili adayları çekmek için bazı sinyaller verir; ancak bu, adayın gerçekten o becerilere sahip olduğu anlamına gelmez. Daha çılgın hikâyeler de duydum; bazı adaylar mülakat sırasında kulaklarına AI ile gerçek zamanlı cevaplar gönderiyor, mülakatçı bir soru sorunca AirPods'ten AI'nın önerileri geliyor.

Bu yüzden giderek daha fazla şirketin bu tür bir mülakat yöntemini benimsediğini duyuyorum. İlk adım, adaylara bir alıştırma verip, AI’yi tamamen kullanmalarını istemek. AI onlara yardımcı olabiliyorsa, bu tam olarak AI’yi etkili bir şekilde nasıl kullandıklarını gösterir. İkinci aşamada, kendi çözümlerini incelemelerini ve “Bu çözümü neden seçtiniz? Bunun doğru olduğunu nasıl doğruladınız?” sorularını yanıtlamalarını isteyin; burada test yeteneğini ve mühendislik karar verme becerisini ölçüyorsunuz. İlk kısım AI kullanım becerisini, ikinci kısım mühendislik temelini test eder. Üçüncü olarak, nasıl iş birliği yaptıklarını, paylaşmaya açık olup olmadıklarını, açık tip mi yoksa bireysel çalışan tip mi olduklarını da gözlemleyin. Bazıları teknik açıdan çok güçlü olabilir ama her şeyi kendi elinde tutmak ister; bu tür kişiler Agent çağında tam bir darboğaz haline gelebilir.

AI'yi uç seviyede kullanabilen, sağlam mühendislik becerilerine sahip ve paylaşmaya ve işbirliği yapmaya istekli olan bu üç özelliği birleştiren kişi, aradığınız kişidir. ML veya AI dersi almış olan kişi değil, hiçbir kod çözme uzmanı değil, bu üç özelliğin bir karışımıdır. Üç özelliği de tamamen sahip olan birini bulamayabilirsiniz, bu sorun değil; örneğin bir aday bir alanda çok güçlü olabilir ama diğer bir alanda rehberliğe ihtiyaç duyabilir. Aynı zamanda bu becerileri bir araya getirip "başlangıç seviyesi" veya "ileri seviye" etiketleriyle karıştırmayın; bunlar farklı beceri boyutlarıdır ve bir kişi AI kullanım becerisi açısından "ileri seviye" olabilirken işbirliği isteği açısından "başlangıç seviyesi" olabilir.

Mühendislik Departmanı Yöneticisi, üst düzey raporlama yapmak zorunda. Bu kadar lisans aldık, yatırım getirisini nasıl kanıtlayacağız? Teslimat hızlandı mı? Belki söz verildi, ancak kanıtlamak zor. Kalite iyileşti mi? Aynı şekilde kanıtlamak zor. Ancak daha önce bahsettiğim iki göstergeye dönersek, müdahale sayısında ne kadar azalma olduğunu, ne kadar iyileştirme sağlandığını ve yeniden kullanım oranında ne kadar artış olduğunu gösterebilirsiniz. Bu, “Agent varken ve yokken kodlama verimliliğini” karşılaştırmaktan çok daha kolay ve ikna edicidir.

Bu nedenle, biri Agent'ın çok para harcadığını şikayet edip limit koymayı önerdiğinde, tepkiniz "tüm harcamaları keselim" olmamalı, bunun yerine "harcamaları nasıl optimize edebiliriz" olmalıdır. En basit çözüm, doğru modeli seçmektir; tüm görevler en güçlü modele ihtiyaç duymaz, bazı görevler için daha ucuz modeller yeterlidir. Geliştiricilere hangi senaryoda hangi modelin kullanılacağını öğretin, daha da ileri giderek onlara daha iyi Context ve Harness sağlayın; bu, Agent'ın yanlış yollara sapmasını önler ve maliyetleri daha da düşürür.

Takım boyutu konusunda bir başka nokta da var. Tüm işleri tek bir çok yönlü kişi yaparsa, bu en son hedeftir. Ancak dikkatli bir şekilde hesaplayın: Bu kişi genellikle bir ürün yöneticisi veya tasarımcı gibi tamamlayıcı becerilere ihtiyaç duyar. Ardından, birisi izindeyse diye yedek kişilere de ihtiyacınız olur; bu da tekrar üç kişiye döner. Daha sonra üretim ve iş taleplerini izleyen biri de gerekebilir; gerçekten çok verimliyseniz, bu görevleri aynı kişilerin yan görev olarak üstlenmesi mümkündür. Ancak bir hata düzeltmeye başladığınızda, özellik geliştirme hızı düşer. Son olarak yeni üyeler de vardır; onlara “iyi” ne demekse onu göstermek için yol hazırlamanız gerekir. Bu nedenle, organizasyon içinde her takımı gerçekten iki veya bir kişi haline getirmenin mümkün olmadığını hâlâ düşünüyorum.

Son olarak, karanlık fabrika tamamen karanlık olmayabilir; biraz ışık kalabilir (dim factory), bu da hangi fonksiyonlar için ne kadar risk taşıyacağınızı belirlemenizi gerektirir; tüm fonksiyonlar tamamen özerk olmaya uygun değildir. Kaynak izleme gibi denetimlere daha fazla yatırım yapabilirsiniz: Kim kodu değiştirdi? İnsan mı, yoksa Agent mi? Kodun gerçekten işe yarayıp yaramadığını kontrol etmek için doğrulayıcılar ekleyin ve otomatik süreçler başarısız olduğunda senaryo bilinci için yatırım yapın. Tamamen mikro yöneticilikten (her satır kod insan tarafından incelenmeli) tamamen özerk onaylamaya (Agent çıktısının doğru olduğu varsayımı) kadar bir spektrum var. Yapmanız gereken, farklı risk seviyelerine göre farklı türdeki değişiklikler için farklı otomasyon düzeyleri seçmektir.

Benim düşünceme göre, sizin koruma duvarınız, şu anda skill, Context ve hatta Harness kısıtlamalarına aktardığınız iş bağlamını içeren derinleşmiş bilgileri yakalamaktır. Bu, bana göre sürekli teslimi sürekli öğrenmeye dönüştürüyor. Kendinize sorun: Yeni bir şeyi sisteme ne kadar hızlı ekleyebilir ve eski bir şeyi ne kadar hızlı çıkarabiliriz? Bu, size ait tepki hızınızdır. Eğer bu beceriyi sürekli geliştirebilirseniz, sorun artık “tüm sistemi daha güvenilir hale getirmeliyim” değil, “sistemin giderek daha fazla kısmını değiştirirken, güvenilirliğini koruyabilir miyim?” haline gelir.

Eğer sadece bir cümle götürüyorsanız, o cümle şu olmalıdır: Kazanan, tek başına hareket eden süper oyuncu değil, çok katmanlı şekilde organizasyonu nasıl geliştireceğini bilenlerdir.