NambaAI - Codex कार्यों को SPEC, validation और PR handoff flow में व्यवस्थित करने वाला CLI टूल

Codex का उपयोग करते समय अस्पष्ट अनुरोधों का सीधे code changes में बदल जाना असुविधाजनक लगा, इसलिए मैं इसे अधिक संरचित development process में व्यवस्थित करने वाला एक CLI टूल बना रहा हूँ.

NambaAI, Codex को replace करने वाला टूल नहीं है; यह Codex के आसपास काम करने वाली workflow layer के अधिक करीब है.

मूल विचार इस प्रकार है.

request → SPEC → execution → validation → PR handoff

यानी, user के अनुरोध को सीधे implementation में भेजने के बजाय पहले goal, scope, constraints और acceptance criteria को व्यवस्थित किया जाए, उसे SPEC file के रूप में छोड़ा जाए, और फिर काम आगे बढ़े—यह टूल उसी में मदद करता है.

फिलहाल यह मुख्य रूप से निम्न flow पर केंद्रित है.

namba project
namba plan "작업 요청"
namba run SPEC-XXX
namba sync
namba pr
namba land

कई SPEC को क्रम से प्रोसेस करने के लिए queue flow पर भी प्रयोग किया जा रहा है.

यह टूल बनाने की वजह यह थी कि AI coding जितनी सुविधाजनक होती जा रही है, उतनी ही बार change process का trace खो जाता है, या बाद में यह देखना कठिन हो जाता है कि implementation किस आधार पर किया गया था. खासकर Codex का बार-बार उपयोग करते समय मुझे लगा कि “क्या करने का तय हुआ था”, “scope कहाँ तक था”, “validation कैसे किया गया”, और “PR में क्या देखना चाहिए” जैसी बातें धुंधली हो सकती हैं.

NambaAI इस समस्या को निम्न तरीकों से कम करने की कोशिश है.

• काम शुरू करने से पहले goal और scope को पहले व्यवस्थित करना
• implementation से पहले SPEC file बनाना
• execution result और validation evidence को दर्ज करना
• PR handoff document बनाना
• Codex द्वारा किए गए changes को इस तरह व्यवस्थित करना कि इंसान के लिए review करना आसान हो
• one-off prompt के बजाय इसे दोहराए जा सकने वाले development process के रूप में manage करना

यह मौजूदा AI agent framework की तरह किसी general-purpose autonomous agent को बनाने की दिशा नहीं है. फिलहाल focus Codex को केंद्र में रखकर काम को ऐसे units में बाँटने और दर्ज करने पर है जिन्हें developer review कर सके.

अभी यह शुरुआती चरण में है, इसलिए कई कमियाँ भी हैं.

• वास्तविक usage examples की कमी
• onboarding documents में सुधार की आवश्यकता
• eval pack की कमी
• installer/hook security review की आवश्यकता
• macOS, Linux, Windows पर cross-testing की आवश्यकता
• मौजूदा AI coding harness के साथ तुलना की कमी
• वास्तविक projects में validation की कमी

यह मेरा खुद बनाया हुआ शुरुआती open source project है, और अभी इसे एक highly polished product से अधिक direction को validate करने वाले चरण के रूप में देखना चाहिए.

जो लोग Codex का उपयोग practical work या personal projects में कर रहे हैं, उनसे खास तौर पर नीचे दिए गए बिंदुओं पर feedback चाहूँगा.

1. क्या ऐसा SPEC-based Codex workflow वास्तविक development process में उपयोगी लगता है
2. कौन-से हिस्से over-engineered लगते हैं
3. इसे वास्तविक project में लागू करने के लिए और कौन-से trust mechanisms की ज़रूरत होगी
4. तुलना के लिए कौन-से मौजूदा tools या patterns देखने लायक हैं
5. installation/use flow में कौन-से हिस्से असुविधाजनक या जोखिमपूर्ण लगते हैं

आलोचनात्मक राय भी स्वागतयोग्य है. यह अभी शुरुआती चरण में है, इसलिए इस समय प्रशंसा से अधिक यह जानना मददगार होगा कि वास्तव में इसकी कमज़ोरियाँ कहाँ हैं.

[namcher9428]

इसे CLI को लक्ष्य बनाकर बनाया था, लेकिन मैं इन दिनों इसे codex desktop में इस्तेमाल कर रहा हूँ! मुझे चिंता थी कि कहीं Codex desktop के built-in harness के साथ टकराव न हो, लेकिन राहत की बात है कि compatibility बहुत स्मूथ है haha

इसके अलावा इस बार के 0.131.0 codex update की बातें भी reflect करनी हैं, और क्योंकि मैं harness के लिए सिर्फ यही इस्तेमाल कर रहा हूँ, इसलिए इसकी कमियाँ भी लगातार दिखती रहती हैं, लेकिन सबसे ज़्यादा कमी तो मेरे समय और ऊर्जा की है...