Ask HN: क्या कोई कोडिंग के लिए LLMs के उपयोग के अलग-अलग तरीकों के साथ प्रयोग कर रहा है?

Hacker News चर्चा ↗

स्पेक-आधारित बनाम एजेंटिक/ऑर्केस्ट्रेटेड कोडिंग

  • कई लोगों का मानना है कि सबसे बड़ा लाभ जटिल ऑर्केस्ट्रेशन नहीं, बल्कि अधिक स्पष्ट स्पेक्स हैं: एकल इरादा, स्पष्ट 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।