Ürün Operasyonları lideri, yapay zekâ iş akışlarının geleceğinin deterministik süreçlere bağlı olduğunu söylüyor

Yapay zekâ ile süreç otomasyonu üzerinde çalışıyor ve yapay zekânın insanların çalışma biçimini nasıl değiştirdiğine odaklanıyorum. Ayrıca yeni teknolojilerin çalışma hayatının geleceğini nasıl değiştirdiği üzerine fikir yürütmeyi seviyorum.

You should also read

• Bir Asana Uygulama Ajansında Teslimat Başkanının Kullandığı Gerçek Dünya Yapay Zekâ İş Akışları

• Yapay Zekâ Destekli Proje Yöneticisi ve Eğitimci, Projelerin İşleyişini Temelden Değiştiren Basit Bir Yapay Zekâ İş Akışını Paylaşıyor

Yapay zekâ geri bildirimleri ayrıştırmamıza ve daha iyi kararlar almamıza nasıl yardımcı oluyor?

Eskiden bir kişinin çok zamanını alan ve bu nedenle çoğu zaman hiç yapılmayan, en zahmetli işlerin büyük bir kısmı otomatik olarak gerçekleştirildi.

Dolayısıyla yapay zekânın en belirgin sonucu, ekiplerin manuel görevlere daha az, çıktılar üzerine düşünmeye ise daha fazla zaman ayırmasıdır.

Geri bildirimleri ayrıştırma konusunda da daha iyi bir iş çıkardık. Önceden insanlar büyük miktarda geri bildirim alıyor, bunun yalnızca küçük bir bölümünü okuyabiliyor ve çoğu zaman yine de içgüdülerine dayanarak karar veriyordu. Ancak o dönemde raporlar oluşturuluyor ve çalışma öğelerine otomatik olarak yorumlar ekleniyordu. Bu da önceliklendirme ve yönlendirme işlemlerini çok daha hızlı yapabileceğimiz anlamına geliyordu.

Ayrıca iyi kararlar almayı nasıl başaracağımız konusunda da daha iyi bir iş çıkardığımızı düşündüm; çünkü yapılan çalışmaları analiz edebiliyorduk. Ve ilgilenmediğimiz önemli boşluklara dair ipuçları elde etmeye başladık.

Ancak bazı şeylerin insanlar tarafından yapılması gerekir; bunlar genellikle zor kararlar ve çoğu zaman kurum kültürü ile çalışma yöntemleriyle ilgilidir. Ayrıca kişisel olarak, bu yapay zekâ ajanlarının oluşturduğu çıktılarla etkileşimi izleyerek insani başarının işaretlerini aradım.

Chris Paylaşıyor

Eskiden bir kişinin çok zamanını alan, en zahmetli işlerin büyük bir kısmı otomatik olarak gerçekleştirildi.

Ajan tabanlı iş akışları ekipleri nasıl destekleyebilir?

Raporlama, önceliklendirme ve yönlendirme ile birden fazla kanaldan müşteri geri bildirimi toplama gibi işler için yapay zekâ kullandık.

Önceliklendirme ve yönlendirme, daha iyi bir ürün geliştirmeye çalışan bir ekip için kritik öneme sahiptir. Ürünümüz teknik açıdan oldukça karmaşıktı; bu nedenle yeni kullanım alanlarını ve hataları önceliklendirmek ve yönlendirmek için çok zaman harcadık. Kullanıcı deneyimi tarafında ise eğilimleri keşfediyor ve üzerinde çalışılacak konulara karar veriyorduk.

Ekibimiz yeniydi ve çok sayıda geri bildirim kaynağımız vardı, ancak tüm bu kaynaklardaki geri bildirimleri ayrıştırıp önceliklendirebilen, kullanımı kolay bir platformumuz yoktu.

Bu nedenle her şeyi geliştirmek için Codespaces, VS Code, Copilot CLI (çeşitli modellerle) ve GitHub Ajan Tabanlı İş Akışlarını kullanıyordum.

Geliştirdiğim son şey, piyasaya sunulan özelliklere ve pazardaki trendlere dayalı bir sosyal medya öneri ajanıydı. Ekip büyük ölçüde mühendislik odaklıydı; bu nedenle çerçevenin pazarlamasını kendi başlarına yapabilmeleri için yardıma ihtiyaçları vardı.

Bunun ve diğer ajanların sonucunda ekibe ürüne odaklanması için daha fazla zaman verildi.

Çok adımlı iş akışları için bir teknoloji yığını

Teknoloji yığınımıza gelince, çok adımlı işleri otomatikleştirmek için GitHub'ın yapay zekâ araçlarını kullandık.

Buna görevleri yapay zekâ ajanlarına devretmek için ajan tabanlı iş akışları, bu ajanları terminalden çalıştırmak için Copilot CLI, bulut tabanlı geliştirme ortamları için Codespaces, yapay zekâya doğru proje bağlamını sağlamak için Copilot Spaces ve tekrarlanabilir talimatları veya iş akışlarını paketlemek için Beceriler dahildi.

Ajan tabanlı iş akışları nasıl oluşturulur?

Ajan tabanlı iş akışlarını çoğunlukla diğer ajanların yardımıyla oluşturdum, test ettim ve izledim.

GitHub Next, aracıları GitHub Actions'a güvenli bir şekilde dahil etmek için Agentic Workflows adlı bir çerçeve oluşturdu. Bu çerçeve, hem insanlara hem de aracılara aracı tabanlı akışları oluşturmak, test etmek ve izlemek için anlaşılır bir yol sunuyor; bu nedenle yararlı bulabilirsiniz.

Aşağıda, belgeleri güncel tutan minimal bir aracı tabanlı iş akışı yer alıyor. Bu, söz dizimini açıklamak için verilmiş basit bir örnektir — üretim kullanımı için tasarlanmamıştır. Daha kapsamlı bir örnek GitHub Next'in örnekler deposunda mevcut. Ayrıca mühendislik dışı kullanım senaryoları için hazırladığım bazı iş akışları da burada yer alıyor.

---

on:

  push:

    branches: [main]

permissions:

  contents: read

  pull-requests: read

safe-outputs:

  create-pull-request:

tools:

  edit:

  web-fetch:

  web-search:

---

# Belge Güncelleyici

Sen bir teknik yazarsın. Görevin, ${{ github.repository }} deposundaki belgeleri _mükemmel_ hâle getirmektir.

Adımlar:

1. Depo değişikliklerini analiz et. Ana dala yapılan her gönderimde, değiştirilen, eklenen veya kaldırılan varlıkları belirlemek için farkları incele.

2. Mevcut belgeleri doğruluk ve eksiksizlik açısından gözden geçir. Eksik veya güncelliğini yitirmiş bölümler de dâhil olmak üzere belgeleme eksiklerini belirle.

3. Belgeleri gerektiği şekilde güncelle.

4. Değişikliklerin açık bir açıklamasını içeren bir çekme isteği oluştur.

Yukarıda görebileceğiniz gibi tetikleyiciler, izinler, çıktılar ve araçların tümü iş akışının tanımında açık ve net bir şekilde belirtilmiştir.

Deterministik süreçler neden hâlâ kritik?

Proje çalışmaları hâlâ deterministik süreçler gerektiriyor.

Arka planda, aracı tabanlı iş akışları hâlâ GitHub Actions üzerine kuruludur; bu da sabit, kural tabanlı adımları daha açık uçlu yapay zekâ çalışmalarıyla birleştirebilecekleri anlamına gelir. Bu önemlidir; çünkü bir aracı gibi daha deterministik olmayan bir şeyle birlikte çalışan deterministik bir sürece ihtiyaç duyduğunuz pek çok an vardır.

Buna iyi bir örnek, haftalık durum özetleridir. Aracı, nelerin değiştiğini sentezleyip bunu yararlı bir özete dönüştürmekte faydalı olabilir; ancak ilk adım — doğru zaman aralığında, doğru proje görünümünden doğru sorun yorumlarını almak — kesin olmalıdır. Bu kısmın, aracı bilgileri yorumlamaya başlamadan önce deterministik bir adım olarak ele alınması daha uygundur.

Bu iş akışlarını yeniden kullanılabilir parçalara ayırmaya da başlamıştık. Bir deterministik adım bilgileri standart bir şekilde toplarken, ayrı bir yönerge kümesi aracıya özeti belirli bir ekip için nasıl biçimlendireceğini söylüyordu. Bu önemlidir; çünkü ekipler genellikle benzer bilgileri biraz farklı şekillerde raporlar.

Diğer önemli parça ise koruyucu sınırlamalardır. Aracı tabanlı iş akışlarında “güvenli çıktılar”, aracının yapmasına izin verilenleri kısıtlayabilir. Örneğin bir aracının sorunlardan veri toplamasına izin verilebilir; ancak çıktı olarak yalnızca bir çekme isteği veya tartışma gönderisi oluşturmasına izin verilebilir. Bu, hassas kurumsal verilerle aracıları kullanmayı daha güvenli hâle getirir.

“Kod olarak süreç” şeklindeki daha büyük fikir de burada devreye girer. İş akışı deterministik adımlara, aracı yönergelerine, izin verilen çıktılara ve insan inceleme noktalarına ayrıldığında süreç artık yalnızca belgeleme değildir. Hem insanların hem de aracıların yürütebileceği bir şeye dönüşür.

Gerçek sürecimiz yalnızca yazıya dökülenlerden ibaret değildir. Yaptıklarımızı, konuştuklarımızı, gerçekten güncellediklerimizi ve güncellemediklerimizi kapsar. Söylediğimiz şeyle yaptığımız şey arasında ve bunun altında var olan gerçek gölge sistem arasında çoğu zaman bir ayrım vardır. Bu tür araçlarla, özellikle de aracı tabanlı iş akışlarıyla, bu farkı kapatmaya başlayabiliriz.

Gerçek sürecimiz sadece yazılı olanlardan ibaret değil. Yaptıklarımız, konuştuklarımız, gerçekten güncellediklerimiz ve güncellemediklerimizdir.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Chris ButlerOpens new window

GitHub'da Eski Ürün Operasyonları Direktörü

AI proje teslimini nasıl değiştiriyor

Yakında AI, bir proje yöneticisinin iş yükündeki manuel kontrollerin çoğunu ortadan kaldıracak.

Raporlama, gönderimden talebe doğru değişecek.

AI, riski şekillendirmek yerine hesaplayacak. Ayrıca nicel (tarihler, ölçümler) ve nitel (insanların görüşmeleri, PR'lar) verileri içeren raporlamalar oluşturarak daha kapsamlı bir risk profili yaratabileceğiz — ekibin içgüdülerinin kırmızı/sarı/yeşil durumu belirlemesine izin vermek yerine.

Bu, proje yöneticileri için ne anlama geliyor? Sonuç olarak gelecekte "iki kez kontrol edenler" için iş olmayacak. Bu iyi bir şey. İnsanlar otomasyonun kendisi olmamalı. Rapor taslaklarını kendimiz toplamadan otomatik olarak almalıyız. Otomatik bir önceliklendirme olmadan yeni bir sorun veya öğe görmemeliyiz.

Ancak bu, proje yöneticilerinin odaklarını paydaş uyumu ve daha önce bahsettiğim zor kararlar gibi daha değerli, insani çalışmalara kaydırmaları gerektiği anlamına geliyor.

İşte tavsiyem: Araçları benimseyin ama onları kontrol edin. Zor kararların sorumluluğunu üstlenin. Ve paydaşlarınızla konuşun.

Chris'ten

İşte tavsiyem: Araçları benimseyin ama onları kontrol edin. Zor kararların sorumluluğunu üstlenin. Ve paydaşlarınızla konuşun.

Takip edin

Chris Butler'ın çalışmalarını LinkedIn üzerinden takip edebilirsiniz.

The Digital Project Manager'da daha fazla uzman röportajı sizleri bekliyor!