JustHTML’i Python’dan JavaScript’e taşımak: Codex CLI ve GPT-5.2 ile 4,5 saatte tamamlandı

 (simonwillison.net)
7 puan yazan GN⁺ 2025-12-19 | 1 yorum | WhatsApp'ta paylaş
  • HTML5 ayrıştırıcısı JustHTML’in Python’dan JavaScript’e tamamen taşındığı bir örnek; Codex CLI ve GPT-5.2 kullanılarak yaklaşık 4,5 saatte hayata geçirildi
  • Yeni kütüphane JustJSHTML, bağımlılığı olmayan bir HTML5 ayrıştırıcısı olarak html5lib-tests’teki 9.200 testi geçti ve özgün API tasarımını birebir yeniden üretti
  • Tüm süreç 8 istem ve birkaç ek komutla ilerledi; GPT-5.2 9.000 satır kod ve 43 commit’i otomatik oluşturdu
  • Proje, otomatik commit, test, dokümantasyon ve playground sayfası üretimi dâhil olmak üzere eksiksiz bir açık kaynak biçiminde tamamlandı
  • Bu deney, LLM tabanlı kodlama ajanlarının gerçek üretkenliğini gösterirken aynı zamanda telif, etik ve güvenilirlik sorunlarını yeniden gündeme getirdi

Projeye genel bakış

  • JustHTML, Emil Stenström tarafından geliştirilen, standartlara uygun bir HTML5 ayrıştırıcısı olup Python ile yazılmış ve html5lib-tests’in tamamını geçen bir uygulama
    • html5lib-tests, HTML5 ayrıştırıcıları arasındaki birlikte çalışabilirlik testlerinin standardı olarak Servo’nun html5ever’ı dâhil çeşitli projelerde kullanılıyor
  • Simon Willison, bu projeyi doğrudan JavaScript’e taşımaya karar verdi ve Codex CLI ile GPT-5.2’yi kullanarak bunu en az düzeyde elle müdahaleyle gerçekleştirdi
  • Ortaya çıkan JustJSHTML, hem tarayıcıda hem de Node.js ortamında çalışıyor ve harici bağımlılık olmadan saf JavaScript ile yazılmış durumda

Geliştirme süreci

  • Yerel ortamda justhtml ve html5lib-tests depoları klonlandı, ardından yeni bir justjshtml dizini oluşturuldu
  • Codex CLI, --yolo seçeneğiyle (onay ve sandbox atlama) çalıştırılarak GPT-5.2 modeli devreye alındı
  • İlk istemde mevcut Python kodunun analiz edilip yeni JavaScript API spesifikasyonunun (spec.md) yazılması istendi
    • Başlangıç aşaması (Milestone 0.5) olarak basit bir HTML belge ayrıştırma testini geçen sürüm uygulandı
  • Sonraki aşamalarda “Implement Milestone 0.5”, “** commit and push often**” gibi komutlarla otomatik geliştirme sürdürüldü
    • GitHub Actions yapılandırılarak her commit’te testlerin çalıştırılması sağlandı
    • Toplamda 43 commit, 9.000 satır kod ve 9.200 testin geçilmesi sonucu elde edildi

Sonuçlar ve çıktılar

  • Codex CLI toplam 2.089.858 token kullandı ve ChatGPT Plus aylık aboneliği kapsamında ek ücret olmadan çalıştırıldı
  • Tamamlanan kütüphane şu özellikleri içeriyor
    • stream(), query()/matches(), toMarkdown() gibi API genişletmeleri
    • bağımlılıksız birim test betiği ve CI entegrasyonu
    • <br> etiketi işleme hatası gibi ayrıntılı bug düzeltmeleri
  • playground.html otomatik üretildi ve tarayıcıda doğrudan test edilebiliyor
  • README.md içinde kullanım, derleme süreci, Node.js ve HTML ortamı örnekleri yer alıyor

LLM kullanımının işaret ettikleri

  • GPT-5.2, yüzlerce araç çağrısını ve saatler süren kesintisiz çalışmayı asgari gözetimle tamamladı
  • Test odaklı problem tanımı mümkün olduğunda, bir kodlama ajanı yüksek tamamlanmışlık düzeyine sahip kodu otonom biçimde üretebiliyor
  • Diller arası taşıma gibi yapısal işler LLM’ler tarafından son derece verimli biçimde yapılabiliyor
  • Kod üretim maliyeti fiilen “neredeyse ücretsiz” seviyesine düşerken, doğrulanmış kodu sürdürmenin maliyeti hâlâ varlığını koruyor

Ortaya çıkan etik ve hukuki sorular

  • Rust ve Python özgün kodlarının telif ihlali oluşturup oluşturmadığı
  • LLM tarafından üretilen kodun telif hakkının kime ait olduğu
  • Bu geliştirme biçiminin açık kaynak ekosistemi üzerindeki etkisi
  • Otomatik üretilen kodun güvenilirliği ve üretim ortamında kullanım sorumluluğu
  • İnsan uzmanların aylar içinde geliştirdiği kodla kalite açısından karşılaştırılabilir olup olmadığı

Sonuç

  • Bu örnek, programlama otomasyonunda yeni bir aşamayı gösteriyor ve yapay zeka kodlama ajanlarının pratik potansiyelini kanıtlıyor
  • Aynı zamanda hukuki ve etik standartların belirlenmesi gereğini ve açık kaynak iş birliği biçimlerinin yeniden tanımlanması ihtiyacını da geride bırakıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-19
Hacker News görüşleri

  • Bu örnekte en ilginç nokta, dilden bağımsız testlere dayanan bir kütüphane portlama projesinin artık çok daha gerçekçi biçimde mümkün hale gelmiş olması
    Buradaki kilit unsur, 9.000’den fazla HTML5 ayrıştırıcı testinden oluşan html5lib-tests paketi. Servo’nun html5ever’ı (Rust), Emil’in JustHTML’i (Python) ve benim JavaScript sürümüm bu testleri kullanıyor
    Kodlama ajanını kullanarak Python kodunu JavaScript’e portlayabildim ve tüm testleri geçene kadar otomatik olarak tekrar tekrar çalıştırabildim
    Bu tür standartlaştırılmış test paketleri nadir bulunuyor ama oldukları yerde büyük bir potansiyel gösteriyor

    • WHATWG spesifikasyonu ile html5lib testleri birleşince çok daha güçlü hale geliyor
      Dün birkaç saat içinde OCaml ile tipleri açıkça belirtilmiş bir sürüm yaptım ve saf OCaml HTML5 validator’ını otomatik kurması için ajanı çalıştırdım
      html5lib testleri ile validator testlerini birleştirerek bağımlılığı az olan bir OCaml HTML5 validator’ı yapıyorum
      Bu, adeta tersine biçimsel doğrulama gibi hissettiriyor — dağınık olgulardan (testlerden) yapılandırılmış bir spesifikasyona yaklaşma süreci
    • Dün Python’dan Rust’a portlarken LLM sorunu hiç yakalayamadı. Sonunda Python orijinalini Rust projesine kopyalayıp karşılaştırınca sorun hemen çözüldü
      Diller arası örüntü eşleştirme konusunda epey güçlü görünüyor. Gizil uzay (latent space) açısından bakınca mantıklı geliyor
    • Bir sonraki adım muhtemelen projeye bağımlı testleri bağımsız bir formata dönüştürmek, bunları orijinalle doğrulamak ve ardından portlamak olacak
    • LLM’ler diller arası portlama işinde çok güçlü. MLE-Bench gibi benchmark’larda ajanlar 24 saat içinde Kaggle yarışmalarında madalya düzeyinde sonuçlar çıkarabiliyor
      AI4AI makalesinde olduğu gibi, AI’ın AI yaptığı çağ başlamış gibi hissettiriyor
    • Bu yüzden mevcut projemin testlerini şu an için açık etmemeye karar verdim. Normalde açık kaynak olarak yayımlarım ama bu kez yeniden düşünüyorum

  • Aslında Firefox’un HTML5 ayrıştırıcısı ilk başta Java ile yazılmıştı, daha sonra Gecko için yarı otomatik olarak C++’a dönüştürüldü
    JustHTML’i portlamak başlı başına iyi bir deney ama bana göre Java kodunu TypeScript’e taşımak daha üretken olurdu

    • Şaşırtıcı biçimde Firefox’un Java ayrıştırıcısı hâlâ korunuyor
      İlgili klasöre ve yakın tarihli commit’lere bakınca kasım ayında da güncelleme olduğu görülüyor
    • Daha iyi birçok yöntem vardı ama Emil’in API tasarımı hoşuma gittiği için JustHTML’i temel aldım
      1.000’den fazla commit ile oluşturduğu bu kütüphaneyi bir akşam içinde Python’a portlamayı denemek ilginçti
    • Hukuki açıdan bakınca, dili değiştirilerek portlanan kod da hâlâ türev eser sayılır
      MIT lisansında orijinal telif hakkı bildirimi ile lisans metnini aynen korumak gerekir
      Yani orijinal telif satırının altına kendi telif bilgini eklemek doğru yaklaşımdır
    • Hata ayıklama ve denetim açısından JavaScript ile yazmanın daha iyi olduğunu düşünüyorum
      TypeScript’in avantajı geliştirici deneyimini iyileştirmesi; ancak makine tarafından üretilmiş kodda buna duyulan ihtiyaç azalıyor

  • “Kod neredeyse bedava” söyleminde asıl maliyet, insanların kodu anlayıp değiştirebilmesine bağlı
    LLM’in ürettiği kodda da karmaşık hatalar veya bağlam sorunları söz konusu olduğunda nihayetinde insan müdahalesi gerekiyor

    • Ama bir gün, bakım yapmaktansa sıfırdan yeniden üretmenin daha ucuz ve hızlı olduğu bir dünyaya da varabiliriz

  • Orijinal deponun test sonuçlarına bakınca html5lib-tests’in 9.000 testinin tamamını geçtiği görülüyor
    Ancak tarayıcılar arasında işleme biçimi farklı. Örneğin selectolax, html5lib ölçütüne göre %68 iken Chrome ile karşılaştırıldığında %90’ın üzerinde eşleşiyor

    • Bu bir namespace işleme sorunu. <svg title> SVG’ye özgü bir etiket ve ayrıştırıcının bunu tanıması gerekiyor
      Testleri Chrome’da da çalıştırmak ilginç olabilir

  • Yakın zamanda HN’de paylaşılan "Yazılım maliyeti %90 düştü" yazısıyla da bağlam örtüşüyor

    • Ancak o yazı fazla basitleştirilmiş bir iddia. Simon’ın deneyi ancak dilden bağımsız 9.000 test ve mevcut bir API tasarımı olduğu için mümkün oldu
      Çoğu projede bu koşullar bulunmadığından genellemek zor

  • Telif hakkı ve etik meselesi konusunda ben de bir MIT lisanslı projeyi Claude Code ile Rust/Python sürümlerine portluyorum
    Açık kaynak ruhunun, mevcut kodu iyileştirerek ekosistemi geliştirmek olduğunu düşünüyorum
    Ancak GPL projelerini asla portlamıyorum

    • Lisans ne olursa olsun telif hakkına saygı gösterilmeli ve LLM’in yaptığı port da türev eser kabul edilmeli
    • GPL’i seçen geliştiricinin net bir niyeti vardır; bu yüzden LLM kullanarak lisansı dolanmayı denemek bu ruhu zedeler

  • “Böyle bir şeyi yaptıktan sonra hukuki ve etik sorunları sormak sorumsuzluk” eleştirisi de vardı

    • Ama ben bu tartışmayı tetiklemek için bilerek belli bir risk aldım
      Şu anda önemli olan, bunun “yalnızca mümkün değil, aynı zamanda şaşırtıcı derecede kolay” olduğunu göstermek diye düşünüyorum

  • Oracle yaklaşımı kullanılırsa standart testler olmasa bile bu iş pratik kalabiliyor
    Orijinal programın girdi/çıktıları yakalanıp test olarak kullanılabiliyor ve Hypothesis gibi araçlarla binlerce durum otomatik üretilebiliyor
    Artık kod tabanının yerine test paketinin kendisinin temel varlık haline geldiği bir döneme giriyoruz

    • Hatta akla “yalnızca testlerle tüm uygulamayı inşa etmek mümkün mü” sorusu geliyor

  • GPT-5.2’nin 9.000 satırlık eksiksiz JavaScript kodu üretmesi $28.31 tuttu
    Bu verimle 5–10 yıl içinde junior ve mid-level geliştiricilerin rolü ciddi biçimde azalabilir gibi görünüyor
    Ayrıntı için maliyet hesaplama bağlantısına bakılabilir

    • Ama bu, mevcut bir projeyi portlama açısından ideal bir örnek. Sıfırdan yeni bir kütüphane yapmak hâlâ farklı bir mesele
      Yine de küçük ekosistemlere sahip diller için ciddi ekonomik değişimler yaratacaktır
    • “Yazılım mühendisi” kavramı yok olmayacak; sadece rol ve beklentiler değişecek
    • “Bütün gün yaptığımız iş yalnızca dil portlamak mı?” itirazı da vardı. Gerçek hayat çok daha karmaşık

  • Her AI portlama girişimi başarılı olmuyor. Başarısız örnekler de var → The port I couldn’t ship

    • Başarı büyük ölçüde kaynak koda kıyasla test oranına bağlı
      Hangi projelerin kolay, hangi yaklaşımın daha hızlı olduğuna dair veri birikirse çok ilginç bir analiz çıkabilir
      Simon böyle karşılaştırmalı deneyler yaparsa gerçekten çok ilginç olur