Ask HN: क्या कोई कोडिंग के लिए LLMs के उपयोग के अलग-अलग तरीकों के साथ प्रयोग कर रहा है?
कोडिंग के लिए large language models के साथ प्रयोग कर रहे इंजीनियर हल्के, spec-driven workflows और अधिक जटिल agent orchestration systems के बीच बँटे हुए हैं। कई लोगों का कहना है कि मौजूदा “vibe coding” और autonomous agents बहुत सा code तो बनाते हैं, लेकिन flow state, समझ, और दीर्घकालिक maintainability को नुकसान पहुँचाते हैं, इसलिए वे detailed upfront specs, issue/PR-based workflows, narrow role-specific tools, और pair-programmer style assistants जैसी patterns की ओर झुक रहे हैं। सभी approaches में bottleneck code generation से हटकर human comprehension, review, और system design की ओर जा रहा है, और उभरते tools raw autonomy के बजाय बेहतर planning, constraints, और safety पर केंद्रित हैं।
स्पेक-आधारित बनाम एजेंटिक/ऑर्केस्ट्रेटेड कोडिंग
- कई लोगों का मानना है कि सबसे बड़ा लाभ जटिल ऑर्केस्ट्रेशन नहीं, बल्कि अधिक स्पष्ट स्पेक्स हैं: एकल इरादा, स्पष्ट I/O कॉन्ट्रैक्ट, बाधाएँ और पूर्व-शर्तें, साथ ही क्रमिक स्पष्टिकरण।
- कुछ लोग “क्लीन स्लेट” उपयोग को पसंद करते हैं: “कॉन्टेक्स्ट रॉट” और इरादे के पतले पड़ने से बचने के लिए न्यूनतम या कोई दीर्घकालिक मेमोरी नहीं; इसके बजाय बाहरी markdown/docs का उपयोग करें जिन्हें मॉडल grep कर सके।
- “Skills” (संकीर्ण, पुन: प्रयोज्य निर्देश और टूल्स) को कम आँका हुआ माना जाता है; “agents” ज़्यादातर कॉन्टेक्स्ट प्रबंधन और बाधाओं में मदद करते हैं।
- अन्य लोग multi-agent टीमों, graph-based workflows, और role-pinned models (mechanics के लिए सस्ते, planning/review के लिए मजबूत) के साथ सफलता की रिपोर्ट करते हैं, लेकिन उच्च token costs और जटिलता को स्वीकार करते हैं।
Flow state और मानवीय अनुभव
- आम शिकायत: chat-style prompting और प्रतीक्षा flow को तोड़ देती है; उपयोगकर्ता खुद को coding करने के बजाय एक junior dev की निगरानी करने वाले manager जैसा महसूस करते हैं।
- कुछ लोग flow वापस पाते हैं:
- गहरी planning/spec work करके, फिर agents को बिना निगरानी चलने देते हैं और बाद में समीक्षा करते हैं।
- pair-programmer-style tools का उपयोग करके जहाँ मानव दिशा देता है और AI छोटे-छोटे चरणों में सहायता करता है।
- कई parallel tasks/agents चलाकर और “orchestration” को ही flow गतिविधि मानकर।
- दूसरों को कई agents के बीच multitasking थकाऊ लगता है, flow-inducing नहीं।
व्यावहारिक workflows और harnesses
- बार-बार दिखने वाले पैटर्न:
- Issue/PR-केंद्रित workflows जहाँ LLMs tickets implement करते हैं, plans generate करते हैं, और comments के माध्यम से iterate करते हैं।
- Code generation से पहले तीन-स्तरीय दस्तावेज़ (philosophy → spec → design)।
- हर feature के लिए automated branches, PRs, और deployable test instances के साथ “workboxes” / sandboxes।
- Hermetic agents: confirmation bias से बचने के लिए एक ही spec से code और tests को अलग-अलग generate करना।
- Custom harnesses terminals, browser-based sandboxes, DAG/graph engines, और local VMs/containers तक फैले हैं, अक्सर strict permissions और tooling के साथ (जैसे bug-hunting loops, security sandboxes)।
Autocomplete, pairing, और editor integration
- editor-centric flows में गहरी रुचि: inline autocomplete, edit-completion, code region के लिए multiple anchored conversations, और ऐसे terminals जहाँ agents parallel panes में काम करते हैं।
- कुछ लोगों का मानना है कि autocomplete harness और UX, थोड़े बेहतर models को squeeze करने से अधिक महत्वपूर्ण है।
Learning, quality, और safety
- चिंता है कि पूरी तरह agentic coding समझ और सीखने को नुकसान पहुँचाती है, खासकर juniors के लिए; विकल्पों में LLM से detailed instructional docs बनवाना या tutor/reviewer के रूप में काम लेना शामिल है।
- कई लोग इस बात पर ज़ोर देते हैं कि LLMs का उपयोग human understanding सुधारने के लिए किया जाए (diagrams, summaries, explanations), क्योंकि अब human code comprehension bottleneck है।
- Security और guardrails बार-बार आने वाले विषय हैं: sandboxed agents, restricted tools, और iterations के बीच automated checks/tests।