AI Destekli Kodla 3D Web Projesi Geliştirme İş Akışı

Kod yazan araç, proje yöneten kişi

3D bir web projesinde kod tarafı hızla karmaşıklaşabiliyor. Bir model yüklenir, kamera ve kontroller kurulur, yükleme durumu gösterilir, mobilde performans korunur, sayfanın geri kalanıyla uyum sağlanır. Bunların her biri ayrı küçük işler ve her birinde yapay zekâ destekli bir kod aracı yardımcı olabilir. Ama araç projeyi yönetmiyor; projeyi yöneten kişi yine siz oluyorsunuz.

Bu yazıda, AI destekli kodla bir 3D web projesini nasıl ilerlettiğimi bir iş akışı olarak anlatıyorum. Bu sitenin kendisi Claude Code ile geliştirildi ve ben her değişikliği tarayıcıda elle kontrol ediyorum. Aşağıdaki akış bu çalışma biçiminin düzenli hali: genel bir yöntem, ölçülmüş bir sonuç iddiası değil. Belirli bir aracın iç işleyişi hakkında da bir şey iddia etmeyeceğim; yalnızca her kod aracında geçerli olan çalışma disiplinini yazıyorum.

Bu yazının felsefi tarafını, yani aracı ortak gibi görüp direksiyonu elde tutmayı, daha kısa biçimde Claude Code ile üretim yaparken benim için en önemli şey yazısında anlatmıştım. Burada o fikri adım adım bir sürece çeviriyorum.

İş akışına genel bakış

Önce akışın iskeletini vereyim. Yedi adımdan oluşuyor:

• Kapsamı ve başarı ölçütünü yazmak.
• Varlıkları, yani 3D modeli ve görselleri hazırlamak.
• Projeyi ve mevcut yapıyı araca tanıtmak.
• Küçük ve test edilebilir adımlarla ilerlemek.
• Her adımda değişikliği okumak, yani diff incelemek.
• Performans ve mobil testini düzenli yapmak.
• Yayın öncesi kontrol ve geri dönüş planı hazırlamak.

Sıralama önemli. Çoğu sorun, ilk iki adımı atlayıp doğrudan "bana bir 3D sayfa yap" demekten çıkıyor. Araç elbette bir şey üretiyor, ama ne üretildiğini değerlendirecek bir ölçütünüz yoksa sonucun iyi olup olmadığını bilemezsiniz.

Kapsamı ve başarı ölçütünü yazmak

İşe, kodla değil bir paragraf metinle başlıyorum. Bu metin şu soruları cevaplıyor: Sayfa ne yapacak? Kim kullanacak? Hangi cihazlarda çalışacak? 3D içerik sayfanın merkezinde mi yoksa destekleyici bir parça mı?

Son soru, tasarım kararlarını belirliyor. 3D, ürün tanıtımının merkezindeyse yükleme süresi ve etkileşim kalitesi öncelik olur. Sadece bir vurgu öğesiyse hafif bir çözüm yeter. Bir web sitesinde 3D kullanımının ne zaman gereksiz olduğuna dair kendi görüşümü bir web sitesinde 3D kullanmak ne zaman gereksiz yazısında yazdım; bu soruya dürüst cevap vermek, projenin yarısını kurtarabiliyor.

Başarı ölçütlerini de yazıyorum. Örnek bir liste:

• Model, orta seviye bir telefonda açılıyor ve akıcı dönüyor.
• Model yüklenirken kullanıcı boş bir alan değil, bir yükleme göstergesi görüyor.
• Model yüklenemezse sayfa bozulmuyor; yedek bir görsel gösteriliyor.
• Sayfa dar ekranda yatay kaydırma yapmıyor.
• Kontroller dokunmatik ve fare ile kullanılabiliyor.

Bu liste hem araç için talimat hem de benim için kontrol listesi oluyor. "Bitti" tanımını baştan yazmanın faydası şu: araç "tamamladım" dediğinde elinizde karşılaştıracak bir şey var.

Varlıkları önce hazırlamak

Kod aracına model vermeden önce modelin kendisinin hazır olması gerekiyor. Düzensiz bir model ya da fazla büyük bir dosya, kodla çözülemeyecek sorunlar çıkarır. Bu yüzden sıralama olarak önce model, sonra kod geliyor.

Hazırlık kontrol listem:

• Model, web için uygun bir formatta mı? Format seçimini GLB, glTF, FBX, OBJ, USDZ farkları yazısında anlattım. Web için genellikle GLB önerilir.
• Dosya boyutu makul mü? Mobil bağlantıda yükleme süresine doğrudan etki eder. Optimizasyon sürecim bir 3D modeli web için optimize etme yazısında var.
• Polygon sayısı ve doku boyutları hedef cihaza uygun mu? Bu konuya web'de kaç polygon kullanılmalı yazısında girdim.
• Model, üretildiği programdan bağımsız bir görüntüleyicide doğru açılıyor mu?
• Yedek olarak kullanılacak sabit bir görsel (poster) hazır mı?

Bu varlıkları hazır hale getirmek kod aracına ihtiyaç duymuyor ve sonradan gelen "kod mu bozuk, model mi bozuk" sorusunu büyük oranda ortadan kaldırıyor. Bir sorunun kaynağı iki yerden gelebiliyorsa, hata ayıklama çok daha zor oluyor.

Projeyi ve yapıyı araca tanıtmak

Yeni bir projede ya da mevcut bir projede araca bağlam vermek gerekiyor. Aracın projeyi tanıması için ona şunları söylemek faydalı:

• Projenin amacı ve hedef kitlesi, birkaç cümleyle.
• Kullanılan yapı: statik bir site mi, bir çerçeve mi, hangi araçlarla derleniyor?
• Değiştirilmemesi gereken yerler: ortak bileşenler, yayın ayarları, başka sayfaların bağlı olduğu dosyalar.
• Kod yazım kuralları: adlandırma, klasör düzeni, stil yaklaşımı.
• Test ya da kontrol yöntemi: sayfa nasıl açılıp denenecek?

Birçok kod aracı proje için kalıcı talimat tutabilecek bir mekanizma sunuyor; bu mekanizmanın ayrıntısı araca göre değişiyor, o yüzden burada belirli bir ayar adı vermiyorum. Hangi aracı kullanırsanız kullanın, ilkesel olarak bu bilgiyi yazılı hale getirmek, her oturumda aynı şeyleri tekrar anlatmaktan iyi.

Mevcut kod tabanında ilk işim, aracın yapıyı doğru anladığını kontrol etmek. "Bu projede 3D görüntüleyici nerede tanımlı?" gibi bir soru, aracın projeyi okuduğunu ve doğru yeri bulduğunu gösteriyor. Yanlış cevap veriyorsa, o aşamada talimat vermek yerine bağlamı düzeltiyorum. Kod okuma ve anlama tarafının önemini Codex ile kod öğrenmek yerine kod anlamak yazısında anlattım.

Küçük ve test edilebilir adımlarla ilerlemek

İş akışının en önemli ilkesi bu: büyük bir istek yerine küçük adımlar. "Ürün sayfasını 3D model ile baştan yap" yerine şu tür adımlar:

• Sayfaya, henüz bir model olmadan, 3D görüntüleyici için boş bir alan ekle.
• Alana tek bir modeli yükle ve göster.
• Yükleme göstergesini ekle.
• Yükleme hatasında yedek görsele geç.
• Kamera hareketini sınırla, kullanıcı modeli kaybetmesin.
• Dar ekranda yerleşimi düzenle.
• Etkileşim ipuçlarını ekle.

Her adımın sonunda sayfayı tarayıcıda açıp bakıyorum. Bir adım çalışıyorsa bir sonrakine geçiyorum. Çalışmıyorsa o adım küçük olduğu için hatanın nerede olduğu da küçük bir alana sığıyor.

Küçük adımların bir avantajı daha var: geri almak kolay. Büyük bir değişiklik bozulursa neyin bozduğunu bulmak zordur; küçük bir değişiklik bozulursa o değişikliği geri alırsınız. Bu yüzden sürüm kontrolü kullanmak ve her çalışan adımı ayrı bir kayıt olarak saklamak iyi bir alışkanlıktır. Böylece "en son çalışan hal" her zaman elinizde olur.

Küçük adım ilkesi aynı zamanda araca daha net talimat vermeyi zorluyor. Belirsiz bir istek belirsiz bir sonuç veriyor. Net, tek amaçlı bir istek ise kontrol edilebilir bir sonuç veriyor.

Her adımda değişikliği okumak

Araç bir değişiklik yaptığında yalnızca sonuca bakmak yetmiyor, değişikliğin kendisini de okuyorum. Bunu yapmanın nedenleri:

• İstenmeyen dosyalar değişmiş olabilir. Bir stil düzeltmesi sırasında ortak bir bileşene dokunulmuşsa, başka sayfalar etkilenir.
• Yeni bir bağımlılık eklenmiş olabilir. 3D tarafında bir kütüphane eklemek dosya boyutuna ve bakım yüküne etki eder; bu, benim onay vermem gereken bir karar.
• Geçici çözümler yerleşmiş olabilir. Bazen araç sorunu kökten çözmek yerine üzerini örter; kodda gereksiz bir koşul ya da sabit bir değer görürsem nedenini soruyorum.
• Kodun ne yaptığını anlamıyorsam bu bir uyarı. Anlamadığım kodu projede bırakmak istemiyorum.

Değişiklik büyükse aracın kendisine de sorabiliyorum: "Bu değişiklikte hangi dosyalara dokundun ve neden?" Cevap, diff ile uyuşmuyorsa bu da başlı başına bir sinyal. Aracın açıklaması bir yardımcı, ama gerçek kaynak kodun kendisi.

Bu konuyu genel çerçevede AI ile üretirken neden her şeye güvenmemek gerekiyor yazısında "kod başka bir yeri bozmuş mu" başlığı altında işlemiştim. 3D projede bunun ek bir yüzü var: görsel sonuç doğru görünürken performansın sessizce bozulmuş olması mümkün.

Performans ve mobil testi

3D bir web projesinde performans, sonradan eklenen bir iyileştirme değil, baştan yürütülen bir kontrol. Her adımdan sonra kısa bir test turu yapıyorum:

• Sayfa ilk açıldığında 3D alanı yüklenmeden önce içerik düzeni kayıyor mu?
• Model yüklenirken sayfanın geri kalanı kullanılabilir mi?
• Model döndürülürken akıcılık korunuyor mu?
• Orta seviye bir telefonda sayfa açılıyor mu, ısınma ya da takılma var mı?
• Aynı sayfada birden fazla 3D alan varsa hepsi aynı anda mı çalışıyor? Bu gereksiz kaynak tüketir.
• Sayfa dışı bir sekmeye geçildiğinde veya 3D alan görünür olmadığında sürekli çizim yapılıyor mu?

Son iki madde, araç çıktılarında sık gözden kaçan şeyler. Kod çalışıyor ve görsel doğru olduğu için sorun fark edilmiyor, ama gereksiz çizim pil ve işlemci tüketiyor. Bu tür sorunlar için geliştirici araçlarındaki performans ve ağ panellerine bakmak gerekiyor. Ölçüm yapamadığım bir iddiada bulunmuyorum; "daha hızlı" demek yerine hangi ölçümü yaptığımı söylemek istiyorum.

Mobil testinde mümkünse gerçek bir telefon kullanıyorum. Tarayıcıdaki cihaz simülasyonu yerleşimi göstermek için iyi, ama bellek ve işlemci sınırlarını tam yansıtmıyor. Tasarım ve performans arasındaki dengeyi 3D web sitesi yaparken tasarım mı performans mı yazısında tartıştım. Genel ilke: görsel zenginlik, düşük cihazda sayfanın kullanılabilirliğini bozuyorsa vazgeçilebilir.

Erişilebilirlik ve yedek durumlar

3D içerik herkes için erişilebilir olmayabilir. Hareketten rahatsız olan kullanıcılar için hareketi azaltma tercihine saygı göstermek, ekran okuyucu için anlamlı alternatif metin sağlamak ve 3D yüklenemediğinde sayfanın hâlâ bilgi vermesi gerekiyor.

Kod aracına bu konuları ayrıca söylemek gerekiyor, çünkü araç genellikle istenmeyen şeyi kendiliğinden düşünmüyor. Talimat listesine şunları ekliyorum:

• 3D alanın bir metin alternatifi olsun; ürünün ne olduğu 3D yüklenmeden de anlaşılsın.
• Otomatik dönen ya da hareket eden öğeler, kullanıcının hareketi azaltma tercihine uysun.
• Kontroller klavye ile ulaşılabilir olsun.
• Model yüklenemezse bir hata mesajı ve yedek görsel gösterilsin.

Kontrollerin nasıl tasarlanacağı kendi başına geniş bir konu; web'deki 3D ürün görüntüleyicisinde kontroller nasıl tasarlanır yazısında ele aldım. Bunları baştan istemek, sonradan eklemekten daha az iş çıkarıyor.

Hazır bileşen mi, özel kod mu?

3D'yi web'e koymanın birkaç yolu var ve kod aracına hangi yolu seçtiğinizi söylemeniz gerekiyor. Basit bir ürün göstermek için hazır bir görüntüleyici bileşeni çoğu zaman yeterli. Bu yaklaşımı model-viewer ile web sitesine 3D model ekleme yazısında kod örneğiyle anlattım. Daha özel bir etkileşim, örneğin sahne üzerinde özel animasyonlar ya da scroll ile bağlı hareketler gerekiyorsa daha esnek ve daha fazla kod isteyen bir yol gerekebilir. Scroll tabanlı yaklaşımı scroll tabanlı 3D web siteleri yazısında tartıştım.

Seçim yaparken kendime şu soruyu soruyorum: ihtiyacım olan etkileşimi hazır bileşen karşılıyor mu? Karşılıyorsa özel kod yazmak, yani hem aracın üreteceği kodu hem de onu bakımını yapmak, fazladan yük. Yapay zekâ kod üretmeyi kolaylaştırdığı için gereksiz karmaşıklığa kaçmak da kolaylaşıyor. Aracın yazdığı her satırı ben okumak ve bakımını üstlenmek zorunda olduğum için en basit çözümü tercih ediyorum.

Aura Reformer gibi bir ürün seçici örneğinde (çalışmaya buradan bakabilirsiniz) 6 ürün ve 57 renk seçeneğinin tutarlı gösterilmesi gerekiyordu. Böyle bir yapıda seçeneklerin veri olarak tek bir yerde tutulması ve kodun bu veriden okuması, kodu azaltıyor ve hata ihtimalini düşürüyor. Bu bir genel ilke: tekrar eden bilgiyi koda gömmek yerine veriye taşımak. Çalışmanın mantığını renk seçici yazısında anlattım.

Yayın öncesi kontrol ve geri dönüş planı

Yayına çıkmadan önce üç şeyi yapıyorum.

Birincisi, son bir tam tur. Sayfayı baştan sona açıyorum: ilk yükleme, model, kontroller, yedek durum, dar ekran, bağlantılar. Başarı ölçütleri listesindeki her maddeyi işaretliyorum.

İkincisi, konsol ve ağ kontrolü. Tarayıcı konsolunda hata ya da uyarı var mı, ağ panelinde beklenmeyen büyük dosyalar ya da başarısız istekler var mı? Kodun çalışması, hatasız çalıştığı anlamına gelmiyor.

Üçüncüsü, geri dönüş planı. Yayından sonra bir sorun çıkarsa önceki sürüme nasıl dönülecek, bunu önceden biliyorum. Her çalışan adımı kaydettiğim için bu plan basit: son sağlam kayda dönmek.

Yayın sonrasında canlı sayfayı bir kez daha açıyorum. Yerelde çalışan bir şeyin canlıda yol, dosya adı ya da önbellek yüzünden farklı davranması sık görülen bir durum. Dosya adlarında büyük küçük harf farkı gibi küçük ayrıntılar bile yerelde fark edilmeyip canlıda modelin yüklenmemesine yol açabilir.

Metin içeriğin yayın öncesi kontrolü için ayrıca AI ile üretilen içerik için yayın öncesi kontrol listesi yazısını hazırladım; sayfadaki yazılar için onu da kullanıyorum.

Araçla iletişim: iyi istek nasıl yazılır

Küçük adımların kalitesi isteğin kalitesine bağlı. Benim için işe yarayan istek yapısı şu:

• Amaç: Ne değişecek ve neden? Tek cümle.
• Kapsam: Hangi dosya ya da bileşen? Hangilerine dokunulmayacak?
• Ölçüt: Bitince neyi görmeliyim?
• Kısıt: Yeni bağımlılık eklenmesin, mevcut kod düzeni korunsun gibi sınırlar.

Örneğin "3D alan yüklenemezse yedek görseli göster; yalnızca ürün sayfası bileşenine dokun; yeni kütüphane ekleme; bitince hata durumunu nasıl test edeceğimi söyle" gibi bir istek, aracın hem ne yapacağını hem sınırlarını biliyor. Sonuç da kontrol edilebilir hale geliyor.

Araç bir sorunu çözemiyorsa aynı isteği tekrar tekrar göndermek yerine durup sorunu anlamaya çalışıyorum. Önce hatanın ne olduğunu, hangi koşulda çıktığını araçla birlikte tanımlıyorum; sonra çözüm istiyorum. Teşhis konmadan verilen çözüm genellikle geçici bir yama olur.

Ne zaman aracı bırakıp kendim yapıyorum?

Her iş araca verilmiyor. Birkaç durumda aracı bırakıp kendim ilerliyorum:

• Görsel karar gerektiren işler. Bir ışık tonu, bir geçişin hissi, bir düzenin dengesi araçla tarif edilmekten çok, gözle denenerek bulunuyor.
• Kodun ne yaptığını anlamadığım yerler. Önce anlıyorum, sonra devam ediyorum.
• Araç aynı yerde birkaç denemedir takılıyorsa. Bu çoğu zaman sorunun yanlış tanımlandığını gösteriyor.
• Yayın ayarları ve güvenlikle ilgili yerler. Bu alanlarda her değişikliği kendim yapıp doğrulamayı tercih ediyorum.

Hedefi ve görsel kararı ben veriyorum, araç uygulamayı hızlandırıyor. Bu iş bölümü projelerimde iyi çalıştı; ama bu bir kural değil, benim çalışma biçimim. Başka bir projenin dengesi farklı olabilir.

Sık sorulan sorular

Sonuç

AI destekli kodla 3D web projesi geliştirmek, doğru çerçevede hızlı ve yönetilebilir bir süreç: kapsamı yazın, varlıkları önce hazırlayın, küçük adımlarla ilerleyin, her değişikliği okuyun ve performansı mobilde sınayın. Araç kodu hızlandırır; projenin doğruluğunu ve kalitesini ise sizin kontrolünüz belirler. Web için hazırlanmış bir 3D ürün modeline ihtiyacınız varsa web için 3D ürün modeli sayfasına bakabilir, projeniz için teklif alabilirsiniz.