मेरा LLM code generation workflow
(harper.blog)- tldr: पहले spec पर brainstorming करो, फिर plan बनाओ, उसके बाद LLM codegen से उसे execute करो। अलग-अलग iteration loop चलाओ। फिर जादू होता है
- मैं LLM का इस्तेमाल करके कई तरह के छोटे products बहुत तेज़ी से बना रहा हूँ। यह मज़ेदार भी है, और उपयोगी भी
- लेकिन अगर गलत approach में फँस जाओ, तो बहुत समय बर्बाद हो सकता है
- बहुत से developers का approach लगभग एक जैसा है, और नीचे मेरा workflow है
"अभी यह अच्छी तरह काम कर रहा है, लेकिन 2 हफ्ते बाद शायद काम न करे या दोगुना बेहतर काम करे"
- डेवलप करने के 2 तरीके हैं
- Greenfield code: नया project शुरू करना
- Legacy modern code: मौजूदा codebase को improve या extend करना
Greenfield: शुरू से नया शुरू करना
- यह process “शुरू से शुरू करने” वाली स्थिति के लिए बहुत उपयुक्त है
- flow यह है कि पहले idea पर brainstorming करो, उसे document करो, छोटे step-by-step plan बनाओ, और फिर code generation tools से implement करो
- Step 1: idea को ठोस बनाना
- ChatGPT जैसे LLM को idea समझाते हुए, उससे एक-एक करके सवाल निकलवाकर उसे एक ठोस spec में refine किया जाता है
- आखिर में एक detailed
spec.mdबनाया जाता है, ताकि उसे किसी developer को सौंपने लायक document की तरह व्यवस्थित किया जा सके - ज़रूरत हो तो Deep Research जैसे tools से idea के लिए supporting material भी लिया जा सकता है
- Step 2: plan बनाना
- spec के आधार पर, एक ज़्यादा शक्तिशाली “understanding/reasoning” model से detailed step-by-step blueprint बनवाया जाता है
- चाहे TDD style हो या नहीं, हर step को छोटे work units में तोड़कर क्रम में रखा जाता है
- इस process से
prompt_plan.mdऔरtodo.mdबनाए जाते हैंprompt_plan.mdमें code generation के लिए prompt design होता है, औरtodo.mdमें checklist होती है
- यह planning आम तौर पर 15 मिनट के भीतर हो जाती है, और बाद में reference के लिए भी आसान रहती है
- Step 3: execution
- Aider, Cursor, Claude जैसे कई code generation/help tools का इस्तेमाल करके असली code लिखा जाता है
- उदाहरण के तौर पर Claude और Aider को लिया जा सकता है
- Claude तरीका
- पहले project structure (boilerplate वगैरह) सेटअप किया जाता है, फिर step-by-step prompts Claude में डाले जाते हैं
- बने हुए code को IDE में copy-paste करके test किया जाता है
- अगर समस्या आती है, तो
repomixजैसे tool से मौजूदा codebase Claude को देकर debugging की जाती है - workflow
- Repo setup (boilerplate, uv init, cargo init, etc)
- Claude में prompt paste करना
- claude.ai से IDE में copy & paste
- code चलाना, tests चलाना, आदि
- …
- अगर काम कर जाए, तो अगले prompt पर जाना
- अगर काम न करे, तो Repomix से codebase Claude को भेजकर debug करना
- इसे बार-बार दोहराना (rinse repeat)
- Aider तरीका
- Aider में भी
prompt_plan.mdको क्रम से डालकर काम किया जाता है - यह अपने-आप tests चलाने, errors ढूँढने और fixes करने की process में मदद कर सकता है
- ज़रूरत पड़ने पर interactive debugging से समस्या हल की जाती है
- Repo setup (boilerplate, uv init, cargo init, etc)
- Aider चलाना
- Aider में prompt paste करना
- Aider को नाचते हुए देखना ♪┏(・o･)┛♪
- Aider tests चला सकता है, या app चलाकर verify कर सकता है
- अगर काम कर जाए, तो अगले prompt पर जाना
- अगर काम न करे, तो Aider के साथ Q&A करते हुए ठीक करना
- इसे बार-बार दोहराना (rinse repeat)
- Aider में भी
- नतीजे
- इस तरीके से scripts, Expo apps, Rust CLI जैसे कई projects को कम समय में implement किया जा सकता है
- अगर आपके पास छोटे या बड़े ऐसे projects पड़े हैं जिन्हें आप टालते आ रहे हैं, तो इसे एक बार आज़माने की सलाह है
- इसका फायदा यह भी है कि नई language या नई technology सीखते हुए तेज़ी से प्रयोग किया जा सकता है
Non-greenfield : मौजूदा code पर incremental/iterative काम
- यह तरीका तब काम आता है जब पहले से मौजूद codebase पर छोटे-छोटे काम बार-बार लागू करने हों
- यहाँ बड़े overall plan से ज़्यादा, हर task unit के हिसाब से specific requests और results का आदान-प्रदान होता है
- context इकट्ठा करना
repomixजैसे tools से codebase का सार बनाकर LLM को दिया जा सकता हैmiseवगैरह से repeated setup manage किया जाता है, और summary result कोoutput.txtनाम की file में रखा जाता है- अगर codebase बहुत बड़ा हो, तो केवल ज़रूरी हिस्सों का ही सार बनवाया जा सकता है
- example workflow
mise run LLM:generate_missing_testsजैसे command से LLM से यह समझवाया जाता है कि किन हिस्सों में tests की कमी है- Claude या Aider से उन suggested items (issues) को लागू किया जाता है, और फिर result को दोबारा test किया जाता है
- इस तरह मौजूदा codebase को धीरे-धीरे improve किया जाता है
मुख्य prompt examples
- Code review
“एक senior developer की तरह code का बहुत ध्यान से review करो। line numbers और context शामिल करो। हल्का-फुल्का review नहीं, गहराई से देखो”
“You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“ - GitHub Issue generation
“एक senior developer की तरह code की जाँच करो, और बड़े issues को Github issue format में लिखो”
“You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“ - Missing tests
“एक senior developer की तरह code की जाँच करो, और कौन से tests गायब हैं या होने चाहिए, यह ठोस रूप से बताओ“
“You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
स्की ᨒ↟ 𖠰ᨒ↟ 𖠰
- LLM की मदद से बहुत तेज़ी से code लिखते-लिखते, एक समय ऐसा आता है जब complexity या context उलझकर भ्रम पैदा करने लगते हैं
- ऐसे समय planning phase के documents (जैसे Greenfield process) को फिर से देखना, या tests को व्यवस्थित रूप से लिखकर रखना मददगार होता है
- जितनी तेज़ी से आगे बढ़ रहे हो, उतना ही ज़रूरी है कि बीच-बीच में थोड़ा break लेकर सोच को व्यवस्थित किया जाए
मैं बहुत अकेला हूँ (｡•́︿•̀｡)
- ज़्यादातर LLM-based workflows अभी ‘single-player mode’ के लिए optimize किए गए हैं
- टीम के रूप में साथ coding करने पर conflicts और merge problems जैसी चीज़ें जटिल हो जाती हैं
- उम्मीद है कि आगे चलकर ऐसे ‘multiplayer’ collaboration environments विकसित होंगे जहाँ कई लोग एक साथ LLM का इस्तेमाल कर सकें
समय
- LLM की वजह से code लिखने की efficiency काफ़ी बढ़ गई है, लेकिन token processing के इंतज़ार से पैदा होने वाला ‘downtime’ भी होता है
- इस समय का इस्तेमाल मैं दूसरे project ideas सोचने, music सुनने, या बातचीत करने में करता हूँ
- मुझे लगता है कि मेरी personal productivity पहले के मुकाबले बहुत बढ़ गई है
Haterade ╭∩╮( •̀_•́ )╭∩╮
- मेरे बहुत से दोस्त “कमीने LLM, यह तो बिल्कुल बेकार है” जैसी attitude दिखाते हैं, और मैं इस नज़रिए को बहुत ज़्यादा तवज्जो नहीं देता
- बेशक, मैं भी उस stance को पूरी तरह share नहीं करता, लेकिन शक की नज़र रखना ज़रूरी है
- AI से नफ़रत करने की वजहें अनगिनत हैं, और मेरी सबसे बड़ी चिंता बिजली की खपत और पर्यावरणीय असर को लेकर है
- फिर भी… "code को बहते रहना चाहिए" हाँ… उफ़
- अगर आप और जानना चाहते हैं लेकिन ज़रूरी नहीं कि cyborg programmer बनना चाहते हों, तो मेरी सलाह है: “अपना मत बदलिए, बस Ethan Mollick की ‘Co-Intelligence: Living and Working with AI’ पढ़िए”
- यह किताब techno-anarchic capitalism style की अतिशयोक्ति के बिना, LLM के फायदों को अच्छी तरह समझाती है
- मुझे व्यक्तिगत रूप से इससे बहुत मदद मिली, और जिन दोस्तों ने यह किताब पढ़ी, उनके साथ मैं कहीं ज़्यादा गहरी बातचीत कर पाया
- ज़ोरदार सिफारिश है
6 टिप्पणियां
Ethan Mollick की ‘Co-Intelligence: Living and Working with AI'
शायद मार्च में 'Dual Brain' शीर्षक से प्रकाशित होने वाली है
अरे, Repomix नाम की भी कोई चीज़ थी। मैं तो हर बार copy-paste ही कर रहा था.. T_T
धन्यवाद!
क्या दूसरे डेवलपरों की गालियां भी अब LLM मेरी जगह खा लेगा?
मैं अभी भी LLM को एक उन्नत Google, एक मददगार Stack Overflow की तरह ही इस्तेमाल कर रहा हूँ, लेकिन लगता है कि इसे और बेहतर तरीके से कैसे काम में लाया जाए, इस पर सोचना चाहिए.
मेरे लिए यह भी ज़रूरी है कि कुछ कैसे बनाया जाए, लेकिन AI के साथ मिलकर यह सोचना भी उतना ही महत्वपूर्ण लगता है कि वह काम क्यों करता है. पुराने तकनीकी दस्तावेज़ या standards खोजते समय LLM काफ़ी उपयोगी होता है.
Hacker News राय
LLM नए प्रोजेक्ट के प्रोटोटाइप जल्दी बनाने का एक टूल है। लेकिन जब मौजूदा कोड या mature प्रोजेक्ट्स में बदलाव किए जाते हैं, तो context की कमी की वजह से यह complexity बढ़ाने या अनावश्यक framework जोड़ने की ओर झुकता है। LLM कोड को समझने का विकल्प नहीं है।
LLM के साथ सहयोग में सवालों के ज़रिए context बनाना महत्वपूर्ण है। यह सीधे context तैयार करने से अधिक प्रभावी है।
हाल में LLM के साथ mob programming आज़मा रहे हैं। एक LLM implementation संभालता है, और दूसरा LLM आलोचना करता है तथा सुधार सुझाता है।
प्रोजेक्ट में opinionated framework नहीं जोड़ना बेहतर है। इससे उस context का आकार बढ़ जाता है जिसे model को समझना होता है। उदाहरण के लिए, Plasmo की जगह browser extension setup LLM को करने दिया गया।
जो लोग Cursor chat से शुरू होकर बेहतर workflow तक पहुँचे हैं, उनके अनुभव सुनना चाहूँगा। यह जानने की जिज्ञासा है कि planning में लगाया गया समय उपयोगी रहा या नहीं, hallucination कम हुए या नहीं, और कुल मिलाकर समय बचा या नहीं।
यह लेख बताता है कि LLM का सही इस्तेमाल कैसे किया जाए। बहुत से लोग language model के साथ प्रभावी ढंग से संवाद करने का पर्याप्त अभ्यास नहीं करते। लेखक ने LLM के साथ संवाद में महारत हासिल कर ली है, और यह workflow efficiency को अधिकतम करता है।
LLM-आधारित workflow में efficiency को अधिकतम करने के लिए तेज typing speed, सही judgment, और हर model की strengths और weaknesses की अच्छी समझ चाहिए।
LLM का इस्तेमाल करने वाले coding tools मज़ेदार हैं, लेकिन वे सच में मददगार हैं या नहीं यह जाँचने के लिए ठोस लक्ष्य और deadline तय करनी चाहिए। ऐसी शर्तों में LLM के असफल होने की संभावना अधिक होती है।
बहुत से नए programmers programming के specification और execution planning वाले हिस्से को भूल जाते हैं। LLM का सफल उपयोग करने के लिए उससे specification और execution plan बनवाना चाहिए।
Claude को लेकर इतनी उम्मीद क्यों है, यह समझ नहीं आता। Apache Spark के बारे में सवालों में बहुत hallucination हुए। समझना चाहता हूँ कि Claude दूसरे models से बेहतर क्यों माना जाता है।
व्यक्तिगत डेवलपर के लिए यह ठीक हो सकता है, लेकिन टीम में एक ही codebase का विश्लेषण करने वाले कई LLM instances आर्थिक रूप से उचित नहीं हैं और जोखिम भरे भी हो सकते हैं। यह जानने की जिज्ञासा है कि क्या टीमों के लिए centralized context देने वाला कोई product मौजूद है।