Vibe coding का उपयोग करके उन्नत Ghostty फ़ीचर लागू करने का अनुभव साझा

• Ghostty की macOS गैर-विघ्नकारी ऑटो-अपडेट नोटिफिकेशन सुविधा को मुख्य रूप से AI एजेंटिक कोडिंग टूल्स की मदद से विकसित करने की पूरी प्रक्रिया साझा की गई है, और 16 सेशन में $15.98 की टोकन लागत पर लगभग 8 घंटे में वास्तव में डिप्लॉय की जा सकने वाली सुविधा पूरी की गई।
• OpenAI keynote के दौरान Ghostty update prompt द्वारा डेमो बाधित होने की घटना के बाद, काम रोके बिना title bar या विंडो के निचले हिस्से में छोटे GUI element से अपडेट स्टेटस दिखाने वाले non-modal तरीके पर जाने का फैसला किया गया।
• AI शुरू करने से पहले Sparkle framework के custom UI protocol और titlebar accessory controller का उपयोग करने वाली एक मोटी backend/frontend योजना पहले बनाई गई, और AI को prototyping tool की तरह इस्तेमाल किया गया।
• UI prototyping, bug fix में विफल होने पर दिशा बदलना, और बार-बार होने वाले cleanup sessions (documentation, refactoring) के जरिए आगे की AI sessions की performance सुधारना, simulation code बनवाना आदि जैसे चरणबद्ध तरीके अपनाए गए।
• AI के काम करते समय परिवार के लिए सुबह की तैयारी जैसे दूसरे काम भी किए जा सकने वाले asynchronous work style के मूल्य पर जोर दिया गया, और यह सिद्धांत निभाया गया कि AI द्वारा बनाया गया हर कोड गहन manual review के बाद ही डिप्लॉय होगा, तथा जिस कोड को समझा न जाए उसे डिप्लॉय नहीं किया जाएगा।

---

फीचर अवलोकन

• पूरी की गई सुविधा macOS पर विंडो को ढके बिना दिखने वाली गैर-विघ्नकारी अपडेट नोटिफिकेशन है।
  • विंडो बनाना या focus छीनना जैसे व्यवधान किए बिना टर्मिनल विंडो के भीतर अपडेट स्टेटस दिखाती है।
  • OpenAI keynote के दौरान Ghostty update prompt दिखने की घटना ने UX सुधार की जरूरत साफ कर दी।
• अपडेट नोटिफिकेशन को non-intrusive बनाने का फैसला किया गया।
  • popup window की जगह कहीं एक छोटा non-modal GUI element दिखाना तय किया गया जो उपयोगकर्ता को बाधित न करे।
  • नोटिफिकेशन दिखाने की default जगह title bar का दायां हिस्सा रखी गई, लेकिन title bar छिपा होने जैसी स्टाइल स्थितियों के लिए विंडो के निचले हिस्से का overlay जैसे विकल्प भी दिए गए।
• पूरी डेवलपमेंट प्रक्रिया में AI agent का उपयोग किया गया, लेकिन साथ में सीधे manual edits, polish, और final review करने वाली human-led assistive tool रणनीति अपनाई गई।

AI इस्तेमाल करने से पहले योजना बनाना

• AI टूल खोलने से पहले पहले एक मोटी योजना बनाई गई।
  • Ghostty द्वारा इस्तेमाल किए जाने वाले Sparkle (बहुत लोकप्रिय macOS update framework) के दस्तावेज़ देखे गए।
  • Obj-C protocol के जरिए custom UI support मिला; शुरुआत से बहुत कुछ फिर से implement करना पड़ता, लेकिन यह संभव था।
• backend की मोटी समझ मिलने के बाद frontend की रूपरेखा सोची गई।
  • title bar में एक छोटा button embed करने का एक अस्पष्ट विचार था।
  • यह पता था कि macOS titlebar accessory controller के जरिए title bar में custom UI को support करता है, लेकिन उसका ठोस look-and-feel स्पष्ट नहीं था।
• पर्याप्त शुरुआती आधार मिलने पर काम शुरू किया जा सका।
  • AI एक बहुत अच्छा prototyper है, इसलिए क्या नहीं पता है यह जानना ही शुरुआत करने के लिए काफी था।
  • बड़े चित्र के बारे में पर्याप्त मजबूत समझ मौजूद थी।

पहला सेशन: UI prototyping

• पहले agentic coding session का शुरुआती prompt:
  • SPUUserDriver को customize करके non-intrusive update notification और install activation request बनाना।
  • इसे सिर्फ UI work तक सीमित रखना।
  • SPUUserDriver को जिन अलग-अलग states की जरूरत है, उन्हें दिखाने वाला SwiftUI view बनाने की योजना माँगना।
  • macOS विंडो के title bar के ऊपर दाएं हिस्से में इसे दिखाने की योजना माँगना।
  • Oracle क्या है? - Amp का read-only sub-agent, जो धीमे और महंगे model का उपयोग करता है और आम तौर पर सोचने-समझने में बेहतर होता है।
• पहले UI prototype पर ध्यान केंद्रित करने का फैसला किया गया।
  • agent को पूरी सुविधा बनाने के लिए नहीं भेजा गया।
  • पहला कारण, UI/UX कैसा दिखना चाहिए यह अभी पता नहीं था, इसलिए AI से यह उम्मीद नहीं की जा सकती थी कि वह दूसरे बदलावों के बीच इसे लगातार सही कर देगा।
  • दूसरा, छोटे काम के हिस्सों की समीक्षा, समझ और iteration करना आसान होता है।
• केवल योजना लिखने को कहा गया और कोड न लिखने का निर्देश दिया गया।
  • क्योंकि अनुरोध अपेक्षाकृत अस्पष्ट था, इसलिए बहुत काम करने (और बहुत token खर्च करने) से पहले योजना की समीक्षा करना महत्वपूर्ण था।
  • टिप: agent के साथ बातचीत के जरिए एक व्यापक योजना बनाना किसी non-trivial काम का अहम पहला चरण है।
  • आम तौर पर इसे spec.md जैसी फ़ाइल में सहेजकर आगे के sessions में “@spec.md को संदर्भित करो और कोई काम करो” जैसे अनुरोध किए जा सकते हैं।
• agent ने इतना उचित plan दिया कि implementation आगे बढ़ाने की अनुमति दे दी गई।
  • बनाया गया UI दिशा के लिहाज़ से बहुत अच्छा था।
  • spacing, color आदि से जुड़े कई polish issues थे, लेकिन UI को देखकर यह प्रेरणा मिली कि वास्तव में क्या चाहिए।
  • टिप: प्रेरणा पाने के लिए AI का बहुत बार उपयोग किया जाता है; इस मामले में बने हुए UI code का बड़ा हिस्सा (पूरा नहीं) रखा गया, लेकिन कई बार ऐसा भी होता है कि agent को prompt देकर सब कुछ बनवाया जाता है और फिर उसे पूरी तरह फेंककर manually दोबारा काम किया जाता है।
  • रचनात्मकता का “zero to one” चरण बहुत कठिन और समय लेने वाला होता है, और AI इसमें muse की तरह शानदार काम करता है।

दीवार से टकराना

• chat 11~14 में slop zone में प्रवेश हुआ।
  • agent द्वारा बनाए गए code में गंभीर bugs थे और वह उन्हें ठीक करने में पूरी तरह विफल रहा।
  • मैं भी नहीं जानता था कि उन्हें कैसे ठीक किया जाए।
• bug fix के लिए कुछ hail mary प्रयास किए गए।
  • अगर agent हल कर देता, तो उससे सीखने और समझने का मौका मिलता।
  • विफल होने पर भी लागत लगभग न के बराबर थी।
  • अगर agent हल कर देता लेकिन समझ में नहीं आता, तो उसे revert कर दिया जाता; जिस code को समझा नहीं जाता, उसे डिप्लॉय नहीं किया जाता।
  • विफलताओं के दौरान tab बदलकर समस्या खोजी गई और खुद हल करने की कोशिश भी की गई।
• इस बिंदु पर यह समझ आया कि पीछे हटकर किए गए काम की समीक्षा करनी होगी और खुद की योजना बनानी होगी।
  • खुद को शिक्षित करने और आलोचनात्मक ढंग से सोचने का समय था।
  • AI अब समाधान नहीं, बल्कि debt बन चुका था।

cleanup sessions

• अगले कुछ sessions agent को मार्गदर्शन देकर code cleanup में लगाए गए।
• दूसरा session: कुछ methods को बेहतर जगह पर ले जाया गया।
  • fill background, foreground, badge functions को UpdateAccessoryView.swift से UpdateViewModel.swift में ले जाकर अधिक सामान्य बनाया गया।
• तीसरा session: code में documentation जोड़ी गई।
  • UpdateBadge.swift के documentation को अपडेट किया गया।
  • टिप: documentation जोड़ना code के बारे में अपनी समझ को फिर से परखने में मदद करता है और उन future agents को भी प्रशिक्षित करता है जो इस code को पढ़ेंगे और बदलेंगे।
  • agent तब कहीं बेहतर प्रदर्शन करता है जब उसके पास natural language explanation और code दोनों हों।
• चौथा session: view model को app-wide स्थान पर ले जाया गया।
  • क्योंकि मूल काम इसे window scope में रख रहा था, जबकि update information app scope की थी।
  • इस प्रक्रिया में सामान्य रूप से छोटे-मोटे manual changes भी साथ किए गए।
• cleanup चरण का महत्व
  • प्रभावी ढंग से cleanup करने के लिए code की काफी अच्छी समझ चाहिए, इसलिए यह AI द्वारा लिखे code को आँख बंद करके स्वीकार करने से रोकता है।
  • बेहतर ढंग से व्यवस्थित और documented code भविष्य के agentic sessions की performance सुधारने में मदद करता है।
• इसे मज़ाक में "anti-slop session" कहा गया।

bug का सामना

• शुरुआती सत्र में मिले बग पर वापस जाने का समय
  • एजेंट से इसे समझवाने के लिए फिर से कुछ सत्र खर्च किए
  • शुरुआत अस्पष्ट रखी और धीरे-धीरे तरीका अधिक ठोस बनाया
• पहला अस्पष्ट सत्र: स्टैंडर्ड native tabs में update accessory view दिखाई नहीं देता; इसे विंडो के titlebar में लगातार दिखना चाहिए — असफल
• दूसरा और अधिक ठोस: TerminalTabsTitlebarTahoe.swift में tab bar constraints अपडेट करके tab bar के दाएँ किनारे को update accessory view के बाएँ किनारे के साथ align करना — असफल
• तीसरी एक अलग ठोस approach की कोशिश: TitlebarTabsTahoeTerminalWindow.swift बदलकर tab bar को bottom accessory view के बजाय top accessory view बना दें ताकि tabs titlebar में आ जाएँ — असफल
• आखिरी कोशिश: right accessory view और layout, TerminalWindow.swift में update accessory view setup से टकरा रहे थे; क्या tab bar को हमेशा update notification के बाईं ओर दिखने तक सीमित किया जा सकता है — असफल
• इस पूरी प्रक्रिया के दौरान manual research और मानवीय मेहनत से खुद भी इसे हल करने की कोशिश की
  • अधिक ठोस prompts उसी प्रक्रिया में सीखी गई बातों पर आधारित थे
  • कुल मिलाकर यह साफ तौर पर काम नहीं कर रहा था
• यह तय किया कि इसे अकेले हल नहीं कर सकता, इसलिए दिशा बदलने का फैसला
  • जिस titlebar style में समस्या थी, उसके लिए titlebar के बजाय विंडो के content view के ऊपर overlay किए गए नीचे-दाएँ कोने में update notification रखना
  • Ghostty में titlebar को पूरी तरह छिपाने की configuration है, इसलिए वैसे भी इसे support करना होगा
  • बाद में titlebar style की समस्या हल हो भी जाए, तब भी इस दूसरे mode को support करना होगा
• अगला सत्र इसी योजना के साथ चला और बहुत ठोस prompt इस्तेमाल किया
  • Update system को बढ़ाकर TerminalView.swift में overlay approach भी support कराई
  • update notification विंडो के नीचे दिखना चाहिए और text के ऊपर render होना चाहिए, इसलिए terminal view का size बदलना नहीं चाहिए
  • सभी click actions accessory view जैसे ही होने चाहिए
• इसने सच में बहुत अच्छा काम किया; बाद में काफी manual polish का काम किया गया (move, rename वगैरह), लेकिन मुख्य काम मजबूत था

बैकएंड की शुरुआत

• लगा कि UI अब पर्याप्त रूप से अच्छा है
  • बाद में देखने लायक कई polish issues नोट किए, लेकिन मुख्य रूप से backend पर जाना चाहता था ताकि ऐसे unknown unknowns सामने आएँ जो योजना को बिगाड़ सकते थे
• अधूरे functions और कई TODO comments के साथ scaffold files manually बनाए। नया सत्र शुरू किया
  • UpdateDriver.swift पूरा करने को कहा, Sparkle docs पढ़कर functionality समझने के लिए कहा
  • टिप: AI blanks भरने या बाकी उल्लू बनाने में बहुत अच्छा है
  • descriptive function names, parameters, todo comments आदि के साथ scaffolding बनाने का यह pattern बहुत आम है और अच्छी तरह काम करता है
• इसने वास्तव में बहुत खराब काम किया और मैंने यह सारा code फेंक दिया
  • बनाया गया code काम तो कर रहा था, लेकिन approach साफ तौर पर गलत थी
  • इसने कई अलग concerns को गड्डमड्ड कर दिया था और driver में state store करने का तरीका भी साफ तौर पर गलत था
• जब इसके काम का अध्ययन किया, तो समझ आया कि view model को एक गैर-इष्टतम तरीके से structure किया गया है
  • AI को, और अगर manually लिखना चुनते तो इंसान को भी, बेहतर framework देने के लिए cleanup mode में शिफ्ट किया

बड़ा re-cleanup

• अनुभव से पता है कि UI frontend और business logic backend की साफ-सफाई अक्सर बीच के view model की quality से तय होती है
  • view model को manually restructure करने में समय लगाया
  • बहुत सारे optional fields वाले struct से tagged union पर शिफ्ट किया, कुछ type names बदले, चीजें इधर-उधर कीं
• अनुभव से यह भी पता था कि बीच में किया गया यह छोटा manual काम आगे frontend और backend दोनों के सत्रों में एजेंट को सफलता तक ले जाएगा
  • restructuring पूरी होने के बाद सबसे पहले एजेंट से फिर एक बार उल्लू पूरा करने को कहा
  • इस बार changes inspect करने, dependent code को नई style के मुताबिक अपडेट करने और पुराना code हटाने को कहा
• marathon cleanup sessions की एक श्रृंखला जारी रही
  • अतिरिक्त dead code हटाने को कहा
  • खुद build तोड़ने के बाद मीटिंग में रहते हुए एजेंट से उसे ठीक करने को कहा
  • टिप: “मैंने गड़बड़ कर दी है, मेरी गलती ठीक कर दीजिए” एजेंट के लिए एक और बहुत आम use case है
  • कुछ views में refactoring शुरू की
  • अतिरिक्त cleanup पर काम किया

simulation

• पहले UI सत्र में एजेंट से demo code बनाने को कहा ताकि बिना असली update check के UI वास्तव में देखा जा सके
  • update flow में कई scenarios थे और इस बिंदु तक सिर्फ happy path ही test किया गया था
• अगले सत्र में simulation code को एक dedicated file में निकाला और एजेंट से और scenarios बनाने को कहा
  • AppDelegate.swift में मौजूद update simulation code को Features/Update की dedicated file में निकाला
  • कई simulation scenarios शामिल किए (happy path, not found, error आदि) ताकि अलग-अलग demos आसानी से आज़माए जा सकें
  • टिप: एजेंट testing और simulation बनाने में शानदार है
  • यहाँ बनाया गया simulation code ईमानदारी से कहें तो काफ़ी भयानक है, लेकिन काम करता है और release binary का हिस्सा नहीं है, इसलिए quality मायने नहीं रखती
  • सत्र में दिखने वाली बुनियादी चीज़ों से आगे इसे व्यवस्थित करने की भी कोशिश नहीं की
• अलग-अलग simulations चलाए और कई UX improvements खोजीं
  • “कोई update नहीं” state को साफ किया
  • error check पर state reset की
  • permission request state के लिए copy और style बदले

आखिरी चरण

• इस बिंदु तक काम करने वाला backend और frontend दोनों थे, और बस इन्हें जोड़ने की ज़रूरत थी
• अगले सत्र में एजेंट को prompt दिया
  • Sparkle के SPUStandardUpdaterController.m जैसा, लेकिन updater type के लिए UpdateController class बनाओ
  • थोड़ा आगे-पीछे और manual polish की ज़रूरत पड़ी, लेकिन वहाँ तक पहुँचे
• फिर छोटे improvements जोड़े
  • appcast वाले updatable state के लिए SUAppcastItem को देखकर, सेट होने पर दूसरा प्रासंगिक metadata भी दिखाया
  • उदाहरण के लिए size के लिए content length

और क्या?

• एजेंट के लिए आख़िरी prompt हमेशा यह पूछना होना चाहिए कि क्या छूट गया
  • यह काम करें, चाहे आपने कोड हाथ से सीधे लिखा हो या नहीं
  • क्या Features/Update फ़ीचर में किए जा सकने वाले अन्य सुधार हैं, कोड न लिखें, Oracle कंसल्टिंग, और उन कोड हिस्सों पर विचार करें जहाँ और unit tests जोड़े जा सकते हैं
• चूंकि मैंने वास्तविक समस्या को हाइलाइट किया था, इसलिए उसे implement करने के लिए कहा
  • मैंने पाया कि एजेंट से किसी विशेष काम के बारे में पूछने के बजाय उसे “सब कुछ करो” कहना आसान है, क्योंकि बाद में optional commits में इसे आसानी से साफ़ किया जा सकता है
• इस session की मज़ेदार बात यह थी कि एजेंट सचमुच एक पागल rabbit hole में जाने लगा, इसलिए मुझे बीच में हस्तक्षेप करके उसे रोकना पड़ा
  • “रुको रुको रुको। सभी main actor आइटम cancel करो”
• साथ ही, मैंने पाया कि एक बेहतर तरीका मौजूद था, लेकिन उसे कुछ ख़राब ढंग से किया गया था
  • error message के मामले में, क्या उसे काटने के बजाय SwiftUI का कोई standard तरीका नहीं है; पूरा message देखने के लिए एक अतिरिक्त UI element जोड़ने की ज़रूरत है

लागत और समय

• इस काम में कुल 16 अलग-अलग sessions लगे और Amp में $15.98 के tokens खर्च हुए
  • मैं यह अनुमान नहीं लगाऊँगा कि यह आम तौर पर महँगा है या सस्ता, लेकिन व्यक्तिगत रूप से इस फ़ीचर पर बिताए 2 दिनों के दौरान मैंने coffee shop में इससे ज़्यादा खर्च किया
• इस फ़ीचर पर मेरा कुल वास्तविक समय लगभग 8 घंटे रहा होगा
  • पहला और आख़िरी commit 3 दिनों में फैला था, लेकिन मैं रोज़ लगभग 4 घंटे ही कंप्यूटर पर काम करता हूँ
  • मैंने अपना पूरा समय सिर्फ़ इसी फ़ीचर पर नहीं लगाया
  • उदाहरण के लिए, इस फ़ीचर पर काम करते समय मैंने Ghostty update release, ThePrimeagen के साथ 1 घंटे की guest appearance, और Zoo के वार्षिक all-hands event में guest presentation जैसी चीज़ें भी कीं
  • घर में एक toddler होने की वजह से मेरा “कंप्यूटर समय” बहुत तयशुदा और बहुत सीमित है
  • इसलिए 8 घंटे का अनुमान भी काफ़ी उदार है
• इंटरनेट पर बहुत से लोग इस बात पर बहस करते हैं कि क्या AI काम को तेज़ बनाता है
  • इस मामले में, मुझे लगता है कि अगर मैं सब कुछ खुद करता तो उससे तेज़ी से मैंने इसे ship किया
  • ख़ासकर इसलिए क्योंकि मामूली SwiftUI styling iteration मुझे व्यक्तिगत रूप से बहुत उबाऊ और समय लेने वाला लगता है, और AI यह काम बहुत अच्छी तरह करता है
• तेज़/धीमा बहस से परे, मुझे सबसे पसंद यह है: AI मेरे लिए तब भी काम कर सकता है जब मैं कुछ और कर रहा हूँ
  • cleanup sessions में से एक की तस्वीर, जब मैं परिवार के लिए नाश्ता बना रहा था
  • “मैं खाना बनाते समय coding नहीं करना चाहता” या “और ज़्यादा present रहो” जैसी हर तरह की आपत्तियाँ होती हैं
  • अगर आप ऐसा करना चाहते हैं, तो ठीक है; मेरे मामले में इस ख़ास उदाहरण में मैं घर में सबसे पहले उठने वाला व्यक्ति था और बाकी सब अभी भी सो रहे थे, तब मैं नाश्ता तैयार कर रहा था
  • मैं अपने हर जागते पल में ऐसा नहीं करता
• निष्कर्ष: यह मेरे लिए काम करता है
  • मैं आपको मनाने की बिल्कुल कोशिश नहीं कर रहा हूँ
  • मेरा किसी भी AI company से कोई वित्तीय संबंध नहीं है
  • मैं बस ऐसा व्यक्ति हूँ जिसे AI tools के साथ बहुत सफलता मिली है और जो इसके बारे में बात करना पसंद करता है, और लोग मुझसे हमेशा examples साझा करने को कहते हैं
  • मैं यहाँ वही कर रहा हूँ

निष्कर्ष

• यह फ़ीचर सुंदर है, शानदार ढंग से काम करता है, और अंतिम manual review के बाद merge कर दिया गया
  • “अंतिम manual review” बहुत बहुत बहुत महत्वपूर्ण है, बिना गहन manual review के AI द्वारा लिखे गए code को deploy नहीं करना चाहिए
  • अगर आप Ghostty user हैं जो tip release इस्तेमाल करते हैं, तो यह अभी उपलब्ध है
  • अगर आप tagged release इस्तेमाल करते हैं, तो यह Ghostty 1.3 में उपलब्ध होगा
• मैं agentic coding sessions को सार्वजनिक रूप से साझा करने के महत्व का खुला समर्थक हूँ
  • इसका एक कारण यह है कि यह दूसरों को इन tools का प्रभावी इस्तेमाल करना सिखाने का अविश्वसनीय रूप से शक्तिशाली तरीका है
  • उम्मीद है कि यह post इसे दिखाने में मदद करेगी

[GN⁺]

Hacker News टिप्पणियाँ

• मैं अक्सर AI को प्रेरणा के एक टूल की तरह इस्तेमाल करता हूँ। इस बार भी UI code का काफ़ी हिस्सा AI ने जनरेट किया, लेकिन कई बार मैं agent से काम करवाकर सब फेंक देता हूँ और फिर खुद दोबारा लिखता हूँ (मैन्युअली!). "zero to one" वाला क्रिएटिव चरण हमेशा बहुत कठिन और समय लेने वाला होता है, इसलिए AI का मेरी muse की तरह काम करना वाकई शानदार है। मेरे लिए code agent का सबसे बड़ा फ़ायदा यही है। बहुत लोग AI-केंद्रित प्रोजेक्ट्स की maintainability या उलझन को लेकर चिंतित रहते हैं, लेकिन मुझे उसकी परवाह नहीं। अगर मैं किसी प्रोजेक्ट को जल्दी उस स्तर तक पहुँचा सकूँ जहाँ मैं उसके features को सच में छू-समझकर लगातार सुधार सकूँ, तो उसके बाद चीज़ें बहुत तेज़ी से आगे बढ़ती हैं। इस "golden moment" तक पहुँचना ही मेरे लिए programming की लागत का सबसे बड़ा 80% हिस्सा है। इसलिए code agent के खिलाफ़ तर्क मुझे ईमानदारी से बहुत समझ नहीं आते। भले ही आख़िर में सिर्फ़ पूरी तरह फेंक देने लायक code बचे, तब भी उसमें साफ़ मूल्य है। PS. bacon का वज़न ज़रूर करना चाहिए

  • हाल ही में मैंने किसी से इस विषय पर बात की थी, और मैं भी काफ़ी हद तक सहमत हूँ। ये tools ऐसे prototypes आसानी से बना देते हैं जिनसे interaction को सीधे छूकर ideas टेस्ट किए जा सकते हैं, और यह बहुत बढ़िया है। लेकिन इसमें दो समस्याएँ हैं। पहली, जो prototype ऊपर से लगभग पूरा हुआ लगता है, लोगों को यह समझाना कि वह अभी production-ready से बहुत दूर है, वैसे ही सिरदर्द है; और LLM-आधारित code तो मेरे पुराने तरीक़े से बने prototypes से भी production से और ज़्यादा दूर होता है। दूसरी, जो prototype मैं हाथ से बनाता हूँ, उसमें tech stack और implementation के बारे में मैं खुद सीखता हूँ। जल्दी बनाना मुख्य लक्ष्य होता है, लेकिन उस प्रक्रिया से बहुत-सी technical सीख मिलती है, और अक्सर मेरे prototypes ही technical direction तय कर देते हैं। इसके उलट, LLM-आधारित prototype में उसका code खुद लगभग बेकार होता है, और अगर सच में कुछ शुरू करना हो तो लगभग शुरू से फिर बनाना पड़ता है। यानी idea validate हो गया, लेकिन technology या design बिल्कुल validate नहीं हुआ। फिर भी, मुझे यह अब भी उपयोगी लगता है। मेरा मानना है कि "prototype जल्दी बनाओ", और LLM के साथ मैं काफ़ी बड़े systems भी लगभग तुरंत जोड़ पाया हूँ। बस process की समझ बदलनी पड़ती है। non-LLM prototype 10 में से लगभग 4-5वें चरण जैसा होता है, जबकि LLM prototype 2वें चरण के करीब है। यह बुरा नहीं है, लेकिन prototype के बाद बचा काम पहले से ज़्यादा है—इस बारे में expectations समायोजित करनी होंगी

  • "जब प्रोजेक्ट उस स्तर पर पहुँच जाए कि उसके साथ सच में काम किया जा सके, तो फिर तुरंत रफ़्तार आ जाती है"—आपकी यह value system अहम है। मेरे लिए तो उलटा "zero to one" चरण ही सबसे संतोषजनक और मज़ेदार होता है। उसी समय संभावनाएँ सबसे ज़्यादा होती हैं और कुछ ऐसा बनाया जा सकता है जो पहले था ही नहीं। अगर AI पहले से दिशा तय कर दे, तो लगता है उस रचनात्मकता का बड़ा हिस्सा खो जाएगा

  • आपकी बातों से लगता है कि blank page fear आपके लिए बड़ी समस्या है। उसे हटाने वाला tool productivity में बड़ा योगदान देता है—इस बात से सहमत हूँ। लेकिन हर किसी की समस्या वही नहीं होती। software development बहुत व्यक्तिगत गतिविधि है, इसलिए हर किसी का workflow और अनुभव अलग हो सकता है। यह बात नहीं कि किसका तरीका बेहतर है; महत्वपूर्ण यह है कि हर व्यक्ति के लिए सही tools अलग हो सकते हैं, और हर किसी के अनुभव को उसी रूप में स्वीकार और भरोसा किया जाए। LLM से जुड़ी बहसों में दोनों पक्ष अक्सर मान लेते हैं कि सामने वाला भी उन्हीं जैसा है

  • इस हफ़्ते मैंने Mitchell के development setup पर एक interview देखा। जब उनसे पूछा गया कि वे neovim क्यों इस्तेमाल करते हैं, तो उनका जवाब—"मैं ऐसा tool नहीं चाहता जो मेरी जगह code लिखे"—काफ़ी असरदार लगा। यह आलोचना नहीं है, लेकिन यह ध्यान देने वाली बात है कि Mitchell जैसे बेहतरीन developer भी पुराने intellisense से अलग LLM में value देखते हैं

  • मैं अपने सहकर्मियों से इसे इस तरह समझाता हूँ कि "मैं खुद पर Cunningham's Law लागू करता हूँ" Cunningham's Law: 'इंटरनेट से सही जवाब पाने का सबसे तेज़ तरीका सवाल पूछना नहीं, बल्कि ग़लत जवाब पोस्ट करना है'। मैं खाली स्क्रीन को घूरते हुए बहुत देर तक सुन्न बैठा रह सकता हूँ, लेकिन जैसे ही कुछ ऐसा सामने आता है जिसकी आलोचना की जा सके, मैं तुरंत productive हो जाता हूँ

• OpenAI incident पर Mitchell की प्रतिक्रिया के लिए मेरे मन में सचमुच बहुत सम्मान है, भले ही वह ghostty के लिए सकारात्मक दिशा ही क्यों न हो। बहुत कम software vendors दिखते हैं जो सक्रिय रूप से users की शिकायत या झुंझलाहट कम करने की कोशिश करते हों—ख़ासकर MS Auto Update जैसी चीज़ों को देखें तो—इसलिए यह एक बेहद स्वागतयोग्य बदलाव है। और इस लेख में AI का programming में ज़िम्मेदारी से उपयोग भी दिखता है; मुझे नहीं लगता कि यह vibe coding की मूल परिभाषा (जिसे बढ़ा-चढ़ाकर कहा जाता था) में बिल्कुल फिट बैठता है

  • मेरे हिसाब से यहाँ "vibe coding" शब्द ही पूरी तरह बेमेल है। इस term का हर जगह ज़रूरत से ज़्यादा इस्तेमाल हो रहा है

  • "AI का programming में ज़िम्मेदारी से उपयोग" वाली बात से सहमत हूँ। यह vibe coding नहीं, बल्कि simonw के शब्दों में यहाँ पहली बार पेश किया गया vibe engineering है। संबंधित लेख

• जानकारी के लिए, Ghostty ने हाल ही में AI coding tools के इस्तेमाल का खुलासा अनिवार्य किया है संबंधित PR लिंक

• यह लेख दिखाता है कि ai agent UI framework के काम में इतने मज़बूत क्यों होते हैं। मैं भी Rust और GTK के साथ apps बनाता हूँ, और मेरा workflow बहुत मिलता-जुलता है। बात यह नहीं कि मुझे कुछ implement करना नहीं आता, बल्कि ai UI framework के काम में दोहराए जाने वाले, उबाऊ search और trial-and-error का बड़ा हिस्सा संभाल लेता है, इसलिए बहुत मदद मिलती है। Mitchell पूरे process के दौरान पूरे code को समझ रहे होते हैं। वे पहले से जानते हैं कि उन्हें क्या करना है, इसलिए इसे आम तौर पर जिस चीज़ को "vibe coding" कहा जाता है, उससे बिल्कुल अलग कहना चाहिए। expert बनने का कोई अलग shortcut नहीं है। Ghostty वाकई बहुत पसंद है

• LLM की वजह से coding फिर से मज़ेदार हो गई है। काम में LLM सबसे मुश्किल पहले कदम—यानी शुरुआत—में मदद करता है, इसलिए मैं जल्दी काम शुरू कर पाता हूँ। नए codebase को समझने या बोरिंग हिस्से लिखने में भी यह सचमुच उपयोगी है। लेकिन असली मज़ा side projects में शुरू होता है। अचानक आए ideas को बहुत जल्दी implement किया जा सकता है। अब boilerplate code लिखने में घंटों नहीं लगाने पड़ते या tooling से जूझना नहीं पड़ता। जो हिस्से मुझे परिचित नहीं हैं, उन्हें मैं agent को सौंप देता हूँ, या एक ही बार में prompt से feature निकलवाकर अगर नतीजा पसंद न आए तो तुरंत rollback कर देता हूँ

• थोड़ा हटकर सवाल है, लेकिन लगभग हर app को अब भी अपना update framework क्यों चाहिए, यह समझ नहीं आता। क्या यह functionality app store या package manager में integrate नहीं की जा सकती?

  • macOS ecosystem में इस तरह की चीज़ें काफ़ी मुश्किल होती हैं

  • उदाहरण के लिए Ubuntu में यह काफ़ी सुविधाजनक है। अगर आप latest version सीधे डाउनलोड करके install करते हैं, तो उसके बाद लगातार automatic updates मिलते रहते हैं

• आख़िरकार जिस हिस्से में आपने खुद स्वीकार किया कि आप उतने अच्छे नहीं हैं—यानी zero to one चरण—अगर वही AI को दे देंगे, तो वह क्षेत्र ऐसा बन जाएगा जिसे आप कभी खुद नहीं सीख पाएँगे। अगर आप आगे भी उसे खुद करना चाहते हैं, तो उस पर जानबूझकर अभ्यास करना होगा

• Ghostty सचमुच बहुत अच्छा था, और मैं लगभग iTerm छोड़ ही देता, लेकिन cmd-f दबाने पर कुछ नहीं हुआ, इसलिए छोड़ना पड़ा issue और feedback page

  • अगर शुरू से cmd-f होता, तो सोचता हूँ ghostty पर होने वाली चर्चाओं का रुख़ क्या होता। हर पोस्ट में यही बात सुनते-सुनते थोड़ा थकान होने लगी है। दरअसल LLM tools या coding style पर और भी दिलचस्प चर्चाएँ हो सकती थीं, लेकिन आख़िर में सब cmd-f पर ही आकर रुक जाते हैं

  • मज़ेदार बात यह है कि पिछले weekend मैंने Claude का इस्तेमाल करके Ghostty में search feature implement किया। असली search के लिए पहले से ही थोड़ा-बहुत काम करता हुआ code था, इसलिए ज़्यादातर काम UI से जोड़ने का था। दो sessions में (कुल लगभग 10 घंटे), मैं Linux frontend में basic search, highlighting, और previous/next match navigation चालू करा पाया। यह search feature अभी साफ़ तौर पर WIP है, इसलिए आम इस्तेमाल के लिए अभी तैयार नहीं है। इस पर काम करते हुए मुझे एहसास हुआ कि जो चीज़ ऊपर से इतनी 'basic' लगती है, उसे streaming text पर काम करवाना कितना जटिल है

  • मुझे भी Ghostty इतना minimal लगा कि अफ़सोस के साथ जल्दी Warp पर लौटना पड़ा। जानकारी के लिए, Ghostty का default scrollback buffer लगभग 10MB है, और इसे settings में मनचाहे ढंग से बदला जा सकता है

  • यह search feature मार्च 2026 में v1.3 के लक्ष्य के रूप में तय है roadmap लिंक

• लेख की यह पंक्ति—"आइए देखें कि इस feature को जोड़ने की प्रेरणा क्या थी"—पढ़कर फिर याद आया कि OS में हम कितनी असुविधाएँ चुपचाप सह लेते हैं। presentation और screen sharing तो दशकों से आम बात हैं, फिर भी यह हैरानी होती है कि अब तक ऐसा बुनियादी setting आसानी से क्यों नहीं मिलता जो सिर्फ़ presentation window को ही screen पर दिखाने दे

[xguru]

यह Ghostty है, एक ऐसा टूल जिस पर HashiCorp के सह-संस्थापक Mitchell Hashimoto आजकल अपना लगभग ज़्यादातर समय लगा रहे हैं.

Ghostty 1.0 रिलीज़ - हाई-स्पीड, क्रॉस-प्लैटफ़ॉर्म टर्मिनल एम्युलेटर
libghostty aa raha hai

वह agentic coding का समर्थन करते हुए कहते हैं कि session sharing वाकई बहुत महत्वपूर्ण है,
और ज़्यादातर लिंक AMP sessions से जुड़े हुए दिखते हैं Amp - एजेंटिक कोडिंग टूल