- Seluruh proses pengembangan fitur notifikasi pembaruan otomatis yang tidak mengganggu di macOS untuk Ghostty dibagikan secara terbuka; fitur yang benar-benar siap dirilis berhasil diselesaikan dalam sekitar 8 jam dengan biaya token $15.98 selama 16 sesi, terutama dengan memanfaatkan alat coding agentik AI
- Setelah insiden prompt pembaruan Ghostty mengganggu demo saat keynote OpenAI, diputuskan untuk beralih ke pendekatan non-modal yang menampilkan status pembaruan melalui elemen GUI kecil di title bar atau bagian bawah jendela tanpa menghentikan pekerjaan
- Sebelum mulai memakai AI, terlebih dahulu disusun rencana kasar backend/frontend dengan memanfaatkan protokol custom UI dari framework Sparkle dan titlebar accessory controller, lalu AI digunakan sebagai alat prototyping
- Menggunakan pendekatan bertahap lewat prototyping UI, perubahan arah saat gagal memperbaiki bug, serta sesi cleanup berulang (dokumentasi, refactoring) untuk meningkatkan performa sesi AI berikutnya dan menghasilkan kode simulasi
- Menekankan nilai cara kerja asinkron yang memungkinkan mengerjakan hal lain seperti menyiapkan sarapan keluarga saat AI bekerja, sambil tetap memegang prinsip bahwa semua kode buatan AI harus ditinjau manual secara ketat sebelum dirilis, dan kode yang tidak dipahami tidak akan dirilis
Ringkasan fitur
- Fitur yang selesai adalah notifikasi pembaruan yang tidak mengganggu di macOS
- Menampilkan status pembaruan di dalam jendela terminal tanpa mengganggu pekerjaan, seperti membuat jendela baru atau mengambil fokus
- Kebutuhan perbaikan UX terkonfirmasi setelah insiden prompt pembaruan Ghostty muncul di tengah keynote OpenAI
- Diputuskan untuk membuat notifikasi pembaruan tidak intrusif
- Alih-alih jendela pop-up, dipilih elemen GUI kecil non-modal yang tidak mengganggu pengguna dan ditampilkan di suatu tempat
- Lokasi tampilan notifikasi secara default adalah sisi kanan title bar, namun alternatif seperti overlay di bagian bawah jendela juga disediakan tergantung gaya, misalnya saat title bar disembunyikan
- Sepanjang proses pengembangan, agen AI dimanfaatkan, namun dengan strategi alat bantu yang dipimpin manusia yang tetap disertai perbaikan manual, pemolesan, dan review akhir secara langsung
Menyusun rencana sebelum memakai AI
- Sebelum mengeluarkan alat AI, terlebih dahulu dibuat rencana kasar
- Setelah mendapatkan gambaran kasar untuk backend, dilanjutkan dengan memikirkan frontend
- Ada ide samar untuk menyematkan tombol kecil di title bar
- Sudah mengetahui bahwa macOS mendukung custom UI di title bar melalui titlebar accessory controller, tetapi belum yakin seperti apa tampilan dan nuansanya secara konkret
- Titik awal yang cukup sudah tersedia sehingga pekerjaan bisa dimulai
- AI adalah prototyper yang sangat hebat, jadi hanya dengan mengetahui apa yang belum diketahui sudah cukup untuk mulai
- Memiliki intuisi yang cukup kuat tentang gambaran besarnya
Sesi pertama: prototyping UI
- Prompt awal dari sesi coding agentik pertama
- Mengkustomisasi SPUUserDriver untuk notifikasi pembaruan yang tidak intrusif dan permintaan aktivasi instalasi
- Membatasi pekerjaan hanya pada sisi UI
- Meminta rencana untuk membuat view SwiftUI yang dapat menampilkan berbagai status yang dibutuhkan SPUUserDriver
- Meminta rencana untuk menampilkannya di kanan atas title bar jendela macOS
- Oracle itu apa? - sub-agent khusus Amp yang hanya-baca, menggunakan model yang lebih lambat dan lebih mahal, dan umumnya lebih unggul dalam bernalar
- Diputuskan untuk fokus dulu pada prototipe UI
- Tidak langsung menyuruh agen membangun seluruh fitur
- Pertama, karena belum tahu seperti apa UI/UX yang diinginkan, maka tidak realistis mengharapkan AI melakukan ini secara konsisten di tengah perubahan lain
- Kedua, pecahan tugas yang kecil lebih mudah ditinjau, dipahami, dan diulang
- Diminta hanya menulis rencana dan tidak menulis kode
- Karena permintaannya relatif ambigu, penting untuk meninjau rencana sebelum banyak pekerjaan dilakukan (dan banyak token terpakai)
- Tip: menyusun rencana komprehensif secara interaktif bersama agen adalah langkah awal penting untuk tugas yang tidak sepele
- Biasanya disimpan dalam file seperti
spec.md, lalu pada sesi berikutnya bisa diminta untuk "merujuk ke @spec.md dan melakukan tugas tertentu"
- Setelah agen menyajikan rencana yang cukup masuk akal, implementasi pun diizinkan berjalan
- UI yang dihasilkan sangat tepat arahnya
- Ada banyak isu pemolesan seperti jarak dan warna, tetapi melihat UI tersebut memicu inspirasi tentang apa yang diinginkan
- Tip: AI sangat sering digunakan untuk mencari inspirasi; dalam kasus ini banyak bagian dari kode UI yang dihasilkan dipertahankan (meski tidak semuanya), tetapi sering juga terjadi hanya memberi prompt ke agen lalu membuang semuanya dan mengerjakannya ulang secara manual
- Tahap kreatif "zero to one" sangat sulit dan memakan waktu, dan AI sangat bagus berperan sebagai muse
Menabrak tembok
- Pada chat 11~14, masuk ke zona slop
- Kode yang dihasilkan agen memiliki bug serius dan sepenuhnya gagal diperbaiki
- Saya pun tidak tahu cara memperbaikinya
- Beberapa percobaan hail mary dilakukan untuk memperbaiki bug
- Jika agen berhasil menyelesaikannya, hasilnya bisa dipelajari dan dijadikan bahan belajar
- Kalaupun gagal, biayanya nyaris tidak ada
- Jika agen berhasil menyelesaikannya tetapi hasilnya tidak dipahami, perubahan akan dibatalkan; kode yang tidak dipahami tidak akan dirilis
- Sambil agen gagal, tab berpindah untuk mencari masalahnya dan mencoba menyelesaikannya sendiri
- Pada titik ini, disadari perlu mundur sejenak, meninjau pekerjaan yang telah dilakukan, dan menyusun rencana sendiri
- Perlu waktu untuk belajar sendiri dan berpikir kritis
- AI tidak lagi menjadi solusi, melainkan utang
Sesi cleanup
- Beberapa sesi berikutnya dihabiskan untuk mengarahkan agen merapikan kode
- Sesi kedua: memindahkan sebagian method ke lokasi yang lebih baik
- Memindahkan fungsi fill background, foreground, dan badge dari UpdateAccessoryView.swift ke UpdateViewModel.swift dan membuatnya lebih umum
- Sesi ketiga: menambahkan dokumentasi ke kode
- Memperbarui dokumentasi untuk UpdateBadge.swift
- Tip: menambahkan dokumentasi membantu menegaskan kembali pemahaman sendiri terhadap kode dan membantu melatih agen masa depan yang akan membaca dan memodifikasi kode ini
- Agen bekerja jauh lebih baik ketika memiliki penjelasan bahasa alami sekaligus kode
- Sesi keempat: memindahkan view model ke lokasi global aplikasi
- Karena implementasi awal menempatkannya pada cakupan jendela, padahal informasi pembaruan berada pada cakupan aplikasi
- Dalam proses ini, biasanya juga dilakukan perubahan manual kecil seperti biasa
- Pentingnya tahap cleanup
- Untuk benar-benar merapikan secara efektif, dibutuhkan pemahaman yang cukup baik terhadap kode, sehingga memaksa agar kode buatan AI tidak diterima begitu saja secara buta
- Kode yang lebih terstruktur dan terdokumentasi membantu meningkatkan performa sesi agentik berikutnya
- Ini secara bercanda disebut "sesi anti-slop"
Menghadapi bug
- Saatnya kembali ke bug yang ditemukan pada sesi awal
- Menghabiskan beberapa sesi lagi agar agen bisa memahami hal ini
- Memulai secara samar lalu membuat pendekatan semakin spesifik
- Sesi samar pertama: untuk tab native standar, update accessory view tidak terlihat, jadi harus dibuat tetap terlihat di title bar jendela - gagal
- Lebih spesifik kedua: perbarui constraint tab bar di TerminalTabsTitlebarTahoe.swift untuk menyelaraskan tepi kanan tab bar dengan tepi kiri update accessory view - gagal
- Mencoba pendekatan spesifik lain yang ketiga: bagaimana kalau mengubah TitlebarTabsTahoeTerminalWindow.swift agar tab bar menjadi top accessory view, bukan bottom accessory view, sehingga tab masuk ke title bar - gagal
- Percobaan terakhir: layout right accessory view bentrok dengan pengaturan update accessory view di TerminalWindow.swift, apakah tab bar bisa dibatasi agar selalu muncul di kiri notifikasi pembaruan - gagal
- Selama seluruh proses ini juga mencoba menyelesaikannya sendiri lewat riset manual dan usaha manusia
- Prompt yang lebih spesifik didasarkan pada apa yang dipelajari selama proses itu
- Secara keseluruhan jelas tidak berjalan baik
- Menyimpulkan bahwa ini tidak bisa diselesaikan sendirian dan memutuskan untuk berubah arah
- Untuk style title bar yang bermasalah, letakkan notifikasi pembaruan di sudut kanan bawah yang dioverlay di atas content view jendela, bukan di title bar
- Ghostty punya konfigurasi untuk menyembunyikan title bar sepenuhnya, jadi ini memang perlu didukung
- Bahkan jika nanti masalah style title bar bisa diselesaikan, mode lain ini tetap perlu didukung
- Sesi berikutnya berjalan dengan rencana ini dan memakai prompt yang sangat spesifik
- Memperkuat sistem Update agar juga mendukung pendekatan overlay di TerminalView.swift
- Notifikasi pembaruan harus muncul di bagian bawah jendela dan ditampilkan di atas teks, jadi tidak ada resize terminal view
- Semua perilaku klik sama seperti accessory view
- Hasilnya sangat bagus, belakangan ada banyak pekerjaan poles manual juga (memindahkan, mengganti nama, dll.), tetapi pekerjaan intinya solid
Memulai backend
- Merasa UI sudah cukup bagus
- Mencatat banyak isu poles yang ingin ditangani nanti, tetapi terutama ingin beralih ke pekerjaan backend untuk menemukan unknown unknown yang bisa mengacaukan rencana
- Membuat file scaffold secara manual dengan fungsi yang belum lengkap dan berbagai komentar
TODO. Memulai sesi baru
- Meminta menyelesaikan UpdateDriver.swift dan membaca dokumentasi Sparkle untuk memahami fungsinya
- Tip: AI sangat bagus dalam mengisi bagian kosong atau menggambar sisa burung hantu
- Pola membuat scaffolding dengan nama fungsi yang deskriptif, parameter, komentar todo, dan sebagainya sangat umum dan bekerja dengan baik
- Sebenarnya melakukan pekerjaan yang sangat buruk sehingga semua kode ini dibuang
- Kode yang dihasilkan memang berjalan, tetapi jelas merupakan pendekatan yang salah
- Banyak concern berbeda tercampur, dan cara menyimpan state di driver jelas salah
- Setelah meneliti apa yang telah dilakukan, menyadari bahwa view model disusun dengan cara yang tidak optimal
- Beralih ke mode cleanup untuk memberi kerangka yang lebih baik bagi AI (dan manusia jika memilih menulis manual)
Cleanup besar-besaran lagi
- Dari pengalaman, kerapian frontend UI dan backend business logic sering ditentukan oleh kualitas view model di tengahnya
- Menghabiskan waktu untuk merestrukturisasi view model secara manual
- Beralih dari struct dengan banyak optional ke tagged union, mengganti nama beberapa tipe, memindahkan beberapa hal
- Dari pengalaman, tahu bahwa pekerjaan manual kecil di tengah ini akan menuntun agen menuju keberhasilan pada sesi frontend dan backend berikutnya
- Setelah restrukturisasi selesai, hal pertama yang dilakukan adalah meminta agen sekali lagi menyelesaikan burung hantu
- Kali ini memeriksa perubahan, memperbarui kode yang bergantung ke style baru, dan menghapus kode lama
- Melanjutkan serangkaian sesi cleanup maraton
Simulasi
- Pada sesi UI pertama, meminta agen membuat kode demo agar UI benar-benar bisa dilihat tanpa pengecekan pembaruan sungguhan
- Alur pembaruan memiliki beberapa skenario, dan sampai titik ini baru menguji happy path
- Di sesi berikutnya, mengekstrak kode simulasi ke file khusus dan meminta agen membuat lebih banyak skenario
- Mengekstrak kode simulasi pembaruan dari AppDelegate.swift ke file khusus di Features/Update
- Menyertakan beberapa skenario simulasi (happy path, tidak ditemukan, error, dll.) agar mudah mencoba berbagai demo
- Tip: agen sangat unggul dalam membuat test dan simulasi
- Kode simulasi yang dibuat di sini terus terang cukup mengerikan, tetapi berfungsi dan bukan bagian dari binary rilis, jadi kualitasnya tidak terlalu penting
- Bahkan tidak membereskannya lebih jauh dari dasar-dasar yang bisa dilihat di sesi
- Menjalankan berbagai simulasi dan menemukan beberapa peningkatan UX
Bagian akhir
- Pada titik ini, backend dan frontend yang berfungsi sudah ada, dan semuanya perlu dihubungkan
- Di sesi berikutnya, memberi prompt kepada agen
- Membuat kelas UpdateController yang sama seperti SPUStandardUpdaterController.m milik Sparkle, tetapi untuk tipe updater
- Perlu sedikit bolak-balik dan poles manual, tetapi akhirnya tercapai
- Lalu menambahkan peningkatan kecil
- Untuk status updateable yang memiliki appcast, melihat SUAppcastItem dan menampilkan metadata terkait lain jika disetel
- Misalnya content length untuk ukuran
Hal lain?
- Untuk agen, prompt terakhir selalu menanyakan apa yang terlewat
- Lakukan ini terlepas dari apakah kode ditulis manual secara langsung atau tidak
- Apakah ada peningkatan lain yang bisa dibuat pada fitur Features/Update, jangan menulis kode, konsultasi ala Oracle, pertimbangkan bagian kode yang bisa ditambahkan lebih banyak unit test
- Karena masalah nyata telah ditekankan, minta agar itu diimplementasikan
- Belakangan saya menyadari lebih mudah memberi tahu agen untuk “lakukan semuanya” daripada menanyakan hal spesifik apa yang harus dikerjakan, karena nanti bisa dengan mudah dirapikan lewat commit opsional
- Hal yang lucu dari sesi ini adalah agen benar-benar mulai masuk ke lubang kelinci yang gila, jadi saya turun tangan untuk menyuruhnya berhenti
- “Berhenti berhenti berhenti. Batalkan semua item main actor”
- Juga menemukan bahwa ada cara yang lebih baik, tetapi dikerjakan dengan agak buruk
- Untuk pesan error, bukankah ada cara standar SwiftUI alih-alih memotongnya, perlu menambahkan elemen UI tambahan agar seluruh pesan bisa dilihat
Biaya dan waktu
- Pekerjaan ini dilakukan dalam total 16 sesi terpisah dengan pengeluaran token $15.98 di Amp
- Saya tidak akan menebak apakah ini umumnya mahal atau murah, tetapi secara pribadi selama 2 hari yang saya habiskan untuk fitur ini saya menghabiskan lebih banyak dari itu di kedai kopi
- Total waktu nyata yang saya habiskan untuk fitur ini diperkirakan sekitar 8 jam
- Commit pertama dan terakhir memang tersebar selama 3 hari, tetapi saya hanya bekerja di komputer sekitar 4 jam per hari
- Tidak semua waktu itu dihabiskan hanya untuk fitur ini
- Misalnya, saya juga melakukan rilis update Ghostty, tampil sebagai tamu selama 1 jam di ThePrimeagen, dan memberikan presentasi tamu di acara all-hands tahunan Zoo sambil mengerjakan fitur ini
- Saya punya balita di rumah, jadi “waktu di depan komputer” sangat terjadwal dan sangat terbatas
- Jadi perkiraan 8 jam itu cenderung cukup longgar
- Banyak orang di internet memperdebatkan apakah AI membuat pekerjaan menjadi lebih cepat
- Dalam kasus ini, saya rasa ini dirilis lebih cepat daripada jika saya mengerjakan semuanya sendiri
- Terutama karena pengulangan styling SwiftUI yang sepele secara pribadi sangat membosankan dan memakan waktu bagi saya, sementara AI sangat jago dalam hal itu
- Hal yang paling saya sukai dibanding perdebatan lebih cepat/lebih lambat: AI bisa bekerja untuk saya sementara saya pergi melakukan hal lain
- Mengambil foto salah satu sesi pembersihan saat saya membuat sarapan untuk keluarga
- Ada berbagai macam sanggahan seperti “saya tidak ingin ngoding saat memasak” atau “hadirlah sepenuhnya”
- Kalau Anda ingin begitu, tidak masalah; dalam kasus saya pada contoh khusus ini, saya adalah orang pertama yang bangun di rumah dan sedang menyiapkan sarapan sementara semua orang lain masih tidur
- Saya juga tidak melakukan ini setiap saat saya terjaga
- Kesimpulannya: ini berhasil untuk saya
- Sama sekali bukan mencoba meyakinkan Anda
- Saya tidak punya hubungan finansial dengan perusahaan AI mana pun
- Sebagai orang yang meraih banyak keberhasilan dengan alat AI dan suka membicarakannya, orang-orang selalu meminta saya membagikan contoh
- Itulah yang saya lakukan di sini
Kesimpulan
- Fitur ini indah dan bekerja dengan sangat baik, lalu di-merge setelah tinjauan manual terakhir
- “Tinjauan manual terakhir” itu sangat sangat sangat penting, jangan pernah merilis kode yang ditulis AI tanpa tinjauan manual yang menyeluruh
- Jika Anda pengguna Ghostty yang memakai rilis tip, ini sudah tersedia sekarang
- Jika Anda memakai rilis bertag, ini akan tersedia di Ghostty 1.3
- Saya adalah pendukung vokal dari pentingnya membagikan sesi agentic coding secara terbuka
- Salah satu alasannya adalah karena ini merupakan cara yang luar biasa kuat untuk mengedukasi orang lain tentang cara menggunakan alat-alat ini secara efektif
- Saya berharap postingan ini membantu menunjukkan hal tersebut
2 komentar
Komentar Hacker News
Saya sering memanfaatkan AI sebagai alat inspirasi, dan kali ini pun saya mempertahankan banyak kode UI yang dihasilkan AI, tetapi kadang saya menyuruh agen mengerjakannya, lalu membuang semuanya dan menulis ulang sendiri (secara manual!). Tahap kreasi "zero to one" selalu sangat sulit dan memakan banyak waktu, jadi AI benar-benar luar biasa sebagai muse bagi saya. Itulah keunggulan terbesar agen kode. Banyak orang mengkhawatirkan maintainability atau kekusutan proyek yang berpusat pada AI, tetapi saya tidak terlalu peduli. Selama saya bisa cepat sampai ke tahap di mana saya benar-benar bisa mengutak-atik fitur proyek dan terus memperbaikinya, setelah itu lajunya benar-benar terasa. Bagi saya, sampai ke "momen emas" ini adalah 80% biaya terbesar dalam pemrograman. Jadi saya jujur agak sulit memahami argumen yang menentang agen kode. Bahkan jika yang tersisa pada akhirnya hanyalah kode yang sepenuhnya dibuang, saya tetap merasa itu punya nilai yang jelas. PS. bacon memang harus ditimbang
Saya baru-baru ini membicarakan topik ini dengan seseorang, dan saya juga pada dasarnya setuju. Alat-alat ini sangat bagus karena bisa dengan mudah membuat prototipe yang memungkinkan kita langsung mencoba interaksi dan menguji ide. Tetapi ada dua masalah. Pertama, meyakinkan orang bahwa prototipe yang tampaknya hampir jadi sebenarnya masih jauh dari siap produksi sudah merupakan sakit kepala, dan kode berbasis LLM bahkan lebih jauh dari produksi dibanding prototipe yang dulu saya buat dengan cara lama. Kedua, prototipe yang saya buat dengan tangan memberi saya pembelajaran langsung tentang tech stack atau implementasinya. Tujuan utamanya memang membuat sesuatu dengan cepat, tetapi ada banyak pelajaran teknis yang saya dapat dalam proses itu, dan sering kali prototipe saya bahkan ikut menentukan arah teknis. Sebaliknya, prototipe berbasis LLM hampir tidak berguna sebagai kode itu sendiri, dan jika benar-benar mulai membangun sesuatu, kita hampir harus memulai lagi dari awal. Rasanya ide memang tervalidasi, tetapi teknologi maupun desain sama sekali belum tervalidasi. Meski begitu saya tetap menganggapnya berguna. Saya percaya pada prinsip "prototipe harus cepat", dan dengan memanfaatkan LLM saya bisa merakit sistem yang cukup besar hampir seketika. Hanya saja, perlu perubahan konsep proses. Prototipe non-LLM itu kira-kira ada di langkah 4~5 dari 10, sedangkan prototipe LLM lebih dekat ke langkah 2. Ini bukan hal buruk, tetapi ekspektasi perlu disesuaikan bahwa setelah prototipe, jumlah pekerjaan yang tersisa lebih banyak daripada sebelumnya
Nilai yang Anda pegang, yaitu "kalau proyek sudah sampai tahap tertentu dan bisa langsung dijalankan, maka kemajuan akan segera terasa", memang penting. Bagi saya justru tahap "zero to one" adalah bagian yang paling memuaskan dan menyenangkan. Di saat itu ada begitu banyak kemungkinan dan kita bisa menciptakan sesuatu yang sebelumnya belum ada. Jika AI sudah lebih dulu menentukan arahnya, rasanya banyak kreativitas yang hilang
Dari pendapat Anda, sepertinya ketakutan pada halaman kosong adalah kekhawatiran besar. Saya paham bahwa alat yang menghilangkan itu bisa sangat membantu produktivitas. Tetapi tidak semua orang punya kekhawatiran yang sama. Pengembangan perangkat lunak adalah aktivitas yang sangat personal, jadi workflow dan pengalaman tiap orang bisa berbeda. Ini bukan soal siapa yang lebih unggul; yang penting adalah menyadari bahwa alat yang cocok bagi tiap orang berbeda, dan mengakui serta mempercayai pengalaman masing-masing apa adanya. Dalam perdebatan soal LLM, kedua kubu sering cenderung menganggap dirinya dan lawannya itu sama
Minggu ini saya melihat wawancara tentang setup pengembangan Mitchell, dan ketika ditanya kenapa memakai neovim, bagian yang berkesan adalah saat ia berkata, "Saya tidak ingin alat yang menulis kode menggantikan saya." Bukan untuk mengkritik, tetapi perlu dicatat bahwa bahkan developer hebat seperti Mitchell pun melihat nilai di LLM, berbeda dengan intellisense zaman dulu
Saya menjelaskannya kepada rekan kerja sebagai "menerapkan Hukum Cunningham pada diri sendiri" Cunningham's Law: 'cara tercepat mendapatkan jawaban yang benar di internet bukan dengan bertanya, tetapi dengan memposting jawaban yang salah'. Kalau saya menatap layar kosong tanpa arah, saya bisa bengong lama, tetapi begitu ada sesuatu yang bisa dikritik, saya langsung jadi produktif
Saya sungguh menghormati pendapat Mitchell dalam merespons insiden OpenAI, meskipun arahnya positif bagi ghostty. Saya hampir tidak pernah melihat vendor perangkat lunak yang secara proaktif berusaha mengurangi keluhan atau frustrasi pengguna—terutama jika memikirkan hal seperti MS Auto Update—jadi ini perubahan yang sangat menyenangkan. Tulisan ini juga menunjukkan penggunaan AI yang bertanggung jawab dalam pemrograman; menurut saya ini sama sekali tidak cocok dengan definisi asli vibe coding yang dulu sering disebut-sebut secara berlebihan
Saya rasa istilah "vibe coding" sendiri sama sekali tidak cocok di sini. Istilah itu sudah terlalu sering dipakai sembarangan di mana-mana
Saya setuju dengan pendapat tentang "penggunaan AI yang bertanggung jawab dalam pemrograman". Ini bukan vibe coding, melainkan vibe engineering seperti yang pertama kali diajukan simonw di sini. Tulisan terkait
Sebagai referensi, Ghostty baru-baru ini mewajibkan pengungkapan penggunaan alat coding AI tautan PR terkait
Tulisan ini menunjukkan mengapa agen AI sangat unggul dalam pekerjaan framework UI. Saya juga mengembangkan aplikasi dengan Rust dan GTK, dan workflow-nya sangat mirip. Bukan karena saya tidak tahu cara mengimplementasikan sesuatu, tetapi karena AI sangat membantu dengan menangani sebagian besar pencarian berulang yang membosankan dan trial-and-error dalam pekerjaan framework UI. Mitchell memahami seluruh kode sepanjang proses. Karena ia sudah tahu apa yang harus dilakukan, ini sama sekali berbeda dari apa yang disebut "vibe coding". Tidak ada jalan pintas terpisah untuk menjadi seorang ahli. Saya sangat suka Ghostty
Berkat LLM, coding jadi menyenangkan lagi. Di pekerjaan, LLM membantu langkah awal tersulit, sehingga saya bisa cepat mulai bekerja. Ini juga sangat berguna untuk memahami codebase baru atau menulis bagian yang membosankan. Tetapi kesenangan yang sebenarnya dimulai dari side project. Saya bisa mewujudkan ide spontan dengan sangat cepat. Sekarang saya tidak perlu lagi menghabiskan berjam-jam menulis boilerplate code atau bergulat dengan tooling. Untuk bagian yang belum saya kuasai, saya serahkan ke agen, atau saya keluarkan dulu fiturnya lewat prompt dalam sekali jalan lalu segera rollback kalau hasilnya tidak memuaskan
Pertanyaan yang agak melenceng, tetapi kenapa sampai sekarang hampir semua aplikasi masih harus punya framework update sendiri? Tidak bisakah fungsi itu diintegrasikan ke app store atau package manager?
Di ekosistem macOS, fungsi seperti ini cukup sulit dilakukan
Misalnya di Ubuntu, ini cukup praktis. Jika Anda mengunduh dan memasang versi terbaru secara langsung, setelah itu Anda akan terus menerima update otomatis
Pada akhirnya, bagian yang Anda akui sendiri belum Anda kuasai—yaitu tahap zero to one—akan menjadi wilayah yang tidak akan pernah benar-benar Anda pelajari sendiri jika diserahkan pada AI. Jika ke depan Anda masih ingin bisa melakukannya sendiri, Anda perlu melatih bagian itu secara sadar
Ghostty benar-benar bagus, dan saya hampir meninggalkan iTerm, tetapi saat saya menekan cmd-f dan tidak ada respons sama sekali, saya pun menyerah halaman issue dan feedback
Kalau cmd-f sudah ada sejak awal, saya jadi penasaran apa yang akan dibicarakan orang di tulisan-tulisan tentang ghostty. Agak melelahkan juga mendengar hal ini di setiap postingan. Sebenarnya bisa saja ada pembahasan yang jauh lebih menarik tentang alat LLM atau cara coding, tetapi pada akhirnya semua orang malah hanya membicarakan cmd-f
Lucunya, akhir pekan lalu saya memakai Claude untuk mengimplementasikan fitur pencarian di Ghostty. Sebenarnya pencariannya sendiri sudah punya kode yang agak bekerja, jadi sebagian besar pekerjaannya adalah menghubungkannya ke UI. Dalam dua sesi saja (total sekitar 10 jam), saya berhasil membuat pencarian dasar, highlight, dan pindah ke hasil cocok sebelumnya/berikutnya bekerja di frontend Linux. Fitur pencarian ini jelas masih WIP, jadi belum cukup siap untuk penggunaan umum. Saat mengerjakannya, saya jadi benar-benar merasakan betapa rumitnya membuat sesuatu yang tampak sebagai fitur 'dasar' agar bekerja pada teks streaming
Saya juga merasa Ghostty terlalu minimalis, jadi sayangnya saya cepat kembali ke Warp. Sebagai catatan, kapasitas default scrollback buffer Ghostty sekitar 10MB, tetapi itu bisa diatur sesuka hati di konfigurasi
Fitur pencarian ini dijadwalkan menargetkan v1.3 pada Maret 2026 tautan roadmap
Saat membaca bagian artikel yang mengatakan "mari kita lihat apa yang mendorong penambahan fitur ini", saya kembali teringat betapa banyak ketidaknyamanan yang kita terima begitu saja di OS. Presentasi atau screen sharing sudah menjadi hal yang wajar selama puluhan tahun, jadi saya heran kenapa bahkan pengaturan dasar untuk memaksa hanya jendela presentasi yang terlihat di layar masih sulit dilakukan
Ini adalah Ghostty, alat yang belakangan ini hampir menyita sebagian besar waktu Mitchell Hashimoto, salah satu pendiri HashiCorp.
Ghostty 1.0 dirilis - emulator terminal cepat lintas platform
libghostty akan hadir
Sambil mendukung agentic coding, ia mengatakan bahwa berbagi sesi benar-benar penting,
dan tampaknya sebagian besar tautannya mengarah ke sesi AMP. Amp - alat agentic coding