पहले मैं इस विचार को जानबूझकर provocative तरीके से कहता था: Codex के लिए TypeScript सबसे अच्छा language है। अब मैं इसे अधिक सटीक तरीके से कहूँगा। मैं जिस तरह का production frontend और full-stack development करता हूँ, उसमें TypeScript वह environment है जहाँ Codex को control, verify और भरोसे के साथ use करना सबसे आसान लगता है।
यहाँ असली शब्द “TypeScript” नहीं, बल्कि control है। AI coding agents plausible code बनाने में बहुत अच्छे हैं। Production engineering को इससे अधिक चाहिए: code existing contracts का पालन करे, behavior न तोड़े, refactor survive करे और गलत assumption पर जल्दी fail हो। Plain JavaScript की तुलना में TypeScript इन constraints का बड़ा हिस्सा machine-readable बना देता है।
Codex को codebase से वास्तव में क्या चाहिए
अच्छा prompt मदद करता है, लेकिन context का केवल एक हिस्सा है। Codebase खुद task को स्पष्ट कर सकता है या model को guess करने पर मजबूर कर सकता है। सबसे मजबूत environment वह है जहाँ महत्वपूर्ण assumptions दिखाई देते हैं और automatically check होते हैं।
- Function signatures valid input और output define करते हैं।
- Interfaces और types domain objects का shape स्पष्ट करते हैं।
- Unions और enums valid states को सीमित करते हैं।
- Compiler edit के तुरंत बाद कई गलत assumptions को concrete errors में बदल देता है।
अगर contract टूटते ही codebase खुद प्रतिक्रिया देता है, तो AI agent को पूरी application perfect तरीके से समझना जरूरी नहीं। Feedback loop जितना छोटा होगा, confident guessing की जगह उतनी कम होगी।
Types सिर्फ documentation नहीं, executable context हैं
अच्छा TypeScript इंसानों को intent समझाता है। Automated workflow में इसकी अतिरिक्त value है: वह documentation machine से verify हो सकती है। उदाहरण:
type PaymentResult =
| { ok: true; receiptId: string }
| { ok: false; code: "declined" | "timeout" };
function getReceiptId(result: PaymentResult) {
if (result.ok) return result.receiptId;
return result.receiptId;
// TypeScript: Property 'receiptId' does not exist
// on the failure branch.
}JavaScript में यही गलती उस branch के runtime पर चलने तक reasonable लग सकती है। TypeScript merge से पहले assumption reject कर सकता है। Codex के लिए compiler error सिर्फ editor की red line नहीं, बल्कि यह संकेत है कि model ने क्या गलत समझा।
इसीलिए मैं Record<string, any> जैसी broad structure की बजाय explicit domain types पसंद करता हूँ। Types reality को जितना सही describe करते हैं, codebase developer और AI दोनों के लिए उतना बेहतर context बनता है।
Compiler गलतियों को feedback loop में बदलता है
मैं “Codex से code माँगो और पहला answer accept कर लो” workflow पर भरोसा नहीं करता। Reliable process iterative है:
task → inspect → edit → typecheck → lint → test → review diffयह sequence boring है, और यही इसकी ताकत है। हर meaningful change के बाद environment जवाब देता है। Type errors broken contracts पकड़ते हैं, lint दूसरी problems पकड़ता है, tests उस behavior को validate करते हैं जिसे types express नहीं कर सकते, और final diff अभी भी human review से गुजरता है।
Smart prompt पहला attempt बेहतर कर सकता है। Strong verification loop हर attempt बेहतर करता है। Production में यह ज्यादा महत्वपूर्ण है।
बड़े refactor में TypeScript की value सबसे अधिक दिखती है
Small isolated edit लगभग हर coding assistant के लिए आसान है। मुश्किल तब होती है जब change दर्जनों files में फैलता है: domain field rename, API response बदलना, component props tighten करना, union split करना या पुरानी abstraction replace करना।
TypeScript में breaking change affected assumptions का map बनाता है। Compiler दिखाता है कि पुराना contract कहाँ अभी भी use हो रहा है। Codex उस list पर काम कर सकता है और हर pass के बाद validation फिर चल सकती है। इससे refactor automatically correct नहीं होता, लेकिन blast radius दिखने लगता है।
TypeScript कहाँ नहीं बचाता
TypeScript guardrail है, correctness proof नहीं।
- गलत business logic: perfectly typed code फिर भी गलत calculation कर सकता है।
- Runtime data: API, database, form या third-party service compile-time assumptions से अलग data दे सकते हैं।
- Missing product context: compiler नहीं जानता कि कोई flow क्यों मौजूद है या कौन-सा edge case user के लिए महत्वपूर्ण है।
- Security और architecture: valid types सही authorization, caching, database boundaries या infrastructure guarantee नहीं करते।
इसलिए runtime validation, tests, logging, observability और review जरूरी हैं। Clean typecheck का मतलब correct feature नहीं है।
AI-assisted changes के लिए मेरा workflow
- Goal narrow रखता हूँ। क्या बदलना है, क्या नहीं और acceptance criteria क्या हैं।
- Edit से पहले Codex से inspect कराता हूँ। Existing types, call sites, tests और nearby modules अक्सर long prompt से ज्यादा useful होते हैं।
- Smallest coherent change चुनता हूँ। Focused diff unrelated rewrite से आसान verify होता है।
- तुरंत typecheck और lint चलाता हूँ। Structural errors change छोटा रहते ही सामने आ जाएँ।
- Relevant tests चलाता हूँ और behavior बदले तो tests जोड़ता हूँ। Types contracts validate करते हैं, tests behavior।
- Final diff खुद review करता हूँ। Naming, architecture, duplication, edge cases और original problem सच में solve हुआ या नहीं।
कब JavaScript अभी भी पर्याप्त है
यह JavaScript के खिलाफ argument नहीं है। Small script, disposable prototype, simple automation या बहुत कम shared state वाले code में TypeScript की अतिरिक्त structure का लाभ छोटा हो सकता है। Strong tests और clear conventions वाला JavaScript project भी AI के लिए अच्छा environment हो सकता है।
मेरा claim सीमित है: codebase जितना बड़ा, long-lived और collaborative होता है, machine-checkable constraints की value उतनी बढ़ती है। और इसी stage पर AI mistakes महंगी भी होती हैं।
Codex के साथ TypeScript पसंद करने का असली कारण
TypeScript Codex को smarter नहीं बनाता। वह environment को bad assumptions के प्रति कम tolerant बनाता है।
Production में मुझे सिर्फ creative agent नहीं चाहिए; मुझे ऐसा agent चाहिए जो ऐसे system में काम करे जो गलत होने पर लगातार feedback दे। Types, compiler errors, lint, tests और human review मिलकर यह system बनाते हैं।
इसलिए TypeScript + Codex की बात language fandom नहीं है। यह fast, machine-checkable feedback की बात है: कम ambiguity, छोटा blast radius, safer refactors और verification को गंभीरता से लेने पर अधिक reliable engineering speed।