CodeSpeak - Kotlin के निर्माता की नई भाषा: अंग्रेज़ी की जगह spec से LLM के साथ बातचीत

(codespeak.dev)

42 पॉइंट द्वारा GN⁺ 2026-03-14 | 4 टिप्पणियां | WhatsApp पर शेयर करें

यह LLM पर आधारित अगली पीढ़ी की प्रोग्रामिंग भाषा है, जो कोडबेस को 5~10 गुना छोटा कर सकती है
डेवलपर कोड की जगह संक्षिप्त spec लिखते हैं, और codespeak build कमांड से कोड अपने-आप जनरेट हो जाता है
spec बदलने पर सिस्टम spec diff को code diff में बदलकर लागू करता है
मैन्युअल कोड और जनरेटेड कोड के मिश्रित प्रोजेक्ट भी सपोर्ट करता है, और वास्तविक open source उदाहरणों में test pass rate में सुधार देखा गया है
यह जटिल software पर काम करने वाली टीम-आधारित engineering पर फोकस करता है, और spec-केंद्रित maintenance के ज़रिए मानव-अनुकूल development environment को लक्ष्य बनाता है

CodeSpeak का अवलोकन

CodeSpeak एक LLM-संचालित अगली पीढ़ी की प्रोग्रामिंग भाषा है, जिसका लक्ष्य कोडबेस को 5~10 गुना कम करना है
- साइट के विवरण के अनुसार, “Shrink your codebase 5–10x” वाक्य के ज़रिए इसकी दक्षता पर ज़ोर दिया गया है
यह भाषा production-grade systems बनाने के लिए एक टूल है, और सिर्फ साधारण prototype नहीं बल्कि लंबे समय के प्रोजेक्ट के लिए डिज़ाइन की गई है
इसके मुख्य उपयोगकर्ता जटिल software विकसित करने वाली engineering teams हैं; यह व्यक्तिगत डेवलपर-केंद्रित प्रयोगात्मक coding के बजाय collaboration-केंद्रित development को लक्ष्य बनाता है

spec-आधारित development तरीका

CodeSpeak का मूल दर्शन है “Maintain Specs, Not Code”
- डेवलपर संक्षिप्त spec लिखते हैं, और codespeak build कमांड से कोड अपने-आप जनरेट हो जाता है
- spec में बदलाव होने पर सिस्टम spec का diff अपने-आप code diff में बदल देता है
यह approach इस बात पर ज़ोर देती है कि कोड की तुलना में spec को maintain और manage करना इंसानों के लिए अधिक आसान है

मिश्रित प्रोजेक्ट सपोर्ट

CodeSpeak ऐसे प्रोजेक्ट्स को सपोर्ट करता है जहाँ मौजूदा मैन्युअल कोड और जनरेटेड कोड साथ-साथ मौजूद हों
- उदाहरण के तौर पर Microsoft के MarkItDown repository को fork करने का मामला दिखाया गया है
- मिश्रित प्रोजेक्ट्स को चरण-दर-चरण संभालने के लिए tutorial guide उपलब्ध है

code → spec रूपांतरण फीचर (जल्द)

CodeSpeak मौजूदा कोड का विश्लेषण करके उसे spec में बदलने वाले फीचर पर काम कर रहा है
- इसके ज़रिए मौजूदा कोड के कुछ हिस्सों को 5~10 गुना छोटे spec से बदला जा सकता है
- यह फिर से रेखांकित करता है कि spec maintenance, कोड maintenance की तुलना में ज़्यादा मानव-अनुकूल है

वास्तविक case studies

CodeSpeak ने कई open source project codebases को spec में बदलकर टेस्ट किया है
- yt-dlp का WebVTT subtitle support: 255 LOC → 38 LOC, 6.7 गुना कमी, 37 tests जोड़े गए
- Faker का Italian SSN generator: 165 LOC → 21 LOC, 7.9 गुना कमी, 13 tests जोड़े गए
- beautifulsoup4 का encoding auto-detection: 826 LOC → 141 LOC, 5.9 गुना कमी, 25 tests जोड़े गए
- markitdown का EML→Markdown converter: 139 LOC → 14 LOC, 9.9 गुना कमी, 27 tests जोड़े गए
हर case में test pass rate बना रहा या बेहतर हुआ, जो spec-आधारित approach की व्यावहारिक उपयोगिता दिखाता है

सारांश

CodeSpeak एक spec-केंद्रित AI प्रोग्रामिंग भाषा है, जो automatic code generation और maintenance efficiency को जोड़ती है
LLM-आधारित code generation, spec-code synchronization, और mixed project support इसकी मुख्य विशेषताएँ हैं
वास्तविक उदाहरणों में code reduction और बेहतर testing साबित होने से, यह टीम-आधारित software engineering productivity बढ़ाने की संभावना दिखाता है

4 टिप्पणियां

roxie 2026-03-21

इसे भाषा कहना बस attention खींचने के लिए है, या सच में ऐसा ज़माना आ गया है।

brainer 2026-03-14

जैसा कि Joel Spolsky ने Yale University के एक व्याख्यान में कहा था, ‘spec से program generate’ करने की कोशिशें हमेशा विफल रही हैं
अगर spec इतनी विस्तृत हो कि वह program को पूरी तरह परिभाषित कर दे, तो उस spec को लिखना अपने-आप में program लिखने जितना ही कठिन काम होगा

मैं सिद्धांततः इससे सहमत हूँ, लेकिन यह आलोचना कुछ ऐसी लगती है जैसे शुरू से ही यह मानकर कोशिश की आलोचना की जा रही हो कि कोई पूर्ण product मौजूद होगा—जबकि स्वाभाविक रूप से, Gödel के प्रमाण की तरह, शुरू से ही पूर्णता जैसी कोई चीज़ नहीं होती।

halfenif 2026-03-14

यह MDD(Model Driven Dev.) की याद दिलाता है।

GN⁺ 2026-03-14

Hacker News की राय

जैसा Joel Spolsky ने Yale के एक व्याख्यान में कहा था, ‘spec से program generate’ करने की कोशिशें हमेशा विफल रही हैं
अगर spec इतनी विस्तृत हो कि वह program को पूरी तरह परिभाषित कर दे, तो उस spec को लिखना खुद program लिखने जितना ही कठिन हो जाता है
मूल व्याख्यान लिंक
- 2007 का ‘spec-based code generation’ और आज का मतलब पूरी तरह अलग है
  अब अपूर्ण prompts से भी program generate किया जा सकता है, और prompts को व्यवस्थित रूप से संभालने पर शोध को मूल्यवान माना जा सकता है
- अब code धीरे-धीरे असंरचित (amorphous) होता जा रहा है
  scalability अब features जोड़ने से ज़्यादा behavior constraints और structural invariants को परिभाषित करने की दिशा में जा रही है
- कंपनी में अक्सर लोगों को प्रक्रियात्मक ढंग से लिखते देखता हूँ
  जैसे “1. user से जानकारी लो, 2. HTTP request भेजो, 3. error आए तो report करो”,
  लेकिन ऐसे में मुझे लगता है कि सीधा script लिखना कहीं तेज़ और deterministic है
- AI से पहले के दौर के Joel ने जिस समाधान के बारे में नहीं सोचा था: spec की व्याख्या करने के लिए ‘मन का crystal’ बना लिया जाए — ऐसा मज़ाक किया गया
यह कोई नई language नहीं, बल्कि LLM-based development के लिए workflow और tooling है
code की जगह Markdown spec files maintain की जाती हैं, और codespeak spec diff के आधार पर code बदलता है
फ़ायदा यह है कि prompts code के साथ version control में रहते हैं, और नुकसान यह कि spec code की हर detail को reflect नहीं कर पाती
- यह तुलना भी जोड़ी गई कि C language भी आख़िरकार assembly development का वैकल्पिक workflow ही थी
- अंततः दुनिया शायद वहाँ जाएगी जहाँ इंसानों को code सीधे छूने की ज़रूरत नहीं होगी, लेकिन अभी वह समय नहीं है
  codespeak takeover नाम के tool से code को spec में बदलने और agent session के prompts को reflect कराने पर प्रयोग हो रहा है
  इसे short-term ‘sprint mode’ से long-term ‘marathon mode’ में बदलाव की अवधारणा के रूप में समझाया गया है
  संबंधित ब्लॉग लिंक
- इसे business के रूप में चलाने की कोशिश अव्यावहारिक लगती है
  idea इतना सरल है कि कोई भी इसे जल्दी दोबारा बना सकता है, और open source version जल्द ही इसकी जगह ले लेगा — ऐसा अनुमान है
- अगर छोटे code fixes, जैसे off-by-one bug, के लिए भी spec बदलनी पड़े तो यह inefficent होगा
  ‘छोटे बदलाव’ की अनुमति देने वाली policy की ज़रूरत बताई गई
  कुल मिलाकर incremental pseudocode compiler का विचार दिलचस्प लगा
- यह बहुत ज़्यादा formal लगता है
  5 साल बाद शायद लोग इस तरह code नहीं लिखेंगे; English-level technical spec ही काफ़ी होगी
यह approach language से ज़्यादा spec को code से map करने वाली tooling है
लेकिन model nondeterministic है, इसलिए एक ही spec से हर बार अलग result आ सकता है
spec मूल रूप से बहुत information loss वाला summary है, इसलिए बड़े codebase में consistency बनाए रखना मुश्किल है
मैं जो देखना चाहता हूँ, वह text spec → formal spec → code तक जाने वाली एक verifiable pipeline है
- इस पर प्रतिवाद है कि अगर result हमेशा तार्किक रूप से सही हो, तो code अलग होने से फ़र्क नहीं पड़ता
  अहम बात code खुद नहीं, बल्कि behavioral outcomes की consistency है
- लेकिन formal spec भी हर बार अलग हो सकती है
  spec जितनी abstract होगी, उतनी तरह की implementations संभव होंगी, इसलिए determinism फिर भी सुनिश्चित नहीं होता
- मैं AGENTS.md, DESIGN.md, TECHNICAL-SPEC.md बनाकर अनौपचारिक spec-based development करता हूँ
  मेरा मानना है कि automated tests को ही असली spec की भूमिका निभानी चाहिए
- model के nondeterministic होने के दावे पर सवाल उठाया गया
  seed fix करने पर एक ही input से वही output मिल सकता है — ऐसा माना गया
- मैं Kiro IDE को spec generator की तरह इस्तेमाल करता हूँ
  Cursor और Antigravity इंसान-केंद्रित ‘vibe coding’ के लिए optimized हैं, लेकिन Kiro agent-centric spec-based development के लिए विशेष है
  यह EARS, INCOSE जैसे structured formats इस्तेमाल करता है, और automatic consistency checks तथा property-based testing (PBT) generate करता है
  अगर spec मज़बूत हो, तो implementation लगभग अपने-आप पीछे आ जाती है
  कई CLI agents को parallel चलाकर उच्च गुणवत्ता वाले results मिल रहे हैं
formal prompt language की समस्या ambiguity नहीं, बल्कि model की context समझने की कमी है
एक ही prompt context के हिसाब से अलग results दे सकता है
prompt को formal बना देने से भी कोई फ़ायदा नहीं, अगर model codebase को ही ग़लत समझे
- अक्सर दो सलाहें सुनने को मिलती हैं
  1. नियमित रूप से context reset करो
  2. agent को Unix-style tools दो, ताकि वह सरल pseudo-English commands से interact कर सके
    क्योंकि model conversational language के लिए optimized है, इसलिए formal language सीधे लिखने के बजाय ज़रूरत पड़ने पर ही उसका उपयोग बेहतर माना जाता है
बस यह इच्छा जताई गई कि काश deterministic और formal तरीके से computer को अपनी intent बताना संभव होता
यह concept LLM की internal structure को ग़लत समझने वाली premise से शुरू होता है
हाल की research के अनुसार LLM में encoding और decoding के बीच एक अलग processing stage मौजूद होती है,
और training के बाद language खुद उतनी महत्वपूर्ण न भी रहे
संबंधित शोध लिंक
- CodeSpeak LLM के लिए नहीं, बल्कि इंसानों के लिए structured tool है
  इसका उद्देश्य इंसानों को अपनी ज़रूरत साफ़ तौर पर व्यक्त करने में मदद करना है
समझ नहीं आता कि ऐसे tool की ज़रूरत ही क्यों है
बस Markdown spec सीधे लिखो, और agent से code generate करने को कहो — इतना काफ़ी है
tutorial के “Prerequisites” में Anthropic API key की ज़रूरत बताई गई है
alpha version होने के कारण यह अस्थायी व्यवस्था हो सकती है, लेकिन फिर भी सवाल है कि API की ज़रूरत क्यों है
Claude Code जैसी session में सीधे prompt inject करना भी पर्याप्त लग सकता है
संदर्भ लिंक
यह project मेरे चल रहे LLM executor language spec से काफ़ी मिलता-जुलता है, इसलिए दिलचस्प लगा
मेरा project AIL YAML-based तरीके से prompt chains को define और execute करता है
इसका मुख्य बिंदु ‘prompt refinement engine’ है, जो user की natural language को structured commands में बदलता है
उदाहरण के लिए, यह user intent का analysis करके उसे चरणों में बाँटता है और modern prompt engineering standards के मुताबिक optimize करता है
अगर ऐसा interceptor हो, तो “मैंने अभी जो कहा उसे CodeSpeak format में बदल दो” जैसा flow संभव होगा
यह सच में शानदार idea है, और मैं इसे ज़रूर गहराई से explore करना चाहूँगा