AI से बनी ऐप पर developer के साथ कैसे काम करें

किसी AI से बनी ऐप पर developer के साथ अच्छी तरह काम करने के लिए, उन्हें एक Git repository में code दें, ऐप क्या करती है और क्यों, इसका एक पेज का सार दें, और एक साफ़ सीमित काम दें जिसकी “पूर्णता की परिभाषा” (definition of done) हो। तय करें कि कौन सा हिस्सा कौन बदलेगा, ताकि आप और AI उनका काम ओवरराइट न करें; repository और hosting accounts अपने नाम में रखें; और secrets को messages के बजाय सही settings के ज़रिए दें।

बहुत से लोग AI से ऐप का पहला संस्करण बनाते हैं और फिर developer को लाते हैं, ताकि payments जोड़े जा सकें, कोई ऐसी गलती ठीक हो जो AI बार-बार करता है, security की समीक्षा हो, या ऐप बढ़ने पर कोई code का मालिक बने। अगर आप अभी भी तय कर रहे हैं कि developer रखें या नहीं, तो developer रखें या AI से बनाएं देखें। यह गाइड मानता है कि आपने तय कर लिया है, और चाहता है कि सहयोग सहज रहे।

कब developer काम का होता है

किसी को लाने के आम कारण:

• एक ऐसी समस्या जिसे AI कई साफ़ प्रयासों और rollbacks के बाद भी नहीं सुलझा पाता।
• जोखिम भरे क्षेत्र: payments, अनुमतियां, संवेदनशील डेटा, database migrations।
• Launch से पहले या बड़े ग्राहकों को लेने से पहले security या code review।
• असली ट्रैफ़िक आने के बाद performance।
• Growth: ऐप एक कारोबार बन गई है और उसे ऐसे व्यक्ति की ज़रूरत है जो code का मालिक हो।

यह साफ़ रखना कि इनमें से कौन सा कारण है, नीचे की हर बात को आकार देता है।

चरण 1: code को साझा करने लायक जगह पर लाएं

Developers Git repositories से काम करते हैं। किसी से संपर्क करने से पहले:

1. प्रोजेक्ट को एक private GitHub (या मिलती-जुलती) repository से जोड़ें, या उसे export करें।
2. पक्का करें कि code या history में कोई secret नहीं है। देखें API keys कैसे सुरक्षित रखें।
3. जांचें कि प्रोजेक्ट एक ताज़ा कॉपी से चलता है — AI से setup के चरण लिखवाएं।

एक README लिखो एक developer के लिए जो इस प्रोजेक्ट से जुड़ रहा है: ऐप क्या करती है, stack क्या है, इसे लोकली कैसे install और चलाना है, किन environment variables की ज़रूरत है (सिर्फ़ नाम), folder structure, और जो भी नाज़ुक या असामान्य है।

अगर Git आपके लिए नया है, तो AI से बनी ऐप के साथ Git कैसे इस्तेमाल करें बुनियादी बातें बताता है।

चरण 2: एक पेज का brief लिखें

Developer ने आपकी chat history में नहीं बैठकर देखा। उन्हें एक पेज में संदर्भ दें:

• ऐप क्या करती है, किसके लिए, और कितने लोग उसे इस्तेमाल करते हैं।
• सबसे ज़रूरी क्या है — वे flows जो कभी नहीं टूटने चाहिए।
• ज्ञात समस्याएं और आपने पहले क्या आज़माया।
• काम, और आप कैसे जानेंगे कि वह पूरा हो गया।
• बाधाएं: बजट, समय-सीमा, और जो चीज़ें उन्हें नहीं बदलनी चाहिए।

अच्छी “पूर्णता की परिभाषा” परखी जा सकती है: “लॉग इन किया हुआ user Stripe Checkout से मासिक प्लान के लिए भुगतान कर सकता है, प्लान उसके account पेज पर दिखता है, और customer portal में cancel करने पर अवधि के अंत में उसका प्लान घट जाता है।” न कि “payments ठीक करो”।

चरण 3: सुरक्षित तरीके से access दें

• Code: Repository में उन्हें collaborator के रूप में जोड़ें। काम शुरू होने के बाद ZIP फ़ाइलें आगे-पीछे न भेजें।
• Builder: अगर आपका AI app builder team members सपोर्ट करता है, तो उन्हें सिर्फ़ इसी प्रोजेक्ट वाली workspace में आमंत्रित करें।
• Secrets: उन्हें अपने host की settings में जोड़ें, या password manager के ज़रिए साझा करें। Keys कभी email या chat में न चिपकाएं।
• Test accounts: test डेटा वाले test accounts बनाएं, अपना login साझा न करें।
• Production डेटा: सिर्फ़ तभी, जब उन्हें सच में ज़रूरत हो, और सिर्फ़ उतना जितना चाहिए।

Repository, domain और hosting accounts आपके नाम पर रखें। लोगों को जोड़ें; accounts न सौंपें।

चरण 4: तय करें कौन क्या बदलेगा

सबसे बड़ी अड़चन तब आती है जब दो पक्ष — आप AI के साथ, और developer — एक ही समय पर एक ही code बदलें। कोई नियम चुनें:

जो भी चुनें: हर prompt session से पहले नवीनतम code pull करें, और बड़े बदलाव ऐसी branches पर करें जिन्हें दूसरा व्यक्ति review कर सके।

चरण 5: लिखित में संवाद करें

• Problems को steps, अपेक्षित और असली नतीजों के साथ बताएं। देखें अच्छी bug report कैसे लिखें।
• फ़ैसले एक ही जगह रखें: एक issue tracker, एक साझा दस्तावेज़, या pull request comments।
• हर pull request में सादी भाषा में समझाने को कहें कि उन्होंने क्या बदला।
• तय करें कि आप कितनी बार चेक-इन करेंगे।

चरण 6: उनके काम की समीक्षा करें

समीक्षा करने के लिए आपको code पढ़ना ज़रूरी नहीं है। जांचें:

• क्या यह brief के अनुसार काम करता है, preview या staging copy पर।
• कुछ और टूटा तो नहीं — अपने महत्वपूर्ण flows चलाएं।
• उन्होंने समझाया कि क्या बदला और क्यों।
• Code में कोई secret नहीं आया।

और गहराई से देखने के लिए, AI-generated code की समीक्षा कैसे करें में एक checklist है जो इंसानों के लिखे code पर भी काम करती है। आप अपने AI builder से यह भी कह सकते हैं कि developer की pull request को सरल भाषा में समझाए।

चरण 7: मालिकाना हक साफ़ रखें

• Repository, hosting, domain और तीसरे पक्ष के accounts आपके नाम पर रहते हैं।
• वे जो code लिखते हैं उसके मालिकाना हक को काम शुरू होने से पहले लिखित में तय करें। कानूनी सवालों के लिए स्थानीय नियम या किसी सलाहकार से जांचें।
• काम खत्म होने पर उनकी पहुंच हटाएं, और जो keys उन्होंने देखी थीं उन्हें बदलें।

उदाहरण prompts

Developer ने पिछले pull में checkout code बदला है। सरल भाषा में समझाओ कि उन्होंने क्या बदला और क्या ऐप का कोई और हिस्सा उस पर निर्भर है।

इस ऐप के वे हिस्से सूचीबद्ध करो जो सबसे जटिल या जोखिम भरे हैं, ताकि मैं developer को बता सकूं कि review कहां केंद्रित करना है।

मैं payments developer को सौंप रहा हूँ। अब से src/payments या /api/billing routes की कोई फ़ाइल मत छुओ। अगर किसी बदलाव को उनकी ज़रूरत हो, तो मुझे बताओ।

आम गलतियाँ

• कोई brief नहीं। Developer भुगतान किए गए घंटे उल्टा इंजीनियर करने में खर्च करता है कि आप क्या चाहते थे।
• धुंधला दायरा, जैसे “bugs ठीक करो” या “production के लिए तैयार करो”।
• एक साथ दोनों का बदलना बिना pull किए, फिर conflicts से काम खोना।
• अपना login साझा करना या keys chat में चिपकाना।
• Accounts developer के नाम पर होना, जिससे बाद में अलग होना मुश्किल हो।
• पहुंच हटाना भूल जाना और काम खत्म होने के बाद keys न बदलना।

चेकलिस्ट

• Code एक private repository में है, मेरे नाम पर, और उसमें कोई secret नहीं।
• एक README setup समझाता है; एक पेज का brief ऐप और काम समझाता है।
• काम की एक परखने योग्य पूर्णता की परिभाषा है।
• Access collaborator invites से है, secrets settings या password manager से।
• तय है कि कौन क्या बदलेगा, और मैं prompt देने से पहले pull करता हूँ।
• काम brief और महत्वपूर्ण flows के खिलाफ़ review होता है।
• मालिकाना हक लिखित में है; काम खत्म होने पर पहुंच हटाई जाती है और keys बदली जाती हैं।

Mythex पर developer के साथ काम

• उन्हें workspace में आमंत्रित करें। Owners असीमित collaborators को प्रति-seat शुल्क के बिना आमंत्रित कर सकते हैं; सदस्य workspace के प्रोजेक्ट पर काम करते हैं। अलग workspace इस्तेमाल करें ताकि वे सिर्फ़ यही प्रोजेक्ट देखें। प्रकाशित ऐप्स के credits workspace owner पर बिल होते हैं। देखें Invites।
• GitHub sync और export (Pro). एक repository जोड़ें और push/pull करें, या प्रोजेक्ट को secrets छोड़कर export करें। देखें GitHub, export, and import।
• Preview link साझा करें, ताकि Mythex account न रखने वाले किसी व्यक्ति को अधूरा काम दिखा सकें; काम खत्म होने पर उसे हटा दें।
• Ask mode code के बारे में सवालों के जवाब देता है बिना उसे बदले — developer के बदलावों को समझने के लिए उपयोगी।

अगर developer ऐप को कहीं और चलाएगा, तो देखें AI से बनी ऐप को export करके खुद होस्ट कैसे करें।

सवाल