"Sanırım gidip biraz uzanmam gerekecek."

• TLDraw'un Make Real demosunu denedikten sonraki izlenim
• Yapay zekayı kullanarak çizimleri çalışan yazılımlara dönüştüren bir araç
  • OpenAI's GPT-4V kullanarak vektör görselleri HTML/TailWind CSS ve Javascript'e dönüştürüyor

[GN⁺]

Hacker News yorumları

• tldraw’dan Steve. Bu, güvenlik kalıpları berbat olan bir oyuncak proje, bu yüzden kusura bakmayın. Yerelde çalıştırmak ya da kaynak koduna bakmak isterseniz burada: https://github.com/tldraw/draw-a-ui
  Başka örnekleri https://twitter.com/tldraw adresinde görebilirsiniz. tldraw veya bu proje hakkında sorularınız varsa yanıtlayabilirim. Kimsenin işini elinden alacak bir şey değil ama kurcalaması gerçekten çok eğlenceli; daha karmaşık bir örnek de burada: https://twitter.com/tldraw/status/1725083976392437894

  • Hemen piyasaya çıkarmalısınız. Bu gerçekten parlak bir ürün; ayda 5 dolar alıp kullanıcının kendi OpenAI anahtarını getirmesini sağlayabilirsiniz.
    MIT lisansıyla yeni yayımladığım bir lisans sunucum da var. Elixir ile yazıldı ve https://go.robocoder.app’i çalıştırıyor. Kurulumda yardıma ihtiyacınız olursa iletişime geçebilirsiniz: https://github.com/emcmanus/robocoder-server/
  • Steve, parayı nereye gönderiyoruz? Şaka bir yana, oldukça ikna edici bir şey. Oyuncak olabilir ama herkes bununla böyle eğleniyor.
  • Harika proje, lansman için tebrikler. OpenAI anahtarımı girdim ama "you exceeded your current quota, check billing" hatası aldım. Ayda 20 dolarlık OpenAI Pro aboneliği ile oluyor mu, yoksa ek bir yetki mi gerekiyor diye merak etmiştim.
    Yanıtı GitHub README’de buldum. “Kendi API anahtarınızı kullanmak için usage tier 1 erişimi gerekir; mevcut tier’ınızı ve yükseltme yöntemini OpenAI ayarlarından kontrol edin” diyor.
  • Şu akış diyagramı örneği gerçekten kilit nokta; bence bu tür araçlarda birinci sınıf bir kavram olarak ele alınmalı. Oyuncak değil, işe yarar şeyler yapılmasını sağlayan tutamaklar sunmaya başlıyor.
  • Son örnek eğlenceli; bu şekilde geri bildirim verebilmek şaşırtıcı. Oluşturulan uygulamayı ve metni birlikte seçince gerçek girdi olarak ne aldığını merak ediyorum. Daha önce oluşturulan kodu ve yeni metni birlikte mi alıyor?

• Depodaki sistem prompt’u şöyle:

  You are an expert tailwind developer. A user will provide you with a  
  low-fidelity wireframe of an application and you will return  
  a single html file that uses tailwind to create the website.  
  They may also provide you with the html of a previous design that they want you to iterate from.  
  Carry out any changes they request from you.  
  In the wireframe, the previous design's html will appear as a white rectangle.  
  Use creative license to make the application more fleshed out.  
  if you need to insert an image, use a colored fill rectangle as a placeholder. Respond only with the html file.  
  

  Burada "creative license" ifadesinin neden geçtiğinden pek emin değilim. Her üretimde kullanıcı prompt’u şu şekilde:

  [IMAGE_LINK]  
  Turn this into a single html file using tailwind.  
  

  https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
  Normal bir tldraw tuvalinin ekran görüntüsünü alıp bu prompt ile birlikte API’ye göndererek “özel olarak” çalıştırmak da yeterince basit görünüyor.

  • "creative license" gündelik İngilizcede kısıtları fazla dert etmeden, en iyi olduğunu düşündüğün şekilde yap anlamına gelir. Yazılım lisansıyla ilgisi yok gibi görünüyor.

• Facebook mülakat sorusunda çıkan modeli denedim. İki onay kutusu listesi ve işaretli öğeleri birbirine taşıyan iki düğme vardı; gayet doğru yaptı: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...

  • toList.appendChild(item.closest('li')); ifadesinin öğeyi taşıdığını hiç bilmiyordum. Her gün yeni bir şey öğreniyoruz.
  • Ekran okuyucuyla kontrol ettim; düğmeye basınca hiçbir şey duyurulmuyor. Bu bir sorun. “Checkbox B sola taşındı” gibi bir şey söylemesi gerekir.
    Herhangi bir duyuru olmazsa kullanıcı düğmeye bastığında gerçekten bir şey olup olmadığını bilemez. Test sayfası: https://output.jsbin.com/jixoqur/quiet

• Bu güncel demolar, son dönemde makine öğrenmesi/yapay zekâdaki ilerlemenin ne kadar etkileyici olduğunu gösterirken, aynı zamanda dünya çapında milyonlarca geliştiricinin ne kadar tekrarlı ve yaratıcılığı düşük işleri tekrar tekrar yeniden uyguladığını da gösteriyor.
  Çoğu UI ekranı bir-iki paragrafla doğru biçimde tarif edilebildiğine göre, nispeten küçük bir embedding vektörü içinde epey ayrıntılı temsil edilebilmesi de şaşırtıcı değil.

  • Genel yöne katılıyorum ama bu demoların çoğunun özenle seçilmiş örnekler olduğunu da unutmamak önemli. Sosyal medyada yalnızca viral demoları görünce, yapay zekânın karmaşık işlerde gerçekte olduğundan çok daha ileride olduğunu sanabiliyorsunuz.
    Gerçek işlerde yapay zekâyı yoğun kullanmamış teknik olmayan roller buna özellikle açık. Sahada deneyimleyenler genelde daha nüanslı bakıyor: Müthiş faydalı ama çok hata yapıyor ve production seviyesinde sonuç almak için dikkatle elden geçirmek gerekiyor. Bir yapay zekâ iyimseri olarak bile, değerin gerçek olduğunu ve etkileyici demoların gideceğimiz yönü gösterdiğini düşünüyorum; ama ortalama sonuçların abartılı beklentileri yakalaması zaman alacak.
  • Yazılım fikirlerini ifade etmenin pek çok yolu da son derece verimsiz. Asıl ilginç kısım, yani entropi, çok küçük.
    Bu demoda kelimenin tam anlamıyla iki CSS özelliğini ayarlayan iki slider var; dolayısıyla UI spesifikasyonundaki bilgi miktarı yüksek değil. Uygun bir UI belirtim dili olsaydı bu üç satırlık kod olurdu. Zorluk, web UI boilerplate’ini yönetmek zorunda kalmaktan geliyor.
  • Yüzlerce “Hello World” tarzı demonun üzerine binen B2C yapay zekâ hype’ından neden rahatsız olduğumu iyi ifade etmiş. Hava “Aman Tanrım, programlama öldü!” gibi.
    Tuhaf olan şu: HN’de geleneksel no-code platformlardan bahsedilirken ölçeklenebilirlik ve bakım sınırları kolayca fark ediliyor; ama işin içine yapay zekâ girince bu sorunlar bir anda çözülmüş de kara kutunun çıkardığı spagetti için endişelenmeye gerek kalmamış gibi davranılıyor.
  • Bu yalnızca yazılım stack’imizin ne kadar aptalca olduğunu ortaya koyuyor. Her şey “bunu da şunu da, bir de 300 tane gereksiz ayrıntıyı da özelleştirmek isteyebilirsin” mantığıyla yürüyor.
    Aslında istenen şey işlev ile sunumu ayırmaktı. Tesadüfe bakın ki 1996’daki saf HTML web tam da buydu. Bir şey akıl almaz derecede aptalca bir biçimde korkunç şekilde ters gitti ve kimse daha iyisini yapmadı. Onun yerine elimizde gölge efektleri ve iç içe flexbox gibi şeyler kaldı.
  • Tekrarlı ve yaratıcılığı düşük işlerin sürekli yeniden uygulanması yalnızca geliştiricilere özgü bir sorun değil. Veri girişinden muhasebeye, yaratıcı işlere kadar ofis işlerinin çoğu buna giriyor.
    Ofis işlerinin önemli bir kısmı aynı şeyi tekrar tekrar yapmaktan ibaret; farklı şirketlerde de esasen aynı işleri farklı insanlar tekrar ediyor.

• Bu, UI tasarımcılarını, belki de product owner’ları zeki ve yetkin gösteren bir araç gibi görünüyor. Ama gerçek iş yine bugün olduğu gibi programcıya gidecek.
  UI tasarımcısı bir “demo” verebilir; peki bu temel işlev uygulamanın geri kalanına nasıl bağlanacak? Bağlanmayacak.

  • Bunun kesinlikle “Ama şurada zaten çalışıyor! Uygulamaya koymak neden bu kadar uzun sürüyor? Sadece indirsek olmaz mı?” gibi keyifli ve verimli konuşmalara yol açacağı belli.
    GPT’den önce de çok erken prototiplerin veya mockup’ların, iç işlevsellik düzeyleriyle orantılı olarak görsel açıdan da düşük olgunlukta görünmesi gerektiği savunulurdu. Güzel görünen ve dışarıdan “çalışıyor” gibi duran yalnızca UI prototipleri, açıkça açıklansa bile gerçekçi olmayan beklentiler yaratır ve prototipin olduğu gibi production’a dönüşmesi, yani proto-duction olasılığını artırır.
  • Tasarımcının Figma’da bitmiş ürün gibi görünen bir UI göstermesinden hoşlanmıyorum. Yöneticilerin gözünde bitmiş ürün gibi görünüyor ve yinelemeli olması gereken UI tasarım sürecine gerçek dışı beklentiler giriyor.
    Bir yöneticinin onayladığı Figma tasarımının kısıtları yüzünden berbat sistem tasarımının mühendislerin üzerine yıkıldığı projeleri birkaç kez gördüm. Elbette böyle organizasyonlarda daha büyük sorunlar da vardır; ama kolay yüksek sadakatli mockup’lar, wireframe’lere göre bu sorunu daha da kötüleştirdi.
  • Yöntem basit. GPT-4’e yeni bir prompt vermek yeterli: "Thanks. Please connect it to the rest of this code:"
    Daha iyi yapmasını istiyorsanız sonuna "it's very important for my career" de ekleyebilirsiniz.

• Kutuları büyütüp döndüren demolar yapan geliştiriciler artık işlerini kaybedecek gibi görünüyor.

  • Bu yalnızca slider hizalamayı bile beceremeyenler için geçerli.

• Bir müşteriyle yazılımımızı kendi yazılımına nasıl entegre edeceğimizi konuşurken, müşteri ana formun ekran görüntüsünü gönderdi.
  O ekran görüntüsünü ChatGPT’ye verip “Buna benzer bir React formunu Bootstrap ile yap” dedim. Birkaç ayardan sonra kendi yazılımımı bağladım ve birkaç saat sonra sistemin bu kadar hızlı entegre edildiğini gösteren proof of concept karşısında müşteri şaşırdı. Web geliştirmede CSS layout sorunu olduğunda ekran görüntüsünü ChatGPT’ye yükleyip çözümünü soruyorum; tweetteki demo da buna epey benziyor.

  • Temel bir form sayfası yapmak zaten basittir. Şaşırtıcı olan, yaklaşık 25 yıllık web geliştirmeden sonra hâlâ yeni web framework’leri yapıp bunu gereğinden fazla karmaşıklaştırmamız.
    Gösterişli kullanım senaryolarında harika ama yaygın ve temel işler için fazla ağır framework’ler çıkmaya devam etti. Ara sıra istisnalar oldu ama çoğu web geliştiricisi bunları sevmez. CV’de de havalı durmaz; açıkçası kariyeri boyunca web formu yapmak isteyen kaç kişi var ki?
  • Müşteri ilk seferinde hıza hayran kalır. İkinci seferinde bu hızı bekler. Üçüncü seferinde gereksinimler ChatGPT’nin altından kalkamayacağı kadar büyüdüğünde takvim patladı diye kızar.
  • Müşteriyle e-posta veya chat üzerinden konuşuyorsanız, müşterinin de ChatGPT’ye gereksinimlerini size en iyi nasıl aktaracağını sorduğunu hayal edebilirsiniz.
    Sonuçta kaplumbağaların üstünde kaplumbağalar var :+)
  • Ama müşteri kendi verilerini ChatGPT’ye açığa çıkarmak istememiş olabilir.
  • CSS layout sorununu ekran görüntüsünü ChatGPT’ye yükleyerek düzeltmek, aklıma gelmemiş temiz bir fikir. Genelde CSS’i geliştirici araçlarında düzeltecek ve stilleri koda taşıyacak kadar kullanıyorum ama akılda tutulmaya değer.
    Kodlama için ChatGPT’den çok, verileri hızlıca işlemek amacıyla komut satırı pipe’ları veya Bash script’leri kullandım. Komut çıktısını verip istediğiniz biçimlendirme, birleştirme, sıralama ya da ayıklama için Bash istediğinizde, normalde yapmayacağınız debug veya hipotez kontrolü işleri de kolaylaşıyor. Elle de yapılabilir ama yavaş; seçenekleri ve argümanları hatırlamak için arama yapmak veya man sayfalarına bakmak gerekiyor. Kod içinse çoğunlukla GH Copilot kullanıyorum.

• Bana şüpheci diyebilirsiniz ama no-code çözümlerin geleceğine inanmıyorum. Küçük cihaz çözünürlüklerinde düğmeleri hizalamak, farklı dillerde de iyi görünmesi için boşluk bırakmak ve sürekli gelen başka gereksinimler var.
  En fazla, daha soyutlanmış bir dille uygulamaları daha hızlı yapmayı sağlayacak bir şey olur. Bu, tic-tac-toe gibi son derece temel ve yaygın şeylerde işe yarar; özgün işlere uymaz.

  • LLM tabanlı no-code’un büyük sorunu, çıktının deterministik olmaması; sonuçta sürüm kontrolüne ancak çıktının kendisini koyabiliyorsunuz.
    Teknolojiden biraz anlayan onlarca kişinin eskiz çizip “bunu gerçekten yap” düğmesine basarak özellik eklediğini düşünün. Her biri yüzlerce satır kod üretiyor. Günün sonunda birinin o çıktıyı anlaması gerekiyor; çıktı deterministik olmadığı için elimizde kalan tek şey o oluyor.
  • Autotune’a benziyor. Perdeli söyleyebilen zanaatkârlar ilginç şeyler üretmeye devam edecek.
    Aynı zamanda, perdeli söylemeyi öğrenememiş ya da öğrenmek istememiş yeni insanlar, çok daha az çabayla yepyeni müzik türleri ve ana akım pop üretecek. Zanaatkârlar da bazı iş akışlarını güçlendirmek, cilalamak ve hızlanmak için bunu ara sıra kullanacak.
  • Bu demoların önemli bir kısmı, saf no-code yaklaşımını zorlamaktan çok, neredeyse anında çalışan bir wireframe oluşturulabildiğini göstermeye benziyor.
    Canva, Figma gibi araçların bu tür özellikleri agresif biçimde benimseyip yüksek doğruluklu wireframe’leri ve demoları ciddi ölçüde iyileştireceğini düşünüyorum.
  • İlk sezgim de aynıydı. Özelleştirme ve entegrasyon tam bir kâbus olacak. Ama prototipleme için harika.
  • Ya LLM/AI kusursuz hale gelecek ya da biz LLM/AI’ın çok daha kolay kullanabileceği kod ve framework’ler kullanmaya başlayacağız.

• Squarespace, Wix vb. zaten pazarın alt segmentini aldı; almasalardı Hindistan’a dış kaynak kullanımı alacaktı.
  Bu, aynı kavramın doğal evrimi. Bir web sitesi oluşturucunun ürün yöneticisi olsam, böyle bir AI builder entegrasyonuna hemen atlarım. Neredeyse hiç tanımlanmamış karmaşık iş süreçlerinde kesinlikle işe yaramaz ama fotoğrafçılık işi için maliyet hesaplayıcı gibi bir şeyi iyi yapabilir.

  • Çoğu KOBİ’nin hâlâ uygulaması ya da web sitesi yok; varsa da çoğu zaman işe yaramıyor. Niş pazarlar ve iyi araçların girebileceği alan çok büyük.
  • Fikirleri hızlıca yinelemek için interaktif demo ve prototipler üretme aracı olarak faydalı görünüyor. Müşterilerle geri bildirim döngüsünü kısa tutup yanlış anlamaları azaltabilir. Örneğin Figma böyle bir şeyi hayata geçirebilir gibi.
  • Neden yalnızca önemsiz işlerde çalışacağını düşündüğünüzü bilmiyorum. Bu neredeyse inkâr gibi.
    İş süreçleri için workflow yazılımları epey popüler. İnsanların sürükle-bırak ya da interaktif widget düzenleyicilerle benzer işler yaptığı birçok uygulama var; karmaşık formlar, ebeveyn-çocuk ilişkileri ve durum geçişleriyle de başa çıkabiliyorlar. GPT Vision gibi bir şey kullanırsanız widget sürükleyip bırakmayı atlayıp daha serbest çizim araçları ya da elle çizilmiş eskizler kullanabilirsiniz. Bugünün en popüler örneği muhtemelen Notion; çok daha eskiden beri daha karmaşık örnekler de vardı.

• Artık yaşlanmış hissediyorum. Onlarca yıl önce de VB veya Delphi ile bunu neredeyse aynı hızda yapabiliyorduk gibi geliyor. Sadece araç etiket adlarından çıkarım yapmak yerine sonuç biraz daha deterministikti.
  Aslında böyle şeylere zaten sahiptik; her şeyi tarayıcıya tıkıştırmadan ve üretken yapay zeka modellerinin devasa hesaplama gücünü kullanmadan da yapılabildiğini unuttuk. Kendimi bulutlara bağıran yaşlı adam gibi hissediyorum.

  • Benzer düşünüyorum. Biraz daha kışkırtıcı söylemek gerekirse, insanlar AI ile Figma’yı HTML’e çevirmeyi gösterdiğinde “Dreamweaver’ı duydunuz mu?” diyorum.
    Elbette Dreamweaver kodu çirkindi ve kullanılamaz düzeydeydi; AI tarafından üretilen kod ise bazen o kadar kötü olmuyor. Yine de bugünkü noktaya zaten epey yaklaşmıştık gibi.
  • Bu tarayıcı meselesi değil; framework’ün ne kadar güçlü kanaatlere sahip bir tasarım sunduğu meselesi.
    VB çok güçlü kanaatleri olan bir araçtı ve yalnızca yerel Windows tarzı UI’lar üretiyordu. Bir tasarımcının getirdiği herhangi bir mockup’ı, tamamen özelleştirilmiş bir look and feel’i piksel piksel VB’de kopyalamak diye bir şey yoktu. Günümüzde çoğu ürünün GUI’si markanın bir parçası. İyi ya da kötü, her şirket kendine özgü bir look and feel ve UI davranışı istiyor. Bu yüzden onu üreten aracın çok daha karmaşık olması gerekiyor. Tarayıcıda da VB’yi yeniden yaratabilirsiniz; hatta benzerini yapan birçok kişi oldu. Ama şirketler sıkıcı ve genel UI istemediği için ürün geliştirmede pek kullanılmıyor.
  • Demek istediğinizi anlıyorum ama bu yalnızca en basit örnekler için geçerli. Bu araç birçok şey yapabiliyor. O thread’e daha fazla bakarsanız tic-tac-toe da uyguluyor.
    Temelde diyagram ekran görüntüsünü GPT-4’e gönderip “bunu uygula” demek şeklinde çalışıyor.
  • Uzun zaman önce Comdex grafik fuarında, bir sonraki aşama diye tanıtılan taze bir işletim sistemi vardı. İri yarı bir nerd, fareyle bir şeyleri sürükleyip bırakarak uygulama yapmak için programcı olmanız gerekmediğini “kanıtlıyordu”.
    Ondan 10 yıl sonra, o dönemde nispeten yeni bir dil olan Java için aynı şeyi sunan Visix Vibe diye bir şey 1-2 yıl kadar ortalıkta dolaştı. Birkaç yılda bir, kabaca 4-5 yılda ya da 10 yılda bir, birileri tüm karmaşıklığı ortadan kaldırmak ister. Ama sonunda işletim sistemi yaparlar.
  • Başlıca yerel UI toolkit’lerini kullanırsanız bugün hâlâ buna benzer şeyler görebilirsiniz. RAD kadar hızlı olmayabilir ama web’de özelleştirilmiş ve genellikle kırılgan JavaScript gerektiren türlü öğe ve etkileşim “bedavaya” gelir.
    Üstelik gerçekten düzgün çalışır, toolkit’in geri kalanıyla beklenen şekilde etkileşir; uluslararasılaştırma ve erişilebilirlik de tutarlı biçimde iyi işler. HTML’in varsayılan olarak çok daha fazla şeyi sunmaması için bir neden yok; bunu yapsa her yıl muazzam miktarda geliştirici zamanı ve kullanıcı hayal kırıklığı azaltılabilir. Ama yapılmıyor.