Claude'a bir uygulama verdim ve ondan dört farklı kıdemli geliştirici gibi davranmasını istedim; işte olanlar.

Özellikle X platformunda, chatbot'ları daha etkili hale getirdiği iddia edilen birçok iddia internette yaygın. Yapay zeka eğitimi uzmanı David Max'in bir dizi iddiasıyla ilk karşılaştığımda şüpheciydim ve bu da onları denemeye karar vermeme neden oldu. Bu iddialar, Claude'u kıdemli bir hata ayıklayıcıdan performans uzmanına kadar her şeye dönüştüreceğini öne sürüyor. Araştırmaya karar verdiğimde neler olduğunu aşağıda bulabilirsiniz. Daha etkili iddialarla ilgileniyorsanız, fikirlerinizi geliştirmek ve verimliliğinizi artırmak için 7 etkili Claude 4 iddiasına göz atabilirsiniz.

Claude'un ev gideri takip aracımı inceleyin.

ChatGPT Work kullanarak gider yer tutucuları içeren genel bir gider takip sistemi zaten oluşturmuştum, bu yüzden onu kullandım ve ardından Claude'dan uygulamayı dört kez incelemesini istedim. Her seferinde ona farklı bir ana mühendislik rolü atadım: tam yığın mühendisi, hata ayıklama mühendisi, ön uç mühendisi ve performans mühendisi.

Sonuç, Claude'dan sadece "uygulamayı geliştirmesini" istemekten çok daha açıklayıcıydı. Her karakter farklı bir dizi soruna odaklandı ve bazen önceki "geliştiricinin" gözden kaçırdığı sorunları bile ortaya çıkardı. İşte olanlar ve kullandıkları iddialar.

1. Uygulamayı kıdemli Full-Stack mühendisi geliştirdi.

Her şey Claude'un herkesin kullanabileceği etkileşimli bir ev gideri takip uygulaması oluşturma isteğiyle başladı. Claude'un uygulama geliştirme yetenekleri hakkında daha fazla bilgi için " Claude ve Gemini kullanarak dakikalar içinde 3 uygulama geliştirdim: ancak bunlardan birinin gizli bir özelliği var ." başlıklı yazıyı okuyun.

Görev: Herkesin harcamalarını kaydetmek ve anlamak için kullanabileceği etkileşimli bir ev gideri takip uygulaması oluşturmak. Bu uygulama, gider ekleme ve silme, kategori atama, işlemleri filtreleme, toplam harcamayı hesaplama ve kategorilerin görsel dökümünü görüntüleme özelliklerini içermelidir.

Kendinizi, bir girişim için kusursuz bir MVP geliştiren kıdemli bir tam yığın geliştirici olarak düşünün. Herhangi bir kod yazmadan önce, mimari, veri yapısı ve kullanıcı akışı hakkında kısa bir özet verin. Ardından uygulamayı bir Bulut Yapıtı olarak oluşturun.

Kodun duyarlı ve kullanımı kolay olmasını sağlayın, ancak son kodun incelenmesi, hata ayıklanması veya iyileştirilmesi için ekstra zaman harcamayın. Bu görevleri diğer geliştiricilere devredeceğim.

Claude, şaşırtıcı derecede kusursuz bir React uygulaması oluşturdu. Uygulama, örnek işlemler, harcama toplamları, kategori sıralamaları, arama ve filtreleme işlevleri ve işlemleri tarihe göre sıralama özelliği içeriyordu. Ayrıca, yapılan değişiklikleri kaydederek uygulamayı yeniden açtıktan sonra da kullanılabilir kalmasını sağlıyordu.

İlk bakışta, tamamlanmamış bir prototipten çok bitmiş bir ürüne benziyordu. Üstte istatistik kartları, temiz bir gider formu ve her kategoride ne kadar harcandığını gösteren renkli çubuklar vardı.

2. Kıdemli hata ayıklama mühendisi bazı sorunlar tespit etti.

Bundan sonra Claude'dan görünüşü görmezden gelmesini ve bir uygulamanın piyasaya sürülmesi için hazırlık yapan bir hata ayıklama mühendisi olarak kendi işine odaklanmasını rica ettim.

Talep şu: Şimdi, uygulamanın halka açık sürümünden önce görevi devralan baş hata ayıklayıcı gibi davranın.

Uygulamayı ve mevcut kodunu, amaçlanan işlevselliğini veya görsel tasarımını değiştirmeden dikkatlice inceleyin. Ana kullanıcı akışlarını test edin ve işlevsel hataları, geçersiz girdi işlemeyi, veri kaybı risklerini, yanlış hesaplamaları, kalıcılık sorunlarını ve uç durumları arayın.

Kodu değiştirmeden önce, test ettiğiniz şeyleri, bulduğunuz her sorunu, her sorunun temel nedenini, her sorunun ciddiyetini ve önerdiğiniz çözümü içeren kısa bir hata ayıklama raporu sağlayın.

Ardından onarımları gerçekleştirin ve orijinal özelliklerin hala işlevsel olup olmadığını doğrulayın. Cepheyi yeniden tasarlamayın, daha geniş kapsamlı bir mimari tadilat yapmayın veya tamamen kozmetik değişiklikler yapmayın.

Hata ayıklama süreci birçok gerçek sorunu ortaya çıkardı.

Örneğin, orijinal giriş düzgün bir biçimde değildi. "İşlemi Kaydet" düğmesine tıklamak işe yarıyordu, ancak Enter tuşuna basmak işe yaramayabilirdi. Claude, bu bölümü bir gönder düğmesi içeren düzgün bir forma dönüştürerek bunu düzeltti.

Ayrıca, kullanıcıların geçmişi temizleyip geçersiz tarih bilgileriyle işlem kaydedebildiklerini de keşfetti. Claude, tarih doğrulamasını ekledi, geçersiz tutarlar için kontrolleri güçlendirdi ve takip listesi boş olsa bile "Konut"un en büyük kategori olarak görünmesine neden olan bir hesaplama hatasını düzeltti.

İşlemleri tek bir tıklamayla kalıcı olarak silmek hala mümkündü. Depolama hataları geliştirici konsolunda gizli kalıyordu, bu da kullanıcıların bilgilerinin kaydedildiğini düşünebileceği anlamına geliyordu, oysa kaydedilmemişti. Dahası, Claude düzeltmelerinin işe yaradığını doğrulamak için otomatik testler uygulamamıştı.

3. Tecrübeli ön uç geliştiricisi tamamen farklı bir uygulama fark etti.

Üçüncü turda, Claude'dan gider takip aracını, duyarlı tasarım ve erişilebilirlik konusunda uzmanlaşmış bir ön uç geliştirici gibi ele almasını istedim.

Talep: Erişilebilir ve duyarlı tüketici uygulamalarında uzmanlaşmış deneyimli bir ön uç geliştiricisi gibi hemen harekete geçin.

Mevcut gider takip aracınızı, onu telefonda, klavyede veya yardımcı teknolojide kullanan birinin bakış açısından gözden geçirin. İşlevselliğini ve genel görsel kimliğini koruyun, ancak kullanılabilirliğini ve erişilebilirliğini iyileştirin.

Kodda değişiklik yapmadan önce, mobil telefonun davranışı ve yanıt verme hızı, klavye navigasyonu, form kullanılabilirliği, ekran okuyucu erişilebilirliği, renk kontrastı, yükleme ve hata durumları, yıkıcı eylemler ve kafa karıştırıcı kontroller konularını kapsayan kısa bir inceleme sunun.

Ardından iyileştirmeleri uygulayın. Her giriş alanının ve etkileşimli kontrolün erişilebilir bir isme sahip olduğundan, odak durumlarının açıkça görülebildiğinden, doğrulama mesajlarının ekran okuyucu tarafından okunabildiğinden ve harcama ayrıntılarının yalnızca renkli çubuklara dayanmadan bilgi ilettiğinden emin olun.

Bu, deneyin en kapsamlı incelemesiydi.

Claude, uygulamanın seçili giriş alanlarının etrafındaki doğal kenarlığı kaldırdığını ancak yerine bir şey koymadığını belirtti. Sonuç olarak, klavye kullanarak gezinen bir kişi aktif alanı görmekte zorluk çekecektir.

Ayrıca, görsel etiketlerin ilgili giriş alanlarına düzgün şekilde bağlanmadığı, arama alanının yalnızca yer tutucu metne dayandığı ve doğrulama hatalarının ekran okuyucular tarafından duyurulacak şekilde ayarlanmadığı tespit edildi.

Claude, görsel odak göstergelerini geri getirdi, etiketleri form kontrollerine bağladı, ekran okuyucu açıklamaları ekledi ve birçok açık gri metin öğesinin kontrastını artırdı. Ayrıca arama çubuğunu küçük ekranlarda daha esnek hale getirdi ve yalnızca simge içeren düğmeler için daha açıklayıcı etiketler ekledi.

En önemlisi, bu karakter hata ayıklayıcının gözden kaçırdığı bir silme sorununu keşfetti. Claude, tek tıklamayla silme düğmesini, kullanıcıların işlemi silmesini veya saklamasını gerektiren iki adımlı bir onay süreciyle değiştirdi.

Tüm iddialar kusursuz değildi. Claude, minimum dokunma alanı boyutunu 44 x 44 piksel olarak tanımladı, ancak yalnızca birincil silme düğmesini 36 x 36 piksele büyüttü. Bu, daha küçük WCAG 2.2 AA hedefini karşılıyor, ancak bahsettiği 44 piksel önerisini karşılamıyor.

Ancak, Claude'un rolünün değiştirilmesi, bakış açısını açıkça değiştirdi. Hata ayıklayıcı uygulamanın çalışıp çalışmadığını kontrol ederken, ön uç geliştiricisi gerçek bir kişinin uygulamayı rahatça kullanıp kullanamayacağını inceledi. Bu deney, tek bir gereksinimin Claude'un sonuçlarını nasıl önemli ölçüde etkileyebileceğini göstermektedir.

4. Performans mühendisi, uygulamanın fazla yardıma ihtiyacı olmadığını kabul etti.

Son olarak, Claude'dan en az 10,000 işlemi takip edebilecek bir gider takip sistemi kurmasını rica ettim .

Talep: Şimdi, kıdemli bir performans mühendisi olarak hareket edin ve bu gider takip sistemini binlerce işlemi yönetebilecek şekilde hazırlayın.

Mevcut uygulamayı gereksiz işleme, tekrarlayan hesaplamalar, verimsiz sıralama veya filtreleme, depolama darboğazları, bellek artışı ve veri boyutu arttıkça yavaşlayabilecek etkileşimler açısından analiz edin.

Performans sorunu olduğunu varsaymayın. Uygulamayı en az 10,000 işlemle test etmenin gerçekçi bir yolunu oluşturun ve kritik işlemler için bir temel ölçüt belirleyin.

Ardından, yalnızca analizle gerekçelendirilen iyileştirmeleri uygulayın. Uygulamanın görünümünü, erişilebilirlik geliştirmelerini ve mevcut davranışını koruyun. Hız artışını ölçmediğiniz veya beklenen bir iyileştirme olarak açıkça tanımlamadığınız sürece, hız artışı iddiasında bulunmayın.

Claude, özellikle önemli bir darboğaz keşfetti. Uygulama, her tutar görüntülendiğinde yeni bir para birimi formatı nesnesi oluşturuyordu. 10,000 satırda, Claude bu işlemi 349 milisaniye olarak ölçtü. Tek bir formatlayıcıyı yeniden kullanmak, bu süreyi 5.2 milisaniyeye düşürdü; Claude bunu 67 katlık bir iyileşme olarak hesapladı.

Claude ayrıca "tablo sanallaştırma" özelliğini de ekledi; bu, tarayıcının binlerce satırı aynı anda görüntülemek yerine yalnızca ekranda görünen işlemleri göstereceği anlamına geliyor. Arama ve depolama güncellemeleri, her tuş vuruşundan veya hızlı değişiklikten sonra maliyetli tekrarlardan kaçınmak için saniyenin küçük bir bölümü kadar geciktirildi.

Claude, stres testi için 1,000, 10,000 veya 50,000 örnek işlem oluşturabilen düğmeler bile ekledi.

Ancak raporun en çarpıcı kısmı, Claude'un bu iyileştirmelerin çoğunun uygulamanın amaçlanan kullanım amacı için gerekli olmadığını kabul etmesiydi.

Tipik bir hane halkı ayda 30 ila 50 arasında işlem ekleyebilir. On yıl sonra bile Claude, orijinal uygulamanın ortaya çıkan verileri önemli sorunlar olmadan işleyebileceği sonucuna vardı. Para birimi biçimlendiricisini önbelleğe almanın dışında, iyileştirmelerin çoğu yalnızca binlerce işlem için destek talep ettiğim için faydalı oldu.

Bu kısıtlama (veya öz denetim), sırf değişiklik yapabilmek için değişiklik yapmaktan daha "olgun" ve "profesyonel" görünüyordu.

Son結論um

Bu iddiaların son derece etkili olduğunu gördüm, çünkü her biri Claude'un güçlü ve zayıf yönlerini açıkça ortaya koyuyordu. Her rol, değerlendirme için benzersiz bir bakış açısı sunuyordu; bunu çok faydalı buldum ve diğer uygulamalar ve web sitelerinin gelecekteki incelemelerimde mutlaka uygulayacağım.

Hata ayıklama mühendisi hatalı davranışları keşfederken, ön uç mühendisi erişilebilirlik ve kullanılabilirlik sorunlarını buldu. Performans mühendisi ise artan veri hacminin etkilerini değerlendirdi ve optimizasyonun gereksiz olduğu durumları tespit etti.

Bu deneyim aynı zamanda, "Üretime hazır hale getirin" gibi tek ve kapsamlı bir talebin neden en iyi yaklaşım olmayabileceğini de gösterdi. Tek bir inceleme, talep kapsamlı görünse bile önemli sorunları gözden kaçırabilir. Çalışmayı odaklanmış aşamalara bölmek, Claude'un ele alması gereken öncelikleri azalttı ve sonuçlarını değerlendirmeyi kolaylaştırdı.

Bulut kullanım limitlerine dikkat edin. Bir dahaki sefere, izin verilen maksimum limite ulaşmamak için uyarıları birleştirmeyi deneyebilirim.

---

---