Claude Code Kullanımı: HTML'nin Şaşırtıcı Verimliliği

 (twitter.com/trq212)
5 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Claude Code içinde Markdown yerine çıktı biçimi olarak HTML kullanmak, görselleştirme, renk, diyagram ve etkileşimi daha zengin biçimde sunarak insanların okuyup incelemesi daha kolay sonuçlar üretmeyi sağlar
  • HTML, tablolar, CSS, SVG, script, JavaScript etkileşimi, görseller, canvas ve mutlak konumlandırma sayesinde Claude'un okuyabildiği bilgilerin büyük kısmını verimli biçimde ifade edebilir
  • Claude Code, dosya sistemi, MCP, tarayıcı ve Git geçmişi gibi bağlamları okuyup bunları HTML çıktılarında bir araya getirebilir; başlamak için yalnızca “Bir HTML dosyası oluştur” demek yeterlidir
  • Başlıca kullanım biçimleri spesifikasyon·planlama·keşif, kod inceleme ve kodu anlama, tasarım ve prototipleme, raporlar·araştırma·öğrenme ve özel tek seferlik düzenleme arayüzleri olarak ayrılır
  • HTML, Markdown'dan 2-4 kat daha uzun sürede üretilir ve diff'leri gürültülü olduğu için sürüm kontrolü zordur; ancak ifade gücü, paylaşılabilirliği ve gerçekten okunma olasılığı daha yüksek olması önemli avantajlar olarak öne çıkar

Neden Markdown yerine HTML'yi tercih etmeye başladım

  • Markdown, ajanların insanlarla iletişim kurmak için kullandığı baskın dosya biçimi haline geldi; basit, taşınabilir, bir miktar biçimlendirme ifade edebiliyor ve insanların doğrudan düzenlemesi kolay
  • Claude, Markdown içinde ASCII diyagramları da iyi üretiyor; ancak ajanlar güçlendikçe Markdown daha kısıtlayıcı bir biçim gibi hissediliyor
  • 100 satırı aşan Markdown dosyalarını okumak zorlaşıyor ve daha zengin görselleştirme, renk ve diyagramları kolayca paylaşma ihtiyacı doğuyor
  • Dosyaları doğrudan düzenlemek yerine çoğu zaman Claude'dan düzenleme istemek daha yaygın hale geldikçe, Markdown'ın en büyük avantajı olan kolay doğrudan düzenleme daha az değerli oluyor
  • Claude Code ekibi içinde de çıktı biçimi olarak HTML kullanımı artıyor; örnekler html-effectiveness içinde görülebilir

HTML'nin ifade gücü ve paylaşılabilirliği

  • HTML, başlıklar ve biçimlendirme gibi belge yapılarının ötesinde, Markdown'dan çok daha çeşitli bilgi türlerini ifade edebilir
  • İfade edilebilen bilgiler arasında tablolarla sunulan tablo verileri, CSS ile tasarım verileri, SVG illüstrasyonlar, script etiketiyle kod parçaları ve JavaScript ile CSS üzerinden etkileşim bulunur
  • SVG ve HTML ile iş akışları gösterilebilir, mutlak konumlandırma ve canvas ile mekânsal veriler ifade edilebilir, img etiketiyle görseller eklenebilir
  • Claude'un okuyabildiği bilgi kümesinin büyük kısmı HTML ile oldukça verimli biçimde ifade edilebilir; böylece modelin derinlikli bilgi aktarması ve insanların da bunları incelemesi için verimli bir biçim ortaya çıkar
  • HTML kullanılamadığında Claude, Markdown içinde ASCII diyagram üretmek ya da Unicode karakterlerle renkleri tahmin etmeye çalışmak gibi verimsiz ifade yollarına yönelebilir
  • Claude daha karmaşık görevler üstlendikçe daha büyük spesifikasyonlar ve planlar yazmaya başladı; pratikte 100 satırı aşan Markdown dosyaları da iyi okunmuyor
  • HTML belgeleri sekmeler, illüstrasyonlar ve bağlantılarla yapıyı görsel olarak düzenleyebildiği için gezinmesi kolaydır; ayrıca ekran boyutuna göre farklı okunacak şekilde mobil uyumlu da hazırlanabilir
  • Markdown dosyaları tarayıcılar tarafından varsayılan olarak iyi render edilmediğinden çoğu zaman e-posta ya da mesaj ekinde gönderilmesi gerekir; buna karşılık HTML, S3 gibi bir yere yüklendiğinde bağlantı olarak kolayca paylaşılabilir
  • HTML biçimindeki spesifikasyonlar, raporlar ve PR açıklamaları ekip arkadaşlarının açıp başvurması için daha kolaydır; bu yüzden gerçekten okunma ihtimali çok daha yüksektir
  • HTML belgeleri, kaydırıcılar veya düğmeler ekleyerek tasarımı ayarlamayı ya da algoritma seçeneklerini değiştirip sonucu görmeyi sağlayan çift yönlü etkileşim sunabilir
  • Yapılan ayarları Claude Code'a tekrar yapıştırılacak bir prompt olarak kopyalama özelliği de eklenebilir; ilgili örnekler playgrounds post içinde ele alınıyor

Claude Code ile HTML'yi birlikte kullanma nedenleri

  • Claude Code, dosya sistemi, MCP, tarayıcı, Git geçmişi gibi çeşitli bağlamları okuyup bunları HTML çıktısı halinde bir araya getirebilir
  • Örneğin bir kod klasöründe oluşturulan tüm HTML dosyalarını bulup gruplandırabilir, sınıflandırabilir ve her türü temsil eden diyagramlar içeren bir HTML dosyası oluşturabilir
  • Dosya sistemi dışında Slack ve Linear gibi MCP kaynaklarından, Claude in Chrome üzerinden web tarayıcısından ve Git geçmişinden ek bağlam da bulunabilir
  • HTML belgelerini Claude ile birlikte oluşturma süreci daha eğlenceli hissettirir ve ortaya çıkan ürüne daha fazla dahil olunduğu, emek verildiği duygusunu yaratır
  • Ayrı bir /html yeteneği oluşturmaya gerek kalmadan yalnızca “Bir HTML dosyası oluştur” veya “Bir HTML artifact'i oluştur” demekle başlanabilir
  • Önemli püf noktası, artifact'in ne yapması gerektiğini ve nasıl kullanılacağını bilmektir; başlangıçta her seferinde sıfırdan prompt yazarak farklı kullanım amaçlarını öğrenmek daha iyidir

Başlıca kullanım biçimleri

  • Spesifikasyon, planlama, keşif

    • HTML, Claude'un bir problemi derinlemesine incelemesi için zengin bir tuval olur; tek bir Markdown planı yerine birkaç HTML dosyasından oluşan bir paketle işe başlanabilir
    • Önce birden fazla yön için beyin fırtınası yapılabilir, ardından bunlardan biri genişletilerek mockup'lar veya kod parçaları oluşturulabilir ve son olarak bir uygulama planı yazılabilir
    • Plan tatmin edici olduğunda yeni bir oturum açıp bu dosyaları vererek uygulamaya geçilebilir; doğrulama ajanı da aynı dosyaları okuyarak gerekli bağlamı daha geniş biçimde edinebilir
    • Bir onboarding ekranı için yerleşim, ton ve yoğunluğu farklı 6 yaklaşım tek bir HTML ızgarasında oluşturulabilir ve her seçeneğin trade-off'ları gösterilebilir
    • Mockup'lar, veri akışları ve incelenecek kod parçaları içeren, okunması kolay bir HTML uygulama planı da üretilebilir
    • Kod uygulama yaklaşımını keşfetmek ve birden fazla görsel tasarımı karşılaştırmak için kullanılabilir

  • Kod inceleme ve kodu anlama

    • Kod, Markdown dosyalarında okunması zor olabilir; ancak HTML içinde diff'ler, notlar, akış şemaları ve modül yapıları render edilebilir
    • Ajanın yazdığı kodu anlamak, kod incelemesi almak ya da PR inceleyen kişilere yapılan değişiklikleri açıklamak için kullanılabilir
    • Bazı durumlarda varsayılan GitHub diff görünümünden daha iyi çalışabilir; hatta her PR için bir HTML kod açıklama dosyası ekleme akışı kurulabilir
    • PR incelemesi için bir HTML artifact oluşturulabilir, tanıdık olunmayan streaming/backpressure mantığına odaklanması istenebilir ve gerçek diff üzerinde kenar notlarıyla önem derecesine göre renklendirme yaptırılabilir
    • PR yazımı, PR incelemesi ve belirli bir kod konusunu anlama için kullanılabilir

  • Tasarım ve prototipleme

    • Claude Design, HTML temellidir ve son yüzey HTML olmasa bile HTML'nin tasarımsal ifade gücü yüksektir
    • Claude, tasarımı önce HTML ile taslak olarak çizebilir, sonra React, Swift veya istenen başka bir dilde yazabilir
    • Animasyon ve aksiyon gibi etkileşimler prototiplenebilir; istenen değerleri ayarlamak için kaydırıcılar veya düğmeler eklenebilir
    • Tıklandığında oynatma animasyonu gösterip ardından hızla mora dönen bir checkout düğmesi yapılabilir; buna birden fazla kaydırıcı ve seçenek ile uygun parametreleri kopyalama düğmesi de eklenebilir
    • Tasarım sistemi artifact'leri üretmek, bileşen ayarlamak, bileşen kütüphanesini görselleştirmek ve keyifli animasyon prototipleri oluşturmak için kullanılabilir

  • Raporlar, araştırma, öğrenme

    • Claude Code, birden fazla veri kaynağından gelen bilgileri sentezleyip okunması kolay raporlara dönüştürmede güçlüdür
    • Slack, kod tabanı, Git geçmişi ve internet üzerinde arama yapması sağlanabilir; ardından kişinin kendisi, liderlik ya da ekip için okunması kolay raporlar üretilebilir
    • Ortaya çıkan çıktı uzun bir HTML belgesi, etkileşimli açıklama, slayt veya deck biçiminde olabilir
    • SVG ile diyagramlar ürettirmek görselleştirmeye yardımcı olur
    • Prompt caching ile ilgili bir yazı hazırlanırken Git geçmişini okuyup prompt caching değişikliklerinin tamamını kapsayan derinlikli bir HTML araştırma dosyası üretme yaklaşımı kullanılmıştır
    • Bir rate limiter'ın ilgili kodları okutulup, token-bucket akış diyagramı, açıklamalı 3-4 kritik kod parçası ve altta bir gotchas bölümü içeren tek bir HTML açıklama sayfası oluşturtulabilir
    • Özellik davranışı özeti, kavram açıklaması, haftalık durum raporu, olay raporu ve SVG illüstrasyonlar, akış şemaları, teknik diyagramlar için kullanılabilir

  • Özel düzenleme arayüzleri

    • Sadece metin kutusuyla isteneni anlatmanın zor olduğu durumlarda, o anda çalışılan veriye uyarlanmış tek seferlik bir HTML düzenleyici oluşturulabilir
    • Bu bir ürün ya da yeniden kullanılabilir araç değil, belirli bir veri parçası için amaca özel hazırlanmış tek bir HTML dosyası olur
    • Buradaki ana fikir, sona “copy as JSON” veya “copy as prompt” gibi bir dışa aktarma seçeneği ekleyerek arayüzde yapılan işlemlerin sonucunu Claude Code'a yapıştırabilmektir
    • 30 Linear bileti Now / Next / Later / Cut sütunlarında sürüklenebilir kartlar haline getirilebilir ve nihai sıralama her bucket için tek satırlık gerekçeyle birlikte Markdown olarak kopyalatılabilir
    • Feature flag ayarları form tabanlı bir düzenleyiciye dönüştürülebilir, alanlara göre gruplanabilir, bağımlılıklar gösterilebilir, ön koşul flag'i kapalıyken bir flag açılmaya çalışıldığında uyarı verilebilir ve yalnızca değişen anahtarlar diff olarak kopyalatılabilir
    • Sistem prompt'unu ayarlarken solda düzenlenebilir prompt ve vurgulanmış değişken yuvaları, sağda ise üç örnek girdinin gerçek zamanlı render'ı; ayrıca karakter ve token sayacı ile kopyalama düğmesi yer alabilir
    • Bilet, test senaryosu ve geri bildirim yeniden sıralama; yapılandırılmış ayar düzenleme; prompt, şablon ve metin ayarı; veri kümesi kürasyonu; belge, transkript ve diff açıklamaları; ayrıca renk, easing curve, crop region, cron schedule ve regex gibi metinle ifade etmesi zor değerlerin seçimi için kullanılabilir

Sık sorulan sorular ve sınırlamalar

  • Markdown genelde daha az token kullanır; ancak HTML'nin ifade gücü ve gerçekten okunma ihtimali daha yüksek olduğu için toplam çıktı daha iyi olabilir
  • Opus 4.7'nin 1MM context window özelliğinde artan token kullanımı bağlam penceresinde çok belirgin hale gelmez
  • Neredeyse her kullanımda Markdown kullanmayı bırakmış olsam da, bu yaklaşım HTML'yi mümkün olan en yüksek düzeyde tercih eden bir kullanım biçimine daha yakındır
  • HTML dosyaları yerel tarayıcıda açılabilir, Claude'dan da açması istenebilir; paylaşılabilir bir bağlantı gerekiyorsa S3'e yüklenebilir
  • HTML üretimi Markdown'a göre daha uzun sürer; 2-4 kat daha fazla zaman alabilir, ancak ortaya çıkan sonucun buna değdiği düşünülür
  • En büyük dezavantajlardan biri sürüm kontrolüdür; HTML diff'leri Markdown'a kıyasla daha gürültülüdür ve incelemesi daha zordur
  • Claude'un zevke uygun HTML üretmesini sağlamak için frontend design plugin yardımcı olabilir
  • Şirket stiline uydurmak için Claude'a kod tabanını inceletip tek bir tasarım sistemi HTML dosyası oluşturtabilir, sonra bunu diğer HTML dosyaları için referans olarak kullanabilirsiniz
  • HTML kullanmak, Claude'un yazdığı planları derinlemesine okumadan seçimleri ona bırakma korkusunu azaltır ve Claude ile çalışırken akış içinde daha fazla kalmayı sağlar

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News görüşleri

  • HTML’e yönelinirse, insanların ve LLM’lerin belgeleri birlikte yazıp düzenlemeyi kolaylaştıran yeteneği kaybetmesinden endişe ediyorum
    Basit açıklama metinleri için sorun olmayabilir, ama daha karmaşık bir şartnameyse üretilen sonucun içine doğrudan girip düzeltme yapabilmek çok önemli. HTML belgelerinde bunu yapmak Markdown’a göre çok daha zor; LLM’e yeniden HTML’i düzenlemesini söylemek de mümkün ama kafanızda söylemek istediğiniz şey zaten netse bu da başlı başına başka bir engel oluyor. Bu kalıp yaygınlaşırsa insan/LLM ortak üretimi daha da azalır ve üslup, ton, hatta içerik seçimini bile LLM’e bırakma yönüne gidilir gibi geliyor. Blog FAQ’sunda bu kaygının hiç yer almamasına şaşırdım

    • Markdown, etkileşimli öğeler için inline HTML destekliyor; bu yüzden bilinen bir HTML şablonuna ve basit bir build adımına bağlanan Markdown belgeleri ilginç bir alternatif olabilir
      Örneğin tek satırlık bir pandoc komutu gibi
    • Bence burada bir adım daha var. HTML ile çoğu şey yapılabiliyor ama LLM’in kendi dilini tanımlamasına izin vermek de şaşırtıcı derecede etkili oldu
      Şu anda izometrik bakış açısına ve sese sahip küçük bir mobil oyun yapıyorum. Codex’ten hazırlanmış three.js dokümanına bloklar yerleştiren ve Chromium geliştirici araçlarıyla ekran görüntüsü alan bir araç yapmasını istedim; o da blokları, renkleri ve efektleri tanımlayan küçük bir JSON yapısı oluşturup 2.5D tileset üretti. Ayrıca uv Python script’iyle ses ve müzik tanımlamasını istediğimde, gürültü üretebilen bir YAML formatı uydurdu. SVG pelican testi tamamen aşıldı ve Codex asker, şövalye ve rahip için yeterli prototip çizimlerle birlikte prototip bir soundtrack bile üretti
    • On yıllardır HTML’i elle kolayca yazıyoruz. Metin editörleri HTML yazmak için çok uygun ve otomatik satır kaydırma, otomatik kapatma gibi pek çok komut sayesinde okuması ve yazması basit
    • Bu ancak kendinizi ilkel bir teleprinter emülatörüne kapatırsanız geçerli gibi geliyor. Düzgün bir kodlama ortamında HTML düzenlemek çok kolay olmalı; zengin model çıktısına doğru gidiliyorsa yerleşik WYSIWYG editörler de bir seçenek olabilir
    • Son zamanlarda raporlarda HTML kullanmaya başladım ama her zaman ara format olarak Markdown dosyası bırakıp LLM’den Markdown tablolarına dayanarak SVG grafikler ve çizimler içeren daha şık bir sürüm yapmasını istiyorum

  • Bunun etkileşimli bir HTML sayfası değil de HTML render’ının görselini paylaşan bir Twitter gönderisi olması ironik
    Markdown’dan daha zayıf anlamsal yapıya sahip bir platformda HTML’i savunmak sonuçta epey komik

  • Yeni fikirleri veya araçları keşfederken sık kullandığım prompt şu

    In a single index.html, no dependencies, sparse styling, create an app that

    AI öncesinde de küçük araçları böyle yapıyordum; arkadaşıma aracı e-postayla gönderip “değiştirmek istersen LLM’e atıver” diyebilmek hoşuma gidiyor

    • Doğru yaklaşım bu
      Dashboard’lar, küçük uygulamalar, API’lerle etkileşen veya bir yerden veri çeken yardımcı araçlar yaparken stil ve JS içeren tek bir HTML dosyasıyla gidilebilecek alan şaşırtıcı derecede geniş. Şirketin paylaşımlı sunucusundaki kişisel ~ klasörüne atarsınız, herkes hemen görüp kullanabilir
    • Yeni bir müşterinin tasarımını iterasyonla geliştirirken de basit bir index.html içinde inline CSS kullanarak yapıyorum; sonuç hoşuma giderse o dosyayı projenin şablon dosyasının yanına koyup LLM’den index.html tasarımını şablon dosyasına işlemesini istiyorum
    • Bu kullanım senaryosunu daha önce hiç düzgün düşünmemiştim, biraz aptal gibi hissettim. Faydalı olacağı fazla açık
      Şimdiye kadar LLM kullanırken odak noktam “uygulama”nın kendisiydi; uygulamanın çevresindeki yardımcı araçlar değil. O yardımcı araçların kusursuz ya da her durumu kapsayan şeyler olması gerekmiyor; işe yarayacak kadar çalışmaları yeterli. İşiniz bitince atar, ertesi gün yenisini yaparsınız
    • Bu numarayı bir süre önce keşfedip analog elektronik devreler için bir sürü hesaplayıcı yaptım: https://cofree.coffee/~solomon/calculators/
      Bu tür araçları hızlıca birleştirip statik siteye koyabilmek çok pratik
    • Claude web’de de HTML isteyince bunu yapıyor. Artifact olarak verdiği için modelin bu kalıba iyi eğitilmiş olma ihtimali yüksek

  • Web teknolojileri gerçekten pek çok şeyi doğru yaptı. İnsanlar çok şikâyet ediyor ama etkileyici
    Önceki işimde vibe coding ile yapılmış uygulamalarla uğraştım ve sonunda bu yüzden ayrıldım; çünkü Next.js tek sayfalık frontend ile ayrı API backend yapısında kullanıcıya görünen URL’ler backend endpoint’leriyle örtüşmüyordu. AI her şeye React hook’ları kullandığı için state bellekte tutuluyordu ve URL tabanlı routing, özellikle düşünülüp tasarlanmadıkça ortada olmuyordu. Sonuç olarak linkler bedavadan ortaya çıkmıyor, kullanıcılar da en üst giriş noktası dışında hiçbir yere bağlantı veremiyordu. Linkten bahsediyorum. Özellikle iç araçlarda her şeyin linklenebilir olması gerekir ki işbirliği ve sorun çözme kolay olsun. Birleşik kaynak konumu ve fiiller gerektiren bu tasarım, 30-40 yıl önce gerçekten çok iyi düşünülmüş bir şeydi

    • Yani başka sayfalara veya sekmelere geçildiğinde URL güncellenmiyor muydu?

  • HTML ile Markdown arasındaki ödünleşimde burada eksik kalan birkaç nokta var. HTML’in token verimliliği çok daha düşük ve HTML planına net geri bildirim vermek Markdown’a göre daha zor
    Bu iki ödünleşim Anthropic’in lehine çalışıyor. HTML’i ortam olarak kullanırsanız token kullanımı artıyor ve Claude Design’ın bir parçası olarak HTML üzerinde açıklama/işaretleme araçlarına yatırım yapıyor olabilirler; bu da lock-in’i güçlendirebilir. Tesadüf de olabilir, müthiş bir strateji de

    • Biraz daha az verimli ama yapısal ya da görsel öğe çok fazla değilse fark devasa olmuyor
      Neden Markdown’a göre daha zor net geri bildirim verildiğini de pek anlamıyorum. Etiketler üzerinden id, section vb. koyulabilir
    • HTML’de kod çalıştırma açıkları için alan da daha geniş. Düz metin zararlı değildir

  • On yıllardır HTML’le uğraşıyorum ama basit belgelerde hâlâ Markdown daha hızlı. Arada bir orta nokta olsa güzel olurdu; aslında GitHub Markdown gibi daha özellikli şeyler zaten var
    Mermaid gömebilirsiniz, gerektiğinde component karıştıran MDX gibi şeyler de kullanılabilir. Bildiğim kadarıyla readme.com da içeride MDX kullanıyor. Kartlar veya düzen gerekiyorsa Bootstrap benzeri bir şey temelli component’ler de eklenebilir. Eksik olan artık sadece arayüz desteği. Saf HTML zaten render edilebildiğine göre daha güçlü bir Markdown eklemek de çok zor görünmüyor

    • MDX’in mükemmel ara nokta olduğunu düşünüyorum. Bu yorum sayesinde düz Markdown yerine MDX kullanmaya başlamayı düşünüyorum

  • Orijinal Markdown spesifikasyonu [1] ve CommonMark [2] ikisi de inline HTML desteğini açıkça tanımlar. Bu yüzden kullanım durumuna göre iki tarafın avantajlarını bir ölçüde birlikte alabilirsiniz
    Çoğunlukla normal Markdown başlıkları ve paragrafları yazarsınız; görseller ve tablolar da HTML etiketi olmadan kaynak hâliyle okunabilir kalır. Yazarın örnek verdiği SVG gibi bir şey eklemek isterseniz SVG’yi doğrudan gömersiniz; bakan kişi de Markdown’ı tercih ettiği görüntüleyiciyle render eder. VS Code’da ham Markdown dosyasına bakarken HTML etiketi görürseniz Cmd+Shift+V ile önizlemeyi açmanız yeterli. Elbette etkileşimli düğmeler, tamamen özel stillendirme olan gerçek bir web sayfası için bu yaklaşım zorlanır; ama ağırlıkla metin/görsel/tablo kullanıp araya sadece ek öğeler serpiştirmek istiyorsanız epey ileri gidebilir
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • Bence Markdown belgeleri önizleme gerektirmemeli. O noktada doğrudan HTML belgesi yapın gitsin

  • Ocaktan beri kod dışı amaçlar için bu yaklaşımı güçlü biçimde savunuyorum. Kritik özellik şu: düzenlenebilir, LLM’in ve insanın anlayabildiği, render edilebilen ve kademeli biçimde değiştirilebilen tek bir doğruluk kaynağı olması
    Sıradan insanlarla AI çalışmaları hakkında sık sık konuşuyorum; sokakta AI sohbetine denk gelince bir antropolog gibi araya girdiğim bile oluyor. HTML artifact’leri yeni nesil tarayıcı adres çubuğu gibi. Nasıl bazı kullanıcılar o çubuğun aslında Google olduğunu sanıyorsa öyle. Bugünlerde pek çok insan “spreadsheet”, “sunum”, “tek sayfalık pazarlama özeti”, “slayt gösterisi”, “rekabet analizi”, “HVAC sistem diyagramı” gibi şeylerden söz ederken ChatGPT veya Claude web içinde çalışmanın pek iyi olmadığını, buna karşılık Claude Code ya da OpenClaw ile yeni belge üretmenin mucize gibi geldiğini söylüyor
    Gerçek belgenin ne olduğunu ve deneyim farkının tam olarak nereden geldiğini sorduğunuzda, bilgisayar terimleri henüz oluşmadığı için epey sorgulamak ya da doğrudan göstermelerini istemek gerekiyor; ama sonuç hep artifact’in HTML olduğu yere çıkıyor. Keyifli deneyim, dosya sistemindeki HTML dosyasını (+CSS+görseller) yüksek kaliteli anlık render ile iteratif biçimde düzenlemekten geliyor; gerektiğinde biraz JavaScript de serpilebiliyor. Bir git sistemi varsa kişi farkında bile olmadan versiyonlama yapmış olabilir. Yoksa checkpoint almalarını öneriyorum. Sıradan kullanıcılar için versiyon kontrolü belki de sonraki öğrenme aşaması
    Buna karşılık web’e gömülü deneyim, bağlam penceresinin içinde kalan DOCX/PPTX/XLSX dosyalarını tekrar tekrar dürtmek ve yerel depolama hakkında bulanık bir kavramla uğraşmak gibi. Aslında yan çubukta HTML olarak render ediliyor olsa bile öyle. HTML iş akışı başka ortamları da çok daha kolay entegre etmeyi sağlıyor. Sonuçta bu tür sunum işleri kitlelerin vibe coding’i hâline geliyor ve alttaki kaplumbağaların hepsini bilmek gerekmiyor. Yine de isterseniz açıp düzenlemek veya başka bir agente kolayca devretmek mümkün. İşbirlikli multimedya iletişimi için kurulmuş bir sistemin, artık makine zekâsının iletişimimize yardım etmesinde işe yarar hâle gelmesi gibi

  • Eskiden bizim (https://www.definite.app/) agent, raporları ve dashboard’ları frontend framework’ünün render ettiği bir YAML spesifikasyonu olarak yazıyordu
    Mesela kullanıcı “Aylık geliri ve sipariş sayısını gösteren, ayrıca son 100 siparişi listeleyen bir rapor oluştur” dediğinde agent, frontend’de render edilecek spesifikasyonu yazıyordu. Bu yöntem hızlıydı ama framework’ün render edebildiği şeylere yönelik özellik isteklerinin altında kaldık. “Buradaki etiketi kaldırmak istiyorum”, “Şurada etiket gerekli”, “Bu grafiği heatmap yapabilir misiniz” gibi talepler geliyordu. Birkaç aydır agente doğrudan HTML yazdırıyoruz; üretim daha uzun sürüyor ama özelleştirme sınırı kalmıyor. Yeni yaklaşımda da teknik olmayan kullanıcıların kendi yarattıkları ucube uygulamayı debug etmesi gibi sorunlar var, ama genel olarak müşteriler bunu çok daha fazla seviyor

    • Bu durumda prompt injection’ı nasıl engelliyorsunuz?

  • Uzun agent çıktıları için VIM ve macOS Quick Look’u (Markdown render uzantısı ile) kullanıyorum ya da önizleme paneli olan MarkEdit’e yapıştırıp okuyorum
    En kötü ihtimalle agente Markdown’ı yorumlayıp render eden basit bir yerel web sayfası yaptırabilirsiniz. Markdown, web sözdiziminin kısaltılmış bir biçimi olarak icat edildi[0] ve tam da bunun için var. Agente temel Markdown’ı HTML’e dönüştürmesini söylemenin token ve zaman maliyeti, bu yöntemlerden muhtemelen daha yüksek olur
    0. https://daringfireball.net/projects/markdown/

    • Muhtemelen daha fazla token harcatır ama yazar Anthropic’te çalıştığı için token maliyetini bizzat ödememiş olabilir
    • Sonuna kadar vibe gitmek istiyorsanız, uzun çıktıları da bota özetletseniz olmaz mı?
      Bot kullanımı gerçekten baş döndürücü ve kendine referans veren bir noktaya gidiyor
    • Hangi Quick Look eklentisi olduğunu merak ettim. İyi bir tane arıyordum