[Claude Code Meetup] लेगेसी कोडबेस में एजेंट और इंसानों, दोनों को बेहतर काम करने वाला बनाने के लिए वातावरण तैयार करना

(यह 17 दिसंबर को Seoul Claude Code Meetup में दी गई प्रस्तुति की सामग्री है। पूरी प्रस्तुति के लिए इस लिंक को देखें.)

---

Korca AX टीम का 'आंतरिक कंसल्टिंग' लक्ष्य

• Korca में अच्छी agentic engineering practices को स्थापित करना और ऐसा आधार बनाना, जिस पर मिलकर लगातार विकास किया जा सके।
  • Korca में 'agentic engineering practices' की परिभाषा है: 'AI एजेंटों का उपयोग करके software की quality और productivity, दोनों को बढ़ाने के लिए अपनाई जाने वाली practical methods'
• engineering capability को Korca की एक और core competitiveness बनाना।
• इसी के लिए Moonlight टीम की मदद करने का काम शुरू किया गया

Moonlight की स्थिति

• Korca का प्रमुख product Moonlight, खुद को 'AI साथी जो आपके साथ मिलकर research papers पढ़ता है' के रूप में प्रस्तुत करता है
• 'PDF से बातचीत' ChatGPT के शुरुआती दौर से मौजूद एक category रही है। ऐसे कई competing products के बीच टिके रहने के बाद, अब यह J-curve के शुरुआती चरण में है (हाल में चीन से users की तेज़ी से बढ़त)
• यहाँ तक पहुँचने में बहुत trial and error हुआ, लेकिन इसकी core strength रही feature development की speed और rhythm को 'किसी तरह' बनाए रखना
• speed के लिए कुछ शुरुआती decision
  • typescript strict: false
  • automation tests को न्यूनतम रखना
  • duplication और hardcoding की अनुमति
  • roles का कठोर विभाजन नहीं। लगभग सभी team members (7 में से 6) coding agents के साथ implementation करके PR उठाते हैं
• लेकिन trajectory पर आने के बाद technical debt की वजह से धीरे-धीरे मुश्किलें बढ़ने लगीं
  • product अधिक complex हुआ, team में नए members बढ़े, और साथ-साथ चलने वाले experiments भी बढ़ गए
  • product improvement की speed धीरे-धीरे कम होने लगी, और anxiety बढ़ने लगी
  • code review का बोझ कुछ लोगों पर केंद्रित होने लगा और छोटी-बड़ी गलतियाँ होने लगीं

AX टीम के सामने तत्काल चुनौतियाँ

• [उत्पाद] Moonlight product की quality बेहतर हो, और साथ ही features जोड़ने व सुधारने की speed भी बढ़े!
• [टीम] कोई भी Moonlight code को अधिक आसानी से बदल सके, और deploy के बाद का stress कम हो!
• [संस्कृति] 1 और 2 के लिए Moonlight टीम और AX टीम मिलकर अच्छी agentic engineering practices खोजें, लागू करें, बेहतर बनाएं, और धीरे-धीरे पूरे organization में फैलाएं!
  → हमें लगा कि अगर coding agents बेहतर responses देने लगें, तो अधिकांश समस्याएँ हल हो जाएँगी

एजेंट बेहतर responses कैसे दें?

[1] शुरुआत से ही उन्हें सही रास्ते पर ले जाएँ

• अगर codebase की quality ऊँची हो, तो 3 तरह से फायदा होता है
• अनावश्यक context कम देना पड़ता है (Less is More)
• एजेंट existing अच्छे patterns को follow करते हैं
• pretraining में मौजूद code में high-quality code वाले हिस्सों से sampled responses आने की संभावना की ओर bias किया जा सकता है
  • high-quality context देने से अच्छे responses आते हैं, इस पर बहुत research है।
  • (व्यक्तिगत अनुमान) अगर import order ठीक से sorted codebase में एजेंट को request भेजें, तो क्या pretraining data में import order sorted रखने वाला code कुल मिलाकर अधिक high-quality होने की संभावना नहीं रखता?
  • Anthropic blog से: "सिर्फ़ दिलचस्प fonts इस्तेमाल करने के लिए कहने से भी दूसरे design elements बेहतर हो जाते हैं"

[2] उन्हें गलत रास्ते पर जाने से रोकें

• type errors check करना, linter errors check करना, automation tests, dead code check, file length check, complexity check, dependency constraints लागू करना, test code बनाम production code ratio enforce करना—ऐसे कई static analysis tools गलत रास्तों को रोक सकते हैं (मानक पास होने तक एजेंट से दोबारा काम करवाना)

[3] उनसे वही काम माँगें, जिसमें वे अच्छे हों

• इंसान, LLM और algorithm—तीनों की ताकतें अलग हैं। किस समय किसका उपयोग करना है, यह समझदारी से चुनें, तो समय और लागत बचती है
  • ex) सिर्फ़ यह कहना कि i18n key मत भूलना बनाम छूटी हुई i18n key खोजने वाली script चलाने को कहना
• कौन, कब, किस काम में अच्छा है, यह समय के साथ और problem domain के अनुसार बदलता है। अपने domain में इस 'sense' को लगातार update करने की आदत फ़ायदेमंद है
  • ex) नया model आए तो अपना benchmark बनाकर test करना, या मशहूर social media examples को follow करना

[4] जो काम वे नहीं कर पाते, उसमें मदद करें

• लेकिन पहले हमेशा जाँचें कि क्या वे सच में नहीं कर पाते। अगर delegation बहुत risky, बहुत inefficient आदि न हो, तो आमतौर पर इंसानों से अधिक काम AI/algorithm से करवाना बेहतर है। (token cost तो अंततः बिजली के बिल जितनी सस्ती हो जाएगी)
• अगर सच में नहीं कर पाते? किसी दूसरे LLM से review करवाएँ
  • ex) सबसे सरल तरीके से, "यह किसी beginner developer ने लिखा है..."
• अगर AI से बेहतर काम करवाना है, तो AI के लिए बेहतर working environment देना होगा। दूसरे शब्दों में, जो चीज़ें (वर्तमान) एजेंट (यहाँ) ठीक से नहीं कर पाते, उन्हें इंसान, algorithm और दूसरे agents से reinforce करना होगा

जिन बातों का ख़ास ध्यान रखा गया

• Moonlight अभी उड़ान भरना शुरू किया हुआ rocket है, और AX टीम बाहर से आई हुई guest team
• यह मॉडल हर हाल में टालना था कि कोई outsider आकर कुछ बना दे और फिर वापस चला जाए
• quality improvement की कोशिश feature development की speed को (जितना संभव हो) बाधित न करे
• यह तय किया गया कि रोज़मर्रा के काम करने के तरीके को बहुत न बदलने वाले कार्यों और चुनौतीपूर्ण लेकिन प्रभावी कार्यों का संतुलित मिश्रण रखा जाए
  → हमने ऐसी तस्वीर की कल्पना की, जिसमें AX टीम और Moonlight टीम 'मिलकर' टीम और product के लिए उपयुक्त practices खोजें और लागू करें, और उसी प्रक्रिया में code quality, product quality और team capability सब साथ-साथ बेहतर हों

पिछले 4 हफ़्तों की प्रमुख उपलब्धियाँ

[1] अच्छी आदतें स्थापित हो रही हैं, और अच्छे patterns खोजे जा रहे हैं

• हर दिन PR review के बिना बहुत छोटे refactoring (tidying) commits उठाना
• अतीत के exemplary commits को follow करने वाले prompts (जैसे नए model support के लिए), और ऐसे patterns को खोजकर इकट्ठा करने वाले prompts
• senior developer की तरह सोचने वाला code review SKILL

[2] code quality metrics को मापना और visualize करना शुरू किया। code lines के मुकाबले errors/warnings की संख्या
तेज़ी से घट रही है

• code quality metrics कभी धीरे-धीरे, कभी नाटकीय रूप से कम हो रहे हैं
• रोज़ाना होने वाला tidying codebase को थोड़ा-थोड़ा सुधारता रहा, जिससे एक समय ऐसा लगा कि अब बड़े refactoring और बड़े कामों की भी हिम्मत की जा सकती है
• knip को एक-एक package पर लागू करते हुए पुराने और unused code को भी हटाया गया
• metrics हमेशा complementary होने चाहिए। 1000 lines के code में 1000 errors होने से कहीं बेहतर है कि 100,000 lines के code में 5000 errors हों। इसलिए सिर्फ़ absolute count नहीं, बल्कि lines के मुकाबले error ratio देखकर अधिक healthy management metric तय किया गया
  • comments और blank lines को छोड़कर meaningful line count tokei से मापा गया

[3] एक साल से अधिक समय से चल रही memory leak समस्या को ठीक किया

• repomix सहित कई tools और prompts का पूरा इस्तेमाल करके, कई प्रयासों के बाद एक साल से अधिक समय से बनी हुई memory leak समस्या को पकड़ा गया
• अब server instance tier घटाया जा सकेगा, यह सोचकर टीम खुश है

[4] हर हफ़्ते एक साथ चलने वाले कई experiments को और आसान व सुरक्षित तरीके से add/remove करने के लिए abstraction structure, prompts और scripts तैयार हुए

नतीजतन, code quality लगातार बेहतर हो रही है, feature development अधिक सुरक्षित और तेज़ हो रहा है, और टीम की (agentic) engineering capability भी लगातार बढ़ रही है—ये तीनों चीज़ें अच्छी तरह तालमेल में चल रही हैं

trial and error

• स्वाभाविक रूप से, सब कुछ शुरू से ठीक नहीं चला। शुरुआत में हम दो चीज़ें साथ करना चाहते थे
  • थोड़ी uncertainty के बावजूद high-value changes एक बार में लाना: strict option चालू करना, कड़े eslint rules लागू करना, dead code एक साथ हटाना आदि
  • भले value कम हो, लेकिन पूरी तरह सुरक्षित छोटे-छोटे कदम लेना: हर दिन tidying commit छोड़ना आदि
• लेकिन पहली दिशा डर की वजह से 'हो' नहीं पाई, और दूसरी दिशा बोरिंग होने की वजह से 'की' नहीं गई
• इसलिए इसे इस तरह बदला गया
  • challenging चीज़ों को अधिक सुरक्षित बनाना (एक-एक file पर tsc strict चालू करके ठीक करना और फिर बंद करना, minimum rules के साथ eslint लागू करना, एक package पर एक बार knip चलाना आदि)
  • safe चीज़ों को अधिक value देना (हाल की changes पर tidying suggestions देने वाला prompt बनाना आदि)
• अभी भी बहुत से काम बाकी हैं
  • typescript: strict चालू करना
  • zod अपनाकर server-client contract align करना
  • और कड़े eslint rules लागू करना
  • अधिक automation test coverage
  • और तरह-तरह के static analysis tools से गलत रास्तों को और मज़बूती से बंद करना
• लेकिन हम मिलकर, लगातार, और कभी भी धीमे पड़े बिना आगे बढ़ रहे हैं

One More Thing: मेरी learning + debugging आदत

ऐसी परिस्थितियों में AI से पूछना, experts से पूछना, और cross-validation करना बहुत कुछ सिखाता है। इस प्रक्रिया को GitHub PRs, issues और Slack में भी दर्ज करके organization के साथ साझा किया जा रहा है

• जो मैं नहीं जानता, वह कोई और जानता है
  • इस व्यक्ति ने यह knowledge/experience कैसे हासिल किया होगा? किस signal से उसने इस problem को पहचाना होगा?
• मेरी mistakes, bugs, और codebase के anti-patterns सामने आते हैं
  • इस problem के पैदा होने के पीछे कौन-कौन से कारण रहे होंगे? अगली बार कम गलती करने और गलती को पहले पकड़ने के लिए structure में क्या सुधार किया जा सकता है?

समापन

• अगर AI बेहतर responses दे सके, तो product team की बहुत-सी समस्याएँ हल हो सकती हैं
  • codebase quality बढ़ाकर (शुरुआत से सही रास्ता), और विभिन्न tools अपनाकर (गलत रास्ता रोकना)
  • team members की agentic engineering capability बढ़ाने में मदद करें (जो काम अच्छा होता है वह माँगें, जो नहीं होता उसमें मदद करें)
• AI के साथ समझदारी से सहयोग करके, अगर team capability बढ़े और अच्छा environment बने, तो 'quality improvement' और 'feature addition/improvement speed'—दोनों एक साथ पूरी तरह संभव हैं
• 'बाहर से' कुछ अच्छा लाकर मदद करने के बजाय, 'अंदर' मिलकर खोजें और आज़माएँ। measure करें, visualize करें, celebrate करें, और एक-दूसरे से सीखें

[kunggom]

मीटअप पर लेख भी आ गया है।

[रिपोर्ट] "कोरिया में Claude का नंबर 1 यूज़र पैदा हुआ"… Anthropic मीटअप इवेंट में जाकर देखा
https://n.news.naver.com/mnews/article/092/0002402940

> इस दिन दुनिया में Claude Code का सबसे ज़्यादा उपयोग करने वाले PsionicAI के इंजीनियर Park Jinhyung भी मौजूद थे और उन्होंने agent उपयोग के अपने नुस्खे साझा किए।
> इससे पहले Anthropic ने Park इंजीनियर को global heavy user में नंबर 1 बताया था। वह फिलहाल Claude Code समेत कई AI tools का इस्तेमाल अपने काम में कर रहे हैं। वह हर महीने AI subscription fee पर लगभग 18 लाख वॉन खर्च करते हैं.

एक महीने में करीब 18 लाख वॉन, द्द्द्द

[ds2ilz]

लगता है कि यह junior developers की सक्रिय भागीदारी और उनके विकास में मदद करने के एक तरीके के रूप में भी सार्थक हो सकता है।

[spilist2]

ओह, सही है haha, हम उस तरफ भी बहुत मेहनत कर रहे हैं।