Foreman लार्ज-लँग्वेज-मॉडेल (LLM) एजंट्सना नेटिव्ह Kubernetes रिसोर्सेसमध्ये रूपांतरित करते, ज्यामुळे टीम्सना खर्च आणि सुरक्षितता काटेकोरपणे नियंत्रणात ठेवून प्रॉडक्शनमध्ये AI-जनरेटेड कोड चालवणे शक्य होते.
ही कल्पना आजच्या डेव्हलपमेंट वर्कफ्लोमध्ये कशी बसते
एंटरप्राइजेस कोड लिहू शकणाऱ्या LLMs सोबत प्रयोग करत आहेत, परंतु बहुतेक अंमलबजावणीमध्ये मॉडेलला एका विश्वासार्ह 'ब्लॅक बॉक्स'प्रमाणे मानले जाते. मॉडेलकडून मिळणारा एक साधा “done” सिग्नल न तपासलेले बदल थेट रिपॉझिटरीमध्ये ढकलू शकतो, ज्यामुळे सुरक्षा आणि विश्वासार्हतेच्या समस्या निर्माण होऊ शकतात. त्याच वेळी, क्लाउडवर AI सेवा चालवणे वेगाने महाग होऊ शकते, विशेषतः जेव्हा CI पाइपलाइनमधून वारंवार एकाच मॉडेलला कॉल केला जातो.
Foreman चे उत्तर संपूर्ण कोडिंग लूप एका Kubernetes क्लस्टरमध्ये एम्बेड करणे हे आहे. Foreman हे Kubernetes रिसोर्सेस म्हणून चालते.
हे प्रत्यक्षात आणणारे चार मुख्य ऑब्जेक्ट्स
- Agent – एका वर्करची व्याख्या करतो. तो कॉल करायचे LLM नाव ठरवतो, मॉडेल वापरू शकणाऱ्या टूल्सची (उदा. file-write किंवा git-push) यादी देतो आणि मॉडेल कॉल्सवर मर्यादा आणण्यासाठी बजेट सेट करतो. येथे भूमिका (roles) जोडल्या जातात; एक coder agent कोड लिहितो, तर verifier agent तो तपासतो.
- Workload – वापरकर्त्याने तयार केलेली कामाची एक युनिट. यामध्ये उच्च-स्तरीय हेतू (उदा. “module X साठी युनिट टेस्ट्स जोडा”), लक्ष्यित रिपॉझिटरीचा संदर्भ आणि काम हाताळण्यासाठी लागणाऱ्या एजंट्सची यादी असते.
- AgenticTask – Workload द्वारे तयार केलेले प्रत्यक्ष कार्य. जसे काम पुढे जाते, प्रत्येक AgenticTask स्टेटस अपडेट्स रेकॉर्ड करते, ज्यामुळे ऑपरेटर्स रिअल-टाइममध्ये पाइपलाइनवर लक्ष ठेवू शकतात.
- FleetNode – एक Kubernetes नोड जो प्रत्यक्षात टास्क चालवतो. इन-बिल्ट शेड्युलर प्रलंबित (pending) AgenticTasks ला आवश्यक भूमिका आणि रिसोर्सेस असलेल्या FleetNodes सोबत मॅच करते.
व्हेरिफिकेशन (Verification) अंधश्रद्धेची जागा घेते
Foreman मॉडेलचे आउटपुट बरोबर आहे असे गृहीत धरत नाही. जेव्हा एखादा coder agent आपले काम पूर्ण करतो, तेव्हा तो अंतिम निकालाऐवजी एक विनंती (request) पाठवतो. एक verifier—जो सहसा दुसरा LLM नसून एक डिटरमिनिस्टिक स्क्रिप्ट असतो—कोड लिनटर्स (linters), युनिट टेस्ट्स किंवा पूर्ण बिल्ड्सद्वारे चालवतो. केवळ हे चेक पास झाले तरच Foreman नवीन ब्रांच रिपॉझिटरीमध्ये परत लिहितो.
जर verifier फेल झाला, तर टास्क 'rejected' म्हणून मार्क केला जातो आणि बदल कधीही लागू होत नाहीत. हे विलगीकरण मॉडेलला सर्जनशीलपणे जनरेट करू देते, तर सुरक्षिततेचे जाळे पूर्णपणे मानवी नियंत्रणाखाली राहते.
क्लस्टरवर स्टॅक इन्स्टॉल करणे
- Helm द्वारे LLMKube कोर चार्ट डिप्लॉय करा.
- Foreman चार्ट देखील Helm द्वारे डिप्लॉय करा.
- एजंट मोड “native” वर स्विच करा जेणेकरून रिअल रिक्वेस्ट-रिस्पॉन्स लूप सक्रिय होईल.
- काम होस्ट करतील अशा FleetNodes ला भूमिका (coder, verifier) नियुक्त करा.
दोन क्रेडेंशियल सेट आवश्यक आहेत: इश्यू वाचण्यासाठी आणि ब्रँचेस पुश करण्यासाठी git क्रेडेंशियल्स, आणि होस्टेड API किंवा सेल्फ-होस्टेड इन्फरन्स सर्व्हिस कॉल करण्यासाठी मॉडेल क्रेडेंशियल्स.
खर्च आणि सुरक्षिततेचे नियंत्रक (knobs) जे तुम्ही प्रत्यक्षात वापरू शकता
Foreman ऑपरेटर्सना एजंटच्या व्याख्येतून टूल्स काढून टाकून मॉडेलचा अधिकार मर्यादित करण्याची परवानगी देते. “bash” किंवा “write_file” काढून टाकल्यास मॉडेलला कोणतेही शेल कमांड्स चालवण्यापासून किंवा नियुक्त केलेल्या वर्कस्पेसच्या बाहेर लिहिण्यापासून रोखता येते.
'Turn limit' प्रत्येक टास्कमधील मॉडेल इन्व्होकेशनच्या संख्येवर मर्यादा आणते, ज्यामुळे खर्च थेट नियंत्रित होतो. कॉन्टेक्स्ट विंडो (context window) ॲडजस्ट करणे—मॉडेलला प्रॉम्प्टचा किती भाग दिसतो—यामुळे टोकनचा वापर अधिक कमी होतो. जेव्हा मॉडेल ऑन-प्रिमाइसेस हार्डवेअरवर स्थानिक पातळीवर चालते, तेव्हा कोणताही डेटा संस्थेबाहेर जात नाही, ज्यामुळे कडक डेटा-प्रायव्हसी पॉलिसींचे पालन होते.
प्लॅटफॉर्म कुठे उत्कृष्ट आहे आणि कुठे अजूनही अडखळतो
Foreman यांत्रिक आणि स्पष्ट व्याप्ती असलेल्या कामांमध्ये उत्कृष्ट आहे:
- डॉक्युमेंट केलेला बग फिक्स करणे.
- गहाळ टेस्ट केसेस जोडणे.
- स्पष्टतेसाठी किंवा स्टाईलसाठी डॉक्युमेंटेशन अपडेट करणे.
या कामांसाठी स्पष्ट यश निकष असतात जे verifier स्वयंचलितपणे तपासू शकतो. उच्च-स्तरीय आर्किटेक्चरल रिडिझाइन किंवा अस्पष्ट फीचर वर्कमध्ये ही प्रणाली अजूनही संघर्ष करते, जिथे “अचूकता” मानवी निर्णयावर अवलंबून असते.
निष्कर्ष
LLM-चालित कोडरला 'फर्स्ट-क्लास' Kubernetes रिसोर्सेस म्हणून मानून आणि एक डिटरमिनिस्टिक व्हेरिफिकेशन स्टेप लागू करून, Foreman प्रॉडक्शन AI कोड जनरेशनसाठी एक व्यावहारिक मार्ग प्रदान करते, ज्यामुळे खर्च दृश्यमान राहतो आणि सुरक्षा नियंत्रणात राहते. हे सर्व डेव्हलपमेंट कामांसाठी रामबाण उपाय नाही, परंतु पुनरावृत्ती करण्यायोग्य आणि टेस्ट करण्यायोग्य कामांसाठी ते एक ऑडिट करण्यायोग्य वर्कफ्लो प्रदान करते जो विद्यमान क्लाउड-नेटिव्ह ऑपरेशन्समध्ये नैसर्गिकरित्या बसतो.