Jeremy Freeman, Allstacks’in Kurucu Ortağı ve CTO’su – Röportaj Serisi

Jeremy Freeman, Allstacks’in Kurucu Ortağı ve CTO’su, bir yazılım mühendisi, teknoloji mimarı ve girişimcidir. Kariyeri, yazılım geliştirme, donanım mühendisliği, makine öğrenimi ve ürün yeniliği alanlarını içermektedir. Allstacks’i 2017’de kurduğu günden beri, şirketin çekirdek platformunun mimari ve geliştirilmesine liderlik etmiş ve yazılım teslimat yönetimini öngörülü analiz ve AI destekli tahminleme yoluyla dönüştürmeye yardımcı olmuştur. Allstacks’ten önce, Freeman, Ravioli Labs ve CertiRx’de liderlik rollerinde bulunmuş ve yazılım mühendisliği, araştırma, karşıt sahtecilik teknolojileri ve ürün geliştirme konularında çalışmıştır. Kariyerinin erken döneminde, startup’lar, büyük şirketler ve akademide deneyim kazanmış ve Wake Technical Community College’de web geliştirme dersleri vermiştir. Teknik arka planı, gömülü sistemler, donanım tasarımı, büyük ölçekli yazılım platformları, makine öğrenimi ve mühendislik liderliğini içermektedir. Bu, veri odaklı ürünler oluştururken şirketlere benzersiz bir bakış açısı sağlamaktadır.

Allstacks, bir yazılım mühendisliği zekası ve değer akışı yönetim platformudur. Şirketler, yazılım geliştirme sürecinin öngörülebilirliğini ve verimliliğini artırmasına yardımcı olur. Platform, yazılım geliştirme yaşam döngüsü boyunca kullanılan araçlardan veri entegre eder ve ardından AI ve makine öğrenimi uygulayarak riskleri tanımlar, teslimat sonuçlarını tahminler ve eyleme geçirilebilir içgörüler sağlar. Mühendislik ve ürün liderlerine proje sağlığı, takım performansı ve geliştirme eğilimlerine ilişkin görünürlük sağlayarak, şirketlerin daha bilinçli kararlar almasına, teslimat belirsizliğini azaltmasına ve mühendislik çabalarını iş hedefleriyle daha iyi hizalamasına olanak tanır. Teknolojisi, şirketlerin, gerçek zamanlı operasyonel verilere dayanarak yazılım teslimat performansını ve stratejik yürütmeğini iyileştirmek için sezgisel planlamadan öteye geçmelerine yardımcı olmak üzere tasarlanmıştır.

Sizin gibi benzersiz bir yolculukınız var, makine öğrenimini yazılım geliştirme verilerine uygulayan araştırma ve mühendislik ekiplerini yönetmekten Allstacks’i 2017’de kurmaya kadar. Sizinle konuşurken, şirket kurmanıza yol açan belirli boşlukları veya tekrarlanan sorunları gözlemlediniz?

Allstacks’i başlattığımızda, müşteri keşfi yapmak için çok zaman harcadık ve ortaya çıkan model tutarlıydı: şirket şirket, büyük miktarda veriye sahip olmasına rağmen ne olduğu hakkında hiçbir fikri yoktu. Yazılım teslimatı, odadaki en akıllı insanlara rağmen öngörülemezdi. Bu sorun çözülmemişti.

Hemen anlaşılacağı gibi, bu bir raporlama problemi veya entegrasyon problemi değildi. Bir ilişki problemiydi. Bir şeyin risk altında olup olmadığını bilmemiz için, bir iş öğesinin bir dal ile nasıl bağlantılı olduğunu, dalın bir PR ile nasıl bağlantılı olduğunu, PR’nin bir sprint hedefi ile nasıl bağlantılı olduğunu ve sprint hedefinin bir iş girişimi ile nasıl bağlantılı olduğunu bilmemiz gerekiyordu. Bu grafik, standart araç zincirinde varsayılan olarak mevcut değildir. Bunu oluşturmanız gerekir ve iyi oluşturmak temel olarak bir çıkarım problemidir, bu da ML arka planının doğrudan faydalı olacağı yerdir.

Başlangıçtan beri amacımız, bireysel bir geliştiricinin özellik X üzerinde daha hızlı olmasını sağlamak değildi. Tüm organizasyonu daha iyi hale getirmekti. Mühendislik çabalarını iş sonuçlarına nasıl hizalayabilirsiniz? Mühendislik, iş için gerçekten hizmet etmesi yerine yalnızca yanında var olmak yerine nasıl iş için gerçekten hizmet edebilir? Bu soruları cevaplamak için veri ilişkileri hakkında daha iyi bir anlayışa ihtiyacınız var. Bu, neredeyse yaptığımız her ürün kararını yönlendirdi.

Allstacks, tüm yazılım geliştirme yaşam döngüsü boyunca verileri analiz ediyor. Teslimat riskini erken tespit etmek için en öngörülü sinyaller veya kalıplar nelerdir?

İyi ve kötüyi öngören tek bir metric seti olduğuna inanmıyorum, ancak farklı aşamalar ve organizasyon türleri için kalıplar var. Daha faydalı bulduğum şey, mühendislik organizasyonlarının geliştirme mevsimlerini geçirdiğini tanımaktır. Bu ay, veritabanı performansı olabilir. Bir sonraki ay, takım içi iletişim olabilir. Sonra “Neden hiçbir PR’yi kapayamayız?” olur. Sonra gözlemlenebilirlik olur. Bir mühendislik lideri olarak, tanısal, izleme ve sadece gürültü olan birçok sinyal içinde yüzüyorsunuz.

Yardımcı olan şey, gördüğünüz problemle başlamaktır, geliştirmek istediğiniz metrikle değil. “Neden geçen yıldan daha az teslim ediyoruz” diye soruyorsanız, bu doğru başlangıç noktasıdır. Oradan, üç tür metriğe ihtiyacınız var: ilk olarak, problemün gerçek olup olmadığını nasıl bileceksiniz (belki geliştirici başına PR sayısı); ikinci olarak, hangi değişiklikleri yapıyorsunuz ve bunları nasıl izliyorsunuz (örneğin, AI PR inceleyicisi benim müdahalem); ve üçüncü olarak, bu problem iş için ne kadar önemlidir. İntuitif olarak doğru olabilirsiniz, ancak gerçek hikaye, QA’nın artık üç kat daha uzun sürmesi olabilir. Doğru şeyi çözüp çözmeyeceğinizi bilmemiz için bu üç merceğe ihtiyacınız var.

Sağlık, enerji ve teknoloji gibi sektörlerde çalıştınız. Bu sektörler arasında yazılım teslimatı zorlukları nasıl farklılık gösteriyor ve bu, Allstacks platformunu nasıl şekillendirdi?

Saf teknoloji sektörleri dışındaki sektörlerdeki deneyimlerimi gerçekten değerli buluyorum. SaaS şirketlerinde, yazılımın kendisi hedef olarak kolayca kaybolabilir. Yazılımı doğrudan satmadığınız bir iş olduğunda, rolünüz çok daha net hale gelir: teknoloji, iş için destek olmak içindir. Sık sık şaka yaparım, eğer iş, bana danışmadan her şeyi aynı hızda yapabilseydi, bu seçeneği gözünü kırpmadan seçerdi.

Bu bakış açısı aslında faydalıdır. Endüstrinin ne yaptığını bağlamında yerleştirir ve birçok teknoloji tartışmasını yerine koyar. İş, Python veya Go kullanıp kullanmadığınıza aldırmaz. Yeniden yazma üzerinde döngüler harcamak muhtemelen gerçek getiri değildir.

Her sektörde tutarlı kalan şey, parçalanma sorunudur. Sektör ne olursa olsun, her mühendislik organizasyonu, sınırlı bağlantılı dokularla birlikte bir düzine araç boyunca dağılmış verilere sahiptir. Ayrıntılar değişir: düzenlenmiş endüstriler, daha uzun planlama döngüleri ve gereksinimlerde belirsizliğe karşı daha düşük toleransa sahiptir, çünkü yanlış şeyi oluşturmanın maliyeti daha yüksektir. Yüksek hızlı teknoloji atölyeleri, gizli borcu daha hızlı biriktirir. Ancak temel başarısızlık modu aynıdır. Ekipler, neyin gönderildiğini söyleyebilir. Neden kaydırdığını, ne mal olduğunu veya problem ortaya çıkmadan önce risk nerede göründüğünü izleyemezler. Bu, platformun nasıl inşa edildiğini şekillendirdi.

Yazılım geliştirme yaşam döngüsünü hızlandıran AI narrative’i artıyor. Gereksinimler, planlama ve spec hazırlığı neden gerçek tıkanma noktaları haline geliyor?

Bunu her gün görüyoruz. İyi bir ajan ve sağlam bir kılıf ile, fikirlerden, bazen doğrudan bir müşterinin ağzından, üretime literal saatlerde geçebilirsiniz.

Bu değişimin önemli olmasının bir kısmı, geri bildirim döngüsündeki değişikliktir. Pilotlu araçlar gibi araçlarla, insan her öneride döngüdedir. AI bir tamamlama önerir; kabul edersiniz veya reddedersiniz hemen. Yanlış olduğunda, hızlı bir şekilde yakalarsınız. Kötü bir önerinin patlama yarıçapı bir kod satırından ibarettir. Ajanslı kodlama farklı çalışır: ajanınıza bir hedef verirsiniz, işin parçalarını ayırır, çok adımlı bir planı yürütür ve çalışan bir modül teslim eder. İnsan, çıktıyı incelemektedir, her adımda değil. Spek yanlış olduğunda, ajan tüm uygulamayı yanlış speke göre oluşturur ve incelemekte olduğunuzda fark edersiniz.

Bu, saf üstünlük gibi görünüyor, ancak önceki gecikme zamanının aslında ne yaptığını tanıyana kadar. Gecikme, gerçek bir amacı hizmet etti. Akıllı insanların birden fazla tur incelediği, planladığı, test ettiği ve daha iyi bir sistem üretmek için fikirlerini işlediği zamanlar.

Şimdiki cazibe, tüm bunları atlayıp hissettirmektir. Ancak ajanlar ve kılıflar henüz tüm SDLC için hazır değil. Hız gerçek. Kalite kapısı, daha yavaş adımlar boyunca meydana gelen eski şeyin yerini almadı. Ajanslı kodlama, ajanın tüm uygulamayı yanlış speke göre oluşturduğu ve yalnızca inceleme sırasında fark edildiği bir boşluk bırakır.

Çok sayıda organizasyon hala eski metriklere dayanarak verimliliği ölçüyor. Liderler, AI destekli bir geliştirme ortamında verimlilik hakkında temel olarak ne yanlış yapıyor?

İnsanlar bu konuda önemli ölçüde olgunlaştı, Allstacks’i başlattığımızdan beri. Ölçüm, gerçekten önemli olan şeylere doğru kaydı ve çerçeveler daha sofistike hale geldi. AI her şeyi alt üst etti.

Geleneksel yazılım geliştirme, bir geliştiricinin kodu, işin gereksinimlerini ve temel teknolojiyi karşılayacak şekilde ne kadar hızlı yazabileceği ile temel olarak sınırlıydı. Bu maliyet, sıfıra yaklaşıyor. Yaklaşmakta olduğumuz şey, bireysel bir geliştiricinin bir ajan yöneticisi olmaya daha yakındır. Bu model, geliştirici saatleri veya üretilen tokenlere dayalı olmak yerine, başka bir şeye dayanan tamamen farklı bir verimlilik ölçüm yaklaşımını gerektirir.

Mevcut metriklere ilişkin tehlike, gerçekten neler olduğunu takım düzeyinde gizlemesidir. AI araçları olan senior mühendisler, avantajlarını biriktiriyorlar: kod tabanı bağlamına ve ajan çıkışını yönlendirmek ve hatalarını yakalamak için yargıya sahipler. Erken kariyerli mühendisler, aynı kod hacmini üretirler, ancak çıktının tam olarak değerlendiremedikleri çıktısını denetlemek için daha fazla zaman harcarlar. Toplam hız görünüşte iyidir, belki sogar iyileşmiştir. İki grup arasındaki fark, standart bir panoda nowhere’da görünmez. Doğru soru, “Ne kadar hızlı gidiyoruz?” değil, “Ne kadarını ilk seferde doğru gönderdik?”

Henüz endüstri çapında bir ölçüm modeli üzerinde uzlaşıya varamadık, ancak çıktı kalitesi ve yeniden çalışma oranını, yalnızca üretim hızı ve benimsemeyi izleyen ekipler, bunu çözmek için başkalarının önüne geçeceklerdir.

Platformunuz, proje yönetimi sistemleri ve kod depoları gibi araçlardan verileri birleştirir. Bu parçalanmış veri kaynaklarını birleştirmek ne kadar önemlidir ve şirketler bunu yapmazsa ne olur?

Allstacks, bu alanda başarılı oldu, çünkü bağlam grafikleri inşa etmeye, bu terimden önce başladık. Müşterilerin sorduğu soruları cevaplamak için tüm verilerin birbirine bağlanmasının gerekli olduğunu erken fark ettik.

Bu bağlantı yoksa, mühendislik verilerinize çalışan AI, resmin sadece bir kısmını görebilir. Proje yönetim sisteminizi analiz edebilir. Kod deposunu analiz edebilir. Ancak bir teslimat gecikmesini, üç araçtaki bir engellenmiş bağımlılığa kadar izleyemez, çünkü sinyaller arasındaki ilişki veri katmanında mevcut değildir. En iyi durumda浅 analiz, en kötü durumda ise yanlış, kendinden emin öneriler alırsınız. Model kalitesi bu sorunu çözmez. Mevcut en yetenekli modeli ham API entegrasyonlarının üzerine koyabilirsiniz ve yine de gerçek sorun nedeni, verilerin sinyaller arasındaki ilişkiyi kodlamaması nedeniyle kaçıracaksınız. Çöp inside, çöp outside, modelin ne kadar akıllı olduğuna bakılmaksızın.

Bu bağlantı, temeldir. Bu, ilk olarak benzeri görülmemiş yeteneklere sahip olmamızı sağlayan şeydir.

AI ajanları, geliştirme iş akışlarına daha fazla entegre olurken, iyi hazırlanmış bir mühendislik organizasyonu, hazırlıksız bir organizasyondan nasıl farklılık gösterir?

Aslında, bir sınıf yaz stajyerini getirmek için güçlü otomatik test süitleri, sağlam belgeler, olgun bir CI/CD pipeline’ı ve ekibe güvenilemeyen bir geliştirici eklediğinizde koyduğunuz gibi korunanlarla aynı değil.

İnsanlar, ajan kurallarınızı, AGENTLERİNİZİ.md dosyalarınızı düzenli olarak gözden geçirmeye gelince, önemini küçümsedikleri bir şey var. İlk geçişte iyi bir iş çıkarabilirsiniz, ancak yeni bir şekilde gönderme ritmine girmek ve ajan çıktısını denetlemek için öğretilebilecek çok şey olduğunu unutmak kolaydır. Bir ajanın, her taahhütten önce testleri çalıştırmasını öğretmek, insan hatırlatma gerektirmez.

Bir mühendislik liderine sormak istediğim bir tanılama sorusu: Son sprintte ajanlarınız neler üretti, bu çıktıların hangisi olduğu kabul edildi, hangisi revize edildi ve revizyon çabası nerede yoğunlaştı? Bunu cevaplayabilirseniz, geliştirmek için enstrümantasyona sahipsiniz. Cevaplayamazsanız, hissinizle uçuyorsunuz.

Mühendislik çalışmalarını iş sonuçlarına hizalamak önemlidir. Şirketler, bu boşluğu pratik ve ölçülebilir bir şekilde nasıl köprüleyebilir?

İki ana başarısızlık modu gördüm. İlk olanı, şirketlerin mühendislik ekiplerini ürünlerle eşleştirmemesidir. Çok fazla takım yapısı, miras ve uzun süredir yerleşik durumda. Bir takım, üç farklı ürünün bir parçasına sahip olabilir, diğer takım ise dört ürünün tamamına sahip olabilir. Mühendislik yatırımı, büyük ölçüde, personele bağlıdır ve ekipler ürünlerle hizalanmadığında, iş beklentilerinin gerçeklikten nasıl farklılaştığını görmek çok zor olur.

İkinci başarısızlık modu, yazılım oluşturma ve bakımına giden tüm işleri hesaba katmamaktır. İş görünümez mühendislik işi kategorisi vardır. Favori örneğim, paketlerin güncellenmesi. Non-teknik iş liderleri, değerini veya neden devam eden ve öngörülemez olduğunu anlamak için mücadele ediyorlar. Ancak yatırım kategorilerini anlarlar. “Kritik güvenlik güncellemeleri” olarak çerçevelendirmek ve ortalama olarak ne kadar kapasite tükettiklerini göstermek, onlarla çalışabileceğiniz bir dilde konuşuyorsunuz.

Bir satış lideri, bir npm paket güncellemesi ile bir özelliği kapatmak arasında seçim yapmak zorunda kaldığında, özellik her zaman kazanır. Ancak “SOC uyumluluğundan çıkıyoruz veya bu özelliği gönderiyoruz” olarak çerçevelendirdiğinizde, gerçekten değerlendirebilecekleri iki ticaret kaptırıyorsunuz. Bu yeniden çerçeveleme, tüm oyun. Müşteriler, R&D sermaye raporlama süresini, bu işleri otomatikleştirmek yerine manuel olarak yaparak iki katından fazla azalttılar. Mekanizma, aynıdır, ister sermaye raporlama, ister personel haklı kılma, ister AI ROI kanıtı olsun: bağlantılı veriler, ilişkili elektronik tabloları değiştirir.

Eldeki mühendislik ve web geliştirme öğretimi geçmişinizle, AI’nin daha fazla kodlama işini üstlendiği medida geliştiricilerin rolünün nasıl evrildiğini görüyorsunuz?

Dürüst olmak gerekirse, biraz endişeliyim, ancak akıllı insanların bunu çözeceğine güveniyorum.

Endişelerim gerçek. Yeni mezunlar, kodlama ajanları olmadan bir dünyada kodlamayan bir dünyada işgücü piyasasına girecekler. Eğitim, bu hızda ilerledi mi? Araçlar hızla ilerliyor; yüksek öğretim her zaman aynı hızda ilerlemiyor. İzlediğim diğer değişiklik, senior mühendisler ve senior ürün insanları arasındaki bulanıklık. Yeni modelin en başarılı uygulayıcıları, ürün düşüncesi ile derinlemesine yatırım yapmış mühendislerdir.

Daha değerli hale gelen şey, yargıdır: bir problemi, bir ajanın çözebileceği kadar kesin bir şekilde tanımlama yeteneği, çözümü doğru olup olmadığını değerlendirme ve ajanın çıktısını yönlendirme yeteneği. Senior mühendisler, avantajlarını biriktiriyorlar, çünkü ajan çıktısını yönlendirebiliyorlar ve hangi çıktıların güvenebileceklerini bilirler. Endişe, erken kariyer yolu içindir. Geleneksel olarak yargıyı oluşturmanın yolu, çok fazla kod yazmak ve hatalardan öğrenmekti. Bu geri bildirim döngüsü, endüstri henüz tam olarak çalışmadığı şekilde değişiyor.

Tarih, bazı güvenceler sunuyor. Derleyici, derleyici geliştiricilerini işinden edeceğine inanan önemli bir kontenjan vardı. Teknoloji değişimi, öngörülen şekilde gerçekleşti. Derleyiciyi izlemeyen geliştiricilere ne oldu? Sonraki on yılda, geliştiricilerin toplam sayısı arttı. Çok sayıda derleyici programcısı, yeni bir dil öğrendi ve temel bilgilerinden dolayı mükemmele ulaştı. Aynı modelin tekrar oynandığını düşünüyorum.

İleriye bakıldığında, AI’nin yazılım geliştirme yaşam döngüsünü, gelecek üç ila beş yıl içinde nasıl yeniden şekillendireceğini görüyorsunuz ve şirketler en büyük rekabet avantajını nerede kazanacaklar?

Önümüzdeki birkaç yıl içinde, benzeri görülmemiş bir özellik silah yarışına tanık olacağız. Yazılımı oluşturmanın maliyeti sıfıra yaklaştıkça, şirketler, hatta büyük olanlar, yeterli müşteri geri bildirimi toplamak ve kaliteli şeyler oluşturmaya devam etmek için yeni bir kısıtlama ile karşı karşıya kalacaklar.

Olmak zorunda olan değişim, inşa edilecek şeylerin barajının yükselmesi gerekiyor. Mevcut kısıtlama, çoğu mühendislik organizasyonunda basittir: beş üst öncelik, belki iki teslimat. Ajanslarla, oran tersine döner. Beş üst, on sonraki, yirmi belki de listede olabilir ve yüz teslim edersiniz. Son altmış beşinin kötü tasarlandığından ve kötü yürütüldüğünden nasıl kaçınılacağını kimsenin tam olarak cevaplayamadığı soru.

Üç ila beş yıllık pencerede fairly emin olduğum iki şey var. İlk olarak, mühendislik AI’sinde rekabet avantajı, model kalitesinden değil, bağlam derinliğinden ve genişliğinden gelecektir. Modeller, masa başı haline geliyor; her aracın yetenekli olanlar olacak. Önde gelen platformları ayıran, sizin organizasyonunuzu ne kadar iyi anladıklarıdır: depolarınız, takım yapınız, teslimat geçmişiniz, dağıtım kalıplarınız. Sistemlerinizi bilen araçlar, bilmeyenlerden temel olarak farklı cevaplar üretecektir. İkincisi, reaktiften proaktife geçiş. Bugünün araçları, sorulduğunda cevaplar verir. Birkaç yıl içinde, önde gelen araçlar sürekli olarak gözlemleyecek ve siz sormadan önce riski ortaya koyacaktır. Bu bağlam katmanını şimdi inşa eden organizasyonlar, bir avantaj biriktiriyorlar. Kaliteyi ölçekte çözmek zorunda olan bir sonraki nesil araçlar ve bunu ilk çözen organizasyonlar, gerçek bir avantaja sahip olacaklar.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular, Allstacks’i ziyaret etmelidir Allstacks.