Temsilci tabanlı kodlama: Sektör liderleriyle yuvarlak masa toplantısı

Merhaba,

Bu hafta veya son iki gün içinde birçok Android Googler'dan bilgi aldınız.

Bu nedenle, konferansı dışarıdan, topluluktan, Android geliştirici topluluğundan bazı kişilerin görüşlerini alarak kapatmanın çok iyi olacağını düşündük.

Temsilci tabanlı kodlama ve bunun gerçek dünyadaki etkisinden bahsedeceğiz.

Önce kendimizi tanıtarak başlayalım.

Ben, Android Geliştirici İlişkileri ekibinden Ben.

Bu konferansta benden bir kez haber aldınız, ancak panelden aşağı inelim.

Merhaba arkadaşlar.

Adım Vinay. Databricks'te yapay zeka araçlarıyla ilgili çalışmalara destek veriyorum.

Burada olduğum için çok heyecanlıyım.

Merhaba, ben Luis Artola.

Google Haritalar'da çalışıyorum.

Temsilci deneyimleri oluşturmak ve yazılım geliştirme döngüsünü iyileştirmek için yapay zekayı kullanan ekipleri yönetiyorum.

Merhaba, ben Annyce Davis.

Ford'da çalışıyorum.

Abonelik ve bağlılık ürünlerimizi geliştiren bazı mühendislik ekiplerini yönetiyorum.

Merhaba arkadaşlar.

Ben Ty Smith.

Uber'de geliştiricilerimize destek veriyorum.

Bu, çok uzun süredir mobil cihazlar.

Son birkaç yıldır, yapay zeka araçlarıyla yaşadığımız bu yeni ve heyecan verici döneme odaklanıyoruz.

Merhaba arkadaşlar.

Ben Kaushik Gopal.

Instacart'ta baş mühendis olarak çalışıyorum. Android geliştiricisi hakkında Fragmented adlı bir podcast'e başladım.

Ty'ın da dediği gibi, son zamanlarda stratejilerimizi biraz değiştirdik ve yapay zeka geliştirme hakkında konuşuyoruz.

İşte böyle.

30 dakikamız var.

Zamanın hızla geçeceğini düşünüyorum. Bu nedenle, doğrudan can alıcı sorulara geçeceğiz.

Android DevRel'de her zaman uygulama geliştirmeyi daha hızlı ve kolay hale getirmek istediğimizi söyledik.

Şimdi yapay zeka hayatımıza girdi ve bizim de "Evet, gerçekten de öyle.

Uygulama geliştirmenin daha hızlı ve kolay olduğunu düşünüyoruz."

Ancak şunu sormak istiyorum: Gerçekten uygulamaları daha hızlı mı yayınlıyoruz yoksa sadece hiçbir işe yaramayan bir sürü kod mu üretiyoruz?

Hadi Vinay.

Anladım.

Evet, hepimiz birbirimize bakıyoruz.

Güzel.

Yani sadece sayılara bakarsanız PR'lar ve kod satırları açısından çıktıda büyük bir hızlanma olduğunu kesinlikle görürsünüz. Sonuç olarak, kodumuzu nerede depoladığımız gibi konularda bile ölçeklendirme zorluklarıyla karşılaşıyoruz, değil mi?

Bu hızlanma çok gerçek.

Ancak bu durumun sonuçları nasıl etkilediği net değil. Bence tüm sektör, sonuçlarla ilgili doğru metriğin ne olduğunu ve kârlılığı nasıl etkilediğini anlamaya çalışıyor.

Ancak bu yaklaşımın işe yaradığını kesinlikle görüyorum.

Son altı ayda, önceki döneme kıyasla daha fazla kod yayınladığımızı düşünüyorum. Yine belirsiz bir ifade kullanacağım ancak bu, çok uzun bir süre.

Bunun sonucunda, verimliliği ölçme stratejimiz bile değişti.

Çünkü bu konuda düşünmenin çeşitli yolları var.

Ortancayı nasıl yükselteceğimizi bulmaya çalışıyoruz, değil mi?

Çünkü uç değerlere ve ortalamaya baktığınızda bu iki kategorideki insanlar arasında 5 ila 10 kat fark var. Bizim odak noktamız ise tabanı ve ortalamayı yükseltmek, bu insanları çevrelerindeki diğer kişiler kadar üretken hale getirmek.

Farklı rollerin bir arada kullanıldığını görüyoruz.

Bazı kişiler çok daha hızlı ilerliyor.

Günde yüz tane PR yapan ve inanılmaz işler çıkaran insanlar var.

Ancak bu, faaliyet gösterdikleri bir alan türüdür.

Bu daha çok yeni bir alan olabilir veya araçları daha akıcı bir şekilde kullanıyor olabilirler.

Ayrıca, daha çok mevcut altyapı veya platform çalışmalarıyla ilgilenen ve farklı türde çalışmaları destekleyen kişiler de görüyoruz. Bu çalışmalar, insan değerlendirmesine daha fazla zaman ayırmaları ve işlerin aksamayacağından emin olmaları gerektiği için o kadar hızlı ilerlemeyebilir.

Bu ikisinin birleşimi, eskisinden çok daha hızlı. Ancak bence bizim için asıl ilginç konu, daha fazla ürün gönderiyor olsak da işletmenin son kullanıcılara gerçekten daha fazla ürün gönderip göndermediği.

Bu, yalnızca kodları değil, özellikleri de daha hızlı yayınlayıp yayınlamadığımızı anlamak için geçtiğimiz yıl yatırım yaptığımız bir alan.

İlk sinyaller öyle olduğunu gösteriyor ancak bu, saf PR'lardan çok farklı bir görünüm oldu.

Bence olan şey şu: İnsanlar çok daha fazla kod gönderiyor, yani PR sayısı, sayılar arttı.

Ancak şu anda bile birçok kişi, "Yapay zekayı ve elimizdeki bu aracı nasıl kullanıp mevcut süreçleri hızlandırabiliriz?" diye düşünüyor.

Doğru mu?

Eskiden kod yayınlama sürecinde, kodun üretim aşamasına kadar her adımını bir insanın yönetmesi gerektiğini düşünürdük.

Ancak şu anda gördüğümüz şey, bunun işe yaradığı.

Daha fazla ürün gönderiyoruz.

Ancak daha önce karşılaşmadığımız her türlü darboğazla karşılaşıyoruz, değil mi?

Çünkü geçmişte bu sorunlarla hiç karşılaşmadık. Ancak şimdi, çok adımlı bir döngünün bir bölümünü hızlandırıyoruz. Bence işin ilginçleştiği yer de burası.

Daha fazla efekt sunuyoruz ancak artık efektler yangın hortumundan fışkırır gibi geliyor."

Bu nedenle başka zorluklarla karşılaşıyoruz.

Bu çok ilginç bir nokta. Çünkü düşündüğünüzde birçok farklı adım var ancak genel bir bakış açısıyla bunları üç aşamaya ayırabilirsiniz, değil mi?

Kodlama var. Bu alanda hızlanma olduğu açık.

Üretime hazırlık aşamasında yasal konular, gizlilik ve ürünün piyasaya sürülmesini sağlayan diğer unsurlar gibi birçok konu ele alınır. Sonra da lansman yapılır, değil mi?

Ayrıca kargo, bulunduğunuz yere göre farklı anlamlara gelebilir.

Tamamen sunucu tarafında bir ürününüz varsa muhtemelen sevkiyat daha akıcı bir süreç anlamına gelir. Ancak tüketiciye giden bir şey gönderiyorsanız bunu deneme aşamasına getirmek yolculuğun ortası gibidir, değil mi?

Yine de çok sayıda deneme ve ölçüm yapmanız gerekir. Bu noktada, söylediklerinizle bağlantı kurmak gerekirse kendinizi bir metropolde, otoyolda, sıkışık bir noktada gibi hissedersiniz. Sonra hızlanmaya başlarsınız ve "Evet, harika.

Çok hızlı ilerliyorum" diyebilirsiniz ancak bir sonraki darboğazla karşılaşırsınız.

Yapay zekanın çok net bir şekilde ortaya koyduğu şey, sürtüşme noktalarını daha net görmenizdir. Bunlardan bazılarının kodlama veya teknolojiyle hiçbir ilgisi yoktur.

Süreçler, insanlar ve yapay zeka ile optimizasyonun nasıl yapılacağıyla ilgilidir.

Uçtan uca optimizasyonun nasıl yapılacağı gerçekten ilginç bir zorluk.

Bu alanı biraz daha farklı bir şekilde ele alıyoruz. Örneğin, kişinin veya ekibin ürünü tam olarak yayınlama konusunda ne kadar yetkisi var?

Şirket içine baktığımızda, şirket içi araçlar geliştiren veya müşteriye gönderilmeyen şeyler yapan birçok ekip olduğunu görüyoruz.

Çok daha hızlı gönderiyorlar, değil mi?

Bu bilgileri müşterilerine hemen ulaştırma konusunda tam yetkiye sahipler.

Harici bir ürününüz varsa ve bu ürünün kullanıcıyla deneme aşamasından geçmesi gerekiyorsa veya uygulama mağazası kullanıma sunma süreleri ya da tasarım ve ürünle çalışma gibi diğer tüm darboğazlar birikiyorsa kod yazan kişilerin bu konuda hızlı hareket etme yetkisi çok daha az olur.

Bu nedenle, sistemdeki diğer darboğazlara takılıyorlar.

Bu nedenle, bunları iki farklı alana ayırmanın, işletme süreçlerinizin nerede iyileştirilebileceğini gerçekten vurguladığını düşünüyorum.

Evet, katılıyorum ve dürüst olmak gerekirse mühendisliğin hiçbir zaman engel teşkil etmediğini düşünüyorum.

Bunu yıllardır söylüyorum.

Mühendislikte işler çok düzenli bir şekilde yürütülür ve işletme tarafından her zaman "Sorun nedir?" sorusu sorulur.

Bu soruya 10 farklı yanıt alırsınız.

Sonra da "Tamam.

Şimdi, bu durumu ürünle ilgili bazı çözümlere dönüştürelim.

Şimdi bu konuyu biraz düşünelim.

Tasarım ekibiyle biraz konuşalım.

Oraya doğru vur."

Mühendislik aşamasına gelindiğinde ne yapmamız gerektiğini az çok biliyorduk.

Sonra Stack Overflow'a gidip bir şeyler kopyalayıp yapıştırır ve işi bitiririz.

Yapay zeka sayesinde en büyük hız artışını bu uyumluluk çalışmalarında görüyorum.

Örneğin, XYZ'yi modernize etmek veya Spring Boot sürümünü hızlıca yükseltmek istediğimiz durumlar.

Bunu çok hızlı yapıyoruz.

Ancak özelliklerin sunulması konusunda önemli bir gelişme gördüğümü söyleyemem.

Hepiniz bir şekilde değindiniz. Belki de darboğazın yeri değişti ve eskiden darboğaz olmayan ama artık darboğaz olan bu süreçlerle karşılaşıyorsunuz.

Ancak bu süreçler muhtemelen geçmişte zor yoldan öğrenilen derslerden kaynaklanmıştır, değil mi?

Bunları değiştirme konusunda baskı hissediyor musunuz? En belirgin olanı kod incelemesi.

Kod incelemenin geleceği hakkında ne düşünüyoruz?

Şu anda ne yapıyoruz?

Bu konudaki düşüncelerinizi öğrenmek isterim.

Bu, daha önce değindiğim noktaya geri dönüyor.

Bu darboğazların çoğunun, yazılım mühendisliğini yeniden icat etmek için sihirli bir değneğiniz olsaydı ve bugün yapay zekaya sahip olsaydınız, aynı şeyleri mi yapardık diye düşünmemizden kaynaklandığını düşünüyorum.

Örneğin, kod incelemesi için bir insanın onayına ihtiyaç duyuyorduk. Son bir çapraz kontrol yapılması gerekiyordu.

Bence bu da değişiyor. Kod incelemeleri hakkında artık şöyle düşünüyoruz: Belki de bir adı yeniden düzenliyorsanız veya kodu yeniden düzenlemeye çalışıyorsanız ve herkesin sahip olduğu harika testleriniz varsa bu fikre açık olmalıyız.

Yapay zekaya yazdırdık, sorun yok.

Hayır, yani belki de o temsilciden çok daha iyi bir iş çıkaracaksınız.

Bilmiyorum, belki de bunu incelemek için zaman harcamamalısınız.

Ancak bir hata gönderirseniz ve CEO'nuzdan "Bu hata bize şu kadar paraya mal oluyor" diyen bir telefon alırsanız, "Bu kritik bir alan.

Bu kritik bir alan değil" diyerek yeniden hayal etmeye çalışın.

Bugün bu şekilde çalıştığımızı düşünmüyorum.

Bugün ise "Bir PR var.

Mühendis benim.

Buna odaklanmış durumdayım.

Yükselir.

Gecenin bir yarısı Vinay'ı kod incelemesi için rahatsız ediyorum çünkü bu şeyi birleştirmek istiyorum."

Ancak belki de bunların çoğunu yeniden düşünmemiz gerekiyor.

Tamamen katılıyorum. Kod incelemesini bir doğrulama sorunu olarak görüyorum. Şunu kastediyorum: Bir şeyi doğrulama yeteneğime tam olarak güvendiğim bir dünyada, PR'lerimin %100'ünü yine de kod incelemesine tabi tutar mıydım?

Muhtemelen hayır, değil mi?

Kod incelemelerinin iki amacı vardır.

Bunlardan biri, doğru şeyi yaptığımızı doğrulamak, ikincisi ise eğitim, değil mi?

Örneğin, etrafınızdaki insanlar ne yaptığınızı ve bu karara katılıp katılmadıklarını bilir.

Bu nedenle, hızlandırma ve koda, hatta sürümlere dahil etme konusunda rahat olmamız gereken bir çalışma kategorisi kesinlikle var.

Bu durum tüm vakalar için geçerli olmayabilir ancak vakaların büyük bir kısmında geçerli olacağını düşünüyorum.

Bu değişiklikleri yapmaya hazırlandığımızı düşünüyorum. Topluluk olarak hepimiz sistemlerimizin buna hazır olduğundan emin olmalıyız çünkü bu değişiklikler yakında yapılacak.

Bunun başka bir yolu yok.

Dönüşüm hunisinin üst kısmı, daha fazla PR oluşturmanıza olanak tanıyan çeşitli yüzeylerle çok geniştir.

Süreçteki en yavaş adımınız kadar hızlısınızdır.

Birçok ekip için bu, kod incelemeleri anlamına geliyor. Daha hızlı ilerleyen ekipler bu gerçeği anlamış ve kabul etmiş durumda.

Evet, dürüst olmak gerekirse gördüğüm PR'ların %70'i bana iyi görünüyor.

Dünyadaki tüm kod tabanlarını ararsak PR yorumları her yerde "bana iyi görünüyor", LGTM olur.

Mühendislik uzmanları olarak bazen kendimize hak ettiğimizden daha fazla pay çıkarıyoruz.

Bu konuda çok iddialıyız.

"Komut kalıbı kullandılar mı?"

Hayır, sadece "Tamam.

Evet, bence iyi görünüyor."

Peki, bunu neden bir temsilciye yaptıramıyorum?

Bence gelecekte "Bana iyi görünen nedir?" gibi soruların yanıtlarını arayacağız. Örneğin, size bu şekilde hissettiren özellikler ve davranışlar nelerdir?

Ardından, temsilcinin de aynı şeyi aradığından emin olalım.

Ya da tam tersi, farklı inceleme yöntemleri de düşünmeye çalışın.

Örneğin, Twitter'da şöyle bir şey söyleyenler var:

Örneğin, bir PR'yi doğrularken temsilcilerinizden bunu farklı bir şekilde görselleştirmelerini isteyebilirsiniz.

Hey, bana önceki halini göster.

Sonraki halini göster.

Kodu satır satır incelemek yerine yazdığınız testleri gösterin.

Ancak bu durum, Bülent, bir şey mi söyleyecektiniz?

Hayır, bence düşündürücü bir şey, değil mi?

Böylece, CL'lerin veya PR'lerin insan müdahalesi olmadan geçmesine izin verme konusunda kendinizi gerçekten rahat hissedeceğiniz bir noktaya geleceğiz.

Şimdi biraz şeytanın avukatlığını yapacağım ve sürtüşmeden bahsettiğimizde, sürtüşmenin kötü olduğunu düşünme eğilimi olduğunu söylemek istiyorum, ancak iyi ve kötü sürtüşme vardır.

Yorumların hâlâ iyi sürtünme kategorisinde olduğunu düşünüyorum.

Bu, geliştiriciler için süreci nasıl daha kolay hale getireceğimizle ilgili bir konu, değil mi?

Bazen de o anda bu incelemeyi nasıl daha iyi veya daha verimli hale getireceğimizle ilgili değildir.

Yapay zeka ile geliştirme sürecinin başlarında daha isabetli sonuçlar elde etmenin yollarını arıyorsunuz, değil mi?

Çünkü yapay zekayı nasıl kullandığınıza bağlı olarak, iyi girişler daha iyi çıktılar üretir, ancak kötü girişler gerçekten kötü sonuçlar verir, değil mi?

Bu nedenle, bu çekici son duruma ulaşmak için sürecin başından itibaren yapay zeka ile bütünsel bir iyileştirme yapılması gerektiğini düşünüyorum. Yapay zekayı kullanarak mimariyi daha iyi anlamak, geliştiricilerin daha az çaba harcamasıyla gerçekten sağlam spesifikasyonlar elde etmek ve böylece ürettiği kodun daha yüksek kalitede olmasını sağlamak gerekiyor.

Bu nedenle, incelemeler geliştiriciler için daha az sorun yaratır.

Bu sürecin sonunda, tüm bu kodların gerçek kişi tarafından yapılan inceleme olmadan yayınlanacağı konusunda çoğu kişinin hemfikir olacağını düşünüyorum.

Bu arada, modellerin geliştiği ve teknik hata yapmaları konusunda daha az endişelendiğimiz, ancak iş hatası yapmaları veya karar verme ya da fikir üretme süreçlerindeki sorunlar konusunda daha fazla endişelendiğimiz bir süreçten geçiyoruz.

Bu nedenle, inceleme aşamasında ayırmak istediğiniz sinyale de dahil edilir.

Örneğin, PR'da satır satır inceleme mi yapmalıyız yoksa sonrasında uygulamaya çalıştıkları amacı mı incelemeliyiz?

Bu konuyu birkaç farklı şekilde ele alabiliriz.

Bunlardan biri, kullanıcıya daha alakalı bilgileri nasıl verebileceğimiz ve böylece kullanıcının bu bilgilere öncelik vermesini nasıl sağlayabileceğimizdir.

Diğeri ise bu tür programlarda denemeler yapabileceğimiz ve daha hızlı ilerleyebileceğimiz daha güvenli alanların neler olduğudur.

Kaushik'in de dediği gibi, her alanda aynı titizliği göstermeniz gerekmez.

Bunu tespit edebilir ve bazılarını daha hızlı yayınlamaya başlayabilir, riski azaltabiliriz. Ancak uyumluluk odaklı veya çok temel alanlarda, yalnızca modellere değil, modellere giren girişlere de gerçekten güvenene kadar daha fazla sürtüşme yaşayabiliriz.

Doğru kararlar olduğunu gösterir.

Örneğin, Uber uygulamasında yeni Android modülünü yeniden düzenlemek uygun olabilir.

Tüm Android geliştiricilerine ücretsiz sürüş imkanı sunuyoruz. Bu kodu kontrol etmek isteyebilirsiniz.

Bu konuyu CEO'muza danışmam gerekiyor.

Üzgünüm Kaushik.

Ancak bu sorunun çözüldüğünü de düşünüyorum.

Özellik bayraklarımız var.

Mavi-yeşil dağıtımımız zaten var.

Bu parçaların çoğu zaten elimizde.

Asıl zorluk, bunu yapamayacak kadar meşgul olmamız.

Davranış izleme özelliğimiz zaten var.

Bu tür verilerin hepsi elimizde var ancak farklı sistemlerde bulunuyor.

Olayları zaten takip ediyoruz.

Elimizde çok fazla veri var ancak tüm bunları kapsamlı bir izleme gibi tek bir yerde toplamak eksik olan parça.

Bu tür bir mühendislik bağlam hizmetinin tüm bu farklı şirketlerde nasıl göründüğünü nihayet anladığımızda, artık endişelenmemize gerek kalmaz çünkü PR birleştirilse bile güvenlidir.

Çünkü bu özelliğin bir özellik bayrağının arkasında olduğunu biliyoruz.

Mavi-yeşil dağıtımımız var.

Tüm gözlemlenebilirlik özelliklerini kullanıyoruz.

Ardından, "Bunu satış hattına ekleyin." diyerek kendinize olan güveninizi gösterebilirsiniz.

Kötü bir şey olduğunda, yol boyunca tüm bu korumalar ve kapılar devreye girer.

Yanıt verme hızı da çok önemli, değil mi?

Örneğin, Android'de bir değişiklik yapıyorsanız ve bu değişikliğin Play Store üzerinden gönderilmesi ve ardından tüketicilerinize sunulması gerekiyorsa, bunu hemen düzeltme yeteneğiniz gerçekten engellenir. Oysa dahili gözlemlenebilirlik ve hemen üzerinde çalışan bir temsilci ile dahili bir dağıtıma sahip bir şey yapıyorsanız, orada daha hızlı hareket etmek için çok daha fazla fırsatınız olur.

Size sormak istediğim sorulardan biri de şu: Bu uygulamalar üzerinde yapılması gereken çalışmalar var ancak daha kolay olan yeni uygulamalarınız ve mevcut uygulamalarınız var. Ayrıca yapay zeka kullanımını yaygınlaştırmak için bu kontrollerin çoğunu yapmanız gereken bir zaman var.

Birçoğunuzun devasa uygulamalar üzerinde çalıştığını biliyorum.

Bu konuda ne düşünüyorsunuz?

CEO'ya gidip "Bana 3 ay ver, bu uygulamayı yapay zekaya hazır hale getireyim" mi diyorsunuz yoksa her gün mü ekliyorsunuz?

Evet.

Zaten bunu hiçbir zaman yapmazlar.

Sanmıyorum.

Çoğu şirketin böyle bir lüksü yoktur.

Bence buna da tıpkı teknik borç gibi zaman ayırmamız gerekiyor. Örneğin, zamanınızın %20'sini buna ayırıyorsanız bunun %5'ini istemleri iyileştirmek için kullanabilirsiniz.

Ardından istemin ne yaptığını anlayıp bağlamı daha iyi hale getirebilir.

Bu konudan bahsetmiştik. Bence bunun en büyük nedeni, mühendislerin bu teknolojinin nasıl çalıştığını hâlâ anlamamış olması.

Hâlâ sihirli ve gizemli bir şeymiş gibi geliyor. Bu yüzden, en iyi değeri ve verimi elde edecek şekilde yapılandırıp ayarlamıyorlar.

Bu nedenle, liderlerin "Ekibimizin bu işleyişi anlaması ve daha fazlasını elde edebilmemiz için ne yapmamız gerekiyor?" diye sorması gereken bir nokta olduğunu düşünüyorum.

Aynı zamanda onun devamıdır.

Çok hızlı değiştiği için bir ekibe bir hafta boyunca en yeni ve en iyi şeyleri öğrenip uygulamaya koymasını söylesem ve sonra öğrenmeye veya denemeye devam edecek zamanları olmasa, bir yıl sonra kontrol ettiğimizde yeni özelliklerin çok gerisinde kalmış olurlar.

Bu nedenle, uçağı uçururken inşa ettiğimiz bir süreçten bahsediyoruz. Koruma önlemleri alıyor, öğreniyor ve olaylar geliştikçe ayarlamalar yapıyoruz. Ekiplerin bu süreci yakından takip etmesi gerekiyor.

Büyük kuruluşlarda ise bizimki gibi ekipler bu bilgileri süzerek daha anlaşılır ve kolayca kavranabilir hale getirmeye çalışır.

Ancak şu anda sektördeki herkes bu zorlukla karşı karşıya.

Biraz değişiklik yapmak istiyorum.

Birçoğunuz geliştirici altyapısı gibi alanlarda çalışıyorsunuz.

Binlerce PR, test altyapınız, sunucularınız, hepsi eriyor mu?

Savaş hikayelerini dinlemek isterim.

Ty?

Evet.

Çok iyi gidiyorlar.

CI'ım her gece ağlayarak uyumama neden oluyor.

Şu anda geliştirici altyapısı ekiplerimizin neredeyse tamamı, bilgi işlemde ölçeklendirme sorunları ve verimlilik sorunlarıyla mücadele ediyor.

Kırmızı kodlar falan var.

Hacimde çok büyük bir artış görüyorlar.

Temsilcilerle mimari değişiklikler yapıyoruz.

Bazel ile uzaktan derleme yürütme ve önbelleğe alma işlemlerimizi mümkün olduğunca hızlı bir şekilde genişletmeye çalışıyoruz. Ana dalın her zaman yeşil olması gerekip gerekmediğini veya belirli alanlarda aracılarla ileriye dönük düzeltmeler yapmaya başlayıp başlayamayacağımızı inceliyoruz. Mühendislerden gelen hacme bakıyor, kendi kendini iyileştiren CI veya daha düşük geri bildirim döngüleri gibi şeyler yapmaya çalışıyoruz. Tüm ekipler, verimlilik düzeyini korurken büyümeye ayak uydurmak için tüm bunlara aktif olarak yatırım yapıyor.

Ancak bu son derece zorlu bir süreçtir.

Evet, Ty'ın söylediklerine tamamen katılıyorum. Ancak bence bu durum bizi, şu andan itibaren 10 kat büyümeye hazır olup olmadığımızı dürüstçe sorgulamaya da zorluyor.

Çoğu kişi için yanıt muhtemelen "hayır"dır.

Sonuç olarak, geleceği düşünürken hedefimizi altyapının destekleyebileceği ölçekle eşleştirmeye çalışıyoruz.

Yapay zekanın yaptığı şeylerden biri de hepimizi daha hırslı hale getirmesi oldu. Çünkü bu anlamlı sıçramayı zaten gördük ve bu yüzden sistemlerimizi dürüstçe yeniden düşünüyoruz.

Doğru, başka hangi sistemin bozulacağını veya bozulacağını tahmin ettiğimizi ve sürpriz olmaması için bunun önüne geçmek için ne yapabileceğimizi düşünüyoruz.

Aslında sürprizlerden kaçınmaya çalışıyoruz.

Doğru, kontrolün bizde olduğunu hissettiğimiz sürece herkes mutlu olur.

Sürprizlerle karşılaştığımız an, herkes için kötü haber olduğunu biliyorum.

Doğru mu?

Bu nedenle, geriye dönüp bakmak, denetlemek ve bir sonraki adımda neyin bozulacağını anlamak için iyi bir zaman. Çünkü bu mutlaka olacak.

Bu kaçınılmazdır.

Biz sadece önlem almak istiyoruz.

Inflow'un CEO'sundan ilginç bir söz duymuştum.

Google'ın şu anki milyarlarca satır koda ulaşmasının yaklaşık 20 yıl sürdüğünü ve bu hızlanmayla birlikte birçok şirketin, yapay zekanın hızlanmasına bağlı olarak sadece birkaç yıl içinde benzer bir ölçeğe ulaşacağını anlatıyordu.

Tüm şirketlerin geliştirme için Google düzeyinde altyapıya sahip olmaya hazır olduğunu düşünmüyorum.

Bu konuyla ilgili olarak, şirketlerinizde bir tür harcama sınırı uygulanıyor mu?

Örneğin, her şey için jeton harcayan geliştiricileri nasıl yönetiyorsunuz? Her zaman mümkün olan en iyi modeli kullanmak gibi.

Örneğin, keşfettiğiniz stratejiler var mı yoksa denemelerden güzel sonuçlar çıktığı için onları serbest bırakmak daha mı iyi?

Geçen yılın deneme yılı olduğunu söyleyebilirim.

Her şeyi yapın.

Hatta bu yılın ilk yarısında da makul bir şekilde kullanmak yeterliydi.

Eylül ayından itibaren jeton sınırları da uygulanmaya başladı.

Bu nedenle, geliştiricilerin jeton kullanımıyla ilgili sınırlamalarımız var.

Ayrıca, oturumlarınızın iyi ve sağlıklı geçip geçmediğini anlamalarını sağlayan araçlarımız da var.

Sağlıklı bir oturum ne anlama gelir?

Oturum başına bu kadar çok sıra mı kullanıyorsunuz?

Sıra nedir?

Bu nedenle, geliştiricileri eğitmek için de araçları kullanmaya çalışıyoruz.

Bence bu sadece ilk adım.

Biliyorsunuz, bir sorunu çözebilmek için önce sorunun ne olduğunu bilmeniz gerekir.

Bu nedenle, en azından bunun ücretsiz olmadığını görmeleri iyi olur.

Eskiden yapay zeka gerçekten ücretsiz gibiydi.

İnsanlar da bunu kullanıyordu.

"Şubemi değiştir" dediğimde "Sorun değil Annyce, şubeni 5 dolar karşılığında değiştiririm" demesini isterim.

Şimdi, "Tamam, komut satırına gidip bunu kendim yapabilirim, değil mi?" diyebileceğimiz bir noktaya geliyoruz.

Bu nedenle, mühendislerin gerçek maliyet konusunda eğitilmeye başlanacağını düşünüyorum.

ECS örneklerini oluşturup öylece bırakmam.

AWS ilk çıktığında, "Evet, kendi örneğimi oluşturabilirim." diyorduk.

Şirkete çok fazla para kaybettiriyorduk.

Şu anda aynı şeyin token'lar için de geçerli olduğunu düşünüyorum.

Pratik sınırların da çok ilginç fırsatlar sunduğunu düşünüyorum.

Çünkü başlangıçta LLM'leri kullanmaya başladığımızda her şeyi onlara atardınız, değil mi?

Kodu inceler, sorunları çözer ve sizin için sihirli bir şekilde çalışır, değil mi?

Ancak bunun bir bedeli vardı.

Ve biz aslında gerçek bir işletmeyiz. Sektör de bunu fark ediyor.

Bu durum, geliştiricileri ve kuruluşları bunu nasıl optimize edebilecekleri konusunda düşünmeye zorluyor.

Neden mi? Somut bir örnek vereyim: Kullanıcı arayüzü bileşenleri üreten bir oluşturucunuz varsa ve bunların belirli bir yapıya, birim testlerine ve benzeri şeylere uyması gerekiyorsa, neden modellerin bunu anında oluşturmasını sağlayasınız ki? Bunu sizin için oluşturabilecek deterministik bir araç oluşturmasını sağlayabilirsiniz, değil mi?

Bu nedenle, jeton ve kullanım sınırlarını kendi avantajınıza kullanmak ve daha etkili olmak için birçok fırsat vardır.

Evet, bu temalar doğrultusunda kesinlikle sınırlar koyduk, en azından Instacart'ta.

Ancak bence amaç, yapay zekayı ne kadar kullandığınızı sınırlamak değil, bir tür hijyen veya sizin de söylediğiniz gibi iç gözlem sağlamak, değil mi?

Örneğin, belirli modelleri diğer modellere tercih etmeniz gereken durumlar.

Saati öğrenmek veya Git dalını değiştirmek için Fable ya da Astra'ya ihtiyacınız yoktur.

Doğru mu?

Biraz zaman ayırıp komut dosyası yazabilirsiniz. Bu işlem tamamen ücretsizdir.

Bu durumda jetonlar boşa harcanmaz.

Doğru mu?

Bu nedenle, kısıtlamanın kullanımınızı sınırlamak için değil, her şeyi bir anda kullanmak yerine daha derinlemesine düşünmenize yardımcı olmak için uygulandığını belirten bir ifade ekleyebilirsiniz.

Doğru mu?

Söylediklerinize katılıyorum. Geçen yıl deneme yılı gibiydi.

Bu yıl ise "Bu teknolojiyi nasıl etkili bir şekilde kullanabiliriz?" sorusuna odaklanıyoruz.

Evet.

Buradaki hikayeler de bizimle çok örtüşüyor.

Özellikle de daha fazla deneme yapmaktan verimlilik ve hesap verebilirlik arasında denge kurmaya geçişte.

Bu, çeşitli yatırımlardan gelir.

Geliştiriciler için eğitim ve görünürlük gibi konular var.

Annyce'ın etkin oturum maliyeti ve bilgileri hakkında bahsettiği gibi.

Örneğin, gereksiz etkileşimleri önlemeye yardımcı olan güvenli varsayılanlara yatırım yaparak kullandıkları becerilerin verimli olduğundan emin olmak için gerilemeleri ve bu tür şeyleri aramak.

Ayrıca harcadıkları maliyet konusunda hesap verebilirlik sağlıyor.

Yani, jeton sınırları var.

Geliştirici bu sınırlara ulaştığında bir düğmeyi tıklayıp gerekçe belirtebilir ve yöneticisi bunu onaylayabilir.

Yani iyi bir çalışma yapılıyorsa bunu incelemelerini istiyoruz.

Ancak daha fazla israfa yol açan veya deneysel bir şey yapıyorlarsa yöneticilerine neden bu konuda para harcamaları gerektiğini açıklayamazlar. Bu nedenle, bütçeyi kontrol altında tutmalarına da yardımcı olur.

Bu da sadece iş yapmamakla kalmayıp, bakıp "Bu doğru model seçimi mi?" diye sormaya yol açıyor.

Bu ağırlık doğru mu?

Bu jetonların maliyeti, rekabet baskısı nedeniyle düşmeye başladı.

Ancak genel olarak mühendislerimizin bu konuyu düşünmesi, onlara verdiğimiz parayı iyi bir şekilde yönetmeleri bence şu anda doğru ve sağlıklı bir yaklaşım.

Uzun vadede ise bu kararı tamamen onlardan alabilmek.

Doğru mu?

Otomatik model yönlendirme gibi özellikler sayesinde kullanıcıların bu konuda düşünmesine gerek kalmaz.

Ancak bu arada, bu sağlıklı bir durumdur.

Evet.

Bence odak noktamızın büyük bir kısmı, model yönlendirici gibi şeyler yapmak oldu. Böylece bu kararı geliştiriciden alıp doğru modele eşlemeye, görevi modele eşlemeye çalışıyoruz.

Ancak doğru tuzakları kurmak da önemlidir.

Bu nedenle, jeton sınırlarını birkaç şekilde ele alıyoruz.

Geliştiriciyi engellemek istemeyiz.

Ancak bir an durup bütçenin doğru alanlarda ve doğru şekilde harcandığından emin olabileceğimiz anlar olmasını istiyoruz.

Örneğin, geliştiricinin kendi başına kaldırabileceği bir engel olarak günlük sınırlar vardır.

Tek yapmaları gereken portala gidip bir düğmeyi tıklamak ve "Şaşırtıcı bir şey olmadı.

Kontrol bende."

Doğru mu?

Bu, basit bir kontrol mekanizmasıdır. Herkes döngüleri kullanıyor ve bu döngüler gece boyunca çalışabiliyor. Bu durumun maliyeti artırmasını istemiyoruz.

Bu oldukça makul bir durum.

Öte yandan, geliştiricilerimizin en iyi modelleri kullanabilmesini de istiyoruz.

Ancak bu model kategorileri için bir öncü bütçe oluşturduk.

Bu nedenle aylık bir bütçe belirlenir.

Yeterince yüksek.

Engellenmediniz.

Engellemenin kaldırılması gerekiyorsa bir istisna süreci vardır.

Yöneticinize gönderilir.

Bu, ne yaptığınızı açıkladığınız andır.

Platform ekibi olarak karar verici biz değiliz çünkü bu kararlar işin yapıldığı yere yakın olmalıdır.

Öncü modeli kullanma konusunda da size bir üst sınırla tam esneklik sunuyoruz.

Bunun işe yaramasının nedeni, sürece öngörülebilirlik kazandırmasıdır.

Doğru mu?

Jeton harcamalarımız için bütçe oluştururken (bu herkes için zorlu bir süreçtir) planladığımız her şeyi hesaba kattığımızdan emin olmak istiyoruz. Bu araçlar da bunu yapmamıza olanak tanıyor.

Bu konuşmalarda beni en çok etkileyen şey ne biliyor musunuz?

Bunun nedeni, hepimizin şirketlerde çalışması.

Kuruluşlar da bu durumdan etkileniyor.

Bu nedenle her bir jeton için ödeme yapmamız gerekir.

Doğru mu?

Ancak internette abonelik fiyatlandırmasının kullanıldığı koca bir dünya var.

Bu nedenle, onlar için bu çok farklı bir hesap.

Doğru mu?

Ancak herkesin aynı havuzda olduğu ve her bir jeton hakkında düşünmeye başlamanız gereken zamanın gelmesi an meselesi.

İşte o zaman, şu anda şirketlerde yapmamız gerektiği gibi, biraz daha sorumlu olma konusunda muhtemelen diğer ayakkabı da düşecek.

Ya da sınırsız bütçeniz olan bir öncü laboratuvarda çalışıyorsunuzdur.

Ardından çalışmaya devam ediyorsunuz ve Twitter'da her yerde gördüğünüz, yapay zekaya özgü heyecan verici çalışma yöntemleri oluşturuyorsunuz.

Tüm şirketlerimiz bunu yansıtmak istiyor ancak bunun için jeton harcamak istemiyorlar…

Google'da çalışanlar var.

Çok merak ediyorum.

Bu düğme nasıl çalışıyor?

Google'ın bütçesi ne kadar?

Luis, bu soruyu sen yanıtlamak ister misin?

Bu konunun ekonomik yönü hakkında konuşmak için doğru kişi olduğumu düşünmüyorum.

Google, birçok farklı kuruluşu olan çok büyük bir şirkettir.

Ama bu aslında bizi mükemmel bir şekilde tamamlıyor, çünkü tam zamanındayız.

Kullanışlıydı.

Zil çaldı, kurtuldunuz.

İşte buna mükemmel moderatörlük denir.

Halkla ilişkiler uzmanları…

Panelimize ve ADS'ye katıldığınız için teşekkür ederiz.