Bir Prompt Değil, Bitmiş İş: Claude Cowork’a Ne Devredilir?

Claude’dan iyi yazılmış bir özet istemek kolaydır. Bilgisayarınızdaki dağınık sözleşmeleri bulmasını, yenileme tarihlerini karşılaştırmasını, eksik bilgileri işaretlemesini ve kontrol edilebilir bir takip tablosu teslim etmesini istemek ise başka türden bir iştir. İlkinde cevap alırsınız. İkincisinde kaynakları, ara adımları, dosyaları ve bitiş ölçütü olan bir işi devredersiniz.

Claude Cowork’u anlamanın en yararlı yolu, onu uzun bir özellik listesi olarak görmek değildir. Cowork; kaynaklara erişim, çok adımlı dönüşüm, araç kullanımı, somut teslimat ve insan denetimi arasında çalışan bir iş katmanıdır. Bu nedenle doğru başlangıç sorusu “Cowork neler yapabiliyor?” değil, “Benim işlerimden hangisi açıkça tanımlanabilir, güvenli biçimde yürütülebilir ve sonunda sınanabilir?” olmalıdır.

Bu yazıda o ayrımı kuracağız. Önce sohbet ile iş devri arasındaki farkı netleştirecek, ardından Cowork’a uygun görevler için dört koşullu bir karar modeli geliştireceğiz. Sonra örnek bir şirketin sözleşme klasöründen yenileme ve risk takip tablosu çıkaran pilotu baştan sona tasarlayacağız. Amacımız etkileyici bir gösteri değil; tekrarlandığında da çalışan, hatası görünür ve teslimatı ölçülebilir bir sistem kurmak.

Cevap almak ile iş teslim almak aynı şey değildir

Bir sohbet arayüzünde “Bu sözleşmeyi özetle” dediğinizde temel alışveriş basittir: Bir belge verirsiniz, karşılığında bir metin alırsınız. Çıktıyı okuyup yeterli bulursanız konuşma sona erer. Fakat gerçek bilgi işi genellikle tek bir belgeye veya tek bir cevaba sığmaz.

Örneğin satın alma sorumlusu, önümüzdeki doksan gün içinde işlem gerektiren tedarikçi sözleşmelerini görmek isteyebilir. Bunun için farklı klasörlerdeki PDF ve Word dosyalarının bulunması, her belgeden tarafların ve tarihlerin çıkarılması, ek protokollerin ana sözleşmeyle ilişkilendirilmesi, otomatik yenileme ve bildirim hükümlerinin birlikte okunması, para birimlerinin korunması, belirsizliklerin işaretlenmesi ve sonuçların bir tabloya yazılması gerekir. Belki yönetici için ayrıca bir sayfalık karar notu hazırlanacaktır.

Burada “iyi cevap” yetersiz bir başarı tanımıdır. İşin tamamlanması için en az dört ayrı koşulun sağlanması gerekir:

• Doğru kaynaklar kapsam içine alınmıştır.
• Kaynaklar arasında tanımlı bir dönüşüm uygulanmıştır.
• Kullanılabilir bir dosya veya çalışma yüzeyi teslim edilmiştir.
• Sonucun kabul edilip edilmeyeceğini belirleyen testler vardır.

Bu ayrım önemlidir; çünkü akıcı bir açıklama, eksik bir klasörü taradığını veya yanlış tarihi seçtiğini gizleyebilir. Bir iş sistemi ise yalnızca sonuç üretmez, sonucun nereden geldiğini ve hangi kuralla sınıflandırıldığını da görünür kılar.

Hangi yüzey hangi işe uygun?

Claude’un sohbet, Cowork ve Claude Code gibi farklı çalışma yüzeyleri birbirinin daha güçlü veya daha zayıf sürümleri olarak düşünülmemelidir. Bunlar farklı iş şekillerine uygundur. Sınırı belirlemek için görevin ağırlık merkezine bakabiliriz.

Bu bir duvar değil, başlangıç kuralıdır. Bir yazılım projesinde karar notu hazırlanabilir veya Cowork içindeki bir görev teknik dosyalara dokunabilir. Yine de şu karar sorusu iş görür:

İstenen değer esas olarak konuşmanın içindeki cevaptan mı, bilgisayardaki kaynaklarda yapılan denetlenebilir bir değişimden mi, yoksa kod tabanında doğrulanan teknik bir sonuçtan mı geliyor?

Yanıt konuşmaysa sohbeti, dosyalar arası bilgi işiyse Cowork’u, kod ve test döngüsüyse Claude Code’u başlangıç noktası olarak seçebilirsiniz.

Cowork’a uygun görevin dört koşulu

Her zahmetli iş ajana devredilmeye uygun değildir. Bazı işler çok belirsizdir; bazıları geri alınamayacak kadar risklidir; bazılarında ise otomasyonu tarif etmek, işi elle yapmaktan uzun sürer. Uygun adayları ayırmak için “kaynak → dönüşüm → teslimat → kabul testi” zincirini kullanabiliriz.

1. Kaynaklar erişilebilir ve sınırlanabilir olmalı

Görevin beslendiği malzemeler tanımlanabilmelidir: belirli bir klasör, bir proje, seçilmiş belgeler veya izin verilmiş bir araç. “Şirketteki her şeyi incele” kötü bir kapsamdır. “Satın Alma/Sözleşmeler/2026 klasöründeki ana sözleşmeleri ve bunlara ait ek protokolleri incele” daha güvenlidir.

Kaynağı tanımlamak yalnızca erişim vermek değildir. Öncelik de belirtmek gerekir. Ana sözleşme ile sonradan imzalanan ek protokol çelişiyorsa hangisi esas alınacak? Dosya adı ile belge içeriğindeki tarih farklıysa ne yapılacak? Kaynak hiyerarşisi açıklanmazsa sistem boşluğu tahminle doldurabilir.

Karar kuralı: Güvenilir kaynağın nerede olduğunu ve çelişki halinde hangi belgenin üstün olduğunu tek paragrafta anlatamıyorsanız görevi henüz devretmeyin.

2. İş birden fazla tanımlı dönüşüm içermeli

Cowork’un değeri yalnızca bir metin üretmesinden değil, adımlar arasında ilerlemesinden gelir. Sözleşmeleri listelemek, alanları çıkarmak, tarihleri karşılaştırmak, riskleri sınıflandırmak ve tablo oluşturmak böyle bir zincirdir.

Fakat “çok adımlı” olmak, sınırsız serbestlik anlamına gelmez. Dönüşüm kuralları mümkün olduğunca açık olmalıdır. Sözleşme yenilemelerinde yalnızca bitiş tarihine bakmak yanıltıcıdır. Otomatik yenilemeyi önlemek için sözleşmede belirli bir bildirim süresi varsa operasyonel eşik, bitiş tarihi değil son bildirim tarihidir. Bu tarih, bitiş tarihinden bildirim süresinin çıkarılmasıyla hesaplanır.

28 Temmuz 2026 referans tarihi için örnek sınıflandırma şöyle kurulabilir:

• Son bildirim tarihi geçmişse: Süre geçti / Aciliyet kritik.
• Son bildirim tarihine 0–30 gün kaldıysa: Yüksek.
• Son bildirim tarihine 31–90 gün kaldıysa: Orta.
• Son bildirim tarihine 91 gün veya daha fazla kaldıysa: Düşük.
• Otomatik yenileme, bitiş tarihi veya bildirim süresi belirlenemiyorsa: İnceleme gerekli.
• Sözleşmede otomatik yenileme yoksa bu risk modeli uygulanmaz; kayıt Otomatik yenileme yok / Bitiş takibi durumuna alınır ve bitiş tarihine göre ayrı bir iş akışı izlenir.

Bu ayrım küçük görünse de kararı değiştirir. Bitişine iki ay kalan bir sözleşmenin bildirim penceresi üç hafta sonra kapanabilir. Buna karşılık otomatik yenilenmeyen bir sözleşmeye, yalnızca bitiş tarihi yaklaşıyor diye “bildirim süresi kaçıyor” etiketi vermek yanlış olur. Kural, sözleşmede gerçekten bulunan hükme dayanmalıdır.

3. Somut teslimat tanımlanmalı

“Belgeleri incele” bir faaliyet tarifidir; teslimat değildir. “Her sözleşme için kaynak dosya, taraflar, bitiş tarihi, otomatik yenileme hükmü, bildirim süresi, hesaplanan son bildirim tarihi, son bildirim tarihine kalan veya bu tarihten geçen gün sayısı, yıllık bedel, risk sınıfı ve not sütunlarını içeren bir tablo hazırla” ise teslimatı tanımlar.

Çıktının biçimi, hedef kullanıcının vereceği karara göre seçilmelidir. Operasyon ekibi filtrelenebilir bir tablo isterken yönetici kısa bir karar notuna ihtiyaç duyabilir. Aynı görev iki teslimat üretebilir:

1. Takip tablosu: ayrıntılı çalışma ve güncelleme yüzeyi.
2. Karar notu: son bildirim tarihi geçmiş veya önümüzdeki 30 gün içinde dolacak kayıtların kısa özeti.

Uygulama sorusu: Sistem görevi bitirdiğinde hangi dosyayı açacak, hangi alanlara bakacak ve hangi kararı vereceksiniz? Cevap belirsizse çıktı da belirsiz kalır.

4. Doğrulanabilir bir bitiş olmalı

“Eksiksiz ve doğru yap” kabul testi değildir. Kabul testi, teslimat üzerinde gözlenebilen koşullardan oluşur. Örneğin:

• Kapsamdaki her ana sözleşme tabloda tam bir satırla temsil edilmiştir.
• Her satırda kaynak dosya adı ve ilgili hükmün bulunduğu sayfa vardır.
• Otomatik yenileme bulunan her kayıtta bitiş tarihi, bildirim süresi ve hesaplanan son bildirim tarihi birbiriyle tutarlıdır.
• Son bildirim tarihine kalan veya bu tarihten geçen gün sayısı, 28 Temmuz 2026 referans tarihine göre doğru hesaplanmıştır.
• Belgede bulunmayan alanlar “Bulunamadı” olarak işaretlenmiştir; tahmin kullanılmamıştır.
• “Süre geçti / Aciliyet kritik” ve “Yüksek” durumundaki her kayıtta önerilen sonraki adım vardır.
• Otomatik yenileme bulunmayan kayıtlar, bildirim süresi risk modeline sokulmadan “Bitiş takibi” olarak ayrılmıştır.
• Toplam satır sayısı ile işlenen ana sözleşme sayısı aynıdır.
• Rastgele seçilen üç satır, kaynak belgelerle insan tarafından karşılaştırılmıştır.

Bu koşullar yalnızca hatayı yakalamaz. “Bitti” kelimesinin anlamını kullanıcı ile sistem arasında ortaklaştırır.

Doldurulmuş örnek: Sözleşme klasöründen risk takip tablosu

Şimdi çerçeveyi gerçekçi bir pilotta kullanalım. Hayalî Ardıç Mobilya’nın satın alma ekibinde 18 tedarikçiye ait 24 dosya bulunuyor. Bazıları ana sözleşme, bazıları fiyat veya süreyi değiştiren ek protokol. Ekip, 28 Temmuz 2026 itibarıyla yaklaşan yenilemeleri ve kaçırılmış bildirim tarihlerini görmek istiyor.

İlk denemede bütün kurumsal depoyu açmak yerine yalnızca kopyalanmış bir pilot klasör kullanılıyor. Klasörde altı tedarikçiye ait sekiz belge var. Sistem dosyaları okuyabilir ve yeni çıktı dosyaları oluşturabilir; fakat kaynak belgeleri değiştiremez, silemez, e-posta gönderemez veya bir sözleşme yenilemesini başlatamaz.

Görev sözleşmesi şöyle yazılabilir:

AMAÇ
28 Temmuz 2026 referans tarihiyle kaçırılmış veya yaklaşan son bildirim
tarihlerini ve eksik bilgileri gösteren bir takip tablosu hazırlamak.

KAYNAKLAR
Yalnızca “Pilot-Sözleşmeler” klasöründeki 8 dosyayı kullan.
İmzalı ek protokol, çelişen alanlarda daha eski ana sözleşmeye üstündür.
Taslak veya imzasız belgeleri karar kaynağı yapma; ayrı not olarak göster.

DÖNÜŞÜM
Her tedarikçi için ana sözleşme ile ilgili ek protokolleri eşleştir.
Tarafları, başlangıç ve bitiş tarihlerini, otomatik yenileme hükmünü,
bildirim süresini, para birimini ve yıllık bedeli çıkar.
Tarih veya hüküm yoksa tahmin etme; “Bulunamadı” yaz.

Otomatik yenileme varsa son bildirim tarihini şu formülle hesapla:
son bildirim tarihi = bitiş tarihi − bildirim süresi.
28 Temmuz 2026 ile son bildirim tarihi arasındaki takvim günü farkını yaz.
Risk sınıfını son bildirim tarihine göre ata:
- Tarih geçmişse: Süre geçti / Aciliyet kritik.
- 0–30 gün kaldıysa: Yüksek.
- 31–90 gün kaldıysa: Orta.
- 91+ gün kaldıysa: Düşük.
- Hesap için gereken hüküm veya tarih bulunamıyorsa: İnceleme gerekli.
Otomatik yenileme yoksa son bildirim riski hesaplama;
“Otomatik yenileme yok / Bitiş takibi” olarak işaretle.

TESLİMAT
“sozlesme-yenileme-pilotu.xlsx” adlı bir tablo ve
“yenileme-karar-notu.docx” adlı en fazla bir sayfalık özet hazırla.
Tabloda kaynak dosya adı ve ilgili hükmün bulunduğu sayfa da yer alsın.
Karar notunda önce “Süre geçti / Aciliyet kritik”, ardından “Yüksek”
kayıtları göster; otomatik yenilenmeyenleri ayrı başlıkta listele.
Kaynak belgelerde hiçbir değişiklik yapma.

KABUL ÖLÇÜTLERİ
6 tedarikçinin tamamı tabloda yer almalı.
Her satır bir kaynak dosyaya ve ilgili hükmün sayfasına izlenebilmeli.
Otomatik yenilenen her kayıtta bitiş tarihi, bildirim süresi,
son bildirim tarihi ve gün farkı aritmetik olarak tutarlı olmalı.
Bulunmayan bilgi açıkça işaretlenmeli.
“Süre geçti / Aciliyet kritik” ve “Yüksek” durumundaki her kayıt için
önerilen sonraki adım bulunmalı.
Teslimat sonunda işlenen, atlanan ve belirsiz dosyaların sayısını raporla.

DURMA KURALI
İmzalı iki belge arasında çözülemeyen çelişki varsa karar verme.
Kaydı “İnsan incelemesi gerekli” olarak işaretle ve devam et.

Bu görev tanımında birkaç bilinçli tercih var. Birincisi, “en güncel görünen dosyayı kullan” gibi sezgisel bir kural yerine imzalı ek protokole öncelik veriliyor. İkincisi, bilinmeyen alanların doldurulması yasaklanıyor. Üçüncüsü, risk sözleşmenin bitiş tarihine değil, otomatik yenilemeyi durdurmak için harekete geçilebilecek son tarihe bağlanıyor. Dördüncüsü, sistemin eylem alanı dosya üretmekle sınırlandırılıyor; tedarikçiye yazmak veya yenileme kararı almak insanın işi olarak kalıyor.

Ortaya çıkan örnek tablonun bir bölümü şöyle olabilir:

Tablodaki sayılar örneğin karar mantığını göstermek içindir; gerçek bir çalışmada doğrudan kaynak belgelerden alınmalıdır. Kuzey Kumaş kaydında 15 Ağustos 2026 bitiş tarihinden 30 takvim günü çıkarıldığında son bildirim tarihi 16 Temmuz 2026 olur. 28 Temmuz’da bu tarih 12 gün geçmiştir. Bu nedenle kayıt yalnızca “Yüksek” değildir; olası otomatik yenileme açısından “Süre geçti / Aciliyet kritik” durumundadır. Sonraki adım, sistemin geç kalmış bir bildirimin sonucunu tahmin etmesi değil, insanın sözleşmeyi ve hukuki seçenekleri derhal incelemesidir.

Mavi Lojistik kaydında ise 30 Eylül 2026’dan 45 takvim günü çıkarıldığında son bildirim tarihi 16 Ağustos 2026 olur. Referans tarihi olan 28 Temmuz’dan bu tarihe 19 gün kaldığı için kayıt Yüksek sınıfındadır. Bitişe 64 gün kalmış olması onu “Orta” yapmaz; operasyonel karar penceresi 19 gün sonra kapanmaktadır. Sayısal sınıflandırmanın değeri tam burada ortaya çıkar: Etiket, hangi işin bugün başlaması gerektiğini değiştirir.

Karar notunun üst bölümü de aynı mantığı izlemelidir: önce son bildirim tarihi geçmiş Kuzey Kumaş, ardından 30 gün içinde işlem isteyen Mavi Lojistik gösterilir. Meşe Ambalaj ise tarih tahmin edilmeden “İnceleme gerekli” bölümüne alınır. Böylece tablo ile yönetici özeti farklı kurallar üretmez.

Eksik veri davranışı neden baştan yazılmalı?

Bilgi işindeki tehlikeli hataların bir bölümü açıkça yanlış sonuçlardan değil, belirsizliğin görünmez hâle gelmesinden doğar. Bir tarih bulunamadığında makul görünen başka bir tarihin seçilmesi tabloyu daha tamamlanmış gösterir; fakat karar kalitesini düşürür.

Bu nedenle görev tanımında dört ayrı durumu ayırmak yararlıdır:

• Bulundu: Bilgi yetkili kaynakta açıkça yer alıyor.
• Bulunamadı: İncelenen kaynaklarda alan yok.
• Çelişkili: İki geçerli kaynak farklı değerler veriyor.
• Okunamadı: Dosya biçimi, tarama kalitesi veya erişim sorunu nedeniyle bilgi çıkarılamıyor.

Bu sınıflar aynı şey değildir. “Bulunamadı” belge sahibine soru sormayı, “Çelişkili” hukuk veya satın alma incelemesini, “Okunamadı” ise teknik bir yeniden tarama adımını gerektirebilir. Tek bir “eksik” etiketi bu farklı iş akışlarını birbirine karıştırır.

Aynı dikkat, otomatik yenileme hükmüne de uygulanmalıdır. Hüküm bulunamadığında sistem “otomatik yenileme yok” sonucuna atlamamalıdır. “Yok” ile “bulunamadı” farklı durumlardır: İlki kaynakta açık bir hükme, ikincisi ise bilgi eksikliğine işaret eder.

Yetkiyi teslimattan daha geniş vermeyin

Cowork bilgisayar ve bağlantılı araçlarla çalışabildiğinde, görev tanımının yanında bir yetki tasarımı da gerekir. Basit ilke şudur: Sistemin yetkisi, kabul edilen teslimatı üretmek için gereken en dar alanla sınırlı olmalıdır.

Sözleşme pilotunda gerekli yetki kaynak klasörü okumak ve çıktı klasörüne iki yeni dosya yazmaktır. E-posta göndermek, sözleşme dosyalarını yeniden adlandırmak, takvim etkinliği oluşturmak veya tedarikçi portalına girmek ilk pilot için gereksizdir. Bunlar ileride ayrı bir görev olarak değerlendirilebilir; fakat dosya inceleme pilotuna sessizce eklenmemelidir.

Web veya mobil üzerinden uzaktan görev vermek erişimi kolaylaştırır; bilgisayarda yürütülen işin riskini kendiliğinden azaltmaz. Uzaktan başlatılan bir görevde de aynı sorular geçerlidir: Hangi cihaz çalışıyor? Hangi klasörler açık? Hangi eylemler için onay gerekiyor? Kullanıcı canlı faaliyeti nereden görecek? Beklenmeyen davranışta görev nasıl durdurulacak?

Özellikle kaynak silme, dışarıya mesaj gönderme, satın alma yapma veya kayıt değiştirme gibi etkisi zor geri alınan işlemleri ayrı bir onay kapısının arkasında tutmak gerekir. İlk pilotun hedefi özerklik gösterisi değil, güvenilir teslimat kanıtıdır.

Pilotu nasıl değerlendireceğiz?

Pilotun başarılı olup olmadığını yalnızca “dosya oluştu mu?” diye ölçersek sistemin gerçek maliyetini göremeyiz. Dört ölçü birlikte izlenmelidir.

Bu değerler gerçek ürün performansı iddiası değil, yöntemin nasıl ölçüleceğini gösteren doldurulmuş örneklerdir. Kendi pilotunuzda başlangıç karşılaştırmasını mutlaka kaydedin. Elle yapılan iş 25 dakika sürüyorsa 20 dakikalık görev hazırlığı ve 15 dakikalık kontrol anlamlı olmayabilir. Buna karşılık iş her hafta tekrarlanıyor, çok sayıda dosya içeriyor ve kaynak izi denetimi hızlandırıyorsa küçük bir ilk yatırım hızla değer kazanabilir.

İlk pilot için makul kabul kararı şöyle yazılabilir:

Görev ikinci kez çalıştırıldığında kapsamın tamamını işler, otomatik yenileme bulunan bütün kayıtlarda son bildirim tarihini doğru hesaplar, kritik alanların tümünü kaynağa bağlar ve insanın düzeltme süresi toplam sürenin üçte birini aşmazsa süreç genişletilecek. Geçmiş son bildirim tarihleri sıradan yaklaşan tarihler gibi sınıflandırılırsa, çözülemeyen çelişkiler tahminle kapatılırsa, kaynak belgeler değişirse veya dış eylem onaysız başlatılırsa pilot durdurulacak.

Burada ölçüler evrensel eşikler değildir. Ekibin riskine ve işin değerine göre değiştirilmelidir. Önemli olan başarı ile durma koşulunu çalıştırmadan önce belirlemektir.

Tek seferlik görevden çalışma sistemine geçmek

Başarılı bir pilot hemen tam otomasyon anlamına gelmez. Önce görev tanımı saklanır, kaynak yapısı standartlaştırılır ve kabul sonuçları kaydedilir. Aynı iş tekrarlanacaksa bir proje içinde ilgili bağlamı, dosyaları ve talimatları bir arada tutmak görevler arasındaki tutarlılığı artırabilir. Zamanlanmış görevler ise ancak kaynakların ne zaman güncellendiği ve eski veriyle çalışıldığında ne yapılacağı tanımlandıktan sonra anlamlıdır.

Örneğin sözleşme tablosu her pazartesi yenilenecekse sistem yalnızca program saatini değil, referans tarihini ve veri tazeliğini de denetlemelidir. Son bildirim tarihine kalan gün sayısı her çalıştırmada yeni referans tarihine göre yeniden hesaplanmalıdır. “Son yedi günde değişen dosya yoksa kaynak alanlarını yeniden çıkarma; ancak kalan gün sayılarını ve risk durumlarını güncelle” kuralı hem gereksiz işlemi azaltır hem de eski bir risk etiketinin yeniymiş gibi görünmesini önler.

Kurumsal kullanımda bir başka katman gözlemlenebilirliktir. Görevin ne zaman başladığı, ne kadar sürdüğü, hangi araçları kullandığı ve nerede hata verdiği izlenebilirse tek bir teslimatın ötesinde sistem davranışı değerlendirilebilir. Bu kayıtlar içeriğin doğru olduğunu tek başına kanıtlamaz; fakat tekrar eden hata, olağandışı süre veya beklenmeyen araç kullanımını görünür kılar.

Yarın deneyebileceğiniz küçük pilot

Başlangıç için yüksek riskli ve bütün kurumu kapsayan bir süreç seçmeyin. Her hafta yaptığınız, kaynakları belirli ve çıktısı kolay denetlenebilir bir işi bulun. Örneğin beş toplantı notundan karar ve sorumlu tablosu çıkarmak, on ürün belgesinden karşılaştırma matrisi oluşturmak veya altı sözleşmeden yenileme takvimi hazırlamak uygun olabilir.

1. Kaynakları ayrı bir pilot klasöre kopyalayın ve kapsam sayısını yazın.
2. Dönüşüm kurallarını, özellikle çelişki ve eksik veri davranışını tanımlayın.
3. Bir referans tarihi belirleyin; türetilen bütün tarihleri ve gün farklarını bu tarihe bağlayın.
4. Kararı gerçekten değiştiren tarihi seçin. Sözleşme örneğinde bu, otomatik yenileme varsa bitiş tarihi değil son bildirim tarihidir.
5. Dosya adı, biçim, sütunlar ve hedef okuyucuyla birlikte teslimatı tarif edin.
6. Üç ila altı gözlenebilir kabul testi yazın.
7. Yalnızca gerekli okuma ve yazma yetkilerini açın.
8. Sonuçtan rastgele örnekler seçip kaynaklarla ve tarih hesaplarıyla karşılaştırın.
9. Toplam insan süresini, düzeltme yükünü ve tekrar çalıştırma kolaylığını kaydedin.

Cowork’a devredilecek iyi iş, yalnızca zahmetli olan iş değildir. Sınırları çizilebilen, ara adımları tarif edilebilen, somut bir ürünle biten ve doğruluğu kanıtlanabilen iştir. Bu dört özellik yoksa daha uzun bir prompt yazmak çoğu zaman sorunu çözmez. Önce işi tasarlamak gerekir.

İlk adımınız, bütün iş akışını otomatikleştirmek değil, tek bir teslimatı sözleşmeye bağlamak olsun: Kaynak nedir, hangi dönüşüm uygulanacak, ne teslim edilecek ve neye bakarak “kabul” diyeceksiniz? Ardından örnekteki gibi tek bir kritik hesabı elle doğrulayın: bitiş tarihi eksi bildirim süresi gerçekten gösterilen son bildirim tarihini veriyor mu? Bu sorulara net cevap verdiğinizde Cowork bir sohbet kutusundan çıkar; denetlenebilir bir çalışma sisteminin parçasına dönüşür.

Kaynaklar

• The Claude Cowork product guide
• Claude Cowork is coming to mobile and web
• Use Claude Cowork on web, desktop, and mobile
• Schedule recurring tasks in Claude Cowork
• Organize your tasks with projects in Claude Cowork
• Monitor Claude Cowork activity with OpenTelemetry
• Use Claude Cowork safely