Claude Code से Mac ऐप बनाना

 (indragie.com)
29 पॉइंट द्वारा GN⁺ 2025-07-07 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code के ज़रिए 20,000 से अधिक लाइनों वाले macOS ऐप का लगभग पूरा कोड जनरेट करके रिलीज़ किया गया, और खुद लिखा गया कोड 1,000 लाइनों से भी कम था
  • AI coding agent के आने के साथ, पारंपरिक IDE के बजाय prompt-केंद्रित development अनुभव मिला
  • Swift और SwiftUI कोड जनरेशन में कुछ सीमाएँ हैं, लेकिन priming, context engineering, feedback loop डिज़ाइन से गुणवत्ता बढ़ाई जा सकती है
  • automation, deployment, documentation, testing तक का ज़्यादातर काम Claude ने संभाला, जिससे दोहराए जाने वाले manual काम और समय की खपत में भारी कमी आई
  • भविष्य का IDE code editor के बजाय agent उपयोग और context management पर केंद्रित नए UX की ओर विकसित होगा

केवल Claude Code से macOS ऐप रिलीज़ करने का अनुभव

प्रोजेक्ट का अवलोकन

  • हाल ही में Context नाम का एक macOS native ऐप रिलीज़ किया गया। यह MCP server debugging के लिए developer tool है
  • यह ऐप लगभग 100% Claude Code से बनाया गया। करीब 20,000 लाइनों में से सीधे लिखी गई कोड 1,000 लाइनों से भी कम थी
  • Claude से software बनाते समय अब भी developer की skill, iteration और prompt लिखने की क्षमता ज़रूरी है
  • यह लेख Claude Code का उपयोग करके ऐप बनाने की पूरी प्रक्रिया, tool selection, फायदे-नुकसान और high-quality code generation के तरीकों को विस्तार से समझाता है

1. Copilot से Claude Code तक, और development environment में बदलाव

  • सबसे पहला AI coding tool GitHub Copilot था, और सिर्फ़ simple autocomplete से भी development efficiency में बड़ा फ़र्क महसूस हुआ
  • इसके बाद Cursor का agent mode, Windsurf जैसे ऐसे agent-based tools आने लगे जो codebase से context इकट्ठा करते हैं और build-test iteration तक automate करते हैं
  • Claude Code पारंपरिक editor (जैसे VS Code) से अलग terminal-only, prompt-input-केंद्रित pure agent environment को अपनाता है
  • इसमें पारंपरिक IDE की ज़्यादातर सुविधाएँ नहीं हैं, और बस prompt box और output दिखाने वाला सरल UX है
  • coding agent यहाँ पारंपरिक IDE की मदद नहीं करता, बल्कि उसे पूरी तरह replace करने की कोशिश करता है
  • UI और user experience मौजूदा tools से काफ़ी अलग होने के कारण UX को लेकर संदेह था, लेकिन नए approach का आकर्षण महसूस हुआ और इसे आज़माने का फैसला किया

2. side project को फिर से शुरू करना

  • नौकरी के साथ काम करने वाले कई developers की तरह, अधूरे side projects लगातार जमा होते जाते हैं
  • prototype जल्दी बन जाता है, लेकिन आख़िरी 20% completion phase में समय और ऊर्जा की कमी के कारण असली रिलीज़ तक पहुँचना मुश्किल होता है
  • MCP server को test करने के अनुभव में native ऐप की ज़रूरत महसूस हुई, इसलिए खुद ऐप बनाने का निर्णय लिया गया
  • इसी दौरान Claude Code का गंभीरता से उपयोग शुरू हुआ, और AI agent वास्तव में कितनी बड़ी मदद कर सकता है यह सीधे महसूस हुआ

3. Claude Code की शानदार code generation क्षमता

  • नवीनतम Sonnet 4 और Opus 4 models का उपयोग करने वाला Claude Code वास्तव में तेज़ी से अच्छा code तैयार करता है
  • यह project context पढ़ता है, code style समझता है, संबंधित docs और specs पढ़कर features implement करता है, और test code भी अपने-आप लिख देता है
  • build, test iteration, console log और screenshot analysis, bug fixing तक लगभग सब कुछ automate हो जाता है
  • वास्तव में developer के बहुत कम coding समय में high-quality output तैयार हो जाता है
  • जैसे कोई junior employee बिना context के project में डाला जाए, फिर भी कुछ ही मिनटों में feature पूरा कर दे, वैसा स्तर हासिल हो जाता है

4. Swift और SwiftUI support की वास्तविक गुणवत्ता

  • Swift 6.1, macOS 15.5 और नवीनतम SwiftUI का उपयोग किया गया
  • Claude Swift 5.5 तक तो अधिकांश चीज़ें अच्छी तरह संभालता है, लेकिन concurrency जैसी नई बदलावों में कमज़ोर है
  • कभी-कभी यह modern API और legacy API, Objective-C और SwiftUI को मिलाकर गलती भी कर देता है
  • SwiftUI code के मामले में शुरुआती draft कुछ अधूरा या रूखा हो सकता है, लेकिन बार-बार निर्देश देने पर काफ़ी अच्छी तरह सुधर जाता है
  • जब UI code जटिल होता है, तो compiler errors (जैसे type inference failure) आते हैं, और Claude इन्हें अपने-आप छोटे functions में refactor कर सकता है
  • अगर CLAUDE.md फ़ाइल में निर्देश स्पष्ट लिख दिए जाएँ, तो Claude की code quality को एक स्तर और ऊपर ले जाया जा सकता है
    • उदाहरण: SwiftUI को प्राथमिकता देना, Apple Human Interface Guideline का पालन, नवीनतम macOS और Swift6 features का सक्रिय उपयोग आदि
  • अतिरिक्त रूप से agent-rules repository की guidelines का उपयोग करने से और बेहतर गुणवत्ता वाला code generation संभव है

5. "इसे और सुंदर बना दो" जैसा अनुरोध करना संभव है

  • Claude से "इसे और सुंदर/ज़्यादा elegant/बेहतर usability वाला बना दो" जैसे सरल prompts के ज़रिए UI design में सुधार कराया जा सकता है
  • UI bugs या improvement points के लिए screenshot को Claude में paste करके बार-बार feedback देने पर तुरंत बदलाव दिखते हैं
  • और अधिक व्यवस्थित तरीके से, पहले "बताओ कि UI को और सुंदर कैसे बनाया जा सकता है" पूछकर, फिर पसंदीदा बदलाव चुनकर लागू करवाना भी संभव है

6. context engineering का महत्व

  • हाल के AI models अधूरे prompts या grammatical errors होने पर भी काफ़ी अच्छी समझ रखते हैं
  • वास्तव में महत्वपूर्ण बात यह है कि सीमित context window (200k tokens) के भीतर सिर्फ़ सबसे ज़रूरी जानकारी को रखा जाए
  • जब Claude की बातचीत का context भर जाता है, तो वह अपने-आप summary (compaction) करके context reset करता है, और इस प्रक्रिया में कुछ details छूटने या quality घटने जैसी सूचना-हानि का जोखिम होता है
  • इसलिए सीमित context के भीतर अधिकतम गुणवत्ता हासिल करने वाली 'context engineering' AI agent उपयोग का मुख्य काम बन जाती है

7. agent priming

  • इस compaction प्रक्रिया में महत्वपूर्ण context छूट सकता है, इसलिए ज़रूरत पड़ने पर manually summary बनवाना या अतिरिक्त जानकारी को priming के रूप में पहले से पढ़वाना प्रभावी होता है
  • CLAUDE.md के अलावा, अगर specific source code, spec documents आदि पहले पढ़वाकर उनका summary बनवाने वाला prompt लिखा जाए, तो output quality बेहतर होती है
  • नई libraries या latest APIs जैसी वे चीज़ें जो Claude के knowledge cutoff के बाद आई हैं, उन्हें भी कुछ tools (Context7, llm.codes आदि) से docs convert करके Claude के लिए आसानी से समझने योग्य बनाया जा सकता है
  • priming का मतलब है Claude से पहले यह कहलवाना: "इन source files, documents और specs को पढ़कर summary बनाओ", ताकि वह पहले context को पूरी तरह समझ ले

8. agent को स्पष्ट spec चाहिए

  • Claude से कोई feature implement कराना हो, तो मनचाहा परिणाम पाने के लिए ठोस और विस्तृत spec देना ज़रूरी है
  • demos में अक्सर दिखाया जाने वाला "एक वाक्य के prompt से ऐप बनाना" असल में अधिकतम prototype स्तर तक ही संभव होता है
  • spec बहुत polished न भी हो, तो voice input या typing जैसे सुविधाजनक तरीक़े से समझाना पर्याप्त है

9. "Ultrathink and Make a Plan"

  • अगर Claude बिना सोचे सीधे implementation में कूद जाए तो output quality गिर सकती है, इसलिए 'think' या 'ultrathink' जैसे expanded reasoning modes में पहले plan बनवाना प्रभावी रणनीति है
  • अगर हर चरण में implementation से पहले plan review और feedback के बाद काम कराया जाए, तो गुणवत्ता बढ़ती है
  • Anthropic के Claude Code: Best practices for agentic coding दस्तावेज़ को अनिवार्य पठन सामग्री के रूप में सुझाया गया है

10. feedback loop बनाना

  • Claude Code की असली ताकत तब अधिकतम होती है जब वह स्वतंत्र रूप से feedback loop चला सके
  • यानी Claude खुद code बदल सके, build कर सके, failure का कारण analyze कर सके, context इकट्ठा कर सके, और फिर वही चक्र दोहराए — यही automation cycle की कुंजी है
  • जितनी बेहतर यह loop design होगी, Claude उतनी ही ज़्यादा स्वायत्तता से high-quality code पूरा कर सकेगा
  • 1. Build (बिल्ड)
    • Claude को ऐप build (compile) करने की प्रक्रिया खुद करनी चाहिए
    • Swift package के मामले में swift build command से आसानी से build हो जाता है, और Claude इसे स्वाभाविक रूप से संभालता है
    • लेकिन macOS app target (जैसे Xcode project) के मामले में Claude अक्सर यह तय करने में उलझ जाता है कि कौन-सा xcodebuild command इस्तेमाल करना है
    • इस समस्या को हल करने के लिए XcodeBuildMCP नाम का tool इस्तेमाल किया गया, जो Claude के लिए app build और execution को आसान बनाने वाला simplified interface देता है
  • 2. Test (टेस्ट)
    • Claude को code build करने के बाद अपने-आप tests चलाने और उनके परिणामों का analysis करने में सक्षम होना चाहिए
    • Swift package में swift test से tests स्वाभाविक रूप से चल जाते हैं, और Claude इस प्रक्रिया को अच्छी तरह संभालता है
    • अभी तक पूरे app tests या UI tests Claude से सीधे नहीं चलवाए गए, लेकिन संभावना है कि इसके लिए भी XcodeBuildMCP जैसे tools की ज़रूरत होगी
    • test results (success/failure logs) के आधार पर code-fix loop आगे बढ़ती है
  • 3. Fix Bugs (बग ठीक करना)
    • Claude debugging के लिए logs जोड़ने के तरीके से समस्याओं को ट्रैक कर सकता है
    • लेकिन Claude खुद ऐप चलाकर logs generate नहीं कर सकता
    • user को ऐप manually चलाने के बाद console logs कॉपी करके Claude में paste करने की प्रक्रिया ज़रूरी होती है
    • यह तरीका व्यवहार में काफ़ी अच्छा काम करता है, लेकिन अगर unit tests या UI tests पहले से पर्याप्त न हों, तो पूरी तरह automatic bug fixing मुश्किल रहती है
    • web apps के लिए playwright-mcp जैसे browser automation solutions हैं, लेकिन native apps के लिए अभी ठोस विकल्प कम हैं
  • 4. Fix UX Issues (UX समस्याएँ ठीक करना)
    • UI/UX issues सुधारने के लिए screenshots सीधे Claude में paste करके iterative feedback दिया जा सकता है
    • Peekaboo जैसे tools से screenshot automation संभव है, लेकिन पहले ऐप को मनचाही स्थिति तक manually चलाना पड़ता है तभी screenshot लिया जा सकता है, यही इसकी सीमा है
    • यानी UX automation में अब भी user intervention की ज़रूरत रहती है

11. Claude Code सिर्फ़ code लिखने से कहीं ज़्यादा काम करता है

  • Claude Code एक general-purpose large language model (LLM) पर आधारित है, इसलिए code लिखने के अलावा भी कई non-development कामों में उपयोगी है
  • उदाहरण के लिए app copy editing, release plan बनाना, feature improvements सुझाना जैसे development के बाहर के काम भी Claude से स्वाभाविक रूप से कराए जा सकते हैं
  • खास तौर पर बहुत उपयोगी चीज़ों में से एक था वास्तविक data न होने पर शुरुआती चरण में Mock data अपने-आप तैयार कर देना
    • Context ऐप के विकास के दौरान Swift के लिए MCP client library अभी पूरी नहीं हुई थी, लेकिन UI prototype पर काम आगे बढ़ाना था
    • सामान्यतः यथार्थवादी mock data खुद बनाना बेहद झंझट वाला और समय लेने वाला काम होता, इसलिए शायद इसे करने की कोशिश भी नहीं की जाती
    • लेकिन Claude ने कुछ ही सेकंड में बेहद विश्वसनीय Mock data बना दिया, जिससे ऐसा UI state तैयार हुआ जिसे वास्तविक data से अलग करना मुश्किल था
    • वास्तव में दोस्तों के साथ UI साझा करते समय भी इसी Mock data पर आधारित screenshots इस्तेमाल किए गए, और वे लगभग production-जैसा प्रभाव दे पाए
    • MCP server के मामले में उस समय official spec की सिर्फ़ कुछ features ही implement हुई थीं, इसलिए वास्तविक data हासिल करना मुश्किल था
    • इसके बावजूद Claude द्वारा बनाए गए Mock data के ज़रिए पूरे UI flow और feature behavior को validate किया जा सका

12. high-quality automation लागू करना अब (लगभग) मुफ़्त है

  • software रिलीज़ के आख़िरी 20% में सबसे दर्दनाक हिस्सों में से एक है app release process का automation
  • खासकर macOS apps में code signing, notarization, packaging (DMG generation) जैसी जटिल deployment प्रक्रियाएँ होती हैं, जिनकी वजह से manual काम या अस्थिर scripts के कारण रिलीज़ अक्सर टल जाती थी
  • पहले fastlane जैसे automation tools को किसी तरह सेट करना पड़ता था, या कम-से-कम छोटे Python scripts खुद लिखने पड़ते थे
  • इस project में कुछ घंटों के iterative prompting और debugging से Claude ने पूरा release automation script तैयार कर दिया
  • इस script के मुख्य काम थे:
    • environment setup check: ज़रूरी tools सही तरह से installed हैं या नहीं, इसकी जाँच
    • automatic changelog generation: git commits से बदलाव निकालकर, manually लिखे गए points के साथ मिलाकर HTML release notes तैयार करना
    • app build और packaging: app build → code signing → notarization → DMG packaging तक पूरी प्रक्रिया automate करना
    • Sparkle update feed (appcast) generation: मौजूदा users तक automatic updates पहुँचाना
    • release tags और deployment: GitHub पर tags जोड़ना और release publish करना
    • Sentry symbol upload: crash report analysis के लिए debug symbols अपने-आप upload करना
  • script पूरा होने के बाद, "CLI output को और सुंदर बना दो" जैसी एक लाइन की prompt से CLI UI में भी सुधार कर दिया गया
  • अंतिम परिणाम करीब 2,000 लाइनों के Python code के रूप में सामने आया; अगर यह सब manual होता तो शायद सिर्फ़ minimum features पर ही रुकना पड़ता, लेकिन Claude की वजह से इसे high quality तक ले जाया गया
  • इस automation script की वजह से हर रिलीज़ पर कई दर्जन मिनट के दोहराए जाने वाले काम बचने लगे
  • natural language में spec समझाकर, और execution के दौरान मिली errors पर Claude को feedback देकर उन्हें ठीक करवाने से ज़्यादातर काम पूरे हो गए

13. भविष्य का IDE पूरी तरह अलग होगा

  • इस project के दौरान वास्तव में शुरू से अंत तक केवल Claude Code और GitHub Desktop (diff देखने के लिए) इन दो tools का ही उपयोग हुआ
  • पारंपरिक IDE की मुख्य सुविधाएँ जैसे file tree, code editor, extensions, plugins लगभग बिल्कुल आवश्यक नहीं रहीं
  • कभी-कभार Xcode खोलकर सीधे code बदला गया, लेकिन Xcode की खास सुविधाएँ (जैसे SwiftUI Previews, View Debugger आदि) भी लगभग इस्तेमाल नहीं की गईं
  • अभी का समय ही AI coding agents की क्षमता का सबसे शुरुआती और कमज़ोर चरण है, इसलिए आगे IDE के पूरी तरह नए रूप में विकसित होने का अनुमान है
  • Copilot, Cursor, Windsurf आदि सभी VS Code से शुरू होकर features जोड़ने वाले tools हैं, लेकिन VS Code खुद 20 साल पुराने JetBrains IDE से लगभग बहुत अलग नहीं है
  • Warp जैसे projects terminal को modern बनाकर उसे agent development environment में बदलने की कोशिश कर रहे हैं, लेकिन आकलन यह है कि terminal-centric UX भी भविष्य का अंतिम उत्तर नहीं होगा
  • भविष्य के IDE का मूल यह होगा कि वह developers को agent context को प्रभावी ढंग से तैयार (priming) करने और feedback loops को design व manage करने में सक्षम बनाए
  • यानी code editor केंद्र में नहीं रहेगा, बल्कि agent उपयोग और context management केंद्रित UX की ओर बड़ा बदलाव होगा

14. अब side projects फिर से रिलीज़ कर पाना संभव हुआ

  • इस पूरी यात्रा में सबसे प्रभावशाली बात यह नहीं थी कि एक शानदार ऐप बना, बल्कि यह थी कि अब फिर से अपने side project को वास्तविक रूप में रिलीज़ करना संभव हो गया
  • ऐसा लगा जैसे हर दिन 5 घंटे अतिरिक्त मिल गए हों, और इसकी कीमत महीने के सिर्फ़ $200 के बराबर थी
  • Claude Code जैसे AI coding agents की वजह से, लंबे समय से टाले गए ideas को वास्तविकता में बदलने की ऊर्जा और आत्मविश्वास फिर से मिल गया

संबंधित पढ़ाई

2 टिप्पणियां

 
geek12356 2025-07-08

बहुत करो
 
GN⁺ 2025-07-07
Hacker News राय

  • सिर्फ 2 साल पहले तक मुझे पूरा भरोसा था कि मैं एक सचमुच बेहतरीन Python engineer हूँ, लेकिन अब मैं native mobile apps, Slack से बात करने वाले desktop apps, Go में लिखा API, और React आधारित पूरा web app भी कुछ दिनों या कुछ घंटों में बना सकता हूँ
    ऐसा लगता है जैसे कोई superpower मिल गई हो, और productivity, speed, creativity सब उमड़ रहे हों, लेकिन दूसरी तरफ एक अजीब-सी उदासी भी महसूस होती है
    मेरा पेशा, मेरा जुनून, और वे सभी काम जिन्हें सीखने और निखारने में मैंने बहुत समय और त्याग लगाया, अब ज़्यादातर मशीनों द्वारा replace किए जा रहे हैं
    ऐसे tools बनाने वाली कंपनियाँ अभी बस शुरुआत में हैं
    यह अगली पीढ़ी के engineers के लिए क्या मायने रखेगा, और यह धारा कहाँ तक जाएगी, यह जानने की उत्सुकता है
    सोच रहा हूँ क्या और लोग भी मेरी तरह ऐसा महसूस करते हैं

    • कई platforms पर native, mobile, Go, React जैसी अलग-अलग tools को efficiently संभाल पाना एक Python engineer के रूप में मेरे software development अनुभव की वजह से संभव हुआ है
      LLM जिस हिस्से को replace करता है, वह यह है कि अब हर platform से जुड़ी छोटी-छोटी खास बातें याद रखने की ज़रूरत नहीं रहती
      मुझे Go में for loop का syntax याद न हो, तब भी मैं तुरंत उपयोगी Go code लिख सकता हूँ
      फिर भी loops, Go के concepts, structured programming, compiler, build और test scripts जैसी बुनियादी बातों की समझ अभी भी ज़रूरी है
      जिन लोगों का programming में background नहीं है, उनके लिए यही हिस्सा बहुत कमज़ोर रहता है
      मुझे LLM ऐसा amplifier और accelerator लगता है, जो मेरे लंबे career में जमा हुए धुंधले ज्ञान को अलग-अलग languages और platforms पर तुरंत लागू करने लायक बना देता है
      पहले मैं Python, JavaScript और SQL से ही हर समस्या हल करने की कोशिश करता था, क्योंकि नई language या platform की छोटी-छोटी भिन्नताएँ फिर से सीखना भारी लगता था
      अब मैं Go, Bash, AppleScript, jq, ffmpeg जैसी चीज़ें भी खुशी से इस्तेमाल करता हूँ, और Swift project पर भी विचार कर रहा हूँ

    • मैंने non-technical background वाले लोगों को LLM से कुछ बनाते देखा है, लेकिन ज़्यादातर मामलों में वे बहुत धीमे होते हैं या लगभग असफल
      तकनीकी skill शायद आखिरकार अनिवार्य न हो, लेकिन साफ़ और सटीक communication ability ज़रूर चाहिए
      अगर HTML की बुनियादी समझ भी हो, तो text को साफ़-सुथरे ढंग से डालकर LLM को और स्पष्ट तरीके से समझाया जा सकता है
      मुझे अब भी लगता है कि technical background एक advantage है

    • मुझे लगता है कि industrial revolution से पहले के कारीगर मज़दूरों ने भी कुछ ऐसा ही महसूस किया होगा
      लेकिन यह भी याद रखना चाहिए कि उनमें से ज़्यादातर को ठीक से शिक्षा नहीं मिली थी, उनके 1-2 बच्चे मामूली बीमारियों से 10 साल की उम्र से पहले मर जाते थे, और वे बिजली, पानी, indoor plumbing, refrigerator के बिना रहते थे
      अपने हाथों से tools बनाना romantic लगता है, जैसे Python code हाथ से लिखना, लेकिन जैसे-जैसे समय आगे बढ़ता है, मुझे लगता है कि ज़्यादा abstract स्तर पर जीना हमारे पूर्वजों के लिए भी फायदेमंद होता
      किसी को भी खुद Python code लिखने से कोई नहीं रोक रहा, और graphite craftsmanship की तरह इसे hobby के रूप में पसंद करने वाले लोग ज़रूर होंगे

    • मैं इस बात से सहमत होना मुश्किल पाता हूँ कि मेरा पेशा, जुनून और skill अब मशीनों ने संभाल लिया है
      मशीनें बस निर्देशों का पालन करती हैं; उनके पास अनुभव, दूरदर्शिता, आत्मचिंतन, योजना बनाने की क्षमता या रचनात्मकता नहीं होती
      सिर्फ इंसानों के पास ideas, creativity, goals, empathy, दूसरों को अच्छे ideas से मनाने की क्षमता, और परिस्थिति के हिसाब से context समझने की योग्यता होती है
      मुझे नहीं लगता कि programming नाम का पेशा गायब हो रहा है; बल्कि यह कहीं ऊँचे abstraction level पर जा रहा है
      पहले भी बिना bits, bytes और assembly की एक-एक line जाने developer बना जा सकता था, जबकि एक समय ऐसा था जब assembly अनिवार्य थी
      अब हम ऐसे दौर में हैं जहाँ programming language खुद न भी आती हो, तो सिर्फ English और requirements अच्छी तरह जानकर program बन सकता है
      फिर भी memory layout, assembly और low-level concepts जानने वाले लोग अभी भी पर्दे के पीछे क्या हो रहा है, यह बेहतर समझते हैं, और ज़रूरत पड़ने पर उसे और "अच्छे" तरीके से कर सकते हैं
      इसका मतलब यह नहीं कि ऊपरी abstraction layers बेकार हो जाएँगी या गायब हो जाएँगी

    • मैं भी बिल्कुल यही महसूस कर रहा हूँ
      20 साल से ज़्यादा समय से मैं professional तौर पर software development कर रहा हूँ, और मुझे यह काम सचमुच बहुत पसंद था
      अब मैं Claude Code का 100% उपयोग कर रहा हूँ और productivity स्पष्ट रूप से बढ़ी है, लेकिन पहले की प्रक्रिया किसी कला जैसी लगती थी, जबकि अब यह industrialized mass production जैसी लगती है
      मैं इस नई reality में फिर से कुछ ऐसा खोजना चाहता हूँ जिसमें मैं software में गहराई से डूब सकूँ, और यह तय है कि पहले वाला आनंद काफ़ी कम हो गया है

  • यह लेख बहुत अच्छी तरह लिखा गया है और सिर्फ पढ़ना भी आनंददायक है
    भविष्य का IDE आज से बिल्कुल अलग होगा
    मैंने भी Cursor से शुरुआत की, फिर VS Code-enhanced IDE इस्तेमाल किया, और अंत में Claude Code पर आ गया
    इस वजह से terminal की अहमियत और बढ़ गई, और मेरा workflow iTerm से Ghostty (तेज़, हल्का और modern), Tmux, Tmuxinator और NeoVim की ओर शिफ्ट हो गया
    मैं cat या bat command से files देखता हूँ, कभी-कभी केवल text edit करता हूँ, और ज़्यादातर भारी काम Claude Code संभालता है
    NeoVim या Emacs में सिर्फ specs और prompts लिखने जैसा काम करता हूँ, और यह workflow मुझे बहुत पसंद है
    सिर्फ code generation ही नहीं, बल्कि zsh, neovim, ghostty जैसी config files बदलने के लिए भी मैं Claude Code को tasks assign करता हूँ
    config refactoring भी कुछ ही मिनटों में हो जाती है
    codebase questions, code refactoring, code documentation, commit message generation जैसी सारी चीज़ें भी उसी से कराता हूँ, और यह Pure awesomeness है

    • आखिर में आपने codebase questions, refactoring, code documentation और meaningful commits तक की बात की; मुझे भी CC से शानदार commit messages बनवाने का अनुभव है, इसलिए मैंने Conventional Commits की जानकारी और examples CLAUDE.md फ़ाइल में डाल रखी हैं

    • क्या CC .zshrc जैसी personal config files बदलने से पहले उनका automatic backup भी बना देता है?

  • Terminal + Claude Code + project folder
    अब जाकर समझ आया कि सच में बस इतना ही काफ़ी है
    full IDE setup मुझे पहले भी झंझट लगता था, और अलग-अलग OS के लिए cross-compile करना हो तो QT setup भी जटिल होता था, इसलिए मुझे हमेशा editor + terminal का combination सबसे logical लगा
    अब Claude Code एक और खुली terminal window की तरह requests process करने में मदद करता है, तो ऐसा लगता है जैसे developer से project leader तक "level up" कर लिया हो
    और staff management का stress भी नहीं है
    अब मैं वे सारे side projects, जिन्हें लंबे समय से करना चाहता था, मार्च में Claude आने के बाद कुछ ही महीनों में पूरा कर चुका हूँ

  • 1-2 साल पहले मेरे मन में एक बात आई थी: skilled developers के लिए LLM एक शानदार assistant है, skilled developers को replace करने की कोशिश में गड़बड़ है, और unskilled developers के लिए एक dangerous assistant है
    खुद अनुभव करने पर यह बात ज़्यादातर सही ही लगी
    अब मुझे लगता है कि unskilled developers के लिए LLM अच्छा mentor भी हो सकता है, लेकिन वास्तविकता में ज़्यादातर लोग code क्यों काम कर रहा है यह समझे बिना random changes करते रहते हैं, जब तक कि वह किसी तरह चलने न लगे
    इसलिए ऐसे हालात में LLM एक dangerous assistant है—यह मेरा शुरुआती विचार अब और मज़बूत हो गया है
    ऐसे में subtle bugs और समस्याएँ अक्सर code में चुपचाप छिपी रह जाती हैं, और पकड़े जाने पर भी लोग उनकी वजह नहीं समझ पाते

  • यह निष्कर्ष खास तौर पर प्रभावशाली लगा कि LLM assistant की वजह से side projects के आख़िरी 20% को पूरा करना बहुत आसान हो गया
    मेरे लिए इस यात्रा की सबसे दिलचस्प बात नई apps नहीं, बल्कि यह है कि अब मैं फिर से coding की अपनी प्यास बुझा पा रहा हूँ और साफ़-सुथरे side projects को अच्छी completion के साथ ship कर पा रहा हूँ
    ऐसा लगता है जैसे दिन में 5 घंटे अतिरिक्त मिल गए हों, और महीने के 200 डॉलर में यह हो जाता है

  • मैं इसे मुख्य रूप से छोटे utilities बनाने में इस्तेमाल करता हूँ, और यह सचमुच कमाल का काम करता है
    मैंने Claude से कुछ ही घंटों में वैसी utility बनवा ली, जो launchctl/launchd task status (run/unload/fail आदि) को OrbStack menu icon की तरह दिखाती है

    • मैंने भी मज़े के लिए एक iOS app और Wordpress plugin बनाया, और उससे बहुत संतुष्ट था
      मुझे लगता है आगे और भी लोग ऐसा करेंगे, लेकिन क्या सभी को github पर code share नहीं करना चाहिए?

  • अगर कोई 2008 से Mac के लिए software बना रहा है, तो मेरा मानना है कि Claude कहाँ गलती कर रहा है, वह जल्दी पकड़कर उसे तुरंत ठीक कर सकता था

    • Claude Code जैसे tools मौजूदा skills और experience को amplify करते हैं
      वे expertise को कभी replace नहीं कर सकते

    • आखिर में पता चलता है कि इस काम पर महीने के 200 डॉलर लगते हैं, और मैं तो अपने मुख्य hobby के लिए ज़रूरी Autodesk पर भी 50 डॉलर खर्च करने में हिचकता हूँ
      मुझे लगता है ये AI कंपनियाँ अभी profit नहीं कमा रहीं, और जैसे ही investors returns माँगना शुरू करेंगे, cost बढ़ना या service quality गिरना तय है
      अगर ये models बिना अनुमति train किए गए code देने के मामले में lawsuit हार गए, तो Claude की Swift generation क्षमता भी तुरंत गिर जाएगी
      क्या हमें सच में उम्मीद करनी चाहिए कि Disney AI lawsuits में हार जाएगा?
      ईमानदारी से कहूँ तो मेरी यह टिप्पणी भले खास मायने न रखती हो, लेकिन AI fatigue सचमुच गंभीर है
      मुझे तो लगता है कि इस समय HN और दूसरे tech forums में ऐसे posts पर रोक होनी चाहिए
      अगर कोई यह लिखे कि उसने Google या StackOverflow से आसानी से code लिख लिया, तो लोग उसे नीरस कहकर हँसी उड़ाएँगे; मुझे लगता है ऐसे posts भी आखिरकार उसी तरह के हैं
      AI के सहारे hobby या profession में "free ride" लेने वाली बातें सुन-सुनकर अब ऊब हो गई है

  • Windsurf जैसे tools और CLI tools के साथ अपना customized tool बनाना अब पहले से कहीं आसान हो गया है
    यह सचमुच बहुत दिलचस्प समय है

  • मुझे लगता है जल्द ही कोई LLM की मदद से MacOS को ही clone कर देगा

  • कुछ हफ़्ते पहले मैंने LLM tooling का इस्तेमाल करके retro68 और c++ के साथ system 6 (classic Mac) app में 6DOF wireframe renderer को boot कराने में सफलता पाई