- AI एजेंटों का उपयोग करके अकेले जनवरी में ही 6,600 से अधिक commits दर्ज करने वाले Peter Steinberger के workflow पर आधारित एक इंटरव्यू लेख
- Moltbot (पूर्व नाम Clawdbot) इस समय GitHub के इतिहास में सबसे तेज़ star growth दर्ज कर रहा है, और Google search volume में Claude Code और Codex को पीछे छोड़ चुका है
- Peter एक साथ 5~10 एजेंट चलाते हैं, और code review की जगह architecture discussion पर ध्यान केंद्रित करके development करते हैं
- AI के साथ प्रभावी सहयोग के लिए ऐसा loop design करना ज़रूरी है जिसमें एजेंट खुद compile, lint और test चलाकर सत्यापन कर सकें
- बारीक implementation से अधिक results और system design-केंद्रित सोच रखने वाले engineer, AI-native development के साथ बेहतर ढंग से अनुकूलित होते हैं
Peter Steinberger कौन हैं
- PSPDFKit को एक global developer tools business में विकसित करने वाले संस्थापक
- 3 साल के विश्राम के बाद लौटे हैं, और इस बार LLM और AI एजेंटों को अपने workflow के केंद्र में रखा है
- 70 से अधिक developers की टीम चलाने के अनुभव ने उन्हें perfectionism छोड़ना सिखाया, और यही क्षमता आज AI एजेंटों के साथ काम में उनकी efficiency बढ़ाती है
- जनवरी 2026 के एक ही महीने में 6,600 से अधिक commits दर्ज करके उन्होंने एक solo developer के रूप में असाधारण productivity दिखाई
- यह सारा काम किसी कंपनी में नहीं बल्कि व्यक्तिगत प्रोजेक्ट्स पर हुआ, और वे development का आनंद ले रहे हैं
Moltbot और विस्फोटक growth
- GitHub पर अब तक की सबसे तेज़ star growth rate दर्ज की, और Tailwind CSS से तुलना करने पर भी इसकी growth curve अभूतपूर्व स्तर की है
- पिछले सप्ताह Google search volume में Claude Code और Codex, दोनों को मिलाकर भी उससे अधिक खोज मात्रा दर्ज हुई
- Peter के शब्दों में: "अगर सिर्फ commits देखें तो यह किसी कंपनी जैसा लगेगा, लेकिन वास्तव में यह घर से मज़े के लिए coding करने वाला एक व्यक्ति है"
AI एजेंट-आधारित workflow से 10 प्रमुख सीख
- Perfectionism छोड़ें: अगर आप यह स्वीकार कर लें कि code हमेशा आपकी पसंद का नहीं होगा, तो एजेंटों के साथ काम करते समय आप अधिक कुशल हो सकते हैं
- Loop को बंद करें: ऐसा system design चाहिए जिसमें AI एजेंट खुद compile, lint, run और validate कर सकें
- Pull Request मर चुका है, "Prompt Request" उभर रहा है: code से ज़्यादा महत्वपूर्ण उस prompt को देखना है जिसने code बनाया
- Code review कम हो रहा है, architecture discussion उसकी जगह ले रही है: Discord पर भी core team code नहीं बल्कि architecture और बड़े निर्णयों पर ही चर्चा करती है
- एक साथ 5~10 एजेंट चलाना और "flow state" बनाए रखना
- हर एजेंट अलग-अलग features पर parallel में काम करता है
- Planning पर काफी समय लगाना, Codex को प्राथमिकता
- एजेंटों के साथ बार-बार बातचीत करके मज़बूत plan तैयार करना
- plan को चुनौती देना, संशोधित करना, उसका विरोध करना, और संतुष्ट होने पर उसे execute करके आगे बढ़ना
- Codex लंबे समय तक स्वतंत्र रूप से काम कर सकता है, जबकि Claude Code बार-बार स्पष्टीकरण के लिए लौट आता है, जिससे ध्यान भटकता है
- जानबूझकर कम विशिष्ट prompts का उपयोग करके कभी-कभी अप्रत्याशित solutions खोज लेना
- Local CI, remote CI से बेहतर है: remote CI के 10 मिनट के इंतज़ार की जगह एजेंट local में tests चलाते हैं
- अधिकांश code उबाऊ data transformation होता है: उस पर आसक्त होने की ज़रूरत नहीं, ऊर्जा system design पर लगानी चाहिए
- वे engineer जो implementation details से अधिक outcomes में रुचि रखते हैं, AI के साथ बेहतर सहयोग करते हैं
- algorithm puzzles सुलझाना पसंद करने वाले engineers को "AI-native" बदलाव में कठिनाई होती है
- product launch पसंद करने वाले लोग बेहतर ढंग से अनुकूलित होते हैं
software engineering के भविष्य पर दृष्टिकोण
- AI से software engineering मरी नहीं है, बल्कि ठीक उल्टा हुआ है
- Peter ऐसे software architect हैं जो प्रोजेक्ट की high-level structure को अपने दिमाग में बनाए रखते हैं
- वे architecture, technical debt, scalability और modularity पर गहराई से ध्यान देते हैं
- Moltbot की सफलता के कारणों में से एक इसकी बेहतरीन scalability है
- नई features जोड़ना आसान बनाने के लिए वे ऊर्जा निवेश करते हैं
- प्रोजेक्ट के "benevolent dictator" के रूप में दिशा और शैली की निरंतरता बनाए रखते हैं
संदर्भ और सीमाएँ
- Moltbot एक प्रयोगात्मक प्रोजेक्ट है जो तेज़ iteration को आधार मानकर बनाया गया है, और अभी भी work in progress है
- "तेज़ी से आगे बढ़ो और चीज़ें तोड़ो" ऐसे प्रोजेक्ट्स की सफलता का शायद एकमात्र तरीका है
- इसे हर टीम या हर product पर समान रूप से लागू करना कठिन है
- फिर भी, इसे ऐसा उदाहरण माना जा रहा है जिसने बड़ी AI labs तक की अपेक्षा से बाहर की demand खोज निकाली
26 टिप्पणियां
समझ नहीं आता कि लोग बार-बार prediction machine को सोचने वाली machine क्यों समझ लेते हैं
कैलकुलेटर deterministic algorithm के आधार पर काम करता है, इसलिए मुझे लगता है कि यह उपमा उपयुक्त नहीं है.
और मैं AI के इस्तेमाल के खिलाफ नहीं हूँ, बल्कि मुझे लगता है कि इस लेख में बताए गए AI के इस्तेमाल के तरीके में समस्या है.
क्योंकि इसे उस संरचना के अनुसार बनाया गया है जैसा हम सोचते हैं।
मूल बात यह है कि इसमें न्यूरॉन्स के आपस में जुड़ने के तरीके को ही अपनाया गया है, और यह साफ़ तौर पर देख पाना संभव नहीं है कि यह किस प्रक्रिया से सोचता है।
"विचार" भी मस्तिष्क में किस प्रक्रिया से निकलते हैं, यह हमें नहीं पता, इसलिए इसकी बुनियादी बनावट और दिखाई देने वाली घटनाएँ एक जैसी हैं।
इसीलिए इसे इस तरह देखा जाता है कि मानव मस्तिष्क भी एक prediction machine की तरह है।
हम जिस चीज़ को "सोचना" कहते हैं, उसे एक यांत्रिक घटना मानकर brain hacking को भी संभव समझने वाला एक क्षेत्र भी है।
दोनों ही ब्लैक बॉक्स हैं, और बुनियादी संरचना भी एक जैसी है, लेकिन इसका मतलब यह नहीं कि उन्हें निश्चित रूप से समान कहा जाए।
यह पूरी तरह एक जैसी चीज़ नहीं है, और साथ ही पूरी तरह अलग भी नहीं है.
किसी चीज़ के मिलते-जुलते होने का मतलब है कि उसमें कुछ समान हिस्से हैं,
इसलिए आखिरकार लोगों के बीच मतभेद होना शायद इस बात पर निर्भर करता है कि वे उसे कितना समान मानते हैं.
इसे बिल्कुल समान नहीं कहा जा सकता, लेकिन मैं इसे मिलती-जुलती चीज़ मानता हूँ,
और geek12356 की टिप्पणी में prediction और thought पर जो दृष्टिकोण है, उस नज़रिए से मुझे भी ऐसा ही लगता है.
साथ ही, मेरा यह दृष्टिकोण भी है कि बुद्धिमत्ता मनुष्यों से अधिक होने के कारण यह मनुष्यों से अलग भी है.
जब दूसरे लोग Excel functions से 1 सेकंड में सैकड़ों लाइनों की गणना कर लेते हैं, तब हम अकेले calculator से एक-एक करके हिसाब लगाते हुए "function मत इस्तेमाल कीजिए" कहने वाले senior न बनें।
मुझे लगता है कि Excel functions और calculator वाली तुलना ठीक नहीं है
अगर LLM की accuracy 100% हो, तो मान लूंगा..
समझ नहीं आता कि कैलकुलेटर इस्तेमाल न करने का विरोध करते हुए फिर अबेकस क्यों चलाते हैं।
फ़िलहाल, अगर कोई प्रोडक्ट इस तरह डेवलप किया गया हो, तो मैं उसे इस्तेमाल नहीं करना चाहूँगा।
अगर इस तरह से विकसित किए गए वाहन या flight software हों, तो मैं तो उन्हें बिल्कुल इस्तेमाल नहीं करूंगा।
इसीलिए जापान में लोग अभी भी ज़्यादातर fax इस्तेमाल करते हैं।
ऊपर से भले ही यह शानदार दिखे, लेकिन बाद में अगर समस्याएँ आएँ, उन्हें ठीक करना पड़े या कोई vulnerability निकल आए, तो उसकी लागत बहुत ज़्यादा हो सकती है..
लगता है कि कई vulnerabilities पहले ही रिपोर्ट की जा चुकी हैं।
आखिरकार इंसान फिर से अहम हो जाता है
इसे सकारात्मक रूप से देखना चाहिए या नकारात्मक रूप से, समझ नहीं आ रहा..
शायद आप इसे पहले से ही जानते-बूझते या अनजाने में इस्तेमाल कर रहे होंगे।
अगर इस तरह उगल दिया गया कोड कोई समस्या पैदा करे, तो आखिर उसकी सफाई कौन करेगा... अगर इसी तरह कोड बनता रहा.. तो एक दिन वह ऐसा नर्क ज़रूर आएगा।
Pull Request की जगह "Prompt Request" — यह वाकई चौंकाने वाला है.
बहुत पहले मुझे MDA में काफी दिलचस्पी थी, लेकिन अव्यावहारिक लगने के कारण मैंने छोड़ दिया था; अब यह इस तरह साकार होता दिख रहा है.
अगर यह GitHub जैसी जगहों पर एक feature के तौर पर उपलब्ध हो, तो अच्छा लगेगा।
"तेज़ी से आगे बढ़ो और चीज़ें तोड़ो"
यह बात काफ़ी relatable लगती है
AI से लिखे गए कोड को पढ़ने की कोशिश करना मेरी ही बड़ी गलती थी.
लगता है कि MoltBot इतने ज़्यादा self-repair PR उठा-उठाकर भेज रहे हैं कि उन सबको खुद बैठकर review करना मुश्किल होगा lol, issue और PR की संख्या भी लगभग बराबर है, क्योंकि issue लिखकर इंतज़ार करने के बजाय बस MoltBot से PR बनवाकर push करवा दो तो काम ख़त्म lol
यह बस इतना है कि AI के कुत्ते और बिल्ली में फर्क कर पाने वाली स्थिति अब हमारे थोड़ा और करीब आ गई है.. इससे ज़्यादा इसकी कोई वैल्यू है या नहीं, मुझे नहीं पता।
लगता है कि आप Codex को पसंद करते हैं, इसकी सेटिंग्स जानने की उत्सुकता है।
Codex के साथ 140 दिनों में, मैंने 115 प्रोजेक्ट किए, और लगता है कि 250 अरब से ज़्यादा tokens इस्तेमाल किए - link
लगभग 75 मिलियन वॉन जैसा है। एक single-person AI-native developer को पहले exit करना होगा और उसके पास थोड़ा ज़्यादा पैसा भी होना चाहिए..
2500 अरब टोकन... इसकी तो मुझे कोई कल्पना ही नहीं है...