एक बुद्धिमान डेवलपर एक विशाल पुल अनुरोध खोलकर एक नया प्रोजेक्ट शुरू नहीं करता है। वे विचार-मंथन, टीम-साथी चर्चा, प्रोटोटाइपिंग, आरेख, प्रस्ताव, एडीआर, एमआर/पीआर और गिटऑप्स के माध्यम से आगे बढ़ते हैं - हर बदलाव पर एक समीक्षा बॉट के साथ - और, जब पैमाने की मांग होती है, तो वर्कस्टेशन की मल्टी-एजेंट वास्तुकला एक महान विकास टीम को इकट्ठा करती है जो तेजी से उत्पादन-ग्रेड काम करती है।
1. किसी नए प्रोजेक्ट पर "बुद्धिमान" का क्या अर्थ है
बुद्धिमत्ता जल्दी सीख लेना और देर से महंगी गलतियाँ करना है। नीचे दिए गए क्रम को इस प्रकार क्रमबद्ध किया गया है कि प्रत्येक चरण अगले चरण की विस्फोट त्रिज्या को छोटा कर देता है:
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. विचार-मंथन
दूसरे लोगों का समय बर्बाद करने से पहले, 30-90 मिनट अकेले बिताएं:
- नतीजा - जब हमारा काम पूरा हो जाएगा तो व्यवसाय के लिए क्या सत्य होना चाहिए?
- प्रतिबंध - समय, अनुपालन, मंच, कौशल, बजट।
- गैर-लक्ष्य — क्या v1 स्पष्ट रूप से शामिल नहीं होगा।
- जोखिम - डेटा, सुरक्षा, प्रदर्शन, लॉक-इन, ऑप्स लोड।
- सफलता के मेट्रिक्स - दो चुनें (जैसे विलंबता + अपनाना, या लागत + त्रुटि दर)।
इसे नीचे लिखें docs/ideas/. अलिखित विचार-मंथन लुप्त हो जाता है।
3. सहकर्मियों के साथ चर्चा
सबसे छोटे उपयोगी समूह को आमंत्रित करें: एक सहकर्मी कार्यान्वयनकर्ता, एक आसन्न प्रणाली का मालिक, और सुरक्षा/एसआरई जब जोखिम की आवश्यकता हो।
- टाइम-बॉक्स (25-45 मिनट)। निर्णयों या खुले प्रश्नों के साथ समाप्त करें।
- बल विकल्प: ए बनाम बी बनाम स्थगित - अस्पष्ट सहमति नहीं।
- एक मुंशी नियुक्त करें; नोट प्रस्ताव का बीजारोपण करता है।
- असुविधा को एडीआर के लिए जोखिम के रूप में देखें - कोई मूक वीटो नहीं।
यदि कोई लूप बंद कर देता है तो Async RFC ठीक हैं।
4. प्रोटोटाइपिंग
अनिश्चितता अधिक होने पर स्पाइक। बुद्धिमान नियम:
- इसे स्पाइक लेबल करें; एक कैलेंडर स्टॉप सेट करें (सामान्य रूप से 1-3 दिन)।
- इसे फेंकी हुई शाखा पर रखें या
spikes/- पॉलिश न करें. - आपने जो सीखा (विशेषकर असफलताएँ) उस पर दस गोलियाँ लिखें।
- निर्णय लें: प्रचार करें, पुनः लिखें, या छोड़ दें - कभी भी "चुपचाप उत्पाद न बनें।"
5. रेखाचित्र
तीन रेखाचित्र आमतौर पर पर्याप्त होते हैं:
| आरेख | जवाब |
|---|---|
| प्रसंग (C4 L1) | कौन किससे बात करता है? सीमाओं पर भरोसा करें? |
| अनुक्रम | शुभ पथ + एक असफलता पथ |
| तैनाती | यह कहाँ चलता है; कॉन्फिग और रहस्य प्रवाहित होते हैं |
प्रस्ताव के आगे मरमेड या एसवीजी स्टोर करें। एडीआर बदलने पर अपडेट करें।
6. प्रस्ताव
आरएफसी को छोटा रखें (1-3 पेज): समस्या, विकल्प (कम से कम दो), सिफारिश, प्रभाव (सुरक्षा/लागत/ऑप्स), रोलआउट और रोलबैक, खुले प्रश्न। स्वीकृत होने पर, निर्णय को एडीआर में बदल दें।
7. एडीआर - वास्तुकला निर्णय रिकॉर्ड
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
एडीआर को गिट में रखें (docs/adr/). उन्हें पीआर से लिंक करें. इतिहास को दोबारा लिखने के बजाय उसका स्थान ले लें।
8. एमआर और पीआर - वितरण की इकाई
श्री (मर्ज अनुरोध) और जनसंपर्क (पुल अनुरोध) एक ही विचार है: एक समीक्षा योग्य परिवर्तन सेट।
- छोटी (अर्थपूर्ण अंतर की <400 पंक्तियों को प्राथमिकता दें); प्रति परिवर्तन एक इरादा.
- विवरण: क्यों, कैसे परीक्षण करें, जोखिम, रोलबैक।
- लिंक: टिकट + एडीआर + आरेख।
- प्रतिक्रिया के लिए जल्दी ड्राफ्ट करें; बिना किसी लिखित अपवाद के कभी भी लाल सीआई या उच्च-गंभीरता वाले बॉट निष्कर्षों के आसपास बलपूर्वक विलय न करें।
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. समीक्षा बॉट - ऑटो टिप्पणियाँ जो उत्पादन की रक्षा करती हैं
एक समीक्षा बॉट एक स्वचालित प्रथम समीक्षक है। यह मनुष्यों का स्थान नहीं लेता; यह उबाऊ और खतरनाक को सामने रखता है इसलिए डेवलपर्स डिज़ाइन और उत्पाद जोखिम पर समय बिताते हैं।
9.1 इसे किस पर टिप्पणी करनी चाहिए
- सुरक्षा: इंजेक्शन, ऑथज़ अंतराल, गुप्त रिसाव, असुरक्षित डिफ़ॉल्ट
- शुद्धता: शून्य रास्ते, दौड़, टूटे हुए प्रवास
- परीक्षण: नई शाखाओं पर लापता कवरेज
- एपीआई/अनुबंध: संस्करण बाधाओं के बिना परिवर्तन तोड़ना
- ऑप्स: लापता टाइमआउट, असीमित पुनर्प्रयास, गैर-इमपोटेंट लेखन
9.2 यह डेवलपर जीवन को कैसे सुव्यवस्थित करता है
- लेखक मिनटों में पीआर → बॉट टिप्पणियाँ खोलता है।
- लेखक इंसानों से पूछने से पहले ठीक करता है या उत्तर देता है।
- मानव बॉट सारांश पढ़ता है + वास्तुकला और विस्फोट त्रिज्या पर ध्यान केंद्रित करता है।
- कम नाइट राउंड; उत्पादन में कम फ़ुटगन बचीं।
9.3 नीति जो बॉट को उपयोगी बनाए रखती है
- गंभीरता: ब्लॉकर / शुड-फिक्स / एनआईटी - एनआईटी को मर्ज को ब्लॉक नहीं करना चाहिए।
- उत्पन्न पथों पर ध्यान न दें; झूठी सकारात्मकता को मासिक रूप से ट्यून करें।
- पर मानवीय अनुमोदन की आवश्यकता है
auth/,infra/, आईएएम, और धन पथ। - उत्पादन-महत्वपूर्ण सेवाओं पर बॉट को कभी भी एकमात्र समीक्षक न बनने दें।
वायर सास बॉट (जैसे कोडरैबिट), कर्सर बगबॉट, या पीआर अंतर पर एक कस्टम एक्शन + एलएलएम। सबसे मजबूत आसन के लिए लेयर लिंट → SAST → LLM।
10. उत्पादन-ग्रेड गुणवत्ता के लिए GitOps सर्वोत्तम अभ्यास
वांछित स्थिति गिट में रहती है। एक रिकन्सिलर (अर्गो सीडी, फ्लक्स, आदि) क्लस्टर को मैच कराता है। पदोन्नति एक मर्ज है; रोलबैक एक वापसी है।
- ऐप कोड और env कॉन्फिगरेशन को अलग करें (या साफ़ करें)।
envs/dev|staging|prodओवरले)। - कोई तदर्थ नहीं
kubectl applyखुशहाल रास्ते के रूप में आगे बढ़ाने के लिए - केवल कांच तोड़ें, ऑडिट किया गया। - प्रगतिशील वितरण: ऑटो-सिंक लोअर एनवीएस; उत्पाद के लिए गेटेड सिंक।
- छवि उत्पाद में परिवर्तनीय टैग पर पचती है।
- विशेषाधिकार और रजिस्ट्रियों के लिए कोड (OPA/Kyverno) के रूप में नीति।
- सिंक के बाद निरीक्षण करें; वापसी का अभ्यास करें.
कोड गुणवत्ता न केवल स्वच्छ कार्य है - बल्कि यह भी है परिवर्तन उत्पादन में कैसे प्रवेश करता है.
11. वर्कस्टेशन मल्टी-एजेंट आर्किटेक्चर - महान विकास टीमों का निर्माण
एक अकेले बुद्धिमान डेवलपर को अभी भी उत्तोलन की आवश्यकता है। वर्कस्टेशन का मल्टी-एजेंट आर्किटेक्चर (एजेंट एआई वर्कस्टेशन पैकेज, और बिजनेस के लिए ओपनक्लॉ जहां आपको सन्निहित या विशेष एजेंट क्रू की आवश्यकता होती है) आपको अनुमति देता है एक विकास टीम का स्वतः निर्माण करें एक व्यावसायिक संक्षिप्त विवरण के इर्द-गिर्द - कोई स्थिर संगठन चार्ट नहीं।
11.1 रचना पाश
- संक्षिप्त - हितधारक परिणाम, बाधाएं, एसएलए।
- लिखें - कौशल (योजनाकार, निर्माता, समीक्षक, संचालन, अनुपालन) के लिए भूमिकाएँ मैप करें।
- बूटस्ट्रैप - एजेंट रनटाइम + एमसीपी टूल्स + मेमोरी + ऑडिट ट्रेल।
- निष्पादित करना - एजेंट काम करते हैं, स्पेक/एसी के विरुद्ध कार्यान्वयन करते हैं, प्रत्येक चरण की लघु समीक्षा करते हैं।
- समीक्षा-जब तक-साफ न हो जाए - समीक्षा बॉट + समीक्षक एजेंट + मानव द्वार।
- जहाज - GitOps उस वातावरण को बढ़ावा देता है जो मायने रखता है।
11.2 भूमिका मानचित्र (मानव + एजेंट)
| भूमिका | एजेंट करता है | मानव अभी भी मालिक है |
|---|---|---|
| योजनाकार | महाकाव्य, कहानियाँ, स्पेक से ए.सी | प्राथमिकता और कार्यक्षेत्र में कटौती |
| बिल्डर्स | समानांतर कार्यान्वयन, परीक्षण | कठोर किनारों पर डोमेन निर्णय |
| समीक्षक | विशिष्ट अनुपालन, समीक्षा बॉट ट्राइएज | वास्तुकला और उत्पाद साइन-ऑफ़ |
| ऑप्स | GitOps सिंक, SLO वॉच, ड्राफ्ट रोलबैक | गो-लाइव और घटना आदेश |
| एचआईटीएल गेट | जोखिम भरा लेखन/खर्च बढ़ाएँ | स्वीकार करें या अस्वीकार करें |
11.3 इससे महान टीमें क्यों बनती हैं?
- विशेषज्ञता - प्रत्येक एजेंट का एक काम होता है; जब भूमिकाएँ धुंधली नहीं होतीं तो गुणवत्ता बढ़ती है।
- अराजकता के बिना थ्रूपुट - एकल स्पेक और रिव्यू बॉट के पीछे समानांतर बिल्डर्स।
- निर्णयों की स्मृति साझा की - एडीआर + स्पेक + पीआर इतिहास टीम की दीर्घकालिक स्मृति बन जाता है।
- मनुष्यों के समान द्वार - सीआई, रिव्यू बॉट, कोडओनर्स, गिटऑप्स - एजेंट उत्पादन अनुशासन को नजरअंदाज नहीं करते हैं।
- व्यापार की गति - प्रत्येक स्पाइक के लिए किराए पर लेने के लिए हफ्तों के बजाय एक सक्षम दल खड़ा करने के लिए घंटे।
11.4 यह किस प्रकार बुद्धिमान पथ पर जुड़ता है
मनुष्य के साथ विचार-मंथन और चर्चा अब भी होती रहती है। प्रोटोटाइप और आरेख अभी भी होते हैं। मल्टी-एजेंट दल तेजी लाता है प्रस्ताव प्रारूपण, एडीआर मचान, कार्यान्वयन स्लाइस, समीक्षा बॉट ट्राइएज, और गिटऑप्स प्रचार - जबकि मनुष्य परिणामों और जोखिम पर निर्णय लेते हैं। वह वर्कस्टेशन मॉडल है: एजेंटिक वर्कस्टेशन और ओपनक्लाव पैकेज आपके वर्कफ़्लो के लिए कॉन्फ़िगर किए गए हैं, न कि एक टीम होने का दिखावा करने वाली चैट विंडो।
12. शुरू से अंत तक गुणवत्ता वाले गेट
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. स्टार्टर चेकलिस्ट
- बनाएं
docs/ideas/,docs/architecture/,docs/adr/ - पीआर/एमआर टेम्प्लेट + कोडओनर्स + शाखा सुरक्षा जोड़ें
- प्री-कमिट + सीआई आवश्यक जांच सक्षम करें
- समीक्षा बॉट स्थापित करें; पथ फ़िल्टर और गंभीरता को ट्यून करें
- ADR-0001 लिखें: "हम तैनाती के लिए GitOps का उपयोग करते हैं"
- एनवी प्रमोशन नियमों और रोलबैक गेम दिवस को परिभाषित करें
- यदि डिलीवरी स्केलिंग है: एचआईटीएल गेट्स के साथ वर्कस्टेशन मल्टी-एजेंट क्रू (प्लानर/बिल्डर/समीक्षक/ऑप्स) को खड़ा करें
14. विरोधी प्रतिमान
- विशाल "डब्ल्यूआईपी कृपया स्वीकृत करें" पीआर
- आर्किटेक्चर केवल स्लैक में - एडीआर में कभी नहीं
- प्रोटोटाइप को बिना किसी परीक्षण के उत्पाद के रूप में विलय कर दिया गया
- समीक्षा बॉट को अक्षम करना क्योंकि यह परेशान करता है
- ऐसे एजेंट जिनके पास लिखने की पहुंच है और कोई मानव द्वार नहीं है
- बिना किसी रिवर्ट योजना के GitOps के बाहर उत्पादन के लिए हॉटफ़िक्स
15. समापन
एक बुद्धिमान डेवलपर एक नई परियोजना को सीखने की कलाकृतियों के अनुक्रम के रूप में मानता है - नोट्स, आरेख, प्रस्ताव, एडीआर - फिर एक समीक्षा बॉट द्वारा देखे गए और GitOps द्वारा प्रचारित छोटे एमआर/पीआर के माध्यम से वितरित करता है। वर्कस्टेशन का मल्टी-एजेंट आर्किटेक्चर उस ज्ञान को एक पूर्ण विकास टीम में विस्तारित करता है: विशेष एजेंट, साझा विशिष्टता, मानव निर्णय जहां यह मायने रखता है, और जीवन के हर रास्ते पर उत्पादन-ग्रेड द्वार। इस प्रकार कोड गुणवत्ता उत्पादन के लिए अनुकूलित रहती है जबकि व्यवसाय अभी भी तेजी से आगे बढ़ता है।
द्वारा प्रकाशित कार्य केंद्र.
