Computer use mu, Playwright mı? Arayüz testinin üç yolu

Bir ajan arayüzü kaç yoldan görebilir?

Kodlama ajanı bir arayüzü değiştirdiğinde iş bitmiyor; değişikliğin gerçekten çalıştığını görmesi gerekiyor. Ajanın kendi işini kontrol ettiği bu döngüyü harness engineering yazısında anlattık. Arayüzde bu kontrolün üç yolu var ve üçü de bugün kodlama araçlarında hazır geliyor:

Computer use’da ajan ekranı bir görüntü olarak görüyor ve fareyle, klavyeyle çalışıyor. Anthropic’in aracı ekran görüntüsü almayı ve fare ile klavye kontrolünü veriyor. Google’ın belgesi de modelin ekranı görüntülerle “gördüğünü”, tıklama ve tuş vuruşu gibi eylemler ürettiğini yazıyor. Bu yol ekranda ne varsa ona ulaşıyor: Google’ın aracı tarayıcıda, mobilde ve masaüstünde çalışıyor.

Browser use’da ajan sayfanın görüntüsüne değil yapısına bakıyor. Anthropic’in browser use aracı sayfayı erişilebilirlik ağacından okuyor: her öğe rolü ve adıyla, yanında [ref_2] gibi bir referansla geliyor ve ajan tıklarken koordinat yerine bu referansı veriyor. Ağacın görmediği yerde, örneğin bir canvas’ta, yine ekran görüntüsüne ve koordinata dönüyor. Playwright MCP de sayfayı ekran görüntüsü yerine bu ağaçtan okuyor. Arama sonuçlarında çıkan açık kaynak Browser Use kütüphanesi ayrı bir proje; bu yazıda “browser use” derken bu yöntemi kastediyoruz.

Kod ve test yolunda ajan tarayıcıyı bir kütüphane üzerinden yönetiyor: bir Playwright testi yazıyor ya da Playwright’ın CLI’ını çağırıyor. Playwright CLI sayfanın verisini modele yüklemiyor; ajan yalnızca komutun çıktısını okuyor. OpenAI’ın computer use rehberi de GPT-6 Astra için kod yolunu öneriyor: model arayüzü yöneten Playwright ya da PyAutoGUI kodu yazıyor, yapılandırılmış computer aracı alternatif olarak kalıyor. Kodun asıl farkı, bir kez yazılınca modelsiz yeniden çalışabilmesi.

Hangisi kaça mal oluyor, ne kadar güvenilir?

Üç yolu üç soruyla karşılaştırdık: bir adım kaç token tutuyor, bir iş ne kadar sürüyor ve iş ne sıklıkla baştan sona bitiyor. Sayıların çoğu sağlayıcıların belgelerinden; benchmark sonuçlarını kimin bildirdiğiyle birlikte verdik.

Ekrandan çalışan ajan her adımda bir ekran görüntüsü okuyor ve görüntü token olarak ücretleniyor. Üç sağlayıcı bu hesabı farklı yapıyor: Anthropic görüntüyü 28 piksellik karelere, OpenAI 32 piksellik karelere bölüp sayıyor; Google ise Gemini 4 ve 3’te boyuttan bağımsız sabit bir sayı kullanıyor. Anthropic’in web uygulamaları için önerdiği 1280×800 çözünürlükte tek bir ekran görüntüsü şöyle tutuyor:

Grafiğin göstermediği şey birikme. Ajan her adımda yeni bir ekran görüntüsü alıyor ve eskileri bağlamda kalıyor. Anthropic’e göre 200K token’lık bir bağlam penceresi 100 ekran görüntüsüne varmadan çok önce doluyor. Bir istekte 20’den fazla görüntü olunca her görüntü daha sıkı bir boyut sınırına giriyor. Anthropic bu yüzden yeni modellerinde ekran görüntülerini kenar başına en fazla 2000 piksele küçültmeyi ve eskilerini sunucu tarafında temizlemeyi öneriyor. Bağlam dolunca ajanın neyi unuttuğunu auto compact yazısında anlattık.

Araç setinin kendi yükü de var. Anthropic’te computer use araç seti her isteğe yaklaşık 4.500, browser use araç seti yaklaşık 6.600 girdi token’ı ekliyor. Bu yük her istekte aynı olduğu için prompt caching burada işe yarıyor. Erişilebilirlik ağacı için tek bir sayı yok, sayfaya göre değişiyor; Anthropic’in belgesi sıradan bir sayfada ağacı okumanın çoğu zaman bir ekran görüntüsünden daha az girdi token’ı tuttuğunu yazıyor. Ağaç da büyüyebiliyor: Playwright’ın ekibi kodlama ajanlarına MCP yerine CLI’ı öneriyor, çünkü CLI büyük araç şemalarını ve uzun erişilebilirlik ağaçlarını modelin bağlamına yüklemiyor.

Süre için sağlayıcılar adım başına bir sayı vermiyor; okuduğumuz belgelerin hiçbirinde eylem başına saniye yazmıyor. Anthropic, computer use’un insanın elle yaptığı işlemlere göre yavaş kalabileceğini yazıyor ve onu hızın önemli olmadığı işlere, örneğin otomatik yazılım testine öneriyor. Görev başına süreyi OpenAI bildiriyor; kendi ölçümüne göre GPT-6 Astra bir OSWorld 2.0 görevini yaklaşık 40 dakikada, GPT-5.6 Sol yaklaşık 75 dakikada bitirdi. Bu görevler uzun: OSWorld 2.0’ın sayfasına göre bir insanın bir görevi bitirmesi yaklaşık 1,6 saat sürüyor (medyan) ve Claude Opus 4.7 bir görevde ortalama 318 araç çağrısı yapıyor; eski OSWorld’de bu sayı yaklaşık 30.

Güvenilirlik için en çok bakılan ölçü OSWorld. Üç sağlayıcı da yeni modellerini OSWorld’ün yeni sürümüyle ölçüp duyurdu, ama her biri farklı bir sürümde ya da alt kümede ölçtü ve hepsi kısmi puan veriyor:

Kaynak: satıcıların kendi duyuruları ve model kartları, 20 Ekim 2026; hepsi satıcının bildirdiği sonuç. Sürüm ve alt küme farklı olduğu için satırlar birbiriyle karşılaştırılamaz. Google’ın model kartları ay veriyor, gün vermiyor.

Kısmi puan, bir görevdeki kontrol noktalarından ne kadarının tuttuğunu ölçüyor; OSWorld 2.0 bir görevi ortalama 27,25 kontrol noktasıyla puanlıyor. Kıyaslamanın kendi ana ölçüsü ise görevin baştan sona bitip bitmediği. İkisi arasındaki fark büyük. OSWorld 2.0’ın kendi tablosunda (15 Ekim güncellemesi, v2.1 sürümü), modelin tek başına çalıştığı koşular arasında en iyi sonuç Claude Opus 5’in en yüksek effort’taki koşusu: kısmi puanı %77,67, görevleri baştan sona bitirme oranı %44,33. Aynı modelin en düşük effort’taki bitirme oranı %18,81.

Tabloda güncel sürümde OpenAI modeli yok; önceki sürümün çevrimdışı alt kümesinde GPT-5.6 Sol en yüksek effort’ta kısmi puanda %64,13, baştan sona bitirmede %28,1 aldı. Gemini modelleri tabloda hiç yok. Yani satıcıların duyurduğu sayılar, ajanın işin büyük kısmını yaptığını söylüyor; işi bitirdiğini söylemiyor. Bir skoru nasıl okuyacağınızı SWE-bench yazısında anlattık.

Ekrandan çalışmanın neden her seferinde aynı sonucu vermediğini sağlayıcılar kendileri yazıyor. GitHub’a göre zamanlamadaki ya da pencerenin durumundaki bir değişiklik farklı bir sonuç doğurabiliyor, ajanın bir eylemi tekrarlamasına ya da takılmasına yol açabiliyor. Anthropic modelin koordinat üretirken hata yapabileceğini, Google beklenmedik açılır pencerelerin ve düzen değişikliklerinin modeli şaşırtabileceğini yazıyor. Erişilebilirlik ağacı bu sorunun bir kısmını çözüyor: Anthropic’e göre bir öğe referansı, piksel koordinatlarını bozan düzen kaymalarından etkilenmiyor. Playwright testinde ise öğe rolü ve adıyla bulunuyor, Playwright beklenen durum oluşana kadar bekliyor ve test her çalışmada aynı adımları aynı sırayla atıyor.

Kaynak: bu bölümde bağlantısı verilen belgeler, 20 Ekim 2026.

Üç sağlayıcı computer use ve browser use için ne sunuyor?

Kendi ajanınızı API üzerinden kuruyorsanız üç sağlayıcının da hazır bir aracı var. Döngü hepsinde aynı: model bir eylem istiyor, sizin kodunuz onu kendi tarayıcınızda ya da sanal makinenizde çalıştırıp sonucu geri veriyor. 20 Ekim 2026 günkü durum:

Kaynak: üç sağlayıcının computer use, browser use ve fiyat belgeleri, 20 Ekim 2026. “Belgesinde yazmıyor”: o gün okuduğumuz sayfalarda bunu anlatan bir cümle bulamadık.

Anthropic’te yakın zamanda bir geçiş oldu. Sürüm notlarına göre computer use 19 Ağustos’ta betadan çıktı ve browser use aracı aynı gün geldi. 22 Eylül’de çıkan Opus 5.5’te eski computer_20251124 aracı Claude API’de ve Google Cloud’da 400 hatası döndürüyor; Sonnet 5.5 ve Haiku 5.5 de eski araçları kabul etmiyor. Yeni araç seti bir turda birkaç eylemi birlikte döndürebiliyor; sizin kodunuz bunları sırayla çalıştırıp ilk hatada durmalı.

OpenAI’da iki yol var. Rehber, modelin tıklama ve yazma gibi eylemler döndürdüğü computer aracını ve modelin Playwright ya da PyAutoGUI kodu yazdığı yolu birlikte anlatıyor. Kod yolunda model tek bir çağrıda birkaç eylemi, bir döngüyü ya da bir koşulu birleştirebiliyor. Rehber, işin sonunda modelin cevabına güvenmek yerine gerçek sonucu kontrol etmenizi de istiyor. 29 Eylül’den beri Agents API de OpenAI’ın barındırdığı bir tarayıcıda computer use sunuyor.

Google’ın aracı önizlemede ve Google önemli işlerde yakın gözetim öneriyor. Model koordinatları 1000×1000’lik bir ızgarada veriyor; sizin kodunuz bunları ekranın boyutuna çeviriyor. Bir eylem riskliyse cevapta require_confirmation geliyor ve kullanıcıya sormanız gerekiyor. Ekran görüntülerinde prompt injection taraması isteğe bağlı ve varsayılan olarak kapalı.

Model seçerken üç satıcı farklı şeyler öneriyor. Google computer use için Gemini 3.8 Flash’ı öneriyor. Anthropic Haiku 5.5’i hızın önemli olduğu browser use işlerine uygun buluyor. Codex’in belgesi ekran görüntüsüne ya da görsel yargıya dayanan zor işler için GPT-6 Astra’yı öneriyor. Modeller arasındaki genel farkları model seçimi yazısında anlattık.

Kodlama ajanları arayüzü nasıl test ediyor?

Beş kodlama aracında da ajanın tarayıcıyı ya da ekranı kullanmasının bir yolu var, ama nerede çalıştığı ve varsayılanları farklı. Tabloyu 20 Ekim 2026 günü her aracın kendi belgesinden okuduk:

Kaynak: her aracın belgesi ve sürüm notları, 20 Ekim 2026. “Belgesinde yazmıyor”: o gün okuduğumuz sayfalarda bunu anlatan bir cümle bulamadık. Copilot’ta computer use 1 Ekim’de önizlemeye çıktı ve varsayılan olarak kapalı.

Gemini CLI’ı hâlâ kullanıyorsanız tarayıcı ajanı varsayılan olarak kapalı; açtığınızda sayfayla erişilebilirlik ağacından çalışıyor. Google, ücretsiz katman ve Google One kullanıcıları için Gemini CLI’ı 18 Haziran 2026’da Antigravity CLI ile değiştirdi; ücretli API anahtarlarıyla Gemini CLI kullanılmaya devam ediyor.

Üç aracın belgesi aynı sırayı öneriyor. Claude Code ekran kontrolünü en geniş ve en yavaş yol sayıyor: önce MCP sunucusunu, sonra Bash’i, sonra Claude in Chrome’u deniyor; ekranı ancak hiçbiri yetmezse kullanıyor. GitHub’a göre bir API, MCP sunucusu, terminal komutu ya da tarayıcı aracı işi yapabiliyorsa, bu araçlar daha yapılandırılmış bilgi ve daha öngörülebilir sonuç veriyor. Codex’in belgesi de yerel bir web uygulaması için önce yerleşik tarayıcıyı, tekrarlanan işler için bir MCP sunucusunu öneriyor.

Bir fark da oturumda. Claude in Chrome tarayıcınızın oturumunu paylaşıyor ve oturum açtığınız her siteye girebiliyor; giriş sayfasında ya da CAPTCHA’da durup size soruyor. VS Code’da ajanın açtığı sayfalar ayrı ve geçici bir oturumda açılıyor. Codex’in yerleşik tarayıcısı ve Antigravity IDE ise sizin profilinizden ayrı bir profil kullanıyor.

Ajana Playwright testi yazdırmak neden çoğu zaman daha iyi?

Ajanın tarayıcıda yaptığı kontrol, oturum bitince kayboluyor. Aynı kontrolü bir Playwright testine çevirirseniz depoda kalıyor ve her pull request’te modelsiz yeniden çalışıyor: token harcamıyor, ekran görüntüsü biriktirmiyor, her seferinde aynı adımları atıyor. VS Code’un belgesi de aynısını öneriyor: tarayıcı araçları oturum içindeki kontrol için; CI’da her seferinde çalışması ya da eski bir hatanın geri dönmesini yakalaması gereken kontroller içinse depoda Playwright ya da başka otomatik testler tutulmalı.

Pratikte iki adımlı bir düzen iyi çalışıyor. Önce ajan tarayıcı aracıyla ya da Playwright MCP ile sayfayı dolaşıyor ve seçicilerin, metinlerin gerçekte ne olduğunu görüyor. Sonra bu akışı bir teste yazıyor, testi çalıştırıp geçtiğini gösteriyor. Playwright bunun için hazır ajanlar da veriyor: Playwright Test Agents uygulamayı gezip test planı çıkaran planner, plandan test yazan generator ve kırılan testleri onaran healer ajanlarından oluşuyor. npx playwright init-agents --loop=claude bu tanımları Claude Code için ekliyor; codex ve vscode seçenekleri de var. Generator seçicileri ve kontrolleri senaryoyu çalıştırırken canlı doğruluyor. Ajanın bir kayıt formu için yazabileceği bir test şöyle:

// Örnek: ajanın yazdığı test, her pull request’te CI’da yeniden çalışır.
import { test, expect } from '@playwright/test';

test('kayıt formu geçersiz e-postayı reddeder', async ({ page }) => {
  await page.goto('/signup');
  await page.getByLabel('E-posta').fill('gecersiz-adres');
  await page.getByRole('button', { name: 'Kayıt ol' }).click();
  await expect(page.getByText('Geçerli bir e-posta girin')).toBeVisible();
  await expect(page).toHaveScreenshot('signup-hata.png');
});

Testte iki tür kontrol var. toBeVisible davranışa bakıyor: hata mesajı çıkıyor mu? toHaveScreenshot görünüme bakıyor: sayfa, depodaki referans görüntüyle piksel piksel karşılaştırılıyor. Playwright’a göre işletim sistemi, tarayıcı sürümü ve donanım bile görüntüyü değiştirebiliyor; bu yüzden referans görüntüyü testin çalışacağı ortamda üretin. Sayfanın yapısını görüntü yerine erişilebilirlik ağacıyla karşılaştırmak isterseniz toMatchAriaSnapshot var.

Test kırıldığında ajanın nedenini görebilmesi için ona kanıt bırakın. Aşağıdaki ayar her başarısız testte bir ekran görüntüsü, CI’daki ilk yeniden denemede de bir trace kaydediyor; trace’te testin her adımında ne olduğunu ileri geri gezerek görebiliyorsunuz. Dosyalar test çıktı klasörüne, genellikle test-results’a düşüyor; ajana hatayı düzeltirken önce oraya bakmasını söyleyin.

// Örnek: kırılan testten kanıt bırakan ayar.
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: 'http://localhost:3000',
    screenshot: 'only-on-failure',
    trace: 'on-first-retry',
  },
});

Ekran görüntüsüne dayanan kontrol şu işlerde hâlâ gerekli: düzen kayması, renk ya da hizalama hatası, bir canvas’a çizilen grafik ya da harita. Anthropic’in belgesi de canvas’ı, gömülü videoyu ve uzak masaüstü yüzeylerini ağacın göremediği yerler arasında sayıyor. Böyle bir hatayı bulmak için ajanın bir kez ekran görüntüsüne bakması yetiyor; geri gelmemesi için toHaveScreenshot ile bir test yazdırın.

Hangi iş için hangi yolu seçmeli?

Kanıtların hepsi aynı sıraya çıkıyor: işi kodla yapabiliyorsanız kodla, sayfa tarayıcıdaysa ağaçla, başka kapı yoksa ekranla. Sık karşılaşılan işler için:

Kartların gerekçeleri yukarıda. Web arayüzünü doğrulamak için test, çünkü test CI’da modelsiz ve her seferinde aynı adımlarla çalışıyor. Tek seferlik bir kontrol için tarayıcı aracı, çünkü ağacı okumak çoğu zaman bir ekran görüntüsünden ucuz ve referans düzen kaymasından etkilenmiyor. Computer use’u API’si, CLI’ı ya da MCP sunucusu olmayan uygulamalara saklayın; GitHub da onu bu tür uygulamalar için tanıtıyor.

Ödeme, şifre ve hesap değişikliği gibi işlerde üç sağlayıcı da aynı şeyi söylüyor: son adımı bir insan onaylasın. Anthropic çerezleri kabul etmek, para işlemi yapmak ya da kullanım koşullarını onaylamak gibi kararlarda insan onayı öneriyor. OpenAI bir forma hassas bilgi yazmayı bile veri gönderimi sayıyor. Google’ın örnek talimatı modelden CAPTCHA’yı asla çözmeye çalışmamasını istiyor. Ajanı ayrı bir sanal makinede ya da ayrı bir tarayıcı profiliyle çalıştırın ve gidebileceği siteleri bir izin listesiyle sınırlayın. Sayfadaki bir metnin ajanı nasıl yönlendirebileceğini MCP güvenliği yazısında anlattık.

diffox, bir yapay zekâ kod inceleme aracı olarak pull request’i git ile okuyor; arayüzü açmıyor, ekran görüntüsü almıyor. Bu yüzden ajanın arayüz için yazdığı test pull request’te iki işe yarıyor: CI arayüzün çalıştığını gösteriyor, incelemede de testin neyi sınadığı diff’te okunabiliyor. Geçen bir testin her zaman bir şey sınamadığını yapay zekânın yazdığı kodu inceleme yazısında anlattık.