lx: डेवलपर के पूर्ण नियंत्रण में रहने वाला vibe coding टूल

परिचय

नमस्ते। मैं कंप्यूटर इंजीनियरिंग में रुचि रखने वाला एक छात्र हूँ। इस बार मैंने lx नाम का एक प्रोग्राम विकसित किया है, और GeekNews पर, जहाँ अब तक मैं सिर्फ़ पढ़ता था, पहली बार पोस्ट करना चाहता हूँ।

हाल के दिनों में AI को प्राकृतिक भाषा में निर्देश देने पर वह अपने-आप पूरा कोड लिख दे—ऐसा vibe coding काफ़ी लोकप्रिय हो गया है।
मुझे इस तरह का vibe coding डरावना लगता है।
यह सिर्फ़ बेरोज़गारी का डर नहीं है, बल्कि "कोड लिखने का आनंद (Wrangling code) (स्रोत: Kent Beck - Augmented Coding: Beyond the Vibes)" और "डेवलपर का नियंत्रण" छिन जाने से पैदा होने वाली प्रोग्रामिंग की हानि की भावना है।

कुछ लोग इस बदलाव को पंच कार्ड से machine language, assembly language, और C language तक पहुँची प्रोग्रामिंग की स्वाभाविक प्रगति बताते हैं। लेकिन मुझे लगता है कि यह उपमा ग़लत है।
अतीत की abstraction दरअसल डेवलपर के हाथ में 'एक बेहतर हथौड़ा' देने की प्रक्रिया थी।
टूल लगातार बेहतर होते गए, लेकिन हथौड़ा चलाने वाला अब भी इंसान ही था, और परिणाम पूरी तरह डेवलपर के नियंत्रण में रहता था।
लेकिन आज का AI coding अलग है।
अब रोबोट हथौड़ा चला रहा है, और डेवलपर बस देखता रह जाता है, या ज़्यादा से ज़्यादा रोबोट को थोड़ा मनाने की स्थिति में होता है।
अगर हम खुद हथौड़ा नहीं चला सकते, तो मेरे विचार में उसे अब प्रोग्रामिंग नहीं कहा जा सकता।
क्योंकि वह पूरी तरह हमारे नियंत्रण में नहीं है।

इसीलिए मैंने lx बनाया।
lx ऐसा टूल है जो रोबोट के हाथ से हथौड़ा वापस लेकर डेवलपर के हाथ में देता है।
lx AI को एक ऐसे टूल की तरह इस्तेमाल करने देता है जिसे पूरी तरह नियंत्रित किया जा सके।

मुख्य भाग

lx की फ़िलॉसफ़ी है: "इंटरफ़ेस इंसान का, लॉजिक AI का"।
डेवलपर फ़ंक्शन के input/output और उसका काम परिभाषित करके एक 'contract' बनाता है, और AI सिर्फ़ उस फ़ंक्शन के अंदरूनी implementation की ज़िम्मेदारी लेता है।

यह तरीका development की continuity सुनिश्चित करता है।
जैसे ही फ़ंक्शन का input/output लिखा जाता है, उस लॉजिक को पहले से पूरा माना जा सकता है।
प्रोग्रामर बारीक implementation में फँसे बिना तुरंत ऊपरी स्तर का लॉजिक लिख सकता है और development flow को बिना रुकावट जारी रख सकता है।

साथ ही, lx सिर्फ़ साधारण text replacement नहीं है। github.com/tree-sitter/go-tree-sitter पैकेज का उपयोग करके यह AST (Abstract Syntax Tree) आधारित source code parsing करता है। इसलिए यह फ़ाइल के भीतर दूसरे कोड, comments, या indentation को दूषित नहीं करता, और केवल निर्दिष्ट scope के लॉजिक को सुरक्षित रूप से बदलता है।

बुनियादी उपयोग

lx का बुनियादी उपयोग इस प्रकार है।

package main  
  
import (  
	"fmt"  
  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
    // डेवलपर फ़ंक्शन कॉल और flow को नियंत्रित करता है.  
	result1 := LX_GetYear(year)  
  
	var age = 30  
	result2 := LX_GetAge(age)  
  
	fmt.Println(result1, result2)  
}  
  
func LX_GetYear(year string) (result string) {  
	// AI को भेजा जाने वाला prompt  
	lx.Generate("yyyy-dd-mm hyungsigeul Hanguksik naljja-ro byeonhwan")  
	return  
}  
  
func LX_GetAge(year int) (result string) {  
	// प्रोग्रामिंग भाषा के अनुसार अलग से lx लाइब्रेरी इंस्टॉल करना झंझट लगे, इसलिए नीचे की तरह lx() comment marker फ़ॉर्म भी समर्थित है.  
    // lx("Hanguksik naireul man nai-ro byeonhwan")  
	return  
}  

ऊपर के कोड में LX_GetYear फ़ंक्शन डेवलपर द्वारा परिभाषित contract है।
जब lx टूल चलाया जाता है, तो यह lx.Generate(...) या // lx(...) marker को पहचानकर LLM को prompt भेजता है, और उस फ़ंक्शन के body को वास्तविक काम करने वाले कोड से overwrite कर देता है।

इस दौरान token optimization लागू होती है। पूरी फ़ाइल भेजने के बजाय, केवल उस फ़ंक्शन का signature और prompt ही LLM को भेजा जाता है, जिससे लागत कम होती है और सुरक्षा बेहतर होती है।

2. डेवलपर का नियंत्रण

lx फ़ंक्शन के अंदर का लॉजिक AI लिखता है, लेकिन उस फ़ंक्शन का उपयोग करने वाला पक्ष डेवलपर ही होना चाहिए।
लेकिन lx फ़ंक्शन के भीतर user-defined logic मिलाने पर उसे अनदेखा कर दिया जाता है, इसलिए नीचे की तरह wrapper फ़ंक्शन के ज़रिए नियंत्रण रखा जा सकता है।

package test  
  
import (  
	"fmt"  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
	result1 := ParseYear(year) // wrapper फ़ंक्शन कॉल  
  
	fmt.Println(result1)  
}  
  
// डेवलपर द्वारा नियंत्रित business logic  
func ParseYear(year string) string {  
    // AI से बने लॉजिक को एक component की तरह इस्तेमाल करें  
	res := LX_GetYear(year)  
    
    // परिणाम पर अतिरिक्त processing डेवलपर का काम है  
	foo := fmt.Sprintf("oneureun %v imnida!", res)  
	return foo  
}  
  
func LX_GetYear(year string) (result string) {  
	lx.Generate("yyyy-dd-mm hyungsigeul Hanguksik naljja-ro byeonhwan")  
	return  
}  

3. सुरक्षित dependency management और transparency

lx single responsibility principle (SRP) को लक्ष्य बनाता है।
यह केवल कोड generate करता है; प्रोग्राम को build या run नहीं करता।
साथ ही, यदि AI द्वारा बनाए गए कोड को external library की ज़रूरत हो, तो lx मनमाने ढंग से package install नहीं करता।

1. Code: generated code के शीर्ष पर // lx-dep: ... comment दर्ज

2. Output: CLI standard output में required install list की report

इसके बजाय, यह इन दो तरीकों से डेवलपर को सूचित करता है।
डेवलपर इसे देखकर तय कर सकता है कि dependency ख़ुद install करनी है या नहीं।

4. सेटिंग

lx का उपयोग करने के लिए LLM configuration आवश्यक है। होम directory(~/) या project root(./) में lx-config.yaml बनाया जा सकता है। यदि दोनों paths पर फ़ाइल मौजूद हो, तो local configuration file को प्राथमिकता दी जाती है, इसलिए हर project के लिए अलग-अलग lx settings प्रबंधित की जा सकती हैं।

# lx-config.yaml  
provider: "gemini"  
api_key: "foo"  
model: "bar"  

5. इंस्टॉलेशन और चलाना

Mac उपयोगकर्ता Homebrew के माध्यम से इसे install कर सकते हैं, और अन्य OS के लिए lx GitHub Releases से binary डाउनलोड करके install किया जा सकता है।

brew tap chebread/lx  
brew install lx  

install करने के बाद project path में lx कमांड चलाने पर वास्तविक कोड generate हो जाता है।
lx में smart generation फ़ीचर है, इसलिए जिन फ़ंक्शनों के लिए कोड पहले से generate हो चुका है, उनके लिए यह दोबारा LLM को कॉल नहीं करता; इस वजह से lx कमांड को निश्चिंत होकर बार-बार चलाया जा सकता है।

संदर्भ: lx generated code की formatting के लिए भाषा-विशिष्ट टूल्स (Go: goimports, Python: ruff, JS: prettier) का उपयोग करता है। ये टूल पहले से install होने चाहिए।

6. लाइसेंस

lx को AGPL-3.0 License के अंतर्गत वितरित किया जाता है।
इसका उद्देश्य यह है कि lx open source ecosystem में योगदान दे, लेकिन इस टूल का बंद रूप में निजीकरण न हो सके।

निष्कर्ष

सॉफ़्टवेयर मानव के निरंतर प्रयासों से बुना गया एक सघन परिणाम है। AI के युग में भी प्रोग्रामर को कोड का मालिक बने रहना चाहिए।
lx उबाऊ implementation जैसे झंझटी regex या data parsing का काम AI को सौंपते हुए भी, प्रोग्राम की संरचना और flow को पूरी तरह इंसान के हाथ में रहने देता है।
जो डेवलपर कोड लिखने का आनंद (Wrangling code) और नियंत्रण खोना नहीं चाहते, उन्हें मैं यह टूल सुझाता हूँ!

[moderator]

संचालन नीति के अनुसार अनुपयुक्त टिप्पणी हटा दी गई है, और संबंधित खाते के उपयोग पर प्रतिबंध लगा दिया गया है।

[callakrsos]

अब भी coding असल में इंसान-केंद्रित ही है
लगता है कि भविष्य में development ऐसी form में होगा जो अक्षम इंसान-केंद्रित भाषाओं के बजाय कुछ और होगी
अभी के लिए इंसान-केंद्रित frameworks का खूब आनंद लें

[galadbran]

यह काफ़ी दिलचस्प है क्योंकि यह आजकल के उस माहौल के बिल्कुल उलट तरीका अपनाता है जिसमें माना जाता है कि कोड को बिल्कुल न देखें तभी काम सही होता है.
चुनाव के अनुसार, इसे शायद सिर्फ़ इस एहसास के साथ भी इस्तेमाल किया जा सकता है कि AI किन हिस्सों को छुएगा, यह साफ़ तौर पर तय कर दिया जाए.
इसे coding agents की skills के रूप में बनाकर देखना भी काफ़ी ठीक हो सकता है, है न?

[chebread]

मैं इसे सक्रिय रूप से समीक्षा करूंगा। अगर आपकी रुचि है, तो कृपया बहुत सारे PR भेजें!

[narubrown]

यह एक दिलचस्प प्रोजेक्ट लगता है!

Ix spec लिखना -> Ix Tool से lx functions को असली functions में बदलना -> फिर go compile करना, ऐसा है।
lx का उपयोग करने वाली एक layer प्रोजेक्ट में बन जाएगी,
इससे LLM से लिखी गई layer को अलग किया जा सकेगा, इसलिए बाद में maintenance करते समय भी इसे आसानी से संभाला जा सकेगा।

लगता है कि यह LLM का उपयोग करने की एक रोचक कोशिश है!

[chebread]

धन्यवाद। lx Go भाषा के अलावा अन्य भाषाओं को भी सपोर्ट करता है, इसलिए कृपया इसका खूब उपयोग करें और अपनी सलाह दें!

[iknowca]

लक्ष्य दिलचस्प है, लेकिन पूरे मुख्य लेख में AI की विशिष्ट लेखन-शैली बहुत ज़्यादा महसूस होती है, इसलिए इस पर भरोसा करना मुश्किल है।

[chebread]

अच्छी बात उठाई आपने। मैं अभी हाई स्कूल का छात्र हूँ, इसलिए मेरे पास ज़्यादा समय नहीं होता। AI की मदद से लिखते-लिखते, लगता है लेख की विश्वसनीयता काफ़ी कम हो गई। थोड़ी असुविधा हो तो भी, कृपया समझने की कृपा करें।

[wegaia]

वाह, यह सचमुच कमाल की बात है कि एक हाई स्कूल छात्र ने ऐसा कुछ सोचा।
जैसे-जैसे अनुभव बढ़ेगा, लगता है वह और भी कमाल की चीज़ें बनाएगा।

[siabard]

मेरा मानना है कि lx.Generate को कॉल करने वाला कोड, जब command line से निर्देश दिए जाएँ, तो LLM द्वारा लिखे गए कोड में बदल जाने वाले तरीके से काम करेगा, सही है न?
कॉल करने वाला हिस्सा एक तरह की type constraint बन सकता है, यह अच्छा विचार लगता है। क्या आप यह भी सोच रहे हैं कि editor आदि में lx कमांड अपने-आप चले और implementation code को बदल दे? (साथ ही, अगर generated code पसंद न आए तो उसे दोबारा generate करने का कोई तरीका हो, तो अच्छा रहेगा।)
प्रोजेक्ट अच्छी तरह देखा।

[chebread]

क्या lx.Generate को कॉल करने वाला कोड, कमांड लाइन से कमांड देने पर LLM द्वारा लिखे गए कोड में बदल जाता है? -> जी हाँ, बिल्कुल सही!

जिस हिस्से से इसे कॉल किया जाता है, वह एक तरह का type constraint बन सकता है—यह अच्छी सोच लगती है। क्या आप इस तरह के तरीके पर भी विचार कर रहे हैं जिसमें editor आदि में lx कमांड अपने-आप चलकर implementation code को replace कर दे? -> यह वास्तव में बहुत अच्छा आइडिया लगता है। हम इसे गंभीरता से ध्यान में रखेंगे.

साथ ही, अगर generated code पसंद न आए तो उसे फिर से generate करने का कोई तरीका हो, तो अच्छा रहेगा। -> प्रोजेक्ट का दर्शन developer के नियंत्रण में AI रखना है, इसलिए अगर पुनर्जनन की ज़रूरत हो तो इसे इस तरह डिज़ाइन किया गया है कि lx marker फिर से बनाया जाए।

[maneuling]

किसी कम उम्र के हाई स्कूल छात्र ने बनाया है, यह देखकर जैसे-तैसे घुसकर ऐसा कमेंट छोड़ने का स्तर देखकर आपकी बुद्धि का स्तर समझ में आ जाता है.

आईने में देखिए और थोड़ा इलाज कराइए.

killdong | 9 महीने पहले | parent | on: मैं अपने सर्वर की सुरक्षा के लिए ZIP बम का उपयोग करता हूँ (idiallo.com)
मेरा मानना है कि अगर लोग इंटरनेट पर भी अपनी उगली हुई गंदगी की ज़िम्मेदारी नहीं लेते, तो उन्हें इंटरनेट इस्तेमाल करने से रोक देना चाहिए. जो उगला है, उसे थोड़ा साफ़ भी कीजिए.