शाम के 4 बजे हैं और लंच के बाद से तीन कोडिंग एजेंट एक ही repository पर काम कर रहे हैं। एक ने कार्ट टोटल की राउंडिंग ठीक की, दूसरे ने डिस्काउंट कोड जोड़ा, तीसरे ने tests लिखे। तीनों कह रहे हैं "done"। main में कुछ भी जाने से पहले आप दो बातें जानना चाहते हैं: क्या दो एजेंट्स ने एक ही function दोबारा लिख दिया, और क्या तीनों बदलाव साथ मिलाने पर भी tests पास करते हैं?
एक codebase के लिए तीन स्क्रीन
osFoundry एक डेस्कटॉप ऐप है जो चैट, एजेंट्स, फ़ाइलें और टूल्स एक ही विंडो में रखता है, और कोड के लिए इसमें तीन जुड़ी हुई स्क्रीन हैं। Code वह जगह है जहाँ आप एक साथ कई एजेंट्स को काम सौंपते हैं: हर run को अपनी Git branch और अपना working folder (एक worktree) मिलता है, और कोई भी फ़ैसला लेने से पहले आप रिव्यू करते हैं, टेस्ट करते हैं और merge का preview देखते हैं। कुछ भी अपने-आप merge नहीं होता। IDE किसी लोकल फ़ोल्डर के लिए कोड एडिटर है, जिसमें explorer, source control, terminal, problems और tests पैनल हैं, और एक assistant कॉलम है जो देखता है कि आप कौन-सी फ़ाइल में हैं। Wiki आपकी मशीन पर मौजूद repository पढ़ता है और ऐसे documentation पेज लिखता है जो path:line का हवाला देते हैं, और जब उस हवाले वाला कोड बदलता है तो पेज को मार्क कर देता है। Code और Wiki, Maestro, Model chat, Multi chat और Research के बगल में टैब के रूप में हैं; IDE का साइडबार में अपना अलग आइटम है। अगर आप Git पैनल वाले VS Code से परिचित हैं, तो IDE जाना-पहचाना लगेगा। Code किसी pull-request inbox जैसा ज़्यादा है, फ़र्क़ बस इतना है कि लेखक आपके एजेंट्स हैं और branches कभी आपके लैपटॉप से बाहर नहीं गईं।
Code टैब पर एक नज़र
इस स्क्रीन पर आप क्या देखते हैं (runs उदाहरण डेटा हैं):
- रेल के ऊपर का बैनर। "3 agents finished · they disagree on 1 file" एक भी diff खोलने से पहले फ़ाइल का नाम बता देता है, यहाँ
src/cart.js। Review together बटन एक साझा रिव्यू शुरू करता है। - run रेल। runs इस हिसाब से ग्रुप किए गए हैं कि उन्हें आपसे क्या चाहिए: Ready to review, Needs attention, और एक मुड़ा हुआ History। हर लाइन में टास्क, जोड़ी और हटाई गई लाइनें, एजेंट ने कितनी देर काम किया, और उसकी branch दिखती है।
- बीच में बातचीत। किसी run पर क्लिक करें और पढ़ें कि एजेंट से क्या कहा गया था और काम करते समय उसने क्या कहा।
- दायाँ पैनल। Changes, Files, Commits, Review और PR टैब हर run का असली diff दिखाते हैं, पहले uncommitted काम, फिर वह जो उसकी branch पर commit हुआ।
- नीचे दाईं ओर Merge station। पूरे हो चुके runs चुनें, और यहीं आप उन्हें टेस्ट करते हैं और उन्हें एक साथ merge करने का preview देखते हैं।
उपयोग का उदाहरण: एक repo पर तीन एजेंट्स के साथ एक tech lead
Dana एक छोटी वेब टीम लीड करती हैं और checkout sprint को तीन एजेंट runs में बाँटती हैं: कार्ट टोटल में राउंडिंग ठीक करना, checkout में डिस्काउंट कोड जोड़ना, और price formatter के लिए tests लिखना। हर run New run से एक लाइन के टास्क और उसके लिए चुने गए एजेंट के साथ शुरू हुआ, इसलिए हर एक की अपनी branch और फ़ोल्डर है और काम करते समय कोई भी दूसरों की फ़ाइलों से नहीं टकरा सकता।
जब बैनर कहता है कि वे असहमत हैं, तो वह तीनों runs पर टिक करती हैं और Review together पर क्लिक करती हैं। Merge पैनल पर लिखा आता है "3 runs · conflicts not checked yet · 3 not yet tested", जो हरी झंडी के बजाय एक ईमानदार "अभी हमें नहीं पता" है। उसके नीचे src/cart.js को contested टैग किया गया है, और हर branch के hunks आमने-सामने दिखाए गए हैं: राउंडिंग फ़िक्स और डिस्काउंट कोड, दोनों ने total() को दोबारा लिखा था।
फिर वह हर run पर test दबाती हैं। tests उसी run के अपने worktree के अंदर चलते हैं, इसलिए उनका अपना checkout कभी छुआ नहीं जाता। डिफ़ॉल्ट रूप से "Tests must pass before a branch can merge", और यह नियम Settings में बदला जा सकता है। तीनों पास हो जाते हैं, लेकिन अलग-अलग पास होना साथ में पास होने जैसा नहीं है, इसलिए वह Preview combined merge दबाती हैं। ऐप पहले branches को एक अस्थायी कॉपी में merge करता है और नतीजा बताता है: दो साफ़ merge होती हैं, एक में conflict है।
वह दोनों साफ़ branches को अपनी current branch में merge करती हैं। सिर्फ़ उसी पल उनकी branch बदलती है। डिस्काउंट कोड वाली branch वैसी ही रहती है, ताकि एजेंट राउंडिंग फ़िक्स के ऊपर अपना बदलाव दोबारा कर सके। अगर वह पूरी branches के बजाय हर कोशिश का सबसे अच्छा हिस्सा चाहतीं, तो Combine into a branch से अलग-अलग hunks टिक करके उनसे नई branch बना सकती थीं।
लंबे दिनों में काम आने वाली एक और बात: अगर कोई run काम कर रहा हो और ऐप बंद हो जाए, तो वह run "running" के बजाय Interrupted के रूप में वापस आता है, इस नोट के साथ कि उसकी branch सुरक्षित रखी गई है।
उपयोग का उदाहरण: assistant के साथ refactor करता एक अकेला डेवलपर
Kenji अकेले एक शॉप का front end संभालते हैं। आज सुबह उन्हें formatPrice बदलना है, और उन्हें पक्का नहीं पता कि इसे कौन-कौन call करता है। वह साइडबार से प्रोजेक्ट फ़ोल्डर IDE में खोलते हैं। एडिटर का लेआउट वही जाना-पहचाना है: बाईं ओर Explorer और Source Control, बीच में टैब, नीचे Terminal, Output, Problems और Tests, और दाईं ओर Assistant, जहाँ वह synced चैट या डिवाइस पर ही रहने वाली local चैट शुरू कर सकते हैं।
वह formatPrice पर राइट-क्लिक करके Show Code Graph चुनते हैं। पैनल में Callers और Calls की लिस्ट आती है। भरा हुआ डॉट मतलब call सीधे कोड से पढ़ी गई; खाली डॉट मतलब उसका अनुमान लगाया गया, इसलिए उसे हाथ से एक बार देख लेना चाहिए। Impact of change callers के भी callers तक जाता है और इस उदाहरण में दिखाता है "15 symbols · 14 files · 3 tests"। किसी लाइन पर क्लिक करने से उसी जगह पहुँच जाते हैं, और Send to chat पूरा graph context के रूप में assistant को दे देता है।
बाद में assistant उनके लिए एक config फ़ाइल एडिट करता है। Source Control में फ़ाइल modified दिखती है, और खोलने पर एक छोटा रोबोट निशान और status line बताते हैं कि इसे आख़िरी बार AI ने लिखा था, मॉडल और उसके बताए कारण के साथ। Review उस write से ठीक पहले सेव की गई कॉपी के मुक़ाबले side-by-side diff खोलता है, इसलिए उन्हें सिर्फ़ वही बदलाव दिखता है। यहाँ दिखता है कि timeout 30 सेकंड से घटाकर 3 कर दिया गया, ठीक उस comment के नीचे जिसमें लिखा है कि बड़े uploads में 20 सेकंड या उससे ज़्यादा लगते हैं। वह commit से पहले ही इसे पकड़ लेते हैं।
अगर कोई एजेंट किसी ऐसी फ़ाइल में लिखता है जिसमें उनके बिना सेव किए बदलाव अभी बाकी हैं, तो एडिटर बताता है कि एडिट करते समय फ़ाइल डिस्क पर बदल गई, और चुपचाप किसी एक को चुनने के बजाय Keep mine या Use the disk version का विकल्प देता है।
उपयोग का उदाहरण: एक सपोर्ट इंजीनियर जिसे कोड बदलना नहीं, समझना है
Priya कस्टमर सपोर्ट में काम करती हैं और उनसे अक्सर पूछा जाता है कि प्रोडक्ट का कोई हिस्सा कैसे काम करता है। वह कोड पढ़ लेती हैं, लेकिन किसी और के repository में grep करते हुए भटकना नहीं चाहतीं। Wiki में वह Open a folder (या https या git@ URL के साथ Clone a public repository) इस्तेमाल करती हैं, और ऐप उनकी मशीन पर प्रोजेक्ट का स्ट्रक्चर पढ़ता है।
प्रोजेक्ट में कुछ भी लिखने से पहले Wiki पूछता है। एक dialog ठीक-ठीक बताता है कि repo के अंदर कौन-सा फ़ोल्डर बनाया जाएगा, और अगर वह Not now पर क्लिक करती हैं, तो कुछ नहीं लिखा जाता। हाँ कहने के बाद वह Generate pages या किसी एक विषय के लिए Write a page इस्तेमाल करती हैं। Settings तय करती हैं कि हर पेज कितने source code से लिखा जाए (Depth: Quick, Standard या Deep) और कितने दावों की जाँच हो (Verification: Off, Sample या Full, जिसमें Full से ख़र्च लगभग दोगुना हो जाता है)। पेज बनने से पहले ख़र्च दिखा दिया जाता है।
हर पेज path:line का हवाला देता है, और किसी हवाले पर क्लिक करने से वह लाइन IDE में खुल जाती है। एक महीने बाद रेल में एक पेज पर निशान लगा होता है, क्योंकि "a file this page cites has changed since it was written", यानी उस पर भरोसा करने से पहले उसे दोबारा बनाना चाहिए। किसी छोटे, एक बार के सवाल के लिए वह पेजों के बगल वाली चैट इस्तेमाल करती हैं, जिसके जवाब भी उसी प्रोजेक्ट से path:line का हवाला देते हैं, और जहाँ वह सीधे शब्दों में नया पेज भी माँग सकती हैं, जैसे "write a page about the retry policy"। पेज ख़ुद repository में markdown फ़ाइलें हैं, इसलिए टीम उन्हें कोड वाले pull requests में ही रिव्यू कर सकती है।
Code, IDE और Wiki काम एक-दूसरे को कहाँ सौंपते हैं
ये तीनों स्क्रीन एक-दूसरे को और ऐप के बाकी हिस्सों को काम आगे बढ़ाती हैं। Wiki का कोई हवाला IDE को उसी लाइन पर खोलता है, और उल्टी दिशा के लिए IDE में Wiki for this folder बटन है। IDE का Assistant और Wiki पेजों के बगल वाली चैट Maestro पर बने हैं, वही assistant जिसे आप osFoundry में बाकी जगह इस्तेमाल करते हैं, इसलिए वहाँ सवाल पूछना किसी भी Maestro चैट की तरह ही काम करता है। किसी codebase में सटीक शब्दों के बजाय मतलब से खोजने के लिए Indexes एक लोकल search index बनाता है जिसे Maestro इस्तेमाल कर सकता है। और जब कोई Code run आपके लैपटॉप से बाहर जाने के लिए तैयार हो, तो Open PR उसकी branch के लिए pull request खोल देता है।
प्रोडक्ट पेजों पर दोनों के interactive demo हैं: Code और IDE।
लोग सबसे पहले क्या पूछते हैं
क्या मुझे डेस्कटॉप ऐप चाहिए?
हाँ। Code, IDE और Wiki लोकल फ़ोल्डरों, Git worktrees, एक shell और language servers पर काम करते हैं, इसलिए ये osFoundry डेस्कटॉप ऐप में चलते हैं।
क्या कोई एजेंट कभी अपने-आप मेरी branch में merge कर देगा?
नहीं। runs अपनी-अपनी branches पर, अपने-अपने फ़ोल्डरों में काम करते हैं। आपकी current branch तभी बदलती है जब आप merge दबाते हैं, और डिफ़ॉल्ट रूप से सिर्फ़ उन्हीं branches के लिए जिनके tests पास हुए हों।
क्या Wiki, Notion जैसी टीम wiki है?
नहीं। यह code repository से documentation लिखता है, फ़ाइल और लाइन का हवाला देते हुए, और जब वह कोड बदलता है तो पेजों पर निशान लगाता है। यह codebase docs के लिए है, जैसे architecture overview या onboarding notes।
जिस branch में conflict हो, उसका क्या होता है?
वह जहाँ है वहीं रहती है। आप अभी साफ़ branches merge कर सकते हैं और एजेंट को conflict वाली branch उनके ऊपर दोबारा करने दे सकते हैं, या Combine into a branch से अलग-अलग hunks चुन सकते हैं।
डेस्कटॉप ऐप osfoundry.io/hi/download पर मुफ़्त में डाउनलोड किया जा सकता है।
