- Ghostty’nin macOS için rahatsız etmeyen otomatik güncelleme bildirimi özelliğini ağırlıklı olarak yapay zeka ajan tabanlı kodlama araçlarıyla geliştirme sürecinin tamamı paylaşılıyor; 16 oturumda 15,98 dolarlık token maliyetiyle yaklaşık 8 saatte gerçekten dağıtıma uygun bir özellik tamamlandı
- OpenAI keynote sırasında Ghostty güncelleme isteminin demoyu bozması üzerine, işi kesintiye uğratmadan başlık çubuğunda ya da pencerenin altında küçük bir GUI öğesi ile güncelleme durumunu gösteren non-modal bir yaklaşıma geçilmesine karar verildi
- Yapay zekaya başlamadan önce Sparkle framework’ünün özel UI protokolü ile başlık çubuğu aksesuar denetleyicisini kullanan kabaca bir backend/frontend planı önce kuruldu ve yapay zeka bir prototipleme aracı olarak kullanıldı
- UI prototipleme, hata çözümü başarısız olduğunda yön değiştirme ve tekrarlayan temizlik oturumları (dokümantasyon, refactoring) üzerinden gelecekteki yapay zeka oturumlarının performansını artırma, simülasyon kodu üretme gibi aşamalı bir yaklaşım kullanıldı
- Yapay zeka çalışırken aile için kahvaltı hazırlamak gibi başka işlerin yapılabildiği asenkron çalışma biçiminin değeri vurgulanırken, yapay zeka tarafından üretilen tüm kodların dağıtımdan önce titiz bir manuel incelemeden geçirildiği ve anlaşılmayan kodun asla dağıtılmadığı ilkesi korundu
Özellik özeti
- Tamamlanan özellik, macOS’ta pencereyi kapatmayan rahatsız etmeyen güncelleme bildirimi
- Pencere oluşturmak ya da odağı ele geçirmek gibi iş akışını bozmadan terminal penceresi içinde güncelleme durumunu gösteriyor
- OpenAI keynote sırasında Ghostty güncelleme isteminin görünmesi, UX iyileştirmesi gereğini ortaya koydu
- Güncelleme bildirimini müdahaleci olmayan bir yapıda yapmaya karar verildi
- Açılır pencere yerine kullanıcıyı rahatsız etmeyen küçük bir non-modal GUI öğesinin bir yerde gösterilmesi benimsendi
- Bildirimin konumu varsayılan olarak başlık çubuğunun sağı olacak şekilde, ancak başlık çubuğunun gizli olması gibi stiller için pencere altı overlay gibi alternatifler de sunuldu
- Geliştirme sürecinin genelinde yapay zeka ajanları kullanılırken, doğrudan manuel düzeltme, cilalama ve nihai inceleme ile birlikte insan yönlendirmeli yardımcı araç stratejisi benimsendi
Yapay zeka kullanmadan önce plan oluşturma
- Yapay zeka aracını açmadan önce önce kabaca bir plan yapıldı
- Backend için kabaca bir fikir edinildikten sonra frontend tasarımına geçildi
- Başlık çubuğuna küçük bir buton gömmeye yönelik belirsiz bir fikir vardı
- macOS’un başlık çubuğu aksesuar denetleyicisi üzerinden başlık çubuğunda özel UI’ı desteklediği biliniyordu, ancak bunun somut görünümü ve hissi net değildi
- Yeterli bir başlangıç noktası elde edildiği için çalışmaya başlanabildi
- Yapay zeka çok iyi bir prototipleyicidir, bu yüzden neyin bilinmediğini bilmek bile başlamak için yeterlidir
- Büyük resme dair yeterince güçlü bir sezgi vardı
İlk oturum: UI prototipleme
- İlk ajan tabanlı kodlama oturumunun başlangıç prompt’u
- SPUUserDriver özelleştirilerek müdahaleci olmayan güncelleme bildirimi ve kurulum etkinleştirme isteği yapılması
- Yalnızca UI çalışması yapacak şekilde sınırlandırılması
- SPUUserDriver’ın gerektirdiği çeşitli durumları gösterebilen bir SwiftUI view oluşturma planı istenmesi
- Bunu macOS pencere başlık çubuğunun sağ üstünde gösterecek planın hazırlanmasının istenmesi
- Oracle nedir? - Amp’e özel salt okunur alt ajan; daha yavaş ve daha pahalı bir model kullanır, genelde akıl yürütmede daha iyidir
- Önce UI prototipine odaklanmaya karar verildi
- Ajana tüm özelliği baştan sona kurması söylenmedi
- Birincisi, UI/UX’in nasıl görünmesi gerektiği henüz bilinmediği için yapay zekadan bunu diğer değişikliklerle birlikte tutarlı biçimde yapması beklenemezdi
- İkincisi, küçük iş parçaları incelemek, anlamak ve yinelemek açısından daha kolaydır
- Yalnızca plan yazması istendi ve kod yazmaması özellikle belirtildi
- Görece muğlak bir istek olduğundan, çok iş yapılmadan önce (ve çok token harcanmadan önce) planı gözden geçirmek önemliydi
- İpucu: Ajanla kapsamlı bir planı etkileşimli biçimde oluşturmak, açık olmayan işlerde kritik ilk adımdır
- Bu genellikle
spec.md gibi bir dosyaya kaydedilir ve sonraki oturumlarda "@spec.md’ye bakıp şu işi yap" denebilir
- Ajan yeterince üzerinde uzlaşılabilir bir plan sundu ve uygulamaya geçmesine izin verildi
- Ürettiği UI yön duygusu açısından çok iyiydi
- Boşluklar, renkler vb. konusunda birçok cilalama sorunu vardı ama UI’ı görmek istenen şeye dair ilham kıvılcımı verdi
- İpucu: İlham almak için yapay zeka çok sık kullanılır; bu örnekte üretilen UI kodunun önemli bir kısmı (tamamı değil) korundu, ancak bazen ajana prompt verilip her şey çöpe atılarak elle baştan çalışıldığı da çok sık olur
- Üretimin “sıfırdan bire” aşaması çok zor ve zaman alıcıdır; yapay zeka da mükemmel bir ilham perisi olabilir
Duvara toslama
- Sohbet 11~14 civarında slop zone’a girildi
- Ajanın ürettiği kodda ciddi hatalar vardı ve bunları düzeltmede tamamen başarısız oldu
- Ben de nasıl düzelteceğimi bilmiyordum
- Hataları düzeltmek için birkaç umutsuz deneme yapıldı
- Ajan çözebilirse incelenip öğrenilebilir
- Çözemezse maliyeti neredeyse yoktur
- Ajan çözdüyse ama nedenini anlamadıysam geri alırım; anlamadığım kodu dağıtmam
- Bunlar başarısız olurken sekme değiştirip sorunu araştırarak kendi başıma çözmeye çalışırım
- Bu noktada geri çekilip yapılan işi gözden geçirmek ve kendi planını kurmak gerektiği fark edildi
- Kendi kendini eğitmek ve eleştirel düşünmek için zaman ayırmak gerekiyordu
- Yapay zeka artık çözüm değil, teknik borçtu
Temizlik oturumları
- Sonraki birkaç oturum, ajan yönlendirilerek kodun temizlenmesine harcandı
- İkinci oturum: bazı metotlar daha iyi bir konuma taşındı
- Dolgu arka planı, ön plan ve badge fonksiyonları UpdateAccessoryView.swift’ten UpdateViewModel.swift’e taşındı ve daha genel hale getirildi
- Üçüncü oturum: koda dokümantasyon eklendi
- UpdateBadge.swift dokümantasyonu güncellendi
- İpucu: Dokümantasyon eklemek, kodu gerçekten anlayıp anlamadığını yeniden doğrulamanı sağlar ve gelecekte bu kodu okuyup değiştirecek ajanların eğitilmesine yardımcı olur
- Ajanlar hem doğal dil açıklamalarına hem de koda sahip olduklarında çok daha iyi performans gösterir
- Dördüncü oturum: view model uygulama geneli bir konuma taşındı
- Başlangıçta iş pencere kapsamına yerleştirilmişti ama güncelleme bilgisi uygulama kapsamındaydı
- Bu süreçte genelde küçük manuel değişiklikler de birlikte yapıldı
- Temizlik aşamasının önemi
- Etkili biçimde temizlik yapmak için kodun oldukça iyi anlaşılması gerekir; bu da yapay zekanın yazdığı kodun körü körüne kabul edilmesini engeller
- Daha iyi yapılandırılmış ve belgelenmiş kod, gelecekteki ajan tabanlı oturumların performansını artırmaya yardımcı olur
- Buna şaka yollu “anti-slop oturumları” denildi
Hatalarla yüzleşmek
- İlk oturumlarda bulunan bug’a geri dönmek için zaman ayırdım
- Ajanın bunu kavramasını sağlamak için birkaç oturum daha harcadım
- Belirsiz başlayıp yaklaşımı giderek daha somut hale getirdim
- İlk belirsiz oturum: standart yerel sekmelerde güncelleme aksesuar görünümü görünmüyor, pencerenin başlık çubuğunda sürekli görünür kalması gerekiyor - başarısız
- İkinci daha somut: sekme çubuğunun sağ kenarını güncelleme aksesuar görünümünün sol kenarına hizalamak için TerminalTabsTitlebarTahoe.swift içindeki sekme çubuğu kısıtlarını güncelle - başarısız
- Üçüncü farklı somut yaklaşım denemesi: TitlebarTabsTahoeTerminalWindow.swift dosyasını değiştirip sekme çubuğunu alt aksesuar görünümü yerine üst aksesuar görünümü haline getirerek sekmeleri başlık çubuğuna taşımak nasıl olur - başarısız
- Son deneme: sağ aksesuar görünümü ve düzen, TerminalWindow.swift içindeki güncelleme aksesuar görünümü ayarıyla çakışıyor; sekme çubuğu her zaman güncelleme bildiriminin solunda görünecek şekilde kısıtlanabilir mi - başarısız
- Bu sürecin tamamı boyunca manuel araştırma ve insan emeğiyle kendi başıma çözmeye de çalıştım
- Daha somut prompt’lar bu süreçte öğrendiklerime dayanıyordu
- Genel olarak net biçimde işe yaramadı
- Bunu tek başıma çözemeyeceğime karar verip yön değiştirmeye karar verdim
- Sorunlu başlık çubuğu stili için güncelleme bildirimini başlık çubuğuna değil, pencerenin içerik görünümünün üstüne bindirilmiş sağ alt köşeye yerleştirdim
- Ghostty’de başlık çubuğunu tamamen gizleyen bir yapılandırma bulunduğundan zaten bunu desteklemek gerekiyordu
- Daha sonra başlık çubuğu stili sorununu çözebilsem bile bu farklı modu yine de desteklemem gerekecekti
- Sonraki oturum bu planla ilerliyor ve çok somut prompt’lar kullanıyor
- Update sistemini genişletip TerminalView.swift içinde overlay yaklaşımını da destekledim
- Güncelleme bildirimi pencerenin altında görünmeli ve metnin üstünde yer almalıydı, dolayısıyla terminal görünümü yeniden boyutlandırılmıyordu
- Tüm tıklama davranışları aksesuar görünümüyle aynıydı
- Gerçekten çok iyi iş çıkardı; sonrasında çok sayıda manuel cila işi yaptım (taşıma, yeniden adlandırma vb.) ama ana iş sağlamdı
Backend başlangıcı
- UI’ın yeterince iyi olduğunu hissettim
- Daha sonra ele almak istediğim çok sayıda cila sorununu not ettim ama esas olarak planı bozabilecek bilinmeyen bilinmeyenleri keşfetmek için backend işine geçmek istedim
- Eksik fonksiyonlar ve çeşitli
TODO yorumları içeren iskelet dosyayı manuel olarak oluşturdum. Yeni oturum başlatıldı
- UpdateDriver.swift dosyasını tamamlamasını istedim, özellikleri anlaması için Sparkle dokümantasyonunu okudu
- İpucu: AI boşluk doldurma ya da baykuşun geri kalanını çizme konusunda çok iyidir
- Açıklayıcı fonksiyon adları, parametreler, todo yorumları vb. ile iskelet oluşturma paterni çok yaygındır ve iyi çalışır
- Aslında çok kötü bir iş çıkardı ve bu kodun tamamını attım
- Üretilen kod çalışıyordu ama yaklaşım açıkça yanlıştı
- Birçok farklı kaygıyı birbirine karıştırmıştı ve driver içinde durum saklama biçimi bariz şekilde yanlıştı
- Yaptığı işi incelediğimde view model’in en iyi olmayan bir şekilde yapılandırıldığını fark ettim
- AI’a (ve elle yazmayı seçseydim insana da) daha iyi bir çerçeve sunmak için temizlik moduna geçtim
Büyük yeniden temizlik
- Deneyimlerime göre UI frontend ile iş mantığı backend’inin temizliği çoğu zaman aradaki view model’in kalitesi tarafından belirleniyor
- View model’i manuel olarak yeniden düzenlemeye zaman harcadım
- Çok sayıda optional içeren struct yerine tagged union’a geçtim, bazı tip adlarını değiştirdim, taşıdım
- Deneyimlerime göre ortadaki bu küçük manuel çalışma, gelecekte hem frontend hem backend oturumlarında ajanı başarıya götürecekti
- Yeniden yapılandırmayı tamamladıktan sonra yaptığım ilk şey ajandan bir kez daha baykuşu tamamlamasını istemek oldu
- Bu kez değişiklikleri inceledi, bağımlı kodu yeni stile göre güncelledi ve eski kodu kaldırdı
- Bir dizi maraton temizlik oturumu devam etti
Simülasyon
- İlk UI oturumunda ajandan, gerçek güncelleme kontrolü olmadan UI’ı gerçekten görebilmek için demo kodu üretmesini istedim
- Güncelleme akışında birden fazla senaryo vardı ve o noktaya kadar sadece happy path’i test etmiştim
- Sonraki oturumda simülasyon kodunu özel bir dosyaya çıkardım ve ajandan daha fazla senaryo üretmesini istedim
- AppDelegate.swift içindeki güncelleme simülasyonu kodunu Features/Update altında özel bir dosyaya taşıdı
- Birden fazla simülasyon senaryosu (happy path, bulunamadı, hata vb.) ekleyerek farklı demoları kolayca denemeyi sağladı
- İpucu: Ajanlar test ve simülasyon üretiminde çok iyidir
- Burada üretilen simülasyon kodu açıkçası oldukça korkunç ama çalışıyor ve release binary’nin bir parçası olmadığı için kalite önemli değil
- Oturumda görülebilen temel şeylerin ötesinde bunu toparlama zahmetine bile girmedim
- Çeşitli simülasyonları çalıştırdım ve bir dizi UX iyileştirmesi keşfettim
Son adımlar
- Bu noktada çalışan bir backend ve frontend vardı ve hepsinin birbirine bağlanması gerekiyordu
- Sonraki oturumda ajana şu prompt’u verdim
- Sparkle’daki SPUStandardUpdaterController.m ile aynı ama updater türü için bir UpdateController sınıfı oluştur
- Biraz gidip gelme ve manuel cila gerekti ama sonuca ulaştı
- Sonrasında küçük iyileştirmeler ekledim
- Appcast bulunan güncellenebilir durumlar için SUAppcastItem’ı inceleyip, ayarlıysa ilgili diğer metadata’yı da göster
- Örneğin boyut için content length
Başka ne var?
- Ajan için son prompt her zaman neyin gözden kaçtığını sormak
- Kodu elle doğrudan yazmış olsam da olmasam da bu adımı uyguluyorum
- Features/Update özelliğinde yapılabilecek başka iyileştirmeler var mı, kod yazmadan, Oracle danışmanlığı gibi düşünerek, daha fazla birim testi eklenebilecek kod bölümlerini değerlendirmek
- Gerçek bir sorunu vurguladığım için, bunu uygulamasını istedim
- Sonradan seçmeli commit'lerde kolayca temizlenebildiği için, yapılacak spesifik şeyleri sormaktansa ajana "hepsini yap" demenin daha kolay olduğunu fark ettim
- Bu oturumun eğlenceli yanı, ajanın gerçekten çılgın bir tavşan deliğine girmeye başlamasıydı ve durdurmak için araya girdim
- "Dur dur dur. Tüm ana aktör öğelerini iptal et"
- Ayrıca daha iyi bir yol olduğunu ama biraz kötü uyguladığımı da fark ettim
- Hata mesajlarında kesmek yerine SwiftUI'nin standart bir yolu yok mu, tam mesajı görebilmek için ek bir UI öğesi gerekli
Maliyet ve zaman
- İş, toplam 16 ayrı oturumda Amp üzerinde 15,98 $ token harcamasıyla tamamlandı
- Bunun genel olarak pahalı mı ucuz mu olduğuna dair tahminde bulunmayacağım ama kişisel olarak bu özellik için harcadığım 2 gün boyunca kahve dükkânında bundan daha fazlasını harcadım
- Bu özelliğe harcadığım toplam gerçek zamanın yaklaşık 8 saat olduğunu tahmin ediyorum
- İlk ve son commit 3 güne yayılıyor ama günde yaklaşık sadece 4 saat bilgisayar başında çalıştım
- Tüm zamanımı sadece bu özelliğe harcamadım
- Örneğin bu özellik üzerinde çalışırken Ghostty güncellemesini yayımladım, ThePrimeagen'e 1 saatliğine konuk oldum ve Zoo'nun yıllık şirket çapı etkinliğinde konuk sunum yaptım
- Evde küçük bir çocuğum olduğu için "bilgisayar zamanı" çok planlı ve çok sınırlı
- Bu yüzden 8 saatlik tahmin cömert bile olabilir
- İnternette birçok kişi yapay zekanın daha hızlı çalışmayı sağlayıp sağlamadığı konusunda tartışıyor
- Bu durumda, her şeyi tek başıma yapsaydım olacağından daha hızlı teslim ettiğimi düşünüyorum
- Özellikle ufak SwiftUI stil yinelemeleri bana kişisel olarak fazla sıkıcı ve zaman alıcı geliyor, yapay zeka ise bunu çok iyi yapıyor
- Daha hızlı/daha yavaş tartışmasından çok sevdiğim şey şu: yapay zeka ben başka işler yaparken benim için çalışabiliyor
- Temizlik oturumlarından birinin ekran görüntüsünü ailem için kahvaltı hazırlarken aldım
- "Yemek yaparken kod yazmak istemiyorum" ya da "anda daha çok kal" gibi her türlü itiraz var
- Bunu yapmak istemiyorsanız sorun değil; benim durumumda bu özel örnekte evde ilk uyanan kişiydim ve diğer herkes hâlâ uyurken kahvaltı hazırlıyordum
- Uyanık olduğum her an bunu yapmıyorum
- Sonuç: bende işe yarıyor
- Kimseyi ikna etmeye çalışmıyorum
- Herhangi bir AI şirketiyle finansal bir bağlantım yok
- AI araçlarıyla çok başarı elde etmiş ve bunun hakkında konuşmayı seven biri olarak insanlar sürekli örnekler paylaşmamı istiyor
- Burada yaptığım şey de bu
Sonuç
- Özellik güzel ve harika çalışıyor; son manuel incelemeden sonra birleştirildi
- "Son manuel inceleme" çok çok çok önemli, yapay zekanın yazdığı kodu kapsamlı bir manuel inceleme olmadan dağıtmayın
- Ghostty kullanıcılarından tip sürümlerini kullananlar için şu anda mevcut
- Etiketlenmiş sürümleri kullananlar için Ghostty 1.3 ile kullanılabilir
- Ben, agentic coding oturumlarını kamuya açık şekilde paylaşmanın öneminin açık sözlü bir savunucusuyum
- Sebeplerden biri, bu araçların etkili kullanımını başkalarına öğretmenin inanılmaz derecede güçlü bir yolu olması
- Umarım bu gönderi bunu göstermeye yardımcı olur
2 yorum
Hacker News görüşleri
Ben AI'yi sık sık bir ilham aracı olarak kullanıyorum; bu sefer de UI kodunun büyük kısmını AI'nin üretmesine izin verdim, ama bazen ajanı çalıştırıp ortaya çıkan her şeyi çöpe atıyor ve sonra kendim baştan yazıyorum (elle!). "Sıfırdan bire" yaratım aşaması her zaman çok zor ve zaman alıcı olduğundan, AI'nin benim için bir ilham perisi gibi çalışması gerçekten mükemmel. Kod ajanlarının en büyük avantajı tam olarak bu. Pek çok kişi AI merkezli projelerde bakım veya karmaşa sorunundan endişe ediyor ama ben etmiyorum. Projeyi gerçekten kurcalayıp özelliklerini deneyebileceğim ve sürekli düzeltebileceğim bir aşamaya hızlıca gelebilirsem, ondan sonra işler gerçekten hızlanıyor. Bu "altın ana" ulaşmak bana göre programlamadaki maliyetin %80'lik kısmı. Bu yüzden kod ajanlarına yönelik itirazları dürüst olmak gerekirse pek anlayamıyorum. Ortada tamamen çöpe gidecek kod kalsa bile, bunun başlı başına açık bir değeri olduğunu düşünüyorum. PS. Bacon mutlaka tartılmalı
Geçenlerde biriyle bu konu hakkında konuşmuştum ve ben de genel olarak katılıyorum. Bu araçların, etkileşimi gerçekten deneyerek fikirleri test edebileceğiniz prototipleri kolayca oluşturabilmesi çok harika. Ama iki sorun var. Birincisi, dışarıdan bakınca neredeyse tamamlanmış gibi görünen bir prototipin aslında production'a hazır olmaktan çok uzak olduğunu insanlara anlatmak zaten başlı başına dertken, LLM tabanlı kod benim eski yöntemlerle yaptığım prototiplerden bile production'dan daha uzak. İkincisi, elimle yaptığım prototiplerde teknoloji yığını ve implementasyon hakkında bizzat bir şeyler öğreniyorum. Evet, asıl amaç hızlı üretmek, ama o süreçte çok sayıda teknik ders çıkıyor ve çoğu zaman prototiplerim teknik yönü de belirliyor. Buna karşılık LLM tabanlı prototiplerde kodun kendisi neredeyse işe yaramıyor; gerçekten bir şeye başlanacaksa neredeyse sıfırdan yeniden başlamak gerekiyor. Fikri doğrulamış oluyorsunuz ama ne teknolojiyi ne de tasarımı doğrulamış oluyorsunuz gibi hissettiriyor. Buna rağmen hâlâ faydalı olduklarını düşünüyorum. Ben "prototip hızlı olmalı" yaklaşımına inanıyorum ve LLM kullanımıyla oldukça büyük sistemleri bile neredeyse anında bir araya getirebildim. Ama süreç anlayışında bir değişim gerekiyor. LLM'siz prototip 10 adımlık bir işte 4-5. adıma denk gelirken, LLM prototipi 2. adıma daha yakın. Bu kötü bir şey değil, ama prototipten sonra kalan iş miktarının eskisine göre daha fazla olduğu konusunda beklentileri ayarlamak gerekiyor
"Projeyi kendi başına bir miktar koşabilecek hâle getirince işler hemen akıyor" şeklindeki değer anlayışın önemli. Benim için ise tam tersine, en ödüllendirici ve eğlenceli kısım "sıfırdan bire" aşaması. Çünkü o noktada gerçekten çok fazla olasılık var ve daha önce olmayan bir şeyi yaratabiliyorsun. AI'nin önceden yön vermesi, o yaratıcılığın önemli bir kısmını kaybettirirmiş gibi geliyor
Yorumuna bakınca asıl büyük meselenin boş sayfa korkusu olduğu anlaşılıyor. Bunu ortadan kaldıran araçların üretkenliğe büyük katkı sağladığı fikrine katılıyorum. Ama herkesin aynı sorunu yaşadığını da düşünmüyorum. Yazılım geliştirme çok kişisel bir faaliyet olduğu için herkesin iş akışı ve deneyimi farklı olabilir. Burada kimsenin yöntemi diğerinden üstün değil; önemli olan herkese uygun aracın farklı olabileceğini ve herkesin kendi deneyimini olduğu gibi kabul edip ona güvenmek. LLM tartışmalarında her iki taraf da sık sık kendisiyle karşısındakinin aynı olduğunu varsayıyor
Bu hafta Mitchell'ın geliştirme kurulumu hakkında bir röportaj izledim; neden neovim kullandığı sorulduğunda "benim yerime kod yazan araçlar istemiyorum" dediği kısım dikkat çekiciydi. Eleştiri olsun diye söylemiyorum, ama Mitchell gibi çok güçlü bir geliştiricinin bile eski intellisense'ten farklı olarak LLM'lerde bir değer görmesi bence not edilmeli
Bunu iş arkadaşlarıma "Cunningham yasasını kendime uyguluyorum" diye açıklıyorum Cunningham's Law: 'İnternetten doğru cevabı almanın en hızlı yolu soru sormak değil, yanlış cevabı paylaşmaktır'. Düşünmeden boş bir ekrana bakarsam uzun süre öylece kalabiliyorum, ama eleştirecek bir şey önümde belirince anında üretken moda geçiyorum
OpenAI olayına verdiği tepkide Mitchell'ın görüşlerine içtenlikle saygı duyuyorum; bu ghostty için olumlu bir yön olsa bile. Kullanıcı memnuniyetsizliğini ya da can sıkıntısını (özellikle MS Auto Update gibi şeyleri düşününce) proaktif olarak azaltmaya çalışan yazılım şirketi neredeyse hiç görmüyoruz; bu çok hoş bir değişim. Ayrıca bu yazıda AI'nin programlamada sorumlu biçimde kullanıldığını görüyoruz; bana kalırsa bu, orijinal vibe coding tanımına (abartılı şekilde anlatıldığı hâline) hiç uymuyor
Burada "vibe coding" ifadesinin kendisi zaten hiç uygun düşmüyor bence. Bu terim aşırı kullanılarak her yere yapıştırılıyor
"AI'yi programlamada sorumlu biçimde kullanmak" görüşüne katılıyorum. Bu vibe coding değil, simonw'nin burada ilk kez ortaya koyduğu vibe engineering. İlgili yazı
Bu arada Ghostty, yakın zamanda AI kodlama araçlarının kullanıldığının zorunlu olarak açıklanmasını şart koştu ilgili PR bağlantısı
Bu yazı, ai ajanlarının neden ui framework çalışmalarında bu kadar güçlü olduğunu gösteriyor. Ben de Rust ve GTK ile uygulama geliştiriyorum ve iş akışım çok benzer. Mesele bir şeyi nasıl uygulayacağımı bilmemem değil; ai, ui framework işlerinde gerekli olan tekrar eden ve sıkıcı arama ile deneme-yanılmanın büyük kısmını üstlenerek çok yardımcı oluyor. Mitchell, çalışma süreci boyunca tüm kodu anlıyor. Ne yapılması gerektiğini zaten biliyor olması açısından, buna "vibe coding" demekle hiçbir ilgisi yok. Uzman olmanın kestirme bir yolu yok. Ghostty'yi gerçekten seviyorum
LLM sayesinde kod yazmak yeniden eğlenceli hâle geldi. İşte, LLM en zor ilk adımı yani başlangıç aşamasını geçmeme yardım ediyor ve böylece çok hızlı biçimde çalışmaya başlayabiliyorum. Yeni bir codebase'i anlamak ya da sıkıcı kısımları yazmak için de gerçekten faydalı. Ama asıl eğlence yan projelerde başlıyor. Aklıma gelen fikirleri gerçekten çok hızlı şekilde hayata geçirebiliyorum. Artık boilerplate kod yazmaya saatler harcamam ya da tooling ile boğuşmam gerekmiyor. Bana yabancı olan kısımları ajana devrediyor ya da tek bir prompt ile bir özelliği çıkarttırıp sonuç hoşuma gitmezse hemen geri alıyorum
Biraz konu dışı bir soru ama neden hâlâ neredeyse bütün uygulamaların kendi güncelleme framework'üne sahip olması gerekiyor, anlamıyorum. Bu iş uygulama mağazalarına ya da paket yöneticilerine entegre edilemez mi?
macOS ekosisteminde bu tür şeyler epey zor
Mesela Ubuntu'da bu oldukça kullanışlı. En güncel sürümü indirip kuruyorsunuz, sonrasında otomatik güncellemeleri almaya devam ediyorsunuz
Sonuçta senin bizzat iyi yapamadığını kabul ettiğin kısım — yani sıfırdan bire aşaması — AI'ye bırakılırsa, bu senin asla doğrudan öğrenemeyeceğin bir alan hâline gelir. Eğer gelecekte bunu kendin de yapabilmek istiyorsan, özellikle o kısmı pratik etmen gerekir
Ghostty gerçekten çok iyiydi; neredeyse iTerm'i bırakacaktım ama
cmd-ftuşuna bastığımda hiçbir şey olmaması yüzünden vazgeçtim issue ve geri bildirim sayfasıEğer en başından beri
cmd-folsaydı, ghostty hakkındaki yazılarda ne tür konuşmalar dönerdi diye merak ediyorum. Her gönderide bunu duymak biraz sıkıcı olmaya başladı. Aslında LLM araçları ya da kod yazma tarzları hakkında çok daha ilginç tartışmalar olabilir, ama dönüp dolaşıp herkes yinecmd-fkonuşuyorİlginç olan şu ki, ben geçen hafta sonu Claude kullanarak Ghostty'ye arama özelliği ekledim. Asıl arama kısmı zaten kabaca çalışan bir kod olarak vardı; yaptığım işin çoğu UI ile bağlamak oldu. İki oturumda (toplam yaklaşık 10 saat) Linux frontend'inde temel arama, vurgulama ve önceki/sonraki eşleşmeye gitmeyi çalışır hâle getirdim. Bu arama özelliği hâlâ bariz şekilde WIP, yani genel kullanım için yeterince hazır değil. Üzerinde çalışırken, bu kadar "temel" görünen bir özelliği bile akış hâlindeki metin üzerinde çalıştırmanın ne kadar karmaşık olduğunu fark ettim
Ben de Ghostty'nin fazla minimal olduğunu düşündüğüm için ne yazık ki hızla Warp'a geri döndüm. Bu arada Ghostty'nin varsayılan scrollback buffer boyutu yaklaşık 10MB, ama ayarlardan istediğiniz gibi değiştirilebiliyor
Bu arama özelliğinin hedefi Mart 2026'da çıkacak v1.3 sürümü olarak planlanmış yol haritası bağlantısı
Yazıdaki "bu özelliği eklemeye neyin yol açtığına bakalım" kısmını görünce, işletim sistemlerinde ne kadar çok rahatsızlığa katlandığımızı yeniden düşündüm. Sunum ya da ekran paylaşımı onlarca yıldır hayatın parçasıyken, neden hâlâ yalnızca sunum penceresinin ekranda görünmesini zorunlu kılan bu kadar temel bir ayarın bile zor olduğunu anlamıyorum
Bu, HashiCorp'un kurucu ortaklarından Mitchell Hashimoto'nun son zamanlarda neredeyse vaktinin çoğunu ayırdığı araç olan Ghostty.
Ghostty 1.0 çıktı - yüksek hızlı, çapraz platform terminal emülatörü
libghostty geliyor
Ajanik kodlamayı savunurken oturum paylaşımının gerçekten önemli olduğunu söylüyor,
bağlantıların çoğu da AMP oturumlarına gidiyor gibi görünüyor Amp - ajanik kodlama aracı